Skip to main content

Author: Robert Wysocki

OUTSIDE THE BOX Forum: Bundled Change Management Process, Part 2

Part 1 described the background and the bundled change management process including the change request form.

The process was integrated into the co-manager model. Part 2 completes the discussion with the decision model for approving and prioritizing the open requests.

Wysocki 05152018 a

At Cycle/Stage Completion Prioritize Change Requests

This prioritization is usually related to how the open Change Requests align with the possible content of the next cycle. This prioritization is usually nothing more than a classification (like MoSCoW, ABC, etc.) so that a group of Change Requests can be further analyzed for inclusion in the next cycle.

Conduct Impact Study for High Priority Change Requests

This is the first detailed analysis of only those Change Requests that are relevant to the next cycle. The impacts can be to requirements satisfaction, solution development, generation of incremental business value, risk/complexity/cost/duration estimates.

The response to a change request is a document called a Project Impact Statement. It is a response that identifies the alternative courses of action that the co-managers are willing to consider. The requestor is then charged with choosing the best alternative. The Project Impact Statement describes the feasible alternatives that the co-managers were able to identify, the positive and negative aspects of each, and perhaps a recommendation as to which alternative might be best. The final decision regarding the choice of alternatives rests with the requestor.
The Project Impact Study involves looking at the project plan, assessing how the change request impacts the plan, and reporting the results to the project team. The project team may return it to the co-managers for further analysis and recommendations. The change request may be accommodated or even rejected with reasons given to the requestor.

Analyze Project Impact Studies

This analysis is designed to build content that will be input to the Next Stage Plan. It is an excellent tool for complex project management. Among the factors to consider are:

  • Schedule –  Any changes to the schedule will almost always have negative effects on completion dates.
  • Resources – There availability has already been accommodated in the current stage and project schedules. Schedule changes will almost always upset those commitments and add time to stage and project completion.
  • Risk – If the changes only impact future cycles, those can be managed. But if the changes impact previous cycles, they can be very disruptive. The point here is that the disruption may result in rework of components of the current solution. The cost of these disruptions needs to be compared with the incremental business value as part of the decision to accept the change.

Select Approved Changes for Next Cycle

While you might think that the selected changes start at the top of the priority list and work down until available resources and cycle duration limits are reached, that is not necessarily the case. For example, Some Change Requests may hold promise of generating excellent business value but the associated risk is high, development time is excessive and resource requirements are scarce. All of this may give way to Change Requests that deliver business value faster even though it may not be to the level of some other Change Request.

Change Requests can generate Probative or Integrative Swim Lane Work Packages for the next cycle. Change Requests focus on “What” is needed in the solution but not “How” those Change Requests can actually be implemented. The “How” may have several alternatives and it is not obvious which if any are the best choice. That calls for some number of Swim Lanes to investigate the alternative “Hows.” In the more obvious situations the “How” will be obvious and so an Integrative Swim Lane will be planned.

Prioritize Changes for Next Cycle/Stage Planning

While you might think that the selected changes start at the top of the priority list and work down until available resources and stage duration limits are reached, that is not necessarily the case. For example, Some Change Requests may hold promise of generating excellent business value but the associated risk is high, development time is excessive and resource requirements are scarce. All of this may give way to Change Requests that deliver business value faster even though it may not be to the level of some other Change Request.

Change Requests can generate Probative or Integrative Swim Lane Work Packages for the next stage. Change Requests focus on “What” is needed in the solution but not “How” those Change Requests can actually be implemented. The “How” may have several alternatives and it is not obvious which if any are the best choice. That calls for some number of Swim Lanes to investigate the alternative “Hows.” In the more obvious situations the “How” will be obvious and so an Integrative Swim Lane will be planned.


Advertisement
[widget id=”custom_html-68″]

SO, WHAT’S DIFFERENT?

Scope change in an ECPM project occurs but not like it does in a traditional project. Learning and discovery are the hallmarks of an ECPM Cycle so that any thought or idea that the client team or the development team has as to something different to do in the solution is captured and stored in the Scope Bank. The major difference between the traditional project and ECPM scope change is that in the traditional project the scope change requests are considered one at a time on a first come first serve basis. That is not the case with the ECPM Framework.

Furthermore, in ECPM Projects scope changes become part of the project plan going forward. It is easy to see that in these approaches there is a lot of wasted time revising a plan to accommodate scope changes. That doesn’t happen in the ECPM Framework because the plan going forward has not yet been prepared and so there is no wasted time processing scope changes. In the ECPM Framework planning is a just-in-time event. In the ECPM Framework resources are used to best business advantage on value added work whereas in traditional projects there is no assurance that that is the case.

