Skip to main content

Author: Robert Wysocki

Viewing the PRINCE2 Project as a System in Balance: Using the ECPM Scope Triangle

PART 1: Defining the ECPM Scope Triangle

This is the first of a two-part article. The “Iron Triangle” has been a mainstay in project management for many years but its value in the complex project landscape is limited.

This is not an article about the “Iron Triangle.” Rather it is an article about its contemporary replacement – the “ECPM Framework Scope Triangle.” This Scope Triangle offers a systems view of complex projects and their effective management. As such it provides the ECPM Framework with a tool to support problem-solving, change management and business decision-making. That same tool can be applied to the PRINCE2 Framework with equal impact.

To begin our discussion know that there is a significant difference between the project variables defined in PRINCE2 (Costs, Timescales, Quality, Scope, Risk and Benefits) and those defined in the ECPM Framework (Cost, Schedule, Resource Availability, Quality, Scope and Risk).

Note that PRINCE2 includes Benefits and the ECPM Framework does not. Benefits are defined within the business value that is generated from the project deliverables and in the Business Case that justified the project.

The biggest and perhaps most important variable is Resource Availability. It is clearly identified as a project, program and portfolio constraint in the ECPM Framework but is absent from the PRINCE2 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 – DEFINING VARIABLES

The ECPM Framework includes the Iron Triangle (Cost, Schedule, Scope define the three sides of the Iron Triangle) but it is much more than that. It is a system defined by the 6 variables shown below

fig 5.1 ECPM Scope Triangle

Risk

Risk overshadows the other 5 variables in the ECPM Framework Scope Triangle. It can impact any of the other 5 variables. In the complex project landscape, risk is so impactful and potentially damaging that one of the team members should be given responsibility for risk management. Assigning that responsibility is essential to effective complex project management. The responsibility spans the entire project life cycle and therefore the risk management life cycle from Identification to Assessment to Mitigation to Monitoring. A risk management plan is developed with the collaboration of the project team. Recall that the project team includes decision-making responsibilities of the client and so risk management decisions are also client decisions. Risk is continuously monitored and reported upon at each project status meeting.

Quality

The project deliverables and the process that produced them will have been defined as part of project requirements elicitation. There is also an implied “fitness for use” against which the process and the product are measured.

The following two types of quality are part of every project:

  • Product quality: As used here “product” includes tangible artifacts like hardware and software solutions as well as business processes. The traditional tools of quality assurance and quality control are used to ensure product quality. In a complex project situation product quality is an evolving quality. Incremental solution development must include a continuous review of the convergence of product quality as measured against product performance requirements.
  • Process quality: Process quality is the enabler of product quality and for that reason it should continuously reflect a best effort. The focus is on how well the project management process works for this project; how it can be improved for this project, and how it can be improved for future projects. A continuous process improvement program for complex project management must be in place.

A sound quality management program with processes in place that monitor the work in a project is a good investment. Not only does it contribute to client satisfaction, but it helps organizations use their resources more effectively and efficiently by reducing waste and revisions. Quality management is one area that should not be compromised. The payoff is a higher probability of successfully completing the project and satisfying the client.

Scope

Simply put, scope defines what is in the project and what is not in the project. Much of this can be described through a necessary and sufficient set of project requirements.

Scope is a statement that defines the boundaries of the project. It tells not only what will be done, but also what will not be done. In the information systems industry, scope is often referred to as a functional specification. In the engineering profession, it is generally called a Statement of Work (SOW). More generally it has been called Project Overview Statement (POS), Project Initiation Document (PID), Document of Understanding (DOU), Scoping Statement, Project Charter, or Project Request are also in common use. PRINCE2 projects begin with a Project Mandate. Project Mandate precedes the PID which is also part of the PRINCE2 Framework. The POS is part of the ECPM Framework Ideation Phase. It is quite similar to the PID but there are some distinct differences too.

Whatever its name, this document is the foundation for all project work to follow. It should be the primary input for all project performance reviews, status meetings, change request approvals and problem resolution. For that reason, it is critical that the scope be correct and be up to date. Beginning a project on the right foot is important, and so is staying on the right foot. It is no secret that a project’s scope can change. In the complex project world, you do not know how or when, but scope will change. Detecting that change and deciding how to accommodate it in the project plan are major challenges for the complex project manager.

Cost

The dollar cost of doing the project is another variable that defines and constrains the project. This includes not only the development costs but also the ongoing maintenance costs of the deliverables. Total cost is a variable often used in project prioritization processes. Cost is best thought of as the budget that has been established for the project. This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.

Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project. The client can simply offer a figure about equal to what he or she had in mind for the project. Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project. Consultants often encounter situations in which the client is willing to spend only a certain amount for the work. In these situations, you do what you can with what you have. In more formal situations, the project manager prepares a proposal for the projected work. That proposal includes an estimate (perhaps even a quote) of the total cost of the project. Even if a preliminary figure has been supplied by the project manager, the proposal allows the client to base his or her go/no-go decision on better estimates.

Schedule

The client specifies a time frame or deadline date within which the project must be completed. To a certain extent, cost and time are inversely related to one another. The time a project takes to be completed can be reduced, but costs will increase as a result. The schedule reflects not only the timeframe within which the project is executed but also the labor hours needed to produce the deliverables within that timeframe. That extends the reach of the schedule into the commitments made of resource utilization across that schedule. That is the root cause of most resource contention problems that arise during the ECPM Framework Project Execution Phase.

Time is an interesting resource. It can’t be inventoried. It is consumed whether you use it or not. The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible. Future time (time that has not yet occurred) can be a resource to be traded within a project or across projects. Once a project has begun, the prime resource available to the project manager to keep the project on schedule or get it back on schedule is time. A good project manager realizes this and protects the future time resource jealously.

Resource Availability

The resources are any finite consumables (people, rooms, computer time, equipment, etc.). In the short run there is only limited capacity of each resource. Some of it has already been allocated to other in-process projects as well as committed to future projects. Resource Availability deserves considerable discussion as it is a constraining variable that impacts all the other variables as well as active and to be approved projects. At the enterprise level, Resource Availability is the link to portfolio management in that the resources are finite, at least in the short run and are allocated across all approved projects by virtue of the strategic plan. So while there are constraints that operate on a single project (time, for example), Resource Availability is a constraint that is binding across the entire project portfolio. It is the ultimate enabler of the strategic plan! It is the binding constraint across all projects in the portfolio. 

In many organizations, Resource Availability is not taken into account when projects are approved for execution. Resource Availability encompasses both skill availability and schedule availability. 

  • Skill availability means that the project portfolio should be balanced with respect to skill and competency requirements. If every project required only senior project managers, what do you do with the junior project managers? That further begs the question about proposed resource requirements for the project. Trade-offs and between project manager negotiations for skills and competencies of the team members are common. 
  • Schedule availability is a bit more forgiving in that schedules can be adjusted to remove resource conflicts. That requires attention to the critical path and slack management. Another tool that has helped is “Management Reserve.” It will be discussed in a future article.

