Author: Robert Wysocki

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.

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.

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.

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.

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

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.

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

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

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