now browsing by tag
The Scope Bank is unique to the Effective Complex Project Management (ECPM) Framework, and it functions as the traffic cop and depository of the solution discovery and development history.
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.
The Scope Triangle is an interesting artifact of project management planning.
The term is not used in PMI’s PMBOK® Sixth Edition. The closest the PMBOK comes is to list scope, quality, schedule, budget, resources and risk as the constraints that impact the project. PMBOK goes on to say that these constraints form an interdependent set in that if one changes at least one other will be affected. In this 3-part article paper we will develop the Scope Triangle and show how it can be used in project management training.
Representing the Project
There are two ways to graphically envision the project that have been described in the literature. They are briefly described below.
The Iron Triangle
I cannot find the source for this term but it has come to mean the relationship between cost, time and scope (Figure 1). As is the case with the six constraints identified in PMBOK these three constraints also form an interdependent set. Specify any two and the third is determined. Or to put it another way if your manager says something like “I want you to develop a web-based order entry system for the new widget line and I will need it operational in 2 months. You have a budget of $50,000 to cover all one-time development costs,” you probably can’t do it. The chances that these three constraints form a consistent set are unlikely. Better would be “I need you to develop and order entry system for the new widget line and I need it operational in 2 months. How much will it cost to develop?”
While Figure 1 may be an intuitive way to envision the project plan it has little value in project execution.
The Scope Triangle
The Scope Triangle (Figure 2) was first introduced in my training programs in the 1980s and subsequently published it in the first edition of my book “Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget,” (Wysocki, Robert K, Robert Beck, Jr. and David B. Crane, 1995, New York, NY: John Wiley & Sons, Inc. ISBN 0-471-11521-5). The intention then was to illustrate with a simple graphic that the project plan was a system in balance, at least on day one of the project.
The interpretation is rather intuitive, which is why there has been excellent instructional value in using it. The Scope and Quality are exactly bounded by the length of the three sides of the triangle representing cost, time and resource availability. Don’t try to draw the Scope Triangle. It is conceptual only. Given that the project plan makes sense on day one of the project the project plan is a system in balance. If any one of the five variables changes, at least one other variable must change in order to restore balance to the system. For example, if the client changes the due date of the deliverables to an earlier date, the length of the time side is reduced and the three sides no longer enclose Scope and Quality. To restore balance to the system anyone of several variables could change. For example, Scope could be reduced or the budget increased to hire outside contractors or some combination of the two.
Figure 2 is a useful way to envision the project plan and it has good value in maintaining the project plan, handling problem situations and managing scope change requests as is discussed below.
Using the Scope Triangle as a Management Tool
The Scope Triangle has been used in training programs for over 25 years. It is a good model in which to imbed and teach the following three project management activities.
Managing Scope Change
In the traditional approaches to project management a formal scope change process is needed. Most processes start with a request from the client. The appropriate team member will analyze the request and issue a Project Impact Statement in which alternatives and their impact on the project plan are documented. The client chooses one and the project plan is updated to reflect the chosen alternative.
The Scope Triangle is used to prioritize the alternatives from those that affect only the project team and the resources it controls to those that affect the resource managers to those that affect the client through added cost or schedule adjustments.
Problems are sure to arise in even the best planned projects. Schedule delays, supplier shipment errors, loss of a scarce resource and a variety of risks that materialize and must be handled. There is a hierarchy of resolutions (related to the Scope Triangle) that are offered in the order listed:
- Accommodated within project resources and timelines
- Accommodated but will require extension of deliverable schedule
- Accommodated within the current deliverable schedule but additional resources will be needed
- Accommodated but additional resources and extension of deliverable schedule will be needed
- Accommodated with multiple releases and prioritization of deliverables across release dates
- Cannot be accommodated without significant change to the project
Representing the Project Portfolio
Recent application of the Scope Triangle deal with some basic concepts of project portfolio management especially agile portfolio management. In the Scope Triangle shown in Figure 2 replace the inside of the triangle with all of the projects vying for inclusion in the portfolio. The initial proposed projects will most likely require more time, or money or more human resources available at that time.
Think of removing the proposed projects in some reversed prioritized order until each of the three bounding constraints are all met. The prioritized order will be based on some combination of risk and business value.
Putting It All Together
The Scope Triangle is a valuable tool for teaching scope management, problem resolution and portfolio management concepts. It is an intuitive graphic that every project manager should burn into their brain to help them approach the three applications with a much better strategy.