Not taking these two availabilities into account as part of project approval becomes a major obstacle to project completion because it leads to resource contention problems and scheduling conflicts during project execution. In other words, it throws the project system out of balance. Project Portfolio Management is out of scope for PRINCE2 at the project level and resource contention is not even considered as a factor in project approval. Even though the Project Board may have knowledge of available resources, these considerations do not appear explicitly in the PRINCE2 Framework. The situation is different at the Program and Portfolio levels. It is clear from the above discussion that a sound human resource management process is critical to project plan achievement. Unfortunately not too many organizations can boast of having such a process in place. Commercial products fall short of meeting the complex project management requirements.

Including resource management during ECPM project planning as a constraining variable is straightforward as long as the appropriate Resource Managers are invited to participate in the planning activities. They have command of the resource schedule and intimate knowledge of the availabilities and capacities of their resource inventory and can make informed decisions about resource availability for both current and future projects. It is not obvious that the PRINCE2 project team has those resource managers in attendance.

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 PRINCE2 is discussed in this article. The Iron Triangle, which is not discussed in PRINCE2 or the ECPM Framework,  does not offer such a rich interpretation.

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 are 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 PRINCE2 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.

fig 5.2 Prioritized Scope Triangle cropped

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 Figure 4.2, 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. Variables 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.

PUTTING IT TOGETHER

The ECPM Scope Triangle is now defined. It will have a number of applications to PRINCE2 as will be discussed in the second part of this article.

Scope

Simply put, scope defines what is in the project and what is not in the project. Much of this can be described through a necessary and sufficient set of project requirements (see Article 3: Elicitation of High-level Requirements).

Scope is a statement that defines the boundaries of the project. It tells not only what will be done, but also what will not be done. In the information systems industry, scope is often referred to as a functional specification. In the engineering profession, it is generally called a Statement of Work (SOW). More generally it has been called Project Overview Statement (POS), Project Initiation Document (PID), Document of Understanding (DOU), Scoping Statement, Project Charter, or Project Request are also in common use. PRINCE2 projects begin with a Project Mandate. Project Mandate precedes the PID which is also part of the PRINCE2 Framework. The POS is part of the ECPM Framework Ideation Phase. It is quite similar to the PID but there are some distinct differences too.

Whatever its name, this document is the foundation for all project work to follow. It should be the primary input for all project performance reviews, status meetings, change request approvals and problem resolution. For that reason, it is critical that the scope be correct and be up to date. Beginning a project on the right foot is important, and so is staying on the right foot. It is no secret that a project’s scope can change. In the complex project world, you do not know how or when, but scope will change. Detecting that change and deciding how to accommodate it in the project plan are major challenges for the complex project manager.

Cost

The dollar cost of doing the project is another variable that defines and constrains the project. This includes not only the development costs but also the ongoing maintenance costs of the deliverables. Total cost is a variable often used in project prioritization processes. Cost is best thought of as the budget that has been established for the project. This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.

Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project. The client can simply offer a figure about equal to what he or she had in mind for the project. Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project. Consultants often encounter situations in which the client is willing to spend only a certain amount for the work. In these situations, you do what you can with what you have. In more formal situations, the project manager prepares a proposal for the projected work. That proposal includes an estimate (perhaps even a quote) of the total cost of the project. Even if a preliminary figure has been supplied by the project manager, the proposal allows the client to base his or her go/no-go decision on better estimates.

Schedule

The client specifies a time frame or deadline date within which the project must be completed. To a certain extent, cost and time are inversely related to one another. The time a project takes to be completed can be reduced, but costs will increase as a result. The schedule reflects not only the timeframe within which the project is executed but also the labor hours needed to produce the deliverables within that timeframe. That extends the reach of the schedule into the commitments made of resource utilization across that schedule. That is the root cause of most resource contention problems that arise during the ECPM Framework Project Execution Phase.

Time is an interesting resource. It can’t be inventoried. It is consumed whether you use it or not. The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible. Future time (time that has not yet occurred) can be a resource to be traded within a project or across projects. Once a project has begun, the prime resource available to the project manager to keep the project on schedule or get it back on schedule is time. A good project manager realizes this and protects the future time resource jealously.

Resource Availability

The resources are any finite consumables (people, rooms, computer time, equipment, etc.). In the short run there is only limited capacity of each resource. Some of it has already been allocated to other in-process projects as well as committed to future projects. Resource Availability deserves considerable discussion as it is a constraining variable that impacts all the other variables as well as active and to be approved projects. At the enterprise level, Resource Availability is the link to portfolio management in that the resources are finite, at least in the short run and are allocated across all approved projects by virtue of the strategic plan. So while there are constraints that operate on a single project (time, for example), Resource Availability is a constraint that is binding across the entire project portfolio. It is the ultimate enabler of the strategic plan! It is the binding constraint across all projects in the portfolio.

In many organizations, Resource Availability is not taken into account when projects are approved for execution. Resource Availability encompasses both skill availability and schedule availability.

Ø  Skill availability means that the project portfolio should be balanced with respect to skill and competency requirements. If every project required only senior project managers, what do you do with the junior project managers? That further begs the question about proposed resource requirements for the project. Trade-offs and between project manager negotiations for skills and competencies of the team members are common.

Ø  Schedule availability is a bit more forgiving in that schedules can be adjusted to remove resource conflicts. That requires attention to the critical path and slack management. Another tool that has helped is “Management Reserve.” It will be discussed in a future article.

Not taking these two availabilities into account as part of project approval becomes a major obstacle to project completion because it leads to resource contention problems and scheduling conflicts during project execution. In other words it throws the project system out of balance. Project Portfolio Management is out of scope for PRINCE2 at the project level and resource contention is not even considered as a factor in project approval. Even though the Project Board may have knowledge of available resources, these considerations do not appear explicitly in the PRINCE2 Framework. The situation is different at the Program and Portfolio levels. It is clear from the above discussion that a sound human resource management process is critical to project plan achievement. Unfortunately not too many organizations can boast of having such a process in place. Commercial products fall short of meeting the complex project management requirements.

Including resource management during ECPM project planning as a constraining variable is straightforward as long as the appropriate Resource Managers are invited to participate in the planning activities. They have command of the resource schedule and intimate knowledge of the availabilities and capacities of their resource inventory and can make informed decisions about resource availability for both current and future projects. It is not obvious that the PRINCE2 project team has those resource managers in attendance.

P2 Lean: Are You a Cook or a Chef?

