Author: Robert Wysocki

Probative and Integrative Swim Lanes: A New Stage Planning Tool

Written by Robert Wysocki on April 13, 2016. Posted in Articles. 5 Comments on Probative and Integrative Swim Lanes: A New Stage Planning Tool

The ECPM Framework aligns with the Lean Principles. That alignment is assured through iteration planning that utilizes two artifacts: Probative Swim Lanes and Integrative Swim Lanes.

Integrative Swim Lanes are not new as they are part and parcel of Scrum and every other agile methodology that uses incremental development. The term is not used in PRINCE2 but the concept is included in the Managing Product Delivery Process.

Probative Swim Lanes were first defined by Wysocki (2014) and are a unique artifact of the ECPM Framework. Their purpose is to explore and identify possible solution components consistent with the ECPM Framework principles of “Lean Practices.” Probative Swim Lanes are a planned search for the unknown parts of the current solution. They are planned on a just-in-time basis with the goal of spending minimal resources as long as the direction is tenable. Probative Swim Lanes are the foundation of the ECPM Framework and a “lean tool” too.

Related Article: The Scope Bank: A PRINCE2 Stage Management Tool

Each iteration planning effort aligns quite well with the Stage Planning process that is fundamental to PRINCE2.

TYPES OF DELIVERABLES IN THE ECPM FRAMEWORK STAGE PLAN

Just as with the Version Scoping Phase, the best way to introduce you to the Stage Planning strategy is from the perspective of its deliverables. The Stage Plan includes these deliverables:

Update the prioritized list of Probative and Integrative Swim Lanes
Establish the contents of the next Stage Build Integrative Swim Lanes
Establish the contents of the next Stage Build Probative Swim Lanes
Create low-level WBS and Work Package (WP) schedules
Establish stage duration
Identify and schedule resource requirements
Establish technical and resource dependencies
Finalize stage schedule

All of the historical and current knowledge to support these deliverables is contained in the Scope Bank. Let’s briefly discuss each deliverable from the Stage Planning Process.

Update the prioritized list of Probative and Integrative Swim Lanes

The input to the updated prioritized functionality list is the prioritized list from the just completed stage: any work planned but not completed from the previous stage, any ideas or changes in the Scope Bank that have not yet been acted upon, and the bundled changes suggested by the client or the development team based on additional learning and discovery from the just completed stage. All of this information is best kept in the Scope Bank.

Establish the Contents of the Next Stage Build Integrative Swim Lanes

This is familiar ground for every project manager. The same vetted tools, templates, and processes used for TPM projects can be used here. Remember that stages will be short (1-6 weeks typically for APM and xPM projects), and so planning is not complex and does not need a lot of software support. For my purposes, whiteboards, sticky notes, and marking pens are sufficient!

The contents of the next stage will take the form of some number of Probative and Integrative Swim Lanes. You also have a preliminary estimate of the stage time box for the coming stage, and so you can determine the stage contents based on what can reasonably be accomplished within that time constraint. If necessary, you might adjust that time-box to accommodate the next item or items on the prioritized list. Apart from any dependencies between the functions, sub-functions, and features, the client team and the development team will jointly decide how much of the prioritized list the development team can deliver in the coming stage. The duration of the stage and the estimated duration of the functions and features to be worked on at this stage is what you will use to determine the contents of what can be worked on at this stage.

If this is the first stage, don’t be too ambitious, especially if your project team members have not had the opportunity to work together on a complex project before. Take the client team into consideration, too. Is this the first opportunity to work with them? What do you know about them? What is your previous experience with them? These are all factors to be considered regarding stage content and length. How they have come together as a team may also influence planning for the coming stage. If they are together for the first time, you should not expect them to be a lean, mean, fighting team. They will stumble at first. So do not burden the team too heavily while they are learning to work together efficiently.

The first step in establishing stage contents is to work down the prioritized list of functions, sub-functions, and features, estimating the time to build them. How far down the list to go is a judgment call. (As a guide, you might use the total number of hours of labor available from the project team in the coming stage. If you feel uncomfortable with this, you might reduce labor hours by some percentage, say 10%, and use that as your guide to cumulative duration hours available in the coming stage.) The cumulative duration of the work you have estimated can be larger than the stage duration if the team size is large enough, so that parallel work can take place. Do not spend time working far down the list past anything that might reasonably be included in the coming stage. That could prove to be a waste of time. Where to stop is a judgment call, so just remember that the complex project manager does not waste time.

Establish the Contents of the Next Stage Build Probative Swim Lanes

The less that is known about the solution, the more important it is to aggressively identify potential solution details. That is the purpose of Probative Swim Lanes. I have often found it helpful to use an iconic prototyping approach in these Probative Swim Lanes to investigate these possible additions to the solution. Several iterations of the prototype can be completed within the stage time-box.

Whereas Integrative Swim Lanes are planned in detail, using TPM tools Probative Swim Lanes are more like xPM projects and do not have such plans, but rather depend on the creative process for their completion. There really is no limit to the approach used in a Probative Swim Lane. Prototyping, brainstorming, and problem solving have already been discussed earlier in this chapter, and are the three approaches I have used in past complex projects. The outputs from these three approaches fall into one of the categories discussed next.

