In 1994 in these very pages I wrote an article outlining a disturbing trend in project management systems deployments. At the time, there was a significant movement away from large project management systems to PC-based systems.
The movement had really started in the mid-’80s with the rapid
adoption of the PC as a work tool, but the release of Windows had spurred the sale of project management systems as never before. The original high-end project systems of the late ’70s, I wrote, cost in the hundreds of thousands of dollars, and companies thought it quite reasonable to spend that much again on training and configuration. The problem was the systems of the ’90s cost only a few thousand dollars or less, and companies wanted to spend an equivalent amount of money on training.
There is a newfound interest in bringing the enterprise together to manage projects and Microsoft is at the forefront of that interest. With the release of Project Server 2002/2003, Microsoft delivered a product that can be deployed as a enterprise project system.
There’s no question the concept is desirable. Virtually everywhere I go, there is a need to bring project information together across organizations.
The legacy Microsoft carries, however, isn’t helping it. Microsoft has become known in the application business as a company that provides low-cost project management software. In virtually all of Microsoft’s applications, the expectation is you’ll be able to quickly install the product and start producing results instantly. The Windows versions of Microsoft Project all held to those principles.
Along comes Project Server and the ability to work across all projects at once and to group projects by portfolio and collaborate with team members and project management office personnel alike. Sound like a match made in heaven?
It’s not. The issue is the same as in 1994. When considering the deployment of Project and Project Server, many clients bring their legacy of experience with Microsoft to the table. In a recent conversation with a very high-tech firm, I helped scope out a deployment plan that called for about four weeks of configuration work, including mapping processes to Project and then another three to four weeks of training for some 200 personnel involved in projects who would have access to the tool. Of the total, only about two days were involved with installation. The project manager was stunned.
“”I had figured on three to four hours,”” he said, “”with a day or so more of training.””
We’ve now seen numerous scenarios where an organization does a minimal EPM effort and ends up having to go back and do it again, this time with less credibility with management.
The need for configuration and training shouldn’t be a big surprise. When the same project managers are asked about any other major enterprise system such as ERP or CRM, they acknowledge the extensive effort that will be required to implement change. Perhaps it’s the shoemaker’s children going barefoot syndrome where project managers can’t seem to apply the same logic to their own systems.