PRINCE2 was designed and deployed before the Agile, Adaptive, and Lean movements were the topics of conversation among the project management thought leaders. Fortunately, PRINCE2 was designed as an adaptive framework with the claim that it could adapt to any type of project. PRINCE2 calls this adaptation “tailoring.”

Tailoring is required in order to adapt the activities to the needs of the project, but it requires the inclusion of every activity to some degree. In this article, I take exception to that requirement with a justification for taking that exception. So PRINCE2 was predisposed to accommodate Lean and Agile variations with minimal disruption. In fact, that can and does happen, but it places a burden on the Project Manager because PRINCE2 does not provide the tools to build those variations. Those who are the architects of PRINCE2 have a choice to make. Leave it to Project Managers to figure out how to adapt PRINCE2 to meet the Lean or Agile requirements. PRINCE2 Agile (Richards, 2015) takes an initial step in that direction. Alternatively, the PRINCE2 architects could equip PRINCE2 with the tools, templates, and business processes needed to create a templatized version of PRINCE2 that is both Lean and Agile. This does not align with the scope of PRINCE2 and is not likely to happen. In designing PRINCE2 LEAN we choose this latter approach. That is the purpose of the series of articles we are now publishing here and next year will publish a more detailed version in book form (Wysocki and Bentley, 2016, (tentatively titled: PRINCE2 LEAN: A Practical and Effective Framework for Increasing Project Performance and Delivered Business Value, under contract with J. Ross Publishing). This article only scratches the surface of an innovative and creative approach to improving PRINCE2 project performance. The details, and there are many, are left for the forthcoming book.

BACKGROUND

PRINCE2 (P2) dates from 1975 with the development of PROMPT II by a team whose members included Colin Bentley. He was also a major contributor to the 1996, 2005 and 2009 editions of the P2 Manual. Colin was the Lead Reviewer and Mentor of the 2009 edition and P2 Chief Examiner from 1998-2008. Colin is still active in the profession. He and I have joined forces on the development of P2 LEAN. That is a work in process and promises practical and effective project performance improvements and delivered business value through P2 LEAN.

P2 has been an unqualified success since its introduction in 1975. It is an adaptive framework adopted by the UK Government in 1989 as the standard for all IT project management. It quickly expanded outside the IT domain and is now used in most industries. The name PRINCE2 was adopted in 1996. Today P2 is used in over 150 countries. It’s application in the U.S. is recent and growing especially among companies with significant operations or headquarters in the EU.

The ECPM Framework is another adaptive framework. Three books document the entire development history of the ECPM Framework (Wysocki, 2010), (Wysocki, 2014a) and (Wysocki,2014b). That history has evolved out of actual client engagements and aligns with the accepted practices.

P2 LEAN

The P2 and the ECPM Frameworks have a number of features in common as well as several differences too. It is those differences that prompted us to eventually develop P2 LEAN. There are 8 artifacts in the ECPM Framework that when integrated into P2 result in P2 LEAN. This article series discusses many of the tools, templates and processes of P2 LEAN. This is my effort to “reach across the pond” and take selected artifacts from the ECPM Framework and show how they can be integrated into the P2 Framework for improved performance and delivery of expected business value.

defn p2 lean

This article contains the first published description of P2 LEAN. In the forthcoming book we will create a definitive work on not only “WHAT” processes and activities are contained in P2 LEAN but “WHEN” and “HOW” these processes and activities can be executed. In the spirit of lean, the “HOW” will come in several flavors (i.e., versions). For example, consider the Risk Management Model. In the smallest and simplest of projects that might be a simple risk/reward (low, medium, high) matrix. As project size, complexity and uncertainty increases that Risk Management Model might be replaced with probabilistic models, multi-criteria scoring models or sophisticated weighted criteria models. These versions are driven by three critical components of every project situation:

  • the defining characteristics of the project itself
  • the environment and culture of the organization as both the consumer of the project deliverables and the producer of the deliverables for the market
  • the market situation viewed as a dynamic entity embracing both the buyer and seller communities

These components define a project landscape that is a continuum that ranges from the small and simple projects to projects of increasing complexity and uncertainty. As you move across this landscape the frequency, depth and sophistication of the tools, templates and business processes used in P2 LEAN increases. There will be business rules for choosing the “WHAT” and “HOW” for a variety of project management situations. The other tools, templates and business processes would have similar choices ordered by project “size, complexity, uncertainty.” In the spirit of lean principles we don’t want to put the project manager in the position of “killing mosquitoes with sledge hammers!” Rather, they should have the flexibility of choosing the appropriate weapons for the situation.

We leave open the question about using or not using a particular activity. The answer is provided by the co-managers and is based on the value added from using the activity to the total cost of using it. So in P2 LEAN a P2 activity can be used, modified, replaced with an equivalent tool. template or process, or not used at all. We recognize that this is not the P2 way and will be viewed by some as heretical. But our retort is that the P2 LEAN co-managers are responsible for delivering a successful project not for having followed a prescribed process. We live and work in a project environment that requires flexibility and creativity. However, P2 LEAN is not a free for all effort. The co-managers decide to manage and they do so within a portfolio of vetted tools, templates and processes. To do otherwise would border on chaos!

The burden of a completely vetted portfolio rests with senior management. That is a daunting task and some accommodations must be made for those cases where the vetted portfolio may be lacking. Clearly, no one can possibly anticipate all conditions that can occur in the execution of a project and hence how these conditions must be managed. So the co-managers need the flexibility to adapt the vetted portfolio with justification for their actions provided. Despite best efforts a fixed set of activities and the supporting vetted portfolio can never fit all projects.

For the P2 LEAN practitioner and professional, project success trumps adherence to process – always!

P2 LEAN offers a new approach to managing complex projects. Despite its uniqueness P2 LEAN is conceptually aligned with contemporary management thought. For example, it aligns to the 7 Lean Principles (Poppendieck & Poppendieck, 2003):

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole

It also aligns to the 7 Principles of Continuous Innovation (Denning, 2011):

  • Principle #1: Focus Work on Delighting the Client.
  • Principle #2: Do Work through Self-Organized Teams
  • Principle #3: Do Work in Client-Driven Iterations
  • Principle #4: Deliver Value to Clients Each Iteration
  • Principle #5: Be Totally Open about Impediments to Improvement
  • Principle #6: Create a Context for Continuous Self-Improvement
  • Principle #7: Communicate through Interactive Conversations

So P2 LEAN is well-suited for the management challenges of the complex project landscape. Its name says that in some way it is a “more efficient” version of P2, and it is, but through that difference it opens the door to agile and adaptive instantiations of P2. P2 LEAN is an agile and adaptive framework. It is not just another version of P2 Agile. It is that and much more too!

SETTING-UP A P2 LEAN PROJECT

P2 LEAN incorporates the three-phased ECPM Framework (Figure 4.1). Those phases are: IDEATION, SET-UP and EXECUTION.

corpdiagram
Figure 4.1: P2 and ECPM Framework Overlay

Note that the P2 SU Process overlaps both the ECPM IDEATION and SET-UP Phases. Other than that aberration the two frameworks are parallel in purpose but different in deployment. That proves to be a great strength in P2 LEAN and we have fully exploited it. The 8 artifacts from the ECPM Framework align perfectly with the P2 management process structure as shown below.

SU: Co-Manager Model
SU: High-level Requirements Definition
IP: Scope Triangle
DP: Client Checkpoint
SB: Probative & Integrative Swim Lanes
SB: Client Checkpoint
CS: Scope Bank
CS: Vetted Portfolio of Tools, Templates and Processes
MP: Bundled Change Request Process
CP: Client Checkpoint

These 8 artifacts are discussed in detail in the article series along with how they can integrate with P2. Further details are included in the forthcoming book.

BOTTOM-UP CONSTRUCTION OF A P2 LEAN MODEL

Across the 7 P2 Processes there are 50 separate Activities that are part of P2 LEAN. 40 of the Activities are defined in P2. The additional 10 Activities result from integrating the 8 artifacts from the ECPM Framework The P2 LEAN Activities are listed below.

Directing a Project (DP)
A Authorize Initiation
A Authorize the project
A Authorize a Stage or Exception Plan
C Give ad hoc direction
C Authorize project closure

Starting Up a Project (SU)

A Appoint the Executive and Co-Managers
D Capture previous lessons
C Prepare the outline Business Case
A Design and appoint the project management team
C Select the project approach and assemble the Project Brief
A Choose and adapt the best fit PMLC Model
B Write the Business Case
A Identify High-level Requirements
A Define the Project
A Write the Project Overview Statement
B Plan the Initiation Stage

Initiating a Project (IP)

B Prepare the Risk Management Strategy
B Prepare the Quality Management Strategy
C Prepare the Configuration Management Strategy
C Prepare the Communication Management Strategy
C Set up the project controls
A Select and Adjust PMLC Model
A Create the Project Plan
D Refine the Business Case
A Assemble the Project Initiation Document
Controlling a Stage (CS)
B Escalate issues and risks
C Report highlights
D Review the Stage status
A Take corrective action
B Capture and examine issues and risks
A Conduct Bundled Change Management
A Authorize Work Packages
C Review Work Package status
A Receive completed Work Packages
Managing Product Delivery (MP)
B Accept Work Package
B Execute a Work Package
A Deliver a Work Package

Managing a Stage Boundary (SB)

C Update Business Case
A Report Stage end
C Produce an Exception Plan
C Update the Project Plan
A Plan the next Stage
A Ending a Cycle
A Update Project Scope Bank
A Plan Probative Swim Lanes

Closing a Project (CP)

C Prepare planned closure
C Prepare premature closure
A Hand over products
D Evaluate the project
D Recommend project closure

The labels A through D are ordered from most significant to least significant. So that the “A” Activities are required of even the smallest and simplest of projects. As the project becomes larger, more complex or uncertain “B” Activities are added, then “C” and finally “D.” This classification scheme is based on the MoSCoW rule. This classification of Activities is of course subjective and using an Activity is really a decision that the project co-managers will make on a project by project basis. The co-managers are concerned about how, by using an Activity, they add value to the project. Value can be measured in several ways. If that value exceeds the effort required to use the Activity, the Activity should be used. Even at that, it is still up to the co-managers to decide on its use. The decision to use an Activity might be nothing more than a decision based on their comfort zone or usual practice. So “value add” will always remain a subjective call by the co-managers. The bottom line is still that there is no room in P2 LEAN for any non-value added work. Using this approach P2 LEAN remains lean. Obviously senior management is part of this business rule too.

Figure 4.2 summarizes the application of these 50 Activities.

fig 4.2
Figure 4.2: Use of Activities by Process using the MoSCoW Model

Once the decision has been made to use an Activity an appropriate version of that Activity will be chosen. Refer to the Risk Management Model example given earlier for the context of that decision.

THE FUTURE OF P2 LEAN

We have just scratched the surface here. So far we have learned that P2 LEAN is more powerful than we originally envisioned. It is far more than just an integration of lean tools, templates and processes from the ECPM Framework into P2. Without realizing it we have created a synergy. P2 LEAN is more powerful than either P2 or the ECPM Framework could be when used on their own. Its value is being discovered as we move forward with application and further development of P2 LEAN.

P2 defines a flexible framework that specifies “WHAT” with little reference of guidance on “HOW.” P2 LEAN does that and more. “HOW” is an important addition. The P2 LEAN/kit is a comprehensive collection of the “HOW”, WHEN” and “WHY” for each of the 50 Activities. The flexible and adaptive opportunities that are presented to the Co-Managed Project Team are strange territory for most project managers. These are not to be interpreted as a license to “Do It Your Own Way.” Rather the Project Team is constrained to a vetted portfolio of tools, templates and business processes from which they will create the “recipes” they will use to manage their project. The burden is on the executives to make sure that that vetted portfolio does not constrain the Project Team to the point that their performance is limited and their ability to deliver business value reduced. That is a major undertaking to provide a complete vetted portfolio and the support to use it effectively. So it is best to think of that vetted portfolio as a work in process and it will never be completed. Experience with complex project management will give rise to changes or additions to that vetted portfolio. In the spirit of continuous process improvement those suggestions must be considered.

ENDNOTES

Denning, Steven, 2011. The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century. San Francisco, CA: Jossey-Bass).