Because of the volatile nature of the Probative Swim Lanes, be prepared to move resources to other stage work as available, when you have:

Positive results—more investigation advised. This idea looks like a promising direction to investigate, but more detail is needed. That detail should be left for a later Probative Swim Lane in their next stage or even later, and so its description should be placed in the Scope Bank for prioritization.
Negative results—looks like a dead end. This idea doesn’t seem like it will produce any fruitful results. No further action on it is recommended. It should be returned to the Scope Bank for further idea generation. Do not throw any ideas away unless you are clairvoyant!
New ideas have surfaced. Probative Swim Lane ideas will often identify other ideas for consideration. Depending on the extent of those ideas, they might be considered within the context of the current swim lane, or relegated to the Scope Bank for later prioritization and consideration.

A cumulative history of project performance metrics should be maintained. These metrics should inform the project team about the rate at which convergence to an acceptable solution is occurring. The frequency of changes, the severity of change, and similar metrics can help.

Tracking Scope Bank Size

One metric that I have found useful is to track the size of the Scope Bank over each stage. The figure below shows three trends in Scope Bank size that I have used in client engagements.

Tracking Scope Bank Size

Tracking the Size of Probative Swim Lanes and Integrative Swim Lanes

The overall size of the Scope Bank is a good indicator of project performance, but it does not tell the whole story. For that, we need to look at the relative sizes of the two swim lanes over time. At the next level of detail, I like to track the relationship between the Probative versus Integrative Swim Lanes over the history of the project. The figure below shows an example of this type of report. It shows all four possible relationships between the two swim lanes: one is increasing, and one is decreasing (a) and (d) are both increasing (c), or both are decreasing (b). Each pattern carries at least one interpretation.

Size of Probative versus Integrative Swim Lanes

There are two strategies that I have used successfully to manage project stages. The first strategy is to have the first stage focus on building a prototype followed by several stages dominated by Probative Swim Lanes. If you have established good client relationships from previous complex projects, this can work quite effectively. If you do not have that client relationship, this strategy is not a good choice for the reason that it does not contribute to the early establishment of meaningful client involvement. For the second strategy, the less I know about the solution, the more I would lean towards prototyping for the first few stages. Before you can effectively define probative initiatives, you and the client need a sense of direction as to where that elusive solution might be found. Early prototyping stages will do the job and will also contribute to building that much needed client relationship.

In this example, little is known about the solution, and so the early stages will be focused on discovering functions and features of the solution. Early brainstorming sessions should be conducted in the Version Scoping Phase and first few Stage Planning Phases. You need to “stoke the fires” and get as many ideas as possible into the Probative Swim Lanes. Prototyping can be effective in the early stages.

As Probative Swim Lanes successfully identify parts of the solution, they should be followed by Integrative Swim Lanes as soon as possible. It is important to get even a partial solution in front of the client. The most useful information about the missing parts of the solution will come from the learning and discovery by the client team as they work with the then solution.

Remember that the successful identification of solution components through the use of Probative Swim Lanes feeds the Integrative Swim Lane contents, and hence the convergence of the solution to the complete solution. It is the responsibility of the co-project managers to maintain a healthy balance between Probative and Integrative Swim Lanes so that convergence to that final solution is assured. That balance will change as the project progresses through the stages.

Written reports that circulate among the team members do not exist in complex projects. They are a waste of time in a complex project. But your management and the sponsor may not share that same opinion and will require periodic status reports. You will have to accommodate their wishes; they pay the bills. All inter-team reporting is verbal, and everyone on the team who needs to know will know. There are reports that circulate outside of the team, but these are the responsibility of the co-project managers. In many cases, they will be exception reports or escalations of open issues and problems that are outside the span of the authority of the co-project managers, and are then escalated to the appropriate senior manager or project sponsor. The co-project managers often will use the team meetings to quickly give the team the status of open issues that affect the project.

The monitoring and controlling functions pertain to the stage build tasks. As part of that control function, the team collects whatever learning and discovery took place and records it in the Scope Bank. All change requests go into the Scope Bank as well. No changes are acted upon within a stage. All changes and other learning and discovery are reviewed at the checkpoint. The review results in placing newly discovered functions and features into a priority list for consideration at the next or some future stage.

NEXT STAGE PLAN

Stage duration and stage contents are the primary focus.

Next Stage Duration

The decision as to stage length for the next stage is based on two prioritized lists: the functionality to be integrated into the current solution and the ideas to be investigated in the next stage. Team resources are also considered because they place constraints on what can actually be accomplished within the stage timeframe. The actual contents of the two prioritized lists have to be evaluated subjectively to decide on stage length. Remember to be true to the overall time box decision made during the Version Scope Phase if possible.

Next Stage Contents

