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.

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.