Project Impact Statement

A common application of the prioritized scope triangle variables occurs whenever a scope change request is made. The analysis of the change request is documented in a Project Impact Statement (PIS). If the change is to be approved, there will be several alternatives as to how that change can be accommodated. These alternatives can be prioritized using the prioritized scope triangle and forwarded to the Client Checkpoint Step for consideration.

If the project is subject to frequent change requests and these are processed on an as received basis, significant resources can be wasted. Bundling change requests and processing them in bulk (say at the end of a cycle or at milestone events) can avoid wasting resources and protect the project plan as well. That is the process followed in the ECPM Framework.

Regardless of the PMLC Model you choose, you will have to deal with scope change requests coming from the client and from the project team. In some cases, you’ll be expecting these change requests, but not when you will get them but you’ll be ready to process them. In other cases, you will not be expecting them (or at least won’t want them), but that doesn’t absolve you from having a way to process them. During project planning I introduce the client to the Bundled Change Management Process and its benefits and get their agreement to its use. So, the Bundled Change Management Process can be in place from the start the project.

BENEFITS OF USING THE BUNDLED CHANGE MANAGEMENT PROCESS

There are four obvious benefits that the ECPM Framework:

  • It is lean – groups the requests into a single decision package
  • It is lean – allows for prioritization of requests
  • It is lean – schedules change implementation for maximum business value
  • It is lean – minimizes non-value-added time

The major benefit is that the process will reduce the time wasted to process change requests. All meaningful analysis of the change requests is done at the completion of the current cycle. The analysis includes a prioritization and scheduling of the approved change requests. So only one plan revision is done at these deadline dates rather than one plan revision for every change request in the bundle – an obvious saving of time, cost and resource utilization.

The major benefit is that the process will reduce the time wasted to process change requests. All meaningful analysis of the change requests is done at the completion of the current cycle. In a TPM environment, that means deadline dates for change requests are established. There can be more than one such deadline date imbedded in the plan-drive model. At these planned dates, all of the open change requests are analyzed as a package. The analysis includes a prioritization and scheduling of the approved change requests, so only one plan revision is done at these deadline dates, rather than one plan revision for every change request in the bundle.

This practice is in contrast to typical change requests, which are handled as they arise in most current methodologies. That is very inefficient and can lead to churning, contradictions and waste of resources. Bundling change requests and analyzing them as a group is far more efficient and consistent with “lean” practices. This is entirely consistent with the agile experience as it considers all learning and discovery since the last completed cycle and asks: What is the best way to proceed given what we now know? That knowledge is cumulative and treated as a group may generate other ideas that would not be discovered if treated one at a time. At the same time some ideas may be related to one another and if pursued as a package, may preserve the lean characteristics of the ECPM Framework. In this way, planning decisions are made as late as possible and always using the most current and cumulative learning and discovery.

PUTTING IT ALL TOGETHER

The major benefit of using the Bundled Change Management Process is two-fold:

  • Preserves the lean properties of the ECPM Framework
    Bundling change requests gives the project team the opportunity to consider the relationships between and among requests. Natural groupings will result. Some groups can be accommodated as one request thus reducing the total labor as compared to handling them separately. Others can be built into a future cycle when related to the content of that cycle again reducing to total labor expended. Others will be postponed and maybe lose priority and not be accommodated at all.
  • Increases the business value delivered
    The ultimate measure of project success will always be delivered business value. The team will try to maximize this for the resources expended. Bundling change requests and analyzing them together allows for prioritization that cannot be done if they are processed individually.

OUTSIDE THE BOX Forum: What is Hybrid Project Management?

Mark Mulally [Mulally, 2017] recently estimated that less than 2% of organizations are practicing project management at CMMI Maturity Level 3 or higher.

So, if you are an inquisitive person, you might ask what are the other 98% of organizations doing for their project management methodologies? According to CMMI they are at Maturity Levels 1 or 2 suggesting a chaotic world for project management. That makes no sense at all. Perhaps we need to revisit the maturity definitions used by CMMI. Let’s say the 98% are practicing what we will call Hybrid Project Management (HPMgt). For them it is not a chaotic world. The term has been used before but very little can be found from an Internet search. Let’s take a risk and step into that gap with a definition and then propose a robust HPMgt Framework. It will be a very high-level framework in order to leave room for creative models and a lot of flexibility on the part of the Hybrid Project Manager (HPMgr). That robust framework is discussed here and will define the WHAT needs to be done but not the HOW to do it. Those details will be forthcoming in the 8th edition of Effective Project Management: Traditional, Agile, Extreme, Hybrid. [Wysocki, 2019]

OVERVIEW OF THE HYBRID PROJECT WORLD

Organizations have spent years and lots of money designing project management models. Their inventories will include versions of the Waterfall Model along with one or more versions of Scrum, FDD, DSDM and perhaps other agile models. So, CMMI Maturity Level 2 is well established but, according to Mulally, is seldom used. Assuming we have competent project managers, it is safe to assume they have found other alternatives than those provided by their organization and defined in the project management body of knowledge. Those alternatives are probably variations of what their organization has provided. These alternatives are not published but travel below the radar but it is safe to assume that these alternatives align with these three factors:

  • the behavioral and physical characteristics of the project
  • their cultural and organizational environment of projects
  • the external supply/demand markets for the deliverables

All three of these are dynamic. They can change at any time and in unexpected ways. When any one of the factors change, the specific project management approach designed by the HPMgr might also need to change. The objective is to maintain the alignment of the project management approach to the project in order to achieve maximum business value and minimization of the risk of project failure. In other words, projects are unique and so should the best fit model for managing them also be unique. That is the basic principle underlying a hybrid approach and sets the stage for defining HPMgt.


Advertisement
[widget id=”custom_html-68″]

HYBRID PROJECT MANAGEMENT FRAMEWORK

According to David Robins [Robins, 2016] HPMgt is built upon traditional project management (TPMgt) to get the project started and Agile Project Management (APMgt) to execute the project. Each hybrid project beings with the Work Breakdown Structure (WBS) from TPMgt and then uses agile practices such as Scrum from APMgt to build the deliverables. That is too restrictive as the Hybrid Project Manager (HPMgr) will find it necessary to take exceptions due to the three factors not aligning to Robin’s model. It is too restrictive to force the project to align to a specific model. The model should be defined to align to the project.

ROBIN’S MODEL:

TPMgt + APMgt = HPMgt
May not align to the needs of the project. 
The HPMgt approach should be defined so as to align to the project.
The proposed HPMgt is a richer framework based on a vetted portfolio of tools, templates and processes.
The proposed HPMgt Framework supports every project from a very informal approach to managing simple TPM projects to a very formal but unique approach to managing very complex APM projects.

In order to achieve and maintain that alignment a robust HPMgt Framework must be defined. At the highest level of abstraction, a robust framework will have 3 phases:

  • Ideation Phase
  • Set-up Phase
  • Execution Phase

Ideation Phase

In this phase a definition of what the project is all about is developed. It begins with some type of request or mandate from a sponsor. Alternative approaches to the project are suggested and prioritized and a Business Case is developed. A short summary of the project approach is developed (such as a Charter Statement) which is used to gain approval and support for the project.

Set-up Phase

In this phase a definition of how the project will be done is developed. It may include a specific project management model which may be an off-the-shelf, customized or unique model. In some cases, the vetted portfolio might be used to create the approach. The Set-up Phase will include a high-level plan with a budget, resource requirements and a schedule. That high-level plan might be subject to approval at an executive level.

Execution Phase

This phase executes the project management model that was designed for the project. In the most complex cases the learning and discovery that resulted from a previous iteration may require a revision of the Set-up Phase.

SCOPE OF THE HPMgt FRAMEWORK

The above robust definition allows for several solutions. In fact, since a project is unique, the solution (a project management model) will also be unique. To be a useful framework the HPMgt Framework must support any project – from the very small and simple to the very large and most complex. At the highest level the Framework is defined by the Ideation, Set-up and Execution Phases. That defines the “WHAT” that must be done for every project. Within that robust structure we can define the “HOW” to do it. In defining that “HOW” the basic assumption is that the HPMgr is in charge and will define the “HOW” utilizing the vetted portfolio of tools, templates and processes. In using that vetted portfolio, the HPMgr can select and adapt items from the vetted portfolio to create an approach that aligns with the three factors that profile the project.

The Project Support Office (PSO) for the HPMgr will be an adaptation of the typical Project Management Office (PMO). The PMO is usually seen as a standards and compliance organization. That won’t work in a HPMgt environment. The PSO is by definition a support organization. That support includes:

  • a vetted portfolio of tools, templates and processes
  • consultants to provide support at the request of the HPMgr.

This article has defined the starting point for HPMgt. Stay tuned for other articles to follow that will put some meat on the bones of the “HOW”.

NOTES

[Mulally, 2017] Mulally, Mark, 2017. All is not the same in the World of Project Management, ProjectManagement.com, 3/27/17

[Robins, 2016] Robins, David, 2016. Introduction to Hybrid project management methodology, (HTTPS://WWW.BINFIRE.COM/AUTHOR/DAVID/)

[Wysocki, 2019] Wysocki, Robert K., 2019. Effective Project Management: Traditional, Agile, Extreme, Hybrid, 8th Edition (EII Publications, forthcoming)

OUTSIDE THE BOX Forum: Bundled Change Management Process, Part 1

In the complex project management landscape, the goal and/or solution are not completely specified at the outset of the project and hence change is an essential component of whatever learning and discovery process has been employed to find an acceptable solution.

Wysocki 05152018 aIn the complex project, space change is encouraged as an integral part of the learning and discovery process. This stands in stark contrast to the traditional project landscape where change is viewed as disruptive and a major contributor to non-value-added work. Because of these differences, the change request process for the traditional project landscape is not one that will work in the complex project landscape. Rather than discouraging change, the complex project management process must not only encourage change but have a lean process for managing it. This Topic introduces a Bundled Change Management Process designed specifically for the complex project landscape.

Once an ECPM Framework Cycle Plan is approved, it is executed without incorporating any change requests that may arise during the execution of that cycle. This is unique to the ECPM Framework, but it can easily be adapted into other agile methodologies. Change requests will arise, that is the nature of complex project execution. Processing them up to the decision point can waste resources. Accepting the change requests as they arise and holding them in the Scope Bank for processing during the Client Checkpoint preserves the “lean” characteristics of the ECPM Framework and significantly improves the effectiveness and business value of the decisions taken. Furthermore this “Bundled Change Management Process” is a collaborative process.

BACKGROUND

In the Traditional Project Management (TPM) world change is the bane of the project manager. The traditional approach to managing change is to process them on an as submitted basis and decide how to proceed. If the change is accepted, it must be incorporated into the plan.
If the project is subject to frequent change requests and these are processed on an as-received basis, significant resources can be wasted. Frequent change requests are a common occurrence in the search for an acceptable solution. Some of these change requests will be well thought out; others may be nothing more than educated guesses or even wild speculation. All requests must be viewed as significant requests until proven otherwise and processed but unless there is a more efficient way of handling them, there will be wasted resources and time.

WHAT IS THE BUNDLED CHANGE MANAGEMENT PROCESS?

In the complex project, world change is constant. A good complex project management methodology must have a clear and effective change management process in place. In effect, the change management process has you plan the project again so it now incorporates the approved changes. Perhaps the use of a PMLC Model based on just-in-time planning is a better approach at least from a “lean” perspective. Even if you have to use a plan-driven PMLC Model, incorporating the Bundled Change Management Process will be a good insurance policy.

In an ECPM Framework project, the change management process does not exist in the forms that the traditionalist will be familiar with. Scope change in an ECPM Framework project occurs, but not like it does in a TPM project. Any thought or idea that the client team or the development team has, as to something different to do in the solution, is captured and stored in the Scope Bank. The major difference between TPM and ECPM Framework scope change is that, in TPM, the scope change requests are considered one at a time on a first come first serve basis and a decision taken. Whereas in ECPM Framework, scope changes become part of the Client Checkpoint. It is easy to see that in a TPM project there is a lot of wasted time in revising a plan to accommodate scope changes. That does not happen in the ECPM Framework because the project plan going forward has not yet been prepared. It is only planned one cycle or stage at a time and so there is no wasted time processing scope changes.

Bundling change requests and processing them in bulk (say, at the end of a cycle or at milestone events) can avoid wasting resources and protect the project plan as well. EII has designed a bundled change request process specifically to handle the unique needs of complex projects in search of an acceptable solution.


Advertisement
[widget id=”custom_html-68″]

The lifeblood of a successful complex project is change. Without change an incomplete solution will never evolve to an acceptable complete solution. The first principle to learn is that every change is a significant change. What that means is that the change process must be open, simple, lean and as painless as possible to the client for that is where the bulk of the changes will originate. The ECPM Framework includes a unique Bundled Change Management Process (Figure 1) that meets these criteria.

Wysocki 05152018 bFigure 1: Bundled Change Management Process

Note that when the Change Request is received that it is review and if accepted without change is added to the Scope Bank. Only when the stage is complete will the change request be analyzed and further action is taken. If the change is approved it will be available as early as the next stage.
What that means is that every change requested by the client must be documented in a Project Change Request. Figure 2 is an example. That document might be as simple as a memo but might also follow a format provided by the project team. Only when the request is clearly understood can the project team evaluate the impact of the change and determine whether, how and when the change can be accommodated.

Wysocki 05152018 cFigure 2: Bundled Change Request Form

Change requests can arise at any time and can come from any one of several sources. Furthermore, the request can be well thought out or just a statement like: “What would it be like if we could …?” or “Maybe we could change this and then it would work.” Both extremes must be accommodated by the request form that formally enters the idea into the project. The request process begins with a statement from the individual making the request. It is designed to allow the requestor to provide as much detail as is available. The last thing would be to have a requirement that creates an obstacle to suggesting a change. Rather, you would rather have a request form that encourages ideas.

The Action section is critical to the process. It allows the project team to clarify any part of the request. It must be understood in the context of the current solution and future stage planning.

Review Change Requests

The Bundled Change Request Process is designed to be a lean process. This is accomplished first by sending the request to either the Business Systems Engineer for management process changes or to the Business Analyst for product change requests (Figure 3). The traditional process would have the request sent to the project team thus taking the team member away from their scheduled work assignments.

Wysocki 05152018 dFigure 3: Complex Project Team

One of the strengths of bundling change requests is that every request is reviewed, critiqued and considered in relation to all of the other open change requests. Both the Business Systems Engineer and the Business Analyst participate in that review and the discussions that follow as the next Iteration or Stage is planned. During Next Stage Planning those change requests are reviewed along with any learning and discovery that occurred during the just completed cycle. There may be some hidden synergies waiting to be exploited in the coming cycles. That is far more effective and efficient than any one at a time approach. It gives the project team the opportunity to group similar open change requests for better decision making and use of resources. This will be a time for further learning and discovery of the elusive solution. There will be situations where the grouping of similar change requests may generate other changes that otherwise would not have seen the light of day.

OUTSIDE THE BOX Forum: CMMI Maturity Levels 2 and 3 Should be Revised to Make Sense for the Hybrid Project World

For several years now the SEI Capability Maturity Model has been widely heralded as the ideal descriptor of the state of project management maturity in the contemporary organization.

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.


Advertisement
[widget id=”custom_html-68″]

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.

END NOTES
[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

OUTSIDE THE BOX Forum: Is CMMI Relevant for Complex Projects

For several years now the SEI Capability Maturity Model has been widely heralded as the ideal descriptor of the state of project management maturity in the contemporary organization.

Level 3: Documented Process that Everyone Uses has been the goal for all to achieve. At that Level projects can be effectively executed and managed to produce the expected business value that justified them in the first place. 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 – i.e., project management processes and practices border on a free for all with project success totally dependent on the expertise and management preferences of the project manager and the team. At best that borders on organized chaos and creates obstacles to senior management’s ability to effectively control project portfolio investment decisions.

So, faced with the preponderance of Maturity Level 1 and 2 organizations how could CMMI adapt in order to maintain its relevance to Hybrid Project Management? This article answers that question.

THE COMPLEX PROJECT MANAGEMENT STATE

The complex project management 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.

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 a dynamic project management approach to a specific project based on the three constraints.

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.


Advertisement
[widget id=”custom_html-68″]

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 maturity of processes and the practice of those processes.

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.

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 in terms of 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 just 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 CMMI 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.

Maturity Level 3: Documented Processes That Everyone Uses

The migration from Level 2 to Level 3 maturity is a big step. At Level 3, documented tools, templates and processes are vetted, supported and maintained. Compliance comes in many forms. In the complex project landscape compliance includes the adaptation of a tool, template or process to provide a 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. In the world of HPMgt, Maturity Level 3 may be the highest level that has business value. That is a topic for a future artricle.

Maturity Level 4: Integrated into Business Processes

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.

Much can be said about the organization that has reached Level 4 maturity. Project managers will have become very skilled in the business processes, and business analysts will have become skilled in project management. In this environment, project management is fully integrated into the business of the organization.

Maturity 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 during 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.

END NOTES

[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