Choosing to Implement Project Server

Choosing to implement Project Server is only appropriate for organizations that practice or are resolved to practice project management as a required discipline. I cite level-three maturity, as measured by the Carnegie Mellon University Software Engineering Institute (SEI) Capabilities Maturity Model (CMM) or the University of California, Berkeley Project Maturity Model (PMM, see http://www.ce.berkeley.edu/pmroi/assessing-PM-maturity.pdf) as a benchmark. To use the tool effectively, an organization is making a commitment to a manage-by-project discipline. At level three in these maturity models, project plans get created early in the project process and are kept current throughout planning and execution.

CMM and PMM

The Capabilities Maturity Model (CMM), developed by the Software Engineering Institute (SEI) of Carnegie Mellon University, describes best practices for organizations seeking to manage excellence in producing software. The University of California, Berkeley Project Maturity Model (PMM) echoes the CMM in its steps describing the project management activities and best practices that correspond to building capabilities maturity. Although originally conceived to drive excellence in software development, you can easily extend the CMM to other industries. The ubiquity of software development across all manner of business and its general influence on business management practices go a long way to support this.

The base levels of both models describe an organization that takes an ad-hoc approach to projects; often referred to as “hero-led project management.” Companies at this level regard project leaders as “project champions.” These terms, or similar expressions, are characteristic of the language spoken in level-one companies. Organizations introduce formal project management at level two, to govern the execution of project work. At level two, an organization makes a commitment to planning all projects. Project plans with work breakdown structures are characteristic of level-two organizations. Unfortunately, the organization may still be struggling with establishing regular update cycles. By the time an organization achieves level three, projects are not only planned, but they are also continuously updated and at any time reflect the current state of the project. Moving through level four, an organization gains the ability to use the data and feedback systems it has built to begin to shorten business cycles and make better project management decisions. Level five is best described as a state where best practice–style management becomes ingrained and autonomic in the enterprise.

Summarizing the characteristics of these models in two paragraphs is a substantial oversimplification. My point in referring to them is that organizations can objectively measure themselves against these accepted standards.

Because Project Server is, at its heart, a progress tracking system, an organization must be committed to tracking its projects before it can derive substantial value from it. Unless your group, division, or company is willing to declare this a requisite for doing business, you will end up repurposing the server in 6 months and shelving the Project Server software. This is not to say that you can’t use Project Server in a limited way to deliver business value, but an enterprise implementation of Project Server is overkill for anything less than this level of commitment. Project tracking is not an on-again, off-again practice; either you require it or you do not need to use a tracking tool.