Project Management Maturity Models (PMMMs), can be powerful tools for improving the performance of project teams and the businesses and customers they serve. Unfortunately, in my opinion, the way that most of the current PMMMs are designed and used, I don’t believe they’ll ever become the kind of day-to-day practical and value-added tool that Project Managers could really use. There are a number of good PMMM products out there, but it seems to me that they focus too much on project management at the institutional level. Certainly businesses must care about, and invest in, improving institutional processes, but in the mean time project teams are struggling in the trenches right now and could use some help.
For those not familiar with Maturity Models, or as they’re sometimes called Capability Maturity Models, check out this CMM overview in Wikipedia.
A typical Maturity Model employs a matrix architecture which identifies selected project management practices or attributes and maps them to a continuum of implementation maturity levels, using a 5-point scale like the one below, as described below in the CMM overview in Wikipedia.
1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
3. Defined – the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being Work Instructions).
4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
5. Optimizing – process management includes deliberate process optimization/improvement.
This clearly communicates that any attribute that is short of what is defined as fully mature or “optimized,” must be incomplete or inadequate. This prescriptive approach, in which only a score of 5 is acceptable, is both unrealistic and lacks practical value at the project team level. No two projects or the contexts, in which they execute, are the same. Some projects, because of their scale, complexity, criticality to the business, and/or the state of their customer relationship, must strive for the highest level of process maturity. For many other projects though…and I’d suggest maybe even the majority of other projects… going after level 5 maturity is not only unnecessary, but perhaps even counter-productive.

My interest in this blog is to explore some ideas and share some things I’ve learned about using maturity models at the project team tactical level that can improve performance, help solve problems and even support team-building.
• Higher Performance Takes Greater Resources. Each project management practice and tool can be tuned to run at a range of performance levels. Performance drives process complexity, and process complexity drives cost. The PM and project team, in collaboration with the project sponsor and customer must analyze the trade between PM practice performance and agree on the practice performance level that best meets the needs and means of the project. Level 5 might be, but isn’t always “best.”
• Pick the PM Practices and Tools That Are Most Important. There are a number of valuable project management practices and tools available for implementation on any project, but not all of them are equally important for your project and this stage of its life cycle. Again, the project team, collaborating with the sponsor and the customer, should select the minimum number of key practices and tools.
o The PM practice areas and tools usually at the top of my list are: Planning; Scheduling; Baseline Management; EVM; Risk Management; Supplier Management; Communication
• Use the Maturity Modeling Activity as an Alignment and Team-building. In applying whatever PMMM you’re using, it’s been my experience that there is great value in having the Project Manager and key team members each separately score the current and desired future states of maturity (performance) for each practice. Then when you summarize the scores, look for gaps and discuss them in a team meeting. Identifying and resolving gaps in perceived maturity levels between project team members, is often more important than deciding on the absolute value of maturity itself. This is especially true for perception and desirability gaps between the Project Managers and the project team members. Maturity Model gaps may reveal leadership disconnects that must be resolved through better objectives clarity and communication. They may also reveal unique and innovative perspectives that should be shared and leveraged. In either case, the resultant conversation can be critical for team building.
• Use the PMMM to Diagnose Project Performance Problems. Maturity Models can also be used by a project team, or a 3rd party assessor, to help diagnose and correct project performance problems. Missed objectives, poor EVM performance, and unhappy customers are always related to one or more project management practice performance problems. Maturity Models provide a forensic methodology to find the root cause and the enable investigators to separate the facts from the emotions.
So, whether you have an in-house project management maturity model or you’re using on the commercially available models, I encourage you to try and take them down to the project team level to see if the pass a tactical test-drive.