This is the most complex decision that has to be made because the swim lanes tasks are staffed by the same limited resource pool. The priorities within a swim lane have been reset, but the priorities between swim lanes are still to be determined. The simplest way to state this last decision about stage contents is: Given the available resources should we add the next Probative Swim Lane tasks or the next Integrative Swim Lane tasks? Resource availability may answer the question without any further considerations, but the decision is usually more complex. It is an issue of balance between the status and needs of each swim lane. Each swim lane will have a backlog that needs to be taken into account. If there is a large backlog in the Integrative Swim Lane, that diminishes the need to invest resources in the Probative Swim Lanes. The reverse strategy also applies.

The next stage length is known, and a new prioritized list of functionality is available. How far down the two swim lane lists can the team expect to get with this next stage? There may be some give and take between next stage deliverables and the stage time box, but this should be minimal and easily resolved.

I had cautioned you that in the early stages of a project, do not be too aggressive. As the team gets to the perform stage and the client team is more comfortable working with the development team, the list of deliverables for the next stage can get a bit more aggressive. The ECPM has the luxury of returning undone functionality to the Scope Bank and reprioritizing it for consideration in a later stage. There is still the temptation on the part of technical professionals to have a “steak appetite on a baloney budget.” Do not set the client up for results that cannot be achieved. That would put a serious dent in a relationship that was hard earned.

IMPLICATIONS FOR PRINCE2

Just as the Probative and Integrative Swim Lanes can be included in the stage so also can these tracking tools be used in Stage Planning.

The process you use for ending a stage may compromise the content and presentation of the swim lane performance, however.

END NOTES
Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. Plantation, FL: J. Ross Publishing.

Business Rules for Ending A Stage: Part 1

Written by Robert Wysocki on March 23, 2016. Posted in Articles. 5 Comments on Business Rules for Ending A Stage: Part 1

In the ECPM Framework, once a cycle begins it continues without change until the time-box expires.

By comparison, PRINCE2 focuses on completion of the Work Package as planned for that stage and allows for movable end dates for a stage. Cycle and Stage are synonyms.

The ECPM Framework identifies three situations regarding the end of a cycle:

Normal End of Cycle when the timebox expires
Abnormal End of a Cycle before the time-box expires
Major Change in the Environment

The ECPM Framework ending strategies can apply with equal effectiveness in PRINCE2 in the Controlling a Stage Phase.

WHAT IS A CYCLE?

In the ECPM Framework cycles can be of varying lengths but usually not more than 6 weeks duration. Within that timebox, the project team identifies the tasks that they have estimated can be delivered. Those tasks are of two types: Tasks associated with Probative Swim Lanes and tasks associated with additions to the evolving solution through Integrative Swim Lanes. In most cases priority would be given to completing an Integrative Swim Lane before completing a Probative Swim Lane. The reason is that an Integrative Swim Lanes delivers business value whereas a Probative Swim Lane delivers knowledge (i.e., learning and discovery).

ENDING A CYCLE

There are three situations that can result in the decision to end a cycle. They are described below.

1. Normal End of Cycle when the Timebox Expires

When the timebox expires, the cycle ends – no exceptions. Any Work Packages (WPs) that were planned for that cycle and had not yet been completed are returned to the Scope Bank for prioritization in future swim lanes and cycles. There are no situations where the timebox is extended for even one day. To do so is not at all in keeping with the lean properties characteristic of the ECPM Framework.

This gives us a strategy for planning the balance between Probative and Integrative Swim Lanes in a cycle. There are two strategies to apply for the scheduling of WPs within a cycle:

Prioritize the contents when scheduling WPs within each swim lane

If the tasks are scheduled according to their priority, then any tasks not completed will be of low priority. Because of the learning and discovery that takes place in the cycle, the lowest priority tasks may never receive a high enough priority to be included in the cycle plan.

Integrative Swim Lanes are of a higher priority than Probative Swim Lanes

Integrative Swim Lane tasks deliver an updated solution and incremental business value. Probative Swim Lanes have the potential for identifying business value but not yet.

{module ad 300×100 Large mobile}

2. Abnormal End of a Cycle Before the Timebox Expires

There will be situations that arise where all of the planned WPs were completed in less time than was estimated. WPs should be finished as soon as possible resulting in cycles completed sooner than was estimated. Do not create work just to fill the timebox duration. End the cycle and proceed to the Client Checkpoint Step.

3. Major Change in the Environment

This situation can arise independently of the cycle and outside the control of anyone. The internal and external environments are in a constant state of flux. Just like risks, changes might be expected but when they will arise cannot. If the change is so disruptive as to render the cycle WPs compromised, it might not make business sense to continue the cycle. End the cycle immediately, save the time and resources, and begin planning the next cycle armed with the new information.

MANAGING STAGE BOUNDARIES

In PRINCE2, just as in the ECPM Framework, the Stage is where it all happens. Both frameworks have planned the specific deliverables to be built within a time and cost constraint. Whenever either of these constraints is challenged, some corrective action is required. The two frameworks are very different in these situations. For the ECPM Cycle, we have discussed the actions above. For the PRINCE2 project, the following is specified.

AN AGILE APPROACH FOR ENDING A PRINCE2 STAGE

Taking into account:

learning and discovery from the just ended stage
incomplete WPs from the just ended stage

it is clear that the ECPM Framework design has two basic tenants:

decision making is contained within the roles and responsibilities of the co-managers whenever possible
the number of hand-offs has been minimized to reduce non-value added work time.

PRINCE2 processes are not clear on how these decisions are taken but seem to leave open how the project manager and team managers choose to proceed. Within Stage boundaries, the decisions can be taken without outside input or intervention. When Stage boundaries are threatened or exceeded, the decisions are taken outside of the project team. That often requires the sharing of information (written or verbal) to the outside decision makers. That process adds non-value work due to the handoff time required. On the other hand, the ECPM Framework processes minimize non-value work time.

The Scope Bank: A PRINCE2 Stage Management Tool

Written by Robert Wysocki on March 9, 2016. Posted in Articles. 4 Comments on The Scope Bank: A PRINCE2 Stage Management Tool

The Scope Bank is unique to the ECPM Framework but offers significant management benefits when applied to the PRINCE2 Framework.

The Scope Bank is the clearinghouse for all project activities – a traffic cop if you will. It brings together in one place solution status, stage performance history, potential solution components and a foundation for stage management of the project. It is the basis for problem resolution, decision making, resource management and just-in-time planning.

The Scope Bank is always up to date at decision time. In the ECPM Framework, the Scope Bank is much like a tool whose purpose is to direct the deliverables coming out of all completed cycles and plan for the deliverables to be developed in the following cycles.

In PRINCE2, the use of a Scope Bank is the logical consequence of executing a Stage Plan. Scope change requests will arise at any time during a Stage, but their resolution is held until the Stage is complete and its deliverables reviewed. This may well be counter to common PRINCE2 practices. There will be situations where an ECPM cycle is not completed. In these situations, the deliverables that were not complete are returned to the Scope Bank for further prioritization and scheduling. The ECPM Framework cycle duration is sacrosanct. It ends as planned and not an hour later.

The Scope Bank has been a major artifact of the ECPM Framework and has every indication that it can bring added value to the processes and practices of the PRINCE2 Framework.

SCOPE BANK

The Scope Bank is the single depository for the current requirements definition (aka, the Requirements Breakdown Structure (RBS). See Article 3.), open change requests, the current solution, and all learning and discovery that has been accumulated from all cycles that has not yet been acted upon. This includes all unresolved change requests. The Scope Bank is unique to the ECPM Framework and is an essential part of the portfolio of tools, templates, and processes that support the ECPM Framework.

I caution teams that nothing should be removed from the Scope Bank unless it is built into the solution. So it still remains in the Scope Bank but from a different perspective. An idea once suggested and thought to be of no use early in the project might later turn out to be just the opposite. In some cases, I have seen a previously rejected idea suggest a new idea that leads to new features and functions added to the solution. So the message is that every idea is a good idea, we just haven’t figured out how – yet! If it isn’t in the Scope Bank, it will have been forgotten and no longer of any value to the solution.

The Scope Bank is the primary input to the Client Checkpoint in the ECPM Framework. In PRINCE2, it can be the input to the Stage Planning Process. The contents of the Scope Bank are updated at the completion of each cycle just as is done in PRINCE2 at the completion of each Stage. The contents include future Integrative Swim Lanes and ideas for future Probative Swim Lanes. Since there are fixed resources for the next cycle, the contents of these two types of swim lanes must be jointly prioritized. Depending on the degree to which the solution is complete, there will be a healthy mix of the two types of swim lanes.

{module ad 300×100 Large mobile}

The process of discovery and learning by the team is continuous throughout the cycle. Any new ideas or thoughts on functionality are simply recorded in the Scope Bank and saved for the Client Checkpoint Phase. The Scope Bank can physically be a list posted in the Team War Room, or some electronic form (spreadsheet or word processing document). Whichever form you decide to use, make sure it is always visible to the team.

The following fields are used to describe an item in the Scope Bank:

ID #:

A reference number or short name that uniquely identifies the entry.

Date posted

The date this entry was first posted to the Scope Bank

Posted by

The person responsible for posting this entry.

Requirements Linkage

Describe the requirement(s) that this change is related too.

Description

A brief statement of what functionality is associated with this entry.

Business value

If known, what business value will be added to the solution if this entry becomes part of the final solution.

Duration

If known, how long will it take to build the functionality associated with this entry?

Resources needed

List the resources that will be needed to build and implement this entry.

Team comments

Any other comments relevant to this entry and its development and deployment into the solution.

Prioritization

Place this entry in the appropriate swimlane (Integrative or Probative) and assign a priority to it.

For the cycle just completed, the cycle plan called for a specific list of functions and features to be added to the deliverables through one or more Integrative Swim Lanes. No schedule or scope changes were allowed during the cycle, yet it is possible that not all the planned functions and features actually made it into the deliverables. There are several reasons for that, which we will not discuss. They are obvious reasons (e.g., schedule slippages that could not be recovered, a discovery that rendered the functionality unnecessary), which occur in all projects. The ECPM Framework accommodates these anomalies without skipping a beat. Any functions or features not completed in the just-completed cycle are returned to the Scope Bank and prioritized for consideration in a future cycle.

