Skip to main content

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.


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.


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.

[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.

Comments (5)