Tag: PRINCE2

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 Pros and Cons of Working Outside Your Comfort Zone

Written by Brad Egeland on March 16, 2016. Posted in Articles. 3 Comments on The Pros and Cons of Working Outside Your Comfort Zone

We often find ourselves working on the familiar things, things we have had repeated success with and things where we are least likely to fail.

We often like to stay in our comfort zone, going with what we know. That’s the easy route. The projects may not always end successfully, but we go into them knowing more and start with a greater chance of success.

It’s easy to start familiar projects with confidence, to win our clients over right out of the gate and start fresh with a new project team knowing we are going down a familiar path. The confidence we start these projects with shows to our customers, and it certainly makes it easier to get these projects off on the right foot because we know what we are doing – there really isn’t any learning curve. But keep in mind there really isn’t much career or professional growth involved, either.

On the other side of the fence, going outside our comfort zone can feel awkward, cause us great concern and stress, and if not handled properly, cause our customers concern and stress as well if we appear to lack confidence. Let’s look at the pros and cons of taking on projects within and outside of our professional comfort zone.

The Pros

Going outside of our comfort zone and immediate areas of knowledge can serve several very positive purposes including:

{module ad 300×100 Large mobile}

Knowledge gain. By going outside our comfort zone, we can acquire new knowledge, try new strategies, test new technology and keep challenging ourselves. At the same time, we bring new project capabilities to our organization’s project offerings.

Expansion of client base. By going outside our comfort zone, we can appeal to a broader client base. As a consultant, I’ve been able to do that by attracting customers that may not be very related to project management and / or professional services. As a project manager, I’ve done that by leading projects for clients outside the area of normal usage for our products and services, thus expanding our niche in the industry and our client base at the same time.

Expansion of services offered. When we go outside our comfort zone, we are open to new and innovative requests from our current project clients. I’ve had several innovative clients ask for services or content that I had not worked on previously, but in the long run, it greatly increased my service offerings to all clients and, therefore, my revenue as well as my service offerings became even broader and more appealing.

The cons

Obviously, there are some very good reasons for going outside of our comfort zones. But with this shift in focus outside of our comfort zone and immediate areas of expertise, comes a realization of a few potential risks. What these are and how we deal with them are specific to our industry, service niche, and the types of customers we are working with, but some general ones that come to mind include:

Vulnerability to cyber crime or data breaches due to working outside expertise and safety zone. Let’s assume that you and / or your organization are as tuned into cyber security as you may claim. Even if you are, once you stroll outside your area of comfort and expertise you may also be taking a walk outside your area of data and data center protection. If you are going where no man in has gone before in your organization, that doesn’t mean you aren’t going right where the hackers find you the most vulnerable. And we now know that everyone and everything can eventually be hacked we are all merely just trying to catch up with the hackers at all times. They are ahead of us, not vice versa, no matter what your IT guys claim.

Increased project failure potential. Project failure happens more frequently than we care to admit and accept anyway, even when we are operating within our comfort zone and areas of expertise. Once we venture outside of that and take on projects in unfamiliar surroundings using unfamiliar technologies with customers in new industries that we haven’t worked in before, we increase the possibility of project failure – at least at first – exponentially. It’s ok, you have to start somewhere, just be mentally prepared and do some extra risk planning just in case.

Winning these projects may be a tougher sell. If you’re used to winning projects easily within your comfort zone, you may need to check your ego at the door and be ready to face some rejections. When asked what credentials you have to take on these new and different projects, don’t lie. But be ready to be heavily questioned by cautious potential clients as to why they should go with you over ‘x’ competitor who has expertise in this particular area where you are lacking. Do research and be ready to respond to such questions. They will come.

Summary / call for input

I’ll be the first to admit; I ‘m not usually one who likes to go outside my comfort zone. At least, I wasn’t most of my life – I’ve gotten better at it in recent years. I even liked to take the same vacations over and over again. Trying new foods? Never. Now – fortunately, or, unfortunately, depending on how you look at it – there isn’t much I won’t eat. Thankfully, my wife is a great cook and takes pride in serving our large family healthy food, so my new lack of pickiness has made her very happy. I’ve managed to take that same open mind into the things I do professionally – including the projects I work on and the customers and technology I work with. It’s opened me up to new project and consulting opportunities, helped increase my revenue and the revenue of the organizations that I work with, and it’s made me a better and more well-rounded professional.

How about our readers? Are you comfortable outside your general area of expertise? Are you comfortable learning new things? Have you taken on projects for your organization that were outside either your comfort zone or the organization’s normal area of focus? How did it go? What did you learn?

The Scope Bank: A PRINCE2 Stage Management Tool

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