SCOPE BANK CONTENTS

The following presents a brief discussion of each of the items that are in the Scope Bank at any point during the project life span. The item descriptors listed above are most useful for scope change requests and processing but otherwise are provided as appropriate.

Current Solution

Complex projects are high-risk projects. That means they could be delayed or even terminated at any point in time. To minimize any potential business losses every cycle ends with an updated production ready solution. That solution is not complete but, at least, any business value that can be generated from it will be generated if the project is terminated and the solution deployed. While the expected return on investment for a completely acceptable solution may not have been realized, at least there is some return on investment.

There are several factors that are at play for a favorable deployment decision. Three are important here:

The Enterprise Release Schedule

If the enterprise has established a release schedule for incorporating change, that release schedule should be honored when updated solutions are implemented. Releases may occur as often as once per quarter but may be not more frequent than annual. Whatever the infrastructure supports, that should be the pace adopted for solution delivery. In the absence of an accepted release schedule, the solution might be deployed at the discretion of the co-managers.

The Business Value From the Current Solution

The premise underlying cycle planning is to maximize the incremental business value of every cycle. That offers a loose prioritization of a deliverables implementation strategy. The deployment strategy might be based on the incremental business value that would result from the deployment. If it meets certain minimums, deployment will occur.

The Challenge of Deploying the Current Solution

The frequency of solution deployment can be problematic if it is too slow or too fast. The impact of a too slow deployment schedule is a loss of business value. That is obvious. But a too frequent deployment schedule has several not so obvious negative impacts.

Support costs for multiple solutions

The problem arises because not every affected business process and practice will be executed using the updated solution. When a new solution is deployed does every affected business unit automatically switch to the updated solution. Probably not. So this adds support costs associated with multiple solutions in place at the same time. The resulting confusion is obvious.

Frequent process or practice changes

Change brings confusion among those who are affected by the changes. It is a matter of forgetting the old and taking up the new. Not so easy to do with frequent changes. Every organization has its own change velocity. How quickly can the organization accept and deploy change is the question.

Maintaining multiple versions of documentation

Version control has always been a problem especially when it involves software version control. The same problems exist for non-software version control. As long as there is one business unit using a release, the support services specific to that release must be in place and that includes training planning and scheduling too.

Requirements

Plan-driven project management models include complete requirements specification as a pre-requisite to the planning effort. That has forced guessing which leads to several requirements revisions during project execution and hence to plan revisions. There is a lot of waste and non-value added work in such approaches. This is not in keeping with lean practices.

Requirements and their elicitation have been a major obstacle to project management for several reasons:

In the complex project landscape, the upfront identification of requirements is unlikely because either or both of the goal or solution is usually not completely known.
Complete requirements specifications are learned and discovered during project execution.
The world is dynamic and ever changing and doesn’t stand still just because you are managing a project.

The ECPM Framework has mitigated this obstacle by modifying the accepted definition of a requirement. This definition begins with a high-level description of what an acceptable solution must provide from a performance aspect. In some cases, it defines what an acceptable solution must contain without any performance criteria added. To wit:

DEFINITION: ECPM Framework High-level Requirement

A specific end-state condition whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization.

The set of ECPM Framework high-level requirements forms anecessary and sufficient set for the attainment of all project success criteria and the delivery of the expected business value.

At the highest level of definition, I would expect the set to contain 6-12 such requirements. These are very high level and speak more towards what an acceptable solution should contain or be able to do. At this level, there is no expectation that those who drafted the high-level requirements would have any idea about how these requirements might be met or even if they can be met. That is part of the adventure of the complex project.

Agreement on the high-level requirements by both the developers and the client is critical to complex project management success. It sets a foundation for change management, decision making, and solution evaluation.

At any point during the project life span the solution is such that requirements are either:

Integrated into the solution
Under development for future integration into the solution
Not yet approved for integration into the solution but requires further study and analysis
Unlikely to be integrated into the solution without compromise

Known Requirements Breakdown Structure

As a result of the learning and discovery from completed cycles, additional requirements specifications will become available. Additionally, the project team will be able to formulate how the requirements can be built. That intelligence will be represented in a hierarchical decomposition called the Requirements Breakdown Structure (RBS). The RBS defines what will be in the solution. Further decomposition of the RBS is called the Work Breakdown Structure (WBS). The WBS defines the hierarchical decomposition of the work needed to accomplish every feature present in the RBS.

Figure 7.1 is a graphical representation of the RBS. Figure 7.2 is a graphical representation of the WBS which follows from the RBS.

Figure 7.1 The Requirements Breakdown Structure

The project begins with the high-level requirements identified. Any decomposition that is known at that time can be added. As each cycle is completed additional decomposition will often be added. The RBS will not be complete until the project is complete.

Figure 7.2 The Work Breakdown Structure

The Work Breakdown Structure (WBS) is a product of cycle planning. At some point in the RBS decomposition, an acceptable solution component will have been identified for inclusion into the current solution. The work needed to implement this solution component is defined during cycle planning.