Poppendieck Mary and Tom Poppendieck, 2003. Lean Software Development: An Agile Toolkit. Boston, MA: Addison Wesley.

Richards, Keith, 2015. P2 Agile, United Kingdom: The Stationary Office.

Wysocki, Robert K., 2010. Adaptive Project Framework: Managing Complexity in the Face of Uncertainty, Boston, MA: Addison Wesley.

Wysocki, Robert K., 2014a. Effective Project Management: Traditional, Agile, Extreme, 7th Edition, Indianapolis, IN: John Wiley & Sons.

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

Wysocki, Robert K. and Colin Bentley, 2016. P2 LEAN: A Practical and Effective Framework for Increasing Project Performance and Delivered Business Value. Plantation, FL: J. Ross Publishing (under contract and in preparation).

Lean Stage Planning in the Face of an Incomplete Solution: Part 2 – The Requirements Breakdown Structure

Part 1 defined High-level Requirements. In Part 2 we discuss the decomposition of those requirements.

The issue has to do with separating the “WHAT” from the “HOW”. Current practice is to define all requirements as part of project initiation. That has proven impossible except in the simplest of project situations. To reach a so-called complete definition means guessing is allowed. This leads to problems and non-value added work. This is counter to the lean principles. Rather I have proposed a two-step approach. The first step is to identify the high-level requirements. These are the “WHAT” that every acceptable solution must include. They will not change. Part 1 discussed the “WHAT.” The second step is to identify “HOW” these requirements will be met. That is the topic of Part 2. As part of identifying the “HOW” additional lower-level requirements might be identified in order to facilitate identifying the “HOW.” This step is nothing more than the decomposition of the “WHAT”. But by assumption, much of the “HOW” is not known at the outset of the project and must be discovered and learned during iteration (PRINCE2 Stages).

