Level 2: There is a standard methodology in place and Level 3: Documented Process that Everyone Uses have been the goals for all to achieve. Operating at Level 3 projects can be effectively executed and managed to produce the expected business value. That may be true, but its adoption statistics are disappointing. Mark Mullaly reports [Mullaly, 2017] that less than 2% of organizations have reached Level 3 or beyond. Based on Mullaly's data most organizations operate at Levels 1 and 2.
So, faced with the preponderance of Maturity Level 1 and two organizations how could CMMI adapt to maintain its relevance to Hybrid Project Management? This article answers that question.
THE HYBRID PROJECT WORLD
The Hybrid project landscape defines the types of projects that have challenged the project management community for nearly 30 years because the commercially available Project Management Life Cycle (PMLC) models do not align well with the constraints placed on these projects:
- the physical and behavioral characteristics of the project
- the cultural and organizational environment in which the project will be executed
- the changing market situation where the deliverables will compete
That lack of fit between the PMLC model and the project is reflected in 2/3 of the projects having failed or challenged. Hybrid Project Management has been below the radar for years. It is a fact of life, and the Capability Maturity Model Integrated (CMMI) has not yet responded and seems to be dismissed as irrelevant. That is not good for the long term. How can the CMMI reply?
THE DESIRED END STATE
The desired end state in a Hybrid Project Management (HPMgt) environment includes a vetted portfolio of tools, templates, and processes that can be used by a Hybrid Project Manager (HPMgr) to design and maintain the alignment of their project management approach to a specific project based on the three constraints listed above.
The success criteria for complex projects is the attainment of the expected business value that justified the approval of and resources to support the project. That success criteria will be one or more of the following metrics:
- Increased Revenue (IR)
- Avoidance of Cost (AC)
- Improved Service (IS)
The criteria are defined by the well-known acronym IRACIS.
The complex project landscape was not defined nor understood when the Capability Maturity Management Integration (CMMI) was introduced. That raises the question of its applicability to HPMgt and effective use to the HPMgr. Given the survey results reported by Mark Mulally, it doesn’t seem relevant. Hopefully, that is a temporary problem and can be solved with a meaningful revision.
CMMI Maturity Level Definitions for Hybrid Project Management
The Software Engineering Institute (SEI) at Carnegie Mellon University introduced the Capability Maturity Model (CMM) in 1987 and the CMMI in 2002. It has become the de facto standard for measuring the maturity of processes and the practice of those processes. But it may have reached its half-life. How might we define the maturity levels to align with HPMgt needs?
HPMgt Maturity Level 1: Ad Hoc or Informal
Basically, everyone is managing projects their own way – a Do It Yourself model. They may be using tools, templates, or processes that they developed, discovered, or borrowed and have been in their toolkits for years. There may be some common practices in the organization, but these are not fully documented or supported—just expected. I have often seen organizations provide a collection of templates as suggestions, not requirements. This may not be as a chaotic environment as you would expect. Give the HPMgr the credit for being intelligent enough to recognize the management tools, templates, and processes that they need and build them into their ad hoc approach.
HPMgt Maturity Level 2: Documented Processes
At Level 2 maturity, the tools, templates, and processes for managing projects have been defined and documented. Level 2 is an interesting level of maturity, not so much regarding what the documentation says, but how it was put in place. Obviously, the motivation for doing the documentation is that the organization expects its project teams to implement the documented processes. It is beyond the scope of this article to talk about how the documentation was created but let me say that if you expect someone to use your stuff, you had better give them an opportunity to participate in its development. Don’t risk the “not invented here syndrome.” This must be a team effort to have a chance at success.
Within the context of HPMgt Maturity Level 2, if the tools, templates, and processes have been vetted by the PSO and are a complete portfolio, then the HPMgt needs of the HPMgr would have been met. But that is just the beginning of the story. Given the unique needs of the project it is unlikely that an off-the-shelf tool, template or process can be aligned. In almost every case it will have to be adapted to the uniqueness of the project. Rules for that adaptation may be part of the documentation.
HPMgt Level 3: Documented Processes That Everyone Uses
Compliance to this extent is not a realistic objective. Uniqueness is the obstacle. Stop and think about it for a minute. Is it possible that the developer of any tool, template or process could have envisioned and met all possible variations? Not likely. At Level 3, documented tools, templates and processes are vetted, supported and maintained. Compliance comes in many forms. In the complex project, landscape compliance must allow the adaptation of a tool, template or process to provide the best fit of the HPMgt process to the three constraints on the project. This is far more flexible than the original intent of Maturity Level 3. The PSO has to be open to suggestions for improvement from the HPMgr community and have a formal process in place for receiving and acting upon those suggestions.
HPMgt Level 4: Integrated into Business Processes
The HPM world is one of collaboration and meaningful client involvement. The client is both outside the project team (i.e., like a stakeholder) and inside the project team as an active member. So, business processes are already integrated into the HPMgt Framework. This is best described by saying that project management has a seat at the business decision-making and planning table. At Level 4, effective project management is recognized as a critical success factor and a strategic asset to the organization. It is considered to be part of every business process or decision and a contributor to business value.
HPMgt Level 5: Continuous Improvement
Maturity Level 5 is the pinnacle of integrating project management into the business. There is a formal and continuous program in place for process and practice improvement. It runs throughout the entire project life cycle. It formally begins with project execution and continues through to the post-implementation audit and lessons-learned exercises at the end of the project. At Maturity Level 5 there is a way to capture these ″best practices″ and integrate them into the recommended tools, templates, and processes. At Maturity Level 5 every project team is constantly on the lookout for problems and offers suggestions for improvement.
THE ROLE OF THE PSO IN HPMgt
In the short run, the best senior management and the Project Support Office (PSO) can do is provide a resource to support the hybrid project teams. To maintain some semblance of control that resource should be a portfolio of tools, templates, and processes for managing the project over its life span. To further maintain comparability of performance between projects that resource should be vetted and the HPMgr encouraged to use only the vetted portfolio over the entire project life cycle.
The PSO will play a pivotal role. They will need a collaborative effort with the HPMgr community to build that vetted portfolio and then follow that up with a program that encourages project teams to use that vetted portfolio. No small task! I have previously written about that vetted portfolio [Wysocki, 2014]. Project managers must see that there is value in using the vetted portfolio because it is a supported portfolio. They are more likely to be users if they have participated in its creation and maintenance.
The Vetted Portfolio
The major strength of the HPMgt environment is that it places full control over the management of the project in the hands of the HPMgr. But that control would be a ticket to chaos if it weren't contained within a portfolio of vetted tools, templates and processes. Having that portfolio in place and used presents several benefits and challenges to the organization:
- the portfolio contains all of the tools, templates, and processes that will be needed to satisfy the management requirements of any project that the organization might encounter.
- the portfolio includes a continuous improvement process that monitors project performance and provides an open environment for project performance enhancements
- the HPMgrs have a detailed working knowledge of the portfolio and how to adjust it to satisfy any project management requirements that might arise
- the HPMgrs have the authority and responsibility to do what makes sense for effective project management
PUTTING IT ALL TOGETHER
CMMI was built for the Industrial Age project. We are in the Information Age. Maybe we need to rethink the CMMI in light of the movement towards a collaborative project management environment. The question to answer is "What is CMMI Level 3 Maturity in HPMgt? Rather than requiring compliance to a documented methodology, it should define the methodology based on the characteristics of the project, the organizational environment and the dynamics of the market situation.
[Mullaly, 2017] Mullaly, Mark. "All is Not the Same in the World of Project Management (Projectmanagement.com), March 27, 2017.
[Wysocki,2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing