Bundled Change Management Process

A Fundamental Characteristic of a Lean Process

In the complex project management landscape, change is an essential component of whatever learning and discovery process has been employed to find an acceptable solution. In 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 it, but have a lean process for managing it. 

This article recommends a Bundled Change Management Process designed specifically for the complex project landscape. It is also a lean process that easily integrates into the PRINCE2 Stage Planning Process.

Both the ECPM Framework and PRINCE2 share a lot in common with respect to the Change Process. 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 has application in any methodology such as PRINCE2. 

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.

WHAT IS THE BUNDLED CHANGE MANAGEMENT PROCESS?

In an ECPM Framework project, the scope change management process does not exist in the forms that the traditionalist will be familiar. 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-served basis and a decision made. 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 revising a plan to accommodate scope changes. That does not happen in the ECPM Framework because the plan going forward has not yet been prepared, so there is no wasted time processing scope changes.

Because change is constant, a good complex project management methodology must have a clear and effective change management process. 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.

An integral part of the Bundled Management Process is documentation. I strongly suggest that every change is treated as a major change until proven otherwise. To not do so is to court disaster. That means every change request follows the same procedure. The figure that follows is an example of the steps in a typical Bundled Change Management Process. 

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.

---

{module ad 300×100 Large mobile}

---

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

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 for a change in the solution is captured and stored in the Scope Bank. 

Change requests are considered one at a time on a first-come-first-served basis in a TPM project. That is not the case with the ECPM Framework. In an ECPM Project, scope changes become part of the project plan going forward.  In traditional and PRINCE2 projects they are an add-on to a project plan that already exists. 

It’s 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 – there is no wasted time processing these 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 can avoid wasting resources and protect the project plan. 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 they arrive – 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 you still need a method 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. The Bundled Change Management Process can be in place from the start the project. 

PRINCE2 and the Change Process

There are four obvious benefits that the ECPM Framework  Scope Triangle, and specifically the change process, can bring to the PRINCE2 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. 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.

Prince2 devotes a chapter to change control and issues management ( Managing Successful Projects with PRINCE2, 2009 edition, AXELOS) with the emphasis on issue management. Issue management is not unlike problem-solving, and I have discussed how the ECPM Framework Scope Triangle is an excellent structure for managing problem-solving and analysis of the alternatives.

In the complex project world change is to be expected, unlike the traditional project world where change is less frequent and disruptive of established plans and schedules. PRINCE2 change control is not lean! The ECPM Framework approach to problem-solving and bundled change management is an excellent lean process that can be adapted and integrated into the PRINCE2 Framework with minimal disruption of the management process.

Benefits of Using the Bundled Change Management Process

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 embedded 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 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. This can be 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 and the PRINCE2 Framework as well. In this way, planning decisions are made as late as possible and always using the most current and cumulative learning and discovery. 

Submit Change Requests

The first principle to learn is that every change is a significant change. Adopt that maxim and you will seldom go wrong. What that means is that every change requested by the client must be documented in a Project Change Request. That document might be as simple as a memo but might also follow a format provided by the project team. In any case, it is the start of another round of establishing Conditions of Satisfaction (COS). 

Only when the request is clearly understood can the project team evaluate the impact of the change and determine whether the change can be accommodated.

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 …? 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. The figure below is an example. 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.

Review Change Requests

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. Those change requests are also 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. 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.

Add Change Requests to Scope Bank

The Scope Bank is the holding pen for all Change Requests. No analysis is done at this early stage. The Change Request might be categorized according to how it relates to requirements and/or the current solution. That gives better visibility into how Change Requests might be leveraged as a group rather than individually.

At Cycle 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 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 project manager is willing to consider. The requestor is then charged with choosing the best alternative. The Project Impact Statement describes the feasible alternatives that the project manager was 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 Impact Study involves looking at the project plan, assessing how the change request impacts the plan, and issuing the impact study. It is then forwarded to upper management for final disposition. They may return it to the project manager for further analysis and recommendations, or reject it and notify the client of their action. The project manager reworks the impact study and returns it to upper management for final disposition. If they approve the change, the project manager will implement it into the project plan.

Analyze Impact Studies

This analysis is designed to build content that will be proposed for the next cycle. It is an excellent planning tool for complex project management. Among the factors to consider are:

• ScheduleAny changes to the schedule will almost always have negative effects on completion dates.
• ResourcesThere availability has already been accommodated in the current cycle and project schedules. Schedule changes will almost always upset those commitments and add time to cycle 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 the 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.

PUTTING IT 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.