REQUIREMENTS BREAKDOWN STRUCTURE

Requirements have always been a sticking point in the process of deciding how to manage a complex project. There will be those situations where the project has been done several times, and there is a documented history of those efforts. All requirements should be known. At the other extreme are projects that have never been done before or are significant departures from previous projects. These will be high-risk projects and most likely complex too. 

DEFINITION: Requirements Breakdown Structure

The requirements breakdown structure (RBS) is a hierarchical description of all ECPM requirements that must be present in the solution in order to deliver the business value expected. The RBS hierarchical structure may include any or all of the following:

  • Functions
  • Sub-functions
  • Processes
  • Activities
  • Features

Elicitation and Decomposition of ECPM Requirements

In the ECPM Framework, the elicitation of requirements is a two-step process: high-level requirements elicitation followed by requirements decomposition. The first step is to elicit a set of high-level requirements that forms the necessary set of requirements whose inclusion in the solution will assure deliverables that meet expected business value. Regardless of the complexity of the project, this high-level identification of requirements will be complete. These requirements capture what will be in the acceptable solution, but not how they will be developed or even if they can be developed. 

The second step is to decompose the high-level requirements for further description of what each requirement includes. This is done incrementally and is very different from PRINCE2 practices. Much of what is done as part of the initial PRINCE2 project plan is done as part of Stage Planning in the ECPM Framework. The benefit here is to deal with certainty up front and to relegate uncertainty to the Stages. That reduces risk, reduces changes that arise from having made bad guesses during initial planning and preserves the lean characteristics of project execution.  The results of the second step inform the team on how they might manage the project. At this point, however, the decomposed requirements definition is limited to what needs to be part of the acceptable solution, but not how those decomposed requirements will be built and integrated into the acceptable solution. That is delivered through an iterative Stage Planning strategy. There the process of learning and discovery takes place as the solution unfolds over the course of the Stages.

Representing Requirements: The Requirements Breakdown Structure

It is best to think of the Requirements Breakdown Structure (RBS) at two levels. At the highest level is a list of “WHAT” must be in an acceptable solution. At the next level is a hierarchical list of a more detailed description of each Requirement. If you add a third level of decomposition, then the RBS transitions into a Work Breakdown Structure (WBS).  So far, requirements were defined from the perspective of what those requirements have to do. Functions, processes, and activities offer us the details of that definition. Given that understanding, our requirements admit a structure like that shown in Figure 3.1, which was introduced in Part 1 of this article and not repeated here. For those of you familiar with the WBS, you will see that this is quite similar to a functional-based WBS (Wysocki, 2014a). And it is, so nothing is new here. However, what is new is what we are going to do with RBS. The RBS (used in the same way as the Product Breakdown Structure in a PRINCE2 project) will be the basis on which you decide how to structure the project management approach you will use for a project with this type of RBS.

As you gather and document requirements by whatever method you choose, place them in their appropriate level in the RBS. The graphical format used in Figure 3.1 works well. Alternatively, you could present the RBS in an indented outline format. It’s all a matter of preference. 

Here is a brief description of each level in the decomposition shown in Figure 3.1:

  • Solution—The solution is the output from the ECPM Framework STEP1: Develop the Business Case.
  • Requirement—Requirements 1 through n form the necessary and sufficient set that describes an acceptable solution. Usually, this set will contain 6-12 requirements. The “necessary and sufficient condition” statement means that all of the stated ECPM requirements are needed in order to achieve an acceptable solution and the expected success criteria. This is important because the project was justified based on the expected business value, as described through the success criteria. Linking the ECPM requirements to the success criteria provides a basis on which to prioritize not only the ECPM requirements, based on their contribution to expected business value, but also to the prioritization of the functions, sub-functions, processes, activities, and features that define the decomposed requirements.
  • Decomposition Levels – Decomposition of the requirements can occur on different levels: 

Function—At the discretion of the project manager, the highest level of decomposition may be at the function level. This level comprises the functions that must be performed in order for the parent requirement to be acceptable. It is important to understand that the RBS reflects what is known about the solution at the time the RBS is first defined. This initial list of functions may or may not be complete. Neither you nor the client can be expected to know if that list is complete. You might know that it is incomplete, but you would not know that it is complete. How could you? For the sake of generating the RBS, you have to proceed on the basis that the initial list will be complete. If it turns out that it is not, you will discover that as part of doing the project.

Sub-function—At the next level of decomposition are sub-functions. For more expansive functions, you may not have any idea of what those sub-functions might be, and that is okay. In any case, the project team should make every effort to identify the sub-functions that further define a function. Once these sub-functions have been developed, the function they define will now be complete. This is the same as the premise underlying the WBS architecture and is very intuitive. For many complex projects, additional sub-functions will be discovered as part of doing the project.

Process—Complex functions and sub-functions can be further described with the business processes that comprise them. These are the business processes that are commonly used in today’s organizations. 

Activity—Activities define work to be done to deliver a function or sub-function.

Feature—At the lowest level of decomposition are features. These are the visible enhancements and characteristics of the entity that they describe. Think of them as cosmetic (i.e., authentication screen background color) and you won’t be far off.

Note that not all decomposition levels are necessary for every requirement. Some requirements will be more comprehensive than others, and utilize all levels. The simplest requirement might be best described using only a Features list. The decomposition is subjective. There can be more than one valid decomposition. In the final analysis, all that is needed is a decomposition that completely describes each requirement.

The RBS will be useful as an aid in helping decide which strategy is best for the PMLC Model to be followed, in other words, the nature of the project as viewed through its RBS. It is the best guide you will have to choosing the best strategy for managing the project. Furthermore, the RBS is a tool that can be used to make sure the project team members have the same understanding of the solution to be delivered. The client is in their comfort zone, and they can participate in assuring that common understanding too.

If you get the RBS right, you are halfway home. That means we should pay particular attention to what is put into the RBS, and make sure you are not victims of scope creep. We will have enough outside influences to add to scope. We do not need to be party to that now.

Approaches to Requirements Elicitation and Decomposition

Requirements have to be defined through a carefully planned engagement with the client. Of all the requirement gathering approaches, I recommend six that work particularly well within the ECPM Framework world. These are widely used methods for generating requirements. Selection of the best method to generate potential requirements for the project is the responsibility of the project manager. Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. Certain methods have been proven effective for specific industries and products. An example of this would be using physical, three-dimensional wireframe models in product design or solid models in bridge construction.

Requirements elicitation is the first and challenging task that the project manager and client will face in the life of a complex project. To do this effectively is as much an art as it is a science. On the art side of the equation, the project manager will have to prepare the client to engage in the elicitation, decomposition, and documentation process. The attitude, commitment, willingness of the client to be meaningfully involved, and preparation of the client are major determinants in the choice of approach. This preparation will include the choice of approach to be used and perhaps some preliminary training of the client and the core team. Some clients will be open and proactive in participating; others will not. Some will be sure of their needs; others will not. Some will be expressing their wants, which may be very different from their needs.

On the scientific side are the many techniques that have been used successfully to decompose and document requirements. I have had good success using brainstorming, user stories, interviews, facilitated group sessions, prototyping, and requirements workshops. All of these should be in your ECPM/kit (Described in a forthcoming article).

The steps to generate requirements begin by looking at the business function as a whole. This is followed by the selection of a method or methods for eliciting requirements. This effort must be planned. A few of the several approaches to requirements elicitation are listed below. These are ordered from least formal to most formal. These are usually understood or easily adopted in less sophisticated environments. (A good reference on methods for gathering requirements is Robertson and Robertson, 2012.). I have personally used and can recommend the following approaches to Requirements Elicitation:

  • Brainstorming
  • User Stories
  • Interviews
  • Facilitated Group Sessions
  • Prototyping
  • Requirements Workshop
  • Using Iterations to Construct the RBS

At the highest level of abstraction, we will have defined the high-level requirements that form the necessary and sufficient set of requirements that every acceptable solution must contain. We formed that set without regard for how or if we could deliver on those requirements. That is a journey of learning and discovery that occurs during project execution. A future article will discuss the Probative and Integrative Swim Lanes that drive that execution effort. For now our focus is on “HOW” those requirements will be met. That will often involve a more definitive understanding of the “WHAT” that defines that solution. That involves the elicitation and decomposition process discussed above and the six approaches listed to do that. Discovering and documenting the “HOW” is equivalent to experimentation with feasible alternatives. The results of those experiments lead to other experiments and finally convergence on solution components and the Integrative Swim Lanes to integrate those components.

When these iterations are complete, we will have converged on a complete requirements elicitation and documentation. The difference here is that it didn’t happen at the beginning of the project but over the course of executing the project. A learn by doing effort!    

The RBS is the foundation of the Work Breakdown Structure

The transition from the RBS to the Work Breakdown Structure (WBS) is straightforward as shown in Figure 3.2.

 fig 3.2 WBS from RBS

Figure 3.2: From the RBS to the WBS

The lowest level of decomposition in the RBS is the highest level in each part of the WBS. As shown in Figure 3.2 that lowest level in the RBS could be any one of function, sub-function, process, activity or feature.

Just as the RBS evolves through a sequence of Stages so also does the WBS evolve through a sequence of Stages. Underlying this evolution are the Probative and Integrative Swim Lanes discussed in a future article in this series.

PUTTING IT TOGETHER

Requirements elicitation and documentation has been the bane of many complex project teams because either the goal, the solution, or both are not clearly known at the beginning of the project. In the absence of methodologies to handle this lack of clarity, guessing has prevailed, and project success has suffered. The two-level requirements elicitation approach suggested in this article solves that problem, but it doesn’t come without a price. Stage Planning is changed to accommodate both Probative and Integrative Swim Lanes. The Change Management Process is also changed. Changes are bundled, and decisions on their acceptance and integration are handled as a group during the Client Checkpoint. The Bundled Change Management Process is discussed in a future article.  

REFERENCES

International Institute of Business Analysis, (2015). The Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 3.0, IIBA.

Robertson, Suzanne and James Robertson. (2012). Mastering the Requirements Process, 3rd Edition, Boston, MA: Addison-Wesley Professional.

Wysocki, Robert K. (2014). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.

Lean Stage Planning in the Face of an Incomplete Solution

Using the ECPM High-level Requirements Definition

PART 1: High-level Requirements Definition

Project management thought leaders are of like mind in that a complete description of requirements is unlikely during project initiation. Beyond the complexity and uncertainty the project is affected by the changing internal environment and external market dynamics. Managing a complex project using PRINCE2 is, of course, complex by definition, but the challenge is further increased due to incomplete requirements (similar to the PRINCE2 Project Product Description). The situation is not hopeless, and there are mitigation strategies that are available in the ECPM Framework during the Project IDEATION Phase and these are easily incorporated into the PRINCE2 Process.

This article puts forth a new definition of requirements (PRINCE2 uses the terms Project Product Description and Product Breakdown Structure) that eliminates the problem of incomplete requirements at Project Initiation. The definitional change is simple and paves the way for fully engaging the Client in Requirements Elicitation.

PRINCE2 recognizes requirements under the term specifications but does not provide any details. However the PRINCE2 Framework should include an understanding of how requirements are defined, elicited and implemented in the life span of a complex project. Having this understanding is a valuable addition to the PRINCE2 practitioner and professional as they accommodate the uncertainties and complexities of contemporary projects. 

DEFINITION OF ECPM REQUIREMENTS

An ECPM requirement is an end-state condition whose successful integration into the solution delivers specific, measurable, and incremental business value to the organization.

The set of ECPM requirements is a necessary and sufficient set for the attainment of all project success criteria including the delivery of the expected business value.

This definition postpones the challenges associated with incomplete requirements and moves them to later in the project.

Requirements define the properties and characteristics of the product, process, or service that is the deliverable of the project. These requirements are the basis for analyzing the effect of any changes to a current situation that your client is seeking. A requirement exists either because the product, process, or service demands certain functions or qualities not present in the current solution. Project requirements start with what the customer really needs, and end when those needs are satisfied. (Note that I am saying “needs,” not “wants.”) This often leads to nonessential or over-specified requirements or some other anomaly. You are cautioned to be very careful about assuming who knows what and who understands what. Double check that the client understands every STEP of the way.

What your client wants may not be what your client needs. As project manager your job is to make sure that what they want is what they need and that you will deliver what they need.

This definition of an ECPM requirement is quite different from the IIBA definition of a requirement, but in its simplicity and uniqueness puts the connection between requirements and the project in a much more intuitive light. ECPM requirements will be the causal factors that drive the attainment of the success criteria, as stated in the POS. Every ECPM requirement should be directly related to one or more project success criteria. This definition results in a small number (8-12) of requirements at the beginning of the project, whereas the IIBA definition generates hundreds of requirements, which can never be considered a complete set at the beginning of the project. The mind could not grasp completeness, anyway.

Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM requirements definition can be considered complete at the beginning of the project. The decomposition of those requirements is not fully known at the beginning of the project, however. An ECPM requirement is a more business value-oriented definition than the IIBA definition.

