The Scope Bank is the clearinghouse for all project activities. It brings together in one place solution status, cycle performance history, potential solution components and a foundation for cycle 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.
Scope change requests will arise at any time during a cycle but their resolution is held until the cycle is complete and its deliverables reviewed. 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 its projects.
The Scope Bank is the single depository for the current requirements. It contains open change requests, the current solution, and all learning and discovery that has been accumulated from all cycles that have 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.
Nothing should ever 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. The contents of the Scope Bank are updated at the completion of each cycle. 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.
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.
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 lifespan. The item descriptors listed above are most useful for scope change requests and processing but otherwise are provided as appropriate.
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
- The Business Value from the Current Solution
- The Challenge of Deploying the Current Solution
- Support costs for multiple solutions
- Frequent process or practice changes
- Maintaining multiple versions of documentation
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 are 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 a necessary and sufficient set for the attainment of all project success criteria and the delivery of the expected business value.
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
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
- Change requests scheduled for integration
- Change requests in the solution
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.
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 to first be added into the prioritized Integrative Swim Lane list.
PUTTING IT ALL 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.