Change Requests

Every cycle will result in new learning and discovery. This will result in requests for changes to requirements, functionality or other project adjustments. The changes might suggest changes to what has already been identified for addition to the solution or changes to potential solution components. They will usually arise from the client members of the project team. The intake process involves documenting them and adding them to the Scope Bank following the cycle in which they first arose. This list is cumulative and includes:

Change requests not yet acted upon – This list will be prioritized and continually updated whenever new change requests are added. That prioritization is usually based on expected business value.
Change requests scheduled for integration – While the actual scheduled cycle may be related to business value more than likely it will be because that cycle will be building deliverables related to the change request.
Change requests in the solution – It is important that the history of integrated change requests be kept for later reference. Project performance reports may well quantitatively compare that history at the cycle level.

Integrative Swim Lanes

Once a deliverable has been approved for integration into the solution it is prioritized along with others to be included in the solution. That prioritization is usually business value based, but other technical considerations will usually determine the cycle in which it will be included.

Built and scheduled for integration

Much like any Scope Change, the schedule is based on technical rather than business criteria. There will be exceptions when the expected business value or marketing benefits exceed the cost of implementation.

Integrated into the solution

It is important that the history of integrated change requests be kept for later reference. Project performance reports may well quantitatively compare that history at the cycle level.

Probative Swim Lanes

Probative Swim Lanes are unique to the ECPM Framework. They include a variety of experiments and other research projects. Most statisticians would see Probative Swim Lanes as just another design of experiments. I am one of those statisticians and would call Probative Swim Lanes primitive designs of experiments. Whatever you choose to call them, the idea here is to preserve the lean characteristics of the ECPM Framework. Probative Swim Lanes are often one of the following:

prototyping – trying out a number of ideas using different models
brainstorming – discussing alternatives and formulating approaches
researching – gathering information on possible approaches

The incremental search for a solution is that Probative Swim Lanes are sequentially linked. The objective is to spend time and money incrementally as ideas develop and earn further expense and time allocations rather than all at once on an untested idea. This is in keeping with the lean characteristics of the ECPM Framework.

Completed but not yet acted upon

Probative Swim Lanes can result in either solution increments to be built (future Integrative Swim Lanes) or result in dead ends (Probative Swim Lane Archives). In both cases, that history must be preserved. It is the best intelligence the project team will have as far as suggesting and executing future Probative Swim Lanes.

Active investigation

The history of a single Probative Swim Lane may include several efforts. Not until a decision is reached is that effort reaches a decision point. Defined but not yet been scheduled
Probative Swim Lanes that result in future additions to the solution have first to be added to the prioritized Integrative Swim Lane list.

PRINCE2 AND THE SCOPE BANK

The Scope Bank is an artifact of a lean framework and for that reason there will be a number of applications to PRINCE2 which is not a lean framework – at least not yet! The two primary applications of the Scope Bank to the PRINCE2 Framework are discussed below.

Stage Planning

The Scope Bank becomes more critical to effective complex project management as the uncertainty and complexity increases.

Uncertainty

The less we know about the goal and the solution, the higher the risk of failure and the more we will depend on the creativity of the project team. When the goal is clearly specified at the beginning of the project and the solution is not known there is no certitude that we will arrive at a solution that meets the expected business value. When the goal is not clearly defined and understood the more like it will be just a dream end state and not achievable as presently stated. For those projects, the goal and solution will converge to deliverables that may or may not achieve the expected business value.

Complexity

The less we know about the solution, the more complex will be the project. The end state is unpredictable.

How to proceed

Planning the next Stage draws on the documented history of the project as stated in the Scope Bank. The next Stage will include some mix of Integrative and Probative Swim Lanes.

PUTTING IT TOGETHER

The Scope Bank is the solution history of the project from its inception. The plans and deliverables from all of the completed cycles are recorded there. All of the change requests and their resolution are also documented. Cumulatively this information is the best available for cycle planning.

Bundled Change Management Process

Written by Robert Wysocki on February 24, 2016. Posted in Articles. 3 Comments on 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.

Viewing the PRINCE2 Project as a System in Balance: Decision-Making and Problem Solving

Written by Robert Wysocki on February 9, 2016. Posted in Articles. 5 Comments on Viewing the PRINCE2 Project as a System in Balance: Decision-Making and Problem Solving

The ECPM Scope Triangle was introduced in Part 1. In Part 2 we are going to discuss applications of this valuable tool.

The biggest and perhaps most important among the six variables that define the ECPM Scope Triangle is Resource Availability. It is clearly identified as a project, program and portfolio constraint in the ECPM Framework but is absent from the P2 Framework at the project level. The program and portfolio level are out of scope here.

There are just a few graphics used in the ECPM Framework that should be burned into your project management brain. They are intuitive and powerful decision-making tools. The ECPM Framework Scope Triangle is one of those graphics.

THE ECPM FRAMEWORK SCOPE TRIANGLE – A SYSTEM IN BALANCE

On the first day of a project, the project system is in balance. No work has been done yet. Due to the dynamics of the situation, this balance may be short-lived. Something changes that was either expected or not expected even though its timing may be unknown. Literally every change has a domino effect on the other variables and causes a change in one or more of the 6 variables. In order to restore balance to the project, a change in one or more of the other variables will have to be made. In that sense, the ECPM Framework Scope Triangle is a management tool for problem resolution, schedule repair, and change management. This systems view of project management is a useful problem-solving tool and change management tool and is explored in detail in the ECPM Framework book (Wysocki, Robert K., 2014, Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing). Its adaptation to P2 is discussed in this article. The Iron Triangle, which is not discussed in P2 or the ECPM Framework, does not offer such a rich interpretation.

{module ad 300×100 Large mobile}

The 6 variables that define the ECPM Framework Scope Triangle form an interdependent set of variables that define the project as a system in balance. To understand this interpretation, visualize the triangle as a geometric figure that encompasses an area (the area occupied by the scope and quality) that is bounded by the three sides of the triangle. Those sides are just long enough to encompass that area. If one of the sides should shrink (budget is reduced, schedule shortened or a previously scheduled resource is no longer available), then the reduced length of the corresponding lines are no longer sufficient to encompass the area defined by the scope and quality. The interpretation and its explanatory figure is conceptual. Don’t try to draw the triangle. It can’t be done. A very common situation arises from scope change request that increase scope. Decreases are rare. In these cases, the area occupied by scope expands and the sides of the triangle are no longer sufficient to enclose the larger area. Something has to change. The length of one or more lines must be increased (increased time or cost and/or more staff assigned to the project), so that the larger scope can be bounded by the larger triangle.

I have had over 25 years of client experiences using the ECPM Framework Scope Triangle. It has been a valuable addition to my project management toolkit, and I can recommend it to you especially if you are a P2 Practitioner or Professional.

PRIORITIZING THE ECPM FRAMEWORK SCOPE TRIANGLE VARIABLES

Except for risk, the other 5 variables can be prioritized as an assist to problem-solving, change management, and other management decision-making. The figure below is an example of one such prioritization schema. It applies to only one project. Every project is different. The matrix shows that the time constraint is the least flexible, and the cost constraint is the most flexible. Also, note that scope is quite flexible as should be the case for any complex project.

Prioritized ECPM Framework Scope Triangle Variables

When alternatives solutions to a problem or change management approval arise, this matrix is easily applied to help prioritize and then make the best choice. For example, in the figure above, since cost is the most flexible, choices that impact cost would receive a higher likelihood of being implemented than those that involve time or resources. Prioritization should be done during project planning to remove any bias that might arise from the problem solving or change management events. That prioritization exercise must involve the client, too.

Problem Solving & the ECPM Framework Scope Triangle

here are a variety of problem-solving models that are in common use. The one that I am recommending is simple and can be used in a variety of contexts within the ECPM Framework. It was developed by J. Daniel Couger (1995, Creative Problem Solving and Opportunity Finding, Boyd & Fraser Publishing Company) and aligns quite well with the divergent/emergent/convergent process used in the Ideation Phase of the ECPM Framework. The Couger model follows the linear process:

Step 1: Delineate opportunity and define problem
Step 2: Compile relevant information
Step 3: Generate ideas
Step 4: Evaluate and prioritize ideas
Step 5: Develop implementation plan

Something has happened that put the project plan at risk. Late shipments from suppliers, equipment malfunctions, sickness, random acts of nature, resignations, priority changes, errors, and a host of other factors can lead to problems that affect deliverables, deliverable schedules, and resource schedules. The project team owns the problem and must find a solution.

This situation is very different for the Project Manager in the case of a change request. When a change request has been made, the Project Manager has some leverage with the client. The client wants something and might be willing to negotiate an acceptable resolution. That is not the case when a problem arises on the project team. The Project Manager does not have any leverage and is in a much more difficult position.

When the unplanned happens, the Project Manager needs to determine who owns the problem and the extent of the problem, then take the appropriate corrective measures. Those measures often include helping the owner of the problem find an acceptable solution following the escalation hierarchy. Minor variations from the plan will occur and may not require corrective measures. There are degrees of corrective measures available to the Project Manager: In trying to resolve a problem, the Project Manager begins at the top of the escalation hierarchy and works down the hierarchy, examining each option until one is found that solves the problem.

The ECPM Framework Scope Triangle enables you to ask the question, ″Who owns what?″ The answer will give you an escalation pathway from project team to resource manager to client to sponsor. The client and senior management own time, budget, and resources. The project team owns how time, budget, and resources are used. Within the policies and practices of the enterprise, any of these may be moved within the project to resolve problems. In solving a problem, the Project Manager should try to find a solution within the constraints of how the time, budget, and resources are used. For these solutions, the Project Manager does not need to go outside of their sphere of control.

The next step in the escalation strategy would be for the Project Manager to appeal to the resource managers for problem resolution. The resource manager owns who gets assigned to a project as well as any changes to that assignment that may arise.

The final step in the problem escalation strategy is to appeal to the client and perhaps to the sponsor for additional resources. They control the amount of time and money that has been allocated to the project. Finally, they control the scope of the project. Whenever the Project Manager appeals to the client, it will be to get an increase in time or budget and some relief from the scope by way of scope reduction or scope release.

There are three levels of escalation strategy: project team–based, resource manager–based, and client-based.

Project Manager–Based Strategies

If the problem occurs within a non–critical path activity, it can be resolved by using available slack (Wysocki, Robert K., 2014, Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons). One example is to reschedule the activity later in its ES–LF window or extend the duration to use some of the available slack. Note that this strategy does not affect any other activities in the project. By using slack, you affect the resource schedule for all activities that have this activity as a predecessor.

Another approach is to continue the schedule compression techniques employed in defining the original project plan. This strategy can affect resource schedules just as in the prior case. The last option open to you is to consider the resource pool under your control as the Project Manager. Can some resources be reassigned from non–critical path activities to assist with the problem activity?

Resource Manager–Based Strategies

After you have exhausted all the options under your control as the Project Manager, it is time to turn to the resource managers for additional help. This help may take the form of additional resources or rescheduling of already committed resources. Expect to make a trade-off here. For example, you might be accommodated now, but at the sacrifice of later activities in the project. At least you have bought some time to resolve the downstream problem that will be created by solving this upstream problem. If you have other projects that you are currently managing, some trades across projects may solve the problem.

Client-Based Strategies

When all else fails, you will have to approach the client. The first option would be to consider any multiple-release strategies. Delivering some functionality ahead of schedule and the balance later than planned may be a good starting point. The last resort is to ask for an extension of time. This may not be as unpleasant as it seems because the client’s schedule may have also slipped and the client may be relieved to have a delay in your deliverable schedule, too.

The Escalation Strategy Hierarchy

The problem escalation strategy presented here is based on the premise that you, as the Project Manager, will try to solve the problem with the resources that you control. Failing to do that, you can appeal to your resource managers. As a last resort, you can appeal to the client.

One thing to note here that is very different from the change request situation discussed previously is the leverage to negotiate. As mentioned, you, as the project manager, have leverage when the client has requested a change, but no leverage when you have a project problem to solve. The client has nothing to gain and is, therefore, less likely to be cooperative. In most cases, the problem can be reduced to how to recover lost time. The following six outcomes are possible to this problem situation:

No action required (schedule slack will correct the problem)—In this case, the slippage involved a non–critical path activity and it will self-correct.
Examine FS dependencies for schedule compression opportunities—Recall that you originally compressed the schedule to accommodate the requested project completion date by changing FS dependencies to SS dependencies. You should use that same strategy again. The project schedule will have changed several times since work began, and there may be several new opportunities to accomplish further compression and solve the current problem.
Reassign resources from non–critical-path activities to correct the slippage—Up to a point, you control the resources assigned to this project and others that you manage. You may be able to reassign resources from non–critical-path activities to the activities that have slipped. These non–critical-path activities may be in the same project in which the slippage occurred or they may be in another project that you manage.
Negotiate additional resources—Having exhausted all of the resources that you control, you need to turn to the resource managers as the next strategy. To recoup the lost time, you need additional resources. These resources may come in the form of added staff or dollars to acquire contract help.
Negotiate multiple release strategies—This strategy involves the client. Just as in the case of a change request, you can use a multiple-release strategy to your advantage. An example will illustrate the strategy: The project manager shares the problem with the client and then asks for the client to prioritize the features requested in the project plan. The project manager then offers to provide the highest-priority features ahead of their scheduled delivery date and the remaining priorities later than the scheduled delivery date. In other words, the project manager gains an extended delivery schedule but gives the client something better than the original bargain offered—namely, something ahead of schedule.
Request a schedule extension from the client—This is the final alternative. Although it’s similar to the multiple-release strategy, it offers the client nothing in trade. The slippage is such that the only resolution is to ask for a time extension.

You, as the project manager, should try to solve the problem by starting at the top of this list of six outcomes and working down until a solution is found. By using this approach, you will first try to solve the problem with resources that you control, then with resources that the resource managers control, and finally with resources and constraints that the client controls.

Change Management & the ECPM Framework Scope Triangle

The ECPM Framework recommends a Bundled Change Management Process. Simply put, all decisions regarding proposed scope changes are held until the Client Checkpoint Step. This is different from the traditional approach. To handle change requests as they arise, as is done in the P2 Framework, is not a lean practice. During the Client Checkpoint Step, all proposed scope changes that have not yet been acted upon are considered together. These will include past requests that have not yet been processed as well as requests that arose during the just completed cycle. From among those change requests some will be approved and available for scheduling, others will be rejected, and others will be held for later decisions.

PUTTING IT TOGETHER

We have taken the static Iron Triangle and turned it into a dynamic tool – the ECPM Scope Triangle. All of this is possible because the ECPM Scope Triangle is really a conceptual depiction of a system in balance. It stresses the dependence of the 5 variables that define it.

As a system in balance, it is an aid to P2 LEAN Project Management as it supports problem solving, decision making and change management.