The learning and discovery derived from completed project cycles will clarify the ECPM requirements through decomposition to the function, sub-function, process, activity, and feature levels. The first level decomposition of an ECPM requirement is to the functional level, and can be considered equivalent to IIBA requirements. So, while you can identify all ECPM requirements at the beginning of the project, you cannot describe the details of the requirements at the functional, sub-functional, process, activity, and feature levels. This detail is learned and discovered in the context of the cycles that make up the project. This two-STEP process for Requirements Elicitation is consistent with the Lean Principles (Poppendieck and Poppendieck, 2003), too.

The ECPM definition of requirements should be preferred to the IIBA definition because it ties requirements directly to the project success criteria, which is not the case with the IIBA definition. That makes it possible to prioritize ECPM requirements, whereas no similar case can be made for prioritizing IIBA requirements. In an IIBA, setting priorities is more of a technical assessment than a business assessment.

The choice of a single project to propose can be made based on the high-level requirements. Since the requirements describe an acceptable solution, the decision can be driven by the degree of fit between a proposed project and the effectiveness it will have in producing deliverables that satisfy the requirements. Reaching this decision is subjective—not objective.

Approaches to Requirements Elicitation and Decomposition

Requirements have to be defined through a carefully planned engagement with the client. Of all the requirement gathering approaches, I recommend six that work particularly well within the ECPM world. These are widely used methods for generating requirements. It is usually the case where more than one method is chosen to generate the requirements on a project. Selection of the best methods to generate potential requirements for the project is the responsibility of the project manager, who must evaluate each method for costs, ease of implementation, reliability, client comfort level with the chosen process, and risks. Further, selection of a particular method should be based on specific product and project needs, as well as proven effectiveness. Certain methods have been proven effective for specific industries and products. An example of this would be using physical, three-dimensional wireframe models in product design or solid models in bridge construction.

Requirements elicitation is the first and challenging task that the project manager and client will face in the life of a complex project. To do this effectively is as much an art as it is a science. On the art side of the equation, the project manager will have to prepare the client to engage in the elicitation, decomposition, and documentation process. The attitude, commitment, willingness of the client to be meaningfully involved, and preparation of the client are major determinants in the choice of approach. This preparation will include the choice of approach to be used and perhaps some preliminary training of the client and the core team. Some clients will be open and proactive in participating; others will not. Some will be sure of their needs; others will not. Some will be expressing their wants, which may be very different from their needs.

On the scientific side are the many techniques that have been used successfully to decompose and document requirements. I have had good success using brainstorming, user stories, interviews, facilitated group sessions, prototyping, and requirements workshops. All of these should be in your ECPM/kit.

It is important to realize that requirements identification and decomposition are critical to understanding the direction of the project. It is now that the framework for the project begins to take shape.

The STEPs to generate requirements begin by looking at the business function as a whole. This is followed by the selection of a method or methods for gathering requirements. This effort must be planned. A few of the several approaches to requirements elicitation are listed below. These are ordered from least formal to most formal. These are usually understood or easily adopted in less sophisticated environments. (A good reference on methods for gathering requirements is Robertson and Robertson, 2012.). I have personally used and can recommend the following approaches to Requirements Elicitation:

  • Brainstorming
  • User Stories
  • Interviews
  • Facilitated Group Sessions
  • Prototyping
  • Requirements Workshop

These are listed in the order of least formal to most formal. I single out these six methods because they work best when trying to translate business requirements into business deliverables. Across the entire history of the ECPM, I have had the most experience and success with these methods. These methods can also be used to decompose requirements and generate the RBS. Regardless of the method you use to generate the RBS, I strongly advise creating an RBS for every project for the following reasons:

  • The RBS is most meaningful to the client.
  • The RBS is a deliverables-based approach.
  • The RBS is consistent with the PMBOK.
  • The RBS remains client-facing as long as possible.
  • The RBS is the higher order part of the WBS.

Choosing a Requirements Elicitation Approach

There are several things to take into consideration when deciding which approach to take:

  • The experience of the client team—If the client team has memorable and effective experience with any of the requirements gathering approaches, try to select from among them. To the most extent possible, you should put the client in their comfort zone so that they can focus on the work of defining requirements.
  • The experience of the development team—If the development team has memorable and effective experience with any of the requirements gathering approaches, try to select from among them. Given the choice of two or more approaches, choose the one that favors the client.
  • The complexity and nature of the project—The more complex the project, the more you would want to use approaches that give detailed information and are less likely to overlook anything. A formal process should be preferred to an informal process.
  • The experience of the session facilitator—First of all, the session facilitator should not be a member of the client team or the development team. This may come as a surprise, but there are good reasons to back it up. The facilitator’s job is so critical that you need someone with experience and with no bias toward the project. Their job is to facilitate, not politic. The client team leader and the development team leader need to focus their attention on the deliverables from the requirements gathering exercise, not on the process of getting them, and so they are not good choices. If there is no one internal to the organization that meets the criteria, hire an outside consultant. This is no place to cut expenses. The more critical and complex the project, the more you should favor the use of an outside facilitator.

Elicitation and Document Requirements

Complete and clear document requirements at the beginning of a project have never really happened. It just isn’t possible, except in the simplest of projects. (Infrastructure projects are an example because they tend to be isolated from the outside world.) A few “cowboys” would claim to have done so, and launched into project planning under the assumption of having a complete requirements document. Later, to their dismay, they are deluged with scope change requests from the client: “What happened? I thought we had all of this nailed. You told us you were satisfied and that we had done an exemplary job of gathering and documenting your requirements.” The problem is not with the process. The problem is not with the initial documentation. The problem is that the world is not a static place. It never has been and never will be. So, why should you expect your requirements document to stand still while you do the project? Change is inevitable, regardless of how well we did at the outset. There must be better ways. And there are!

The RBS is the major input to help you make the decision as to which category of project you have, and which PMLC model would be most appropriate for managing the project. I will show how the RBS can be used to help the project team decide which strategy, among the five major project management categories, should be chosen and under what circumstances you should use each one. The strategy that you choose then becomes the infrastructure on which you will choose a project management model and build your project plan. The status of the RBS relative to its completeness can be used as the measure of progress towards the solution.

The completeness and clarity of the RBS present you with two critical decisions as to which of five major directions to go (linear, incremental, iterative, adaptive, or extreme). Within that choice is which specific PMLC model will be used. In this book, the chosen direction is down the adaptive road, the ECPM road. As you will see, these decisions are not obvious. While there is some objectivity involved, the decision process leans heavily towards the subjective side.

