EPM stands for Effort Project Management

In 1994 I wrote an article outlining a disturbing trend in project management systems deployments.  At the time, there was a significant movement away from large-scale project management systems to PC-based systems.  The movement had really started in the mid-80’s 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 70’s, I wrote, cost in the hundreds of thousands of dollars and clients thought it quite reasonable to spend that much again on training and configuration.  The problem was, the systems of the 90’s cost only a few thousand dollars or less and the general reaction of clients I met was to spend an equivalent amount of money on training comparative to the value of the software rather than the training that had always been required.

I bring up the subject because of the recent advances into the enterprise project management domain of Microsoft.  There is a newfound interest it seems in bringing the enterprise together to manage projects and Microsoft is at the very forefront of that interest.  With the release two years ago of Project Server 2002 and the release of Project Server 2003 last year, Microsoft delivered a product that can be deployed as a enterprise project system.  What’s fascinating about the release of this product into the marketplace is the way people are going about using it to deploy Enterprise Project Management.

First of all, there’s no question that the concept is desirable.  Virtually everywhere I go from the smallest to the largest organization, there is a need to bring project information together and to strive for making better decisions about projects across the organization rather than project-by-project.

The legacy that 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 to the individual.  In virtually all of Microsoft’s applications, the expectation is that you’ll be able to quickly install the product yourself, configure it immediately and then be able to start producing results instantly.  The Windows versions of Microsoft Project all held to those principles.

Now, along comes Project Server and the ability to work across all projects at once and to group projects by portfolio and to collaborate with team members and PMO personnel alike.  Sounds like a match made in heaven, yes? 

Sorry, no.

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 4 weeks of configuration work including mapping processes to Project and then another 3-4 weeks of training for the 200+ personnel involved in projects who would have access to the tool.  Of the total, only about 2 days were involved with installation.  The project manager was stunned.  “I had figured on 3 to 4 hours,” he replied.  “with maybe 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.

Maybe the solution to the problem is much simpler.  We should ask Microsoft just to add two zero’s to their project system pricing so we can take it more seriously.