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

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.