I advise creating an RBS for every project because:

  • The RBS is most meaningful to the customer.
  • The RBS promotes customer ownership and eventual buy-in of the solution.
  • The RBS is a deliverables-based approach and in the customer’s comfort zone.  The RBS can be used to measure progress towards solution definition.
  • The RBS can be used to measure project status.
  • The RBS is consistent with the PMI® PMBOK.
  • The RBS remains customer-facing as long as possible into the planning exercise.

If you happen to know the complete RBS, you are in good shape but if you don’t, you have a problem. In complex projects, an incomplete RBS is the rule rather than the exception. It would be unusual to have a complete RBS at the start of a complex project. Some functions and features may not be known, and their absence may not be known at this early stage, either. Being able to say that the RBS is complete is based more on a feeling than on hard fact. The ECPM is designed to learn and discover the complete RBS, and hence the solution, through iteration.

Conventional wisdom says that a complete Requirements Breakdown Structure is not possible at the start of a complex project, but can only be defined through an iterative process. There may be exceptions for projects that are often repeated.

So far, we have defined requirements from the perspective of what those requirements have to do. Functions and features offer us the details of that definition. Given that understanding, our requirements admit a structure much like that shown in Figure 3.1. For those of you familiar with the WBS, you will see that this is quite similar to a functional-based WBS. It will be the basis on which you decide how to structure the project management approach you will use for a project with this type of RBS (the reference here is to complexity, completeness, and uncertainty of the RBS for the project at hand).

fig 3.1 RBS
Figure 3.1 Requirements Breakdown Structure

PUTTING IT TOGETHER

Requirements Elicitation is the heart of any effective complex project management approach. Change is inevitable and the project environment dynamic. It can change at any time and in unexpected ways and it directly impacts requirements. The only steady state in all of this change is the Business Case that initially was the justification for authorizing the project. The alignment to that and the expectation of the validating business value being realized is the justification for continuing or modifying the project.

To the extent possible the requirements infrastructure must be such that it brings as much stability to the project as is possible. The definition of requirements as provided by the ECPM Framework delivers that stability. The iterative definition of the RBS is the enabling tool.

REFERENCES

International Institute of Business Analysis, (2009). The Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0, IIBA.

Wysocki, Robert K. (2014). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.

A New Brainstorming Model for Client Involvement Part 2: The Ideation Phase

In my previous article, A New Brainstorming Model for Client Involvement PART 1: A New Brainstorming Model, I discussed the ECPM Framework and the Ideation phase. Phase 1 was to develop the business case.

In this article I further discuss the elements of the Ideation phase, including phase 2, Elicit Requirements, and phase 3, Write a Project Overview Statement.

Figure 2.2 highlights the three STEPs that are executed during the IDEATION Phase of a complex project. The approach discussed below is simple and intuitive. Once an idea is submitted:

  1. A business case is developed;
  2. High-level requirements are elicited; and,
  3. A Project Overview Statement (POS) is prepared.

fig2cropped

Project IDEATION Phase STEP 2: Elicit Requirements

Many authors will use the term “Gather” with respect to building the list of requirements. That suggests the requirements are just laying around and waiting to be picked up and added to the requirements bucket. In complex projects, nothing could be farther from the truth. The term “Elicit.” suggests that requirements must be discovered and drawn out for documentation and addition to the list.

Project management thought leaders are of like mind in that requirements are rarely complete during project definition. Beyond the complexity and uncertainty the project is affected by the changing internal environment and external market dynamics. Managing a complex project using PRINCE2 is of course complex by definition but the challenge is further increased due to incomplete requirements. The situation is not hopeless and there are mitigation strategies that are available in the ECPM Framework during the Project IDEATION Phase and these are easily incorporated into the PRINCE2 Process.

My next article will be: High-Level Requirements Elicitation for details on the recommended approaches to elicit requirements in the face of client levels of participation.

Project IDEATION Phase STEP 3: Write A Project Overview Statement

A Project Overview Statement (POS) is the first formal document that describes the project idea at a high-level and is used for general distribution. It is written in the language of the business so that anyone who has the occasion to read it, will understand it. No “techie talk” allowed. It is only one page, so there isn’t an opportunity to say much other than a few basic pieces of information. The PRINCE2 Project Identification Document (PID) is the analog of the POS.

Definition of the Project Overview Statement

The POS is brief—one page is always sufficient. A POS basically summarizes the RBS. A POS template with an example is shown in Figure 2.3. The POS contains the following five sections:

  • A statement of the problem or opportunity (reason for doing the project).
  • A goal statement (what will generally be done).
  • A statement of the objectives (general statements of how it might be done).
  • The quantifiable business outcomes (what business value will be obtained).
  • General comments on risks, assumptions, and obstacles to success.
fig2nov25

Figure 2.3 A Typical POS Template with Example Data

After more than 50 years of managing projects, I can honestly say that I have always been able to write a one-page POS regardless of the scope of the project. Being able to write a one-page POS means that you really understand the project and can communicate it intelligently to senior management. Think of it as though it was the two minute elevator speech and you won’t go far astray. I’ve seen project initiation documents as large as 70 pages. I’m not sure who reads these, if anyone. If they do, do they really understand the project at the level of detail needed for granting approval to create the project plan? I doubt it! A document of that length may be of value to the development team but not to the sponsor and certainly not to the executive who will be approving it.

Seek StageGate #1 Approval

StageGate #1 is the senior management approval to proceed to the Project SET-UP Phase. Along with this approval is the release of the resources that will be needed for that phase. There is still a lot about this project that has to be defined before any version planning work can be done and one more approval STEP (StageGate #2) before the actual work of the project is authorized and budgeted by senior management.

There will be occasions when the POS is not approved. This usually means that the sponsor has not made a compelling argument for the business viability of their intended approach to the problem or opportunity. Despite the fact that the business need may be critical, the risk of failure is weighed against the expected business value of the solution. Expected business value may not justify the cost of the project. It does not mean that the project is not important to the executives, just that the approach chosen does not make good business sense. Some other approach is needed. The sponsoring business unit is invited to revise and resubmit the POS. Alternatively, the POS may be rejected without further consideration.

PUTTING IT ALL TOGETHER

In the IDEATION Phase we have brought an idea from a very informal statement of need or opportunity to a initial definition of one or more prioritized projects and finally to a choice of the initial project to be pursued. The IDEATION Phase is ended with a one page statement of that project that is forwarded for management approval. The IDEATION Phase includes the first three STEPs to defining a project and seeking the resources and authorization to proceed to the SET-UP Phase.

REFERENCES

Gray, Dave, Sunni Brown and James Macanufo (2010). Game Storming: A Playbook for Innovators, Rulebreakers, and Changemakers, O’Reilly Media, Inc.

Maul, June (2011). Developing A Business Case: Expert Solutions to Everyday Challenges, Harvard Business Review Press. Project Management Institute, (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, Inc.

Wysocki, Robert K. (2014a). Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons, Inc.

Wysocki, Robert K. (2014b). Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing.