Skip to main content

Tag: PRINCE2

Viewing the PRINCE2 Project as a System in Balance: Decision-Making and Problem Solving

The ECPM Scope Triangle was introduced in Part 1. In Part 2 we are going to discuss applications of this valuable tool.

The biggest and perhaps most important among the six variables that define the ECPM Scope Triangle is Resource Availability. It is clearly identified as a project, program and portfolio constraint in the ECPM Framework but is absent from the P2 Framework at the project level. The program and portfolio level are out of scope here.

There are just a few graphics used in the ECPM Framework that should be burned into your project management brain. They are intuitive and powerful decision-making tools. The ECPM Framework Scope Triangle is one of those graphics.

THE ECPM FRAMEWORK SCOPE TRIANGLE – A SYSTEM IN BALANCE

On the first day of a project, the project system is in balance. No work has been done yet. Due to the dynamics of the situation, this balance may be short-lived. Something changes that was either expected or not expected even though its timing may be unknown. Literally every change has a domino effect on the other variables and causes a change in one or more of the 6 variables. In order to restore balance to the project, a change in one or more of the other variables will have to be made. In that sense, the ECPM Framework Scope Triangle is a management tool for problem resolution, schedule repair, and change management. This systems view of project management is a useful problem-solving tool and change management tool and is explored in detail in the ECPM Framework book (Wysocki, Robert K., 2014, Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing). Its adaptation to P2 is discussed in this article. The Iron Triangle, which is not discussed in P2 or the ECPM Framework, does not offer such a rich interpretation.


{module ad 300×100 Large mobile}


The 6 variables that define the ECPM Framework Scope Triangle form an interdependent set of variables that define the project as a system in balance. To understand this interpretation, visualize the triangle as a geometric figure that encompasses an area (the area occupied by the scope and quality) that is bounded by the three sides of the triangle. Those sides are just long enough to encompass that area. If one of the sides should shrink (budget is reduced, schedule shortened or a previously scheduled resource is no longer available), then the reduced length of the corresponding lines are no longer sufficient to encompass the area defined by the scope and quality. The interpretation and its explanatory figure is conceptual. Don’t try to draw the triangle. It can’t be done. A very common situation arises from scope change request that increase scope. Decreases are rare. In these cases, the area occupied by scope expands and the sides of the triangle are no longer sufficient to enclose the larger area. Something has to change. The length of one or more lines must be increased (increased time or cost and/or more staff assigned to the project), so that the larger scope can be bounded by the larger triangle.

I have had over 25 years of client experiences using the ECPM Framework Scope Triangle. It has been a valuable addition to my project management toolkit, and I can recommend it to you especially if you are a P2 Practitioner or Professional.

PRIORITIZING THE ECPM FRAMEWORK SCOPE TRIANGLE VARIABLES

Except for risk, the other 5 variables can be prioritized as an assist to problem-solving, change management, and other management decision-making. The figure below is an example of one such prioritization schema. It applies to only one project. Every project is different. The matrix shows that the time constraint is the least flexible, and the cost constraint is the most flexible. Also, note that scope is quite flexible as should be the case for any complex project.

fig 5.3 Prioritized Scope Triangle febPrioritized ECPM Framework Scope Triangle Variables

When alternatives solutions to a problem or change management approval arise, this matrix is easily applied to help prioritize and then make the best choice. For example, in the figure above, since cost is the most flexible, choices that impact cost would receive a higher likelihood of being implemented than those that involve time or resources. Prioritization should be done during project planning to remove any bias that might arise from the problem solving or change management events. That prioritization exercise must involve the client, too.

Problem Solving & the ECPM Framework Scope Triangle

here are a variety of problem-solving models that are in common use. The one that I am recommending is simple and can be used in a variety of contexts within the ECPM Framework. It was developed by J. Daniel Couger (1995, Creative Problem Solving and Opportunity Finding, Boyd & Fraser Publishing Company) and aligns quite well with the divergent/emergent/convergent process used in the Ideation Phase of the ECPM Framework. The Couger model follows the linear process:

  • Step 1: Delineate opportunity and define problem
  • Step 2: Compile relevant information
  • Step 3: Generate ideas
  • Step 4: Evaluate and prioritize ideas
  • Step 5: Develop implementation plan

Something has happened that put the project plan at risk. Late shipments from suppliers, equipment malfunctions, sickness, random acts of nature, resignations, priority changes, errors, and a host of other factors can lead to problems that affect deliverables, deliverable schedules, and resource schedules. The project team owns the problem and must find a solution.

This situation is very different for the Project Manager in the case of a change request. When a change request has been made, the Project Manager has some leverage with the client. The client wants something and might be willing to negotiate an acceptable resolution. That is not the case when a problem arises on the project team. The Project Manager does not have any leverage and is in a much more difficult position.

When the unplanned happens, the Project Manager needs to determine who owns the problem and the extent of the problem, then take the appropriate corrective measures. Those measures often include helping the owner of the problem find an acceptable solution following the escalation hierarchy. Minor variations from the plan will occur and may not require corrective measures. There are degrees of corrective measures available to the Project Manager: In trying to resolve a problem, the Project Manager begins at the top of the escalation hierarchy and works down the hierarchy, examining each option until one is found that solves the problem.

The ECPM Framework Scope Triangle enables you to ask the question, ″Who owns what?″ The answer will give you an escalation pathway from project team to resource manager to client to sponsor. The client and senior management own time, budget, and resources. The project team owns how time, budget, and resources are used. Within the policies and practices of the enterprise, any of these may be moved within the project to resolve problems. In solving a problem, the Project Manager should try to find a solution within the constraints of how the time, budget, and resources are used. For these solutions, the Project Manager does not need to go outside of their sphere of control.

The next step in the escalation strategy would be for the Project Manager to appeal to the resource managers for problem resolution. The resource manager owns who gets assigned to a project as well as any changes to that assignment that may arise.

The final step in the problem escalation strategy is to appeal to the client and perhaps to the sponsor for additional resources. They control the amount of time and money that has been allocated to the project. Finally, they control the scope of the project. Whenever the Project Manager appeals to the client, it will be to get an increase in time or budget and some relief from the scope by way of scope reduction or scope release.

There are three levels of escalation strategy: project team–based, resource manager–based, and client-based.

Project Manager–Based Strategies

If the problem occurs within a non–critical path activity, it can be resolved by using available slack (Wysocki, Robert K., 2014, Effective Project Management: Traditional, Agile, Extreme, 7th Edition, John Wiley & Sons). One example is to reschedule the activity later in its ES–LF window or extend the duration to use some of the available slack. Note that this strategy does not affect any other activities in the project. By using slack, you affect the resource schedule for all activities that have this activity as a predecessor.

Another approach is to continue the schedule compression techniques employed in defining the original project plan. This strategy can affect resource schedules just as in the prior case. The last option open to you is to consider the resource pool under your control as the Project Manager. Can some resources be reassigned from non–critical path activities to assist with the problem activity?

Resource Manager–Based Strategies

After you have exhausted all the options under your control as the Project Manager, it is time to turn to the resource managers for additional help. This help may take the form of additional resources or rescheduling of already committed resources. Expect to make a trade-off here. For example, you might be accommodated now, but at the sacrifice of later activities in the project. At least you have bought some time to resolve the downstream problem that will be created by solving this upstream problem. If you have other projects that you are currently managing, some trades across projects may solve the problem.

Client-Based Strategies

When all else fails, you will have to approach the client. The first option would be to consider any multiple-release strategies. Delivering some functionality ahead of schedule and the balance later than planned may be a good starting point. The last resort is to ask for an extension of time. This may not be as unpleasant as it seems because the client’s schedule may have also slipped and the client may be relieved to have a delay in your deliverable schedule, too.

The Escalation Strategy Hierarchy

The problem escalation strategy presented here is based on the premise that you, as the Project Manager, will try to solve the problem with the resources that you control. Failing to do that, you can appeal to your resource managers. As a last resort, you can appeal to the client.

One thing to note here that is very different from the change request situation discussed previously is the leverage to negotiate. As mentioned, you, as the project manager, have leverage when the client has requested a change, but no leverage when you have a project problem to solve. The client has nothing to gain and is, therefore, less likely to be cooperative. In most cases, the problem can be reduced to how to recover lost time. The following six outcomes are possible to this problem situation:

  • No action required (schedule slack will correct the problem)—In this case, the slippage involved a non–critical path activity and it will self-correct.
  • Examine FS dependencies for schedule compression opportunities—Recall that you originally compressed the schedule to accommodate the requested project completion date by changing FS dependencies to SS dependencies. You should use that same strategy again. The project schedule will have changed several times since work began, and there may be several new opportunities to accomplish further compression and solve the current problem.
  • Reassign resources from non–critical-path activities to correct the slippage—Up to a point, you control the resources assigned to this project and others that you manage. You may be able to reassign resources from non–critical-path activities to the activities that have slipped. These non–critical-path activities may be in the same project in which the slippage occurred or they may be in another project that you manage.
  • Negotiate additional resources—Having exhausted all of the resources that you control, you need to turn to the resource managers as the next strategy. To recoup the lost time, you need additional resources. These resources may come in the form of added staff or dollars to acquire contract help.
  • Negotiate multiple release strategies—This strategy involves the client. Just as in the case of a change request, you can use a multiple-release strategy to your advantage. An example will illustrate the strategy: The project manager shares the problem with the client and then asks for the client to prioritize the features requested in the project plan. The project manager then offers to provide the highest-priority features ahead of their scheduled delivery date and the remaining priorities later than the scheduled delivery date. In other words, the project manager gains an extended delivery schedule but gives the client something better than the original bargain offered—namely, something ahead of schedule.
  • Request a schedule extension from the client—This is the final alternative. Although it’s similar to the multiple-release strategy, it offers the client nothing in trade. The slippage is such that the only resolution is to ask for a time extension.

You, as the project manager, should try to solve the problem by starting at the top of this list of six outcomes and working down until a solution is found. By using this approach, you will first try to solve the problem with resources that you control, then with resources that the resource managers control, and finally with resources and constraints that the client controls.

Change Management & the ECPM Framework Scope Triangle

The ECPM Framework recommends a Bundled Change Management Process. Simply put, all decisions regarding proposed scope changes are held until the Client Checkpoint Step. This is different from the traditional approach. To handle change requests as they arise, as is done in the P2 Framework, is not a lean practice. During the Client Checkpoint Step, all proposed scope changes that have not yet been acted upon are considered together. These will include past requests that have not yet been processed as well as requests that arose during the just completed cycle. From among those change requests some will be approved and available for scheduling, others will be rejected, and others will be held for later decisions.

PUTTING IT TOGETHER

We have taken the static Iron Triangle and turned it into a dynamic tool – the ECPM Scope Triangle. All of this is possible because the ECPM Scope Triangle is really a conceptual depiction of a system in balance. It stresses the dependence of the 5 variables that define it.

As a system in balance, it is an aid to P2 LEAN Project Management as it supports problem solving, decision making and change management.

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).

Crossing the Domain Expertise Chasm

In my last article, I provided some tips on how someone who is interested in entering the project management profession, but lacks specific experience, might improve their odds of landing a role. This month, I’ll try to answer the related question which is frequently asked in online discussion groups: “How do I get a project management role in a different domain or industry?”.

This question always manages to stir up a lively debate!

First we have those project management purists who believe that subject matter notwithstanding, a project is a project. The same hard and soft competencies which are required to successfully manage a project in one domain apply when managing a project in another. This group will bring up tales of uber-project managers who crossed multiple industries, successfully managing projects across all.

In the other corner, we have those who believe that in spite of how successful a project manager has been in one domain, their effectiveness decreases when they have to manage a project in a different one. This side will recall the horror stories of project managers they had worked with who tried to apply their expertise in one domain to another, only to abjectly fail.

So which is the correct view?

IT DOESN’T MATTER.

It really depends on a few factors including economic conditions and your own situation.

If you happen to be transitioning domains within your own company, you have a track record of successful delivery in your existing role, and you have an established network of champions within your current department as well as the one you wish to enter, the lack of experience in the new domain could be successfully positioned as an area for short-term development rather than a showstopper.

Similarly, if you have the good fortune to work in a geographic location where the demand for competent, experienced project managers exceeds the supply of such talent, you could be offered a role in spite of your lack of specific domain expertise.

Unfortunately, neither of these situations might apply to your case.

Few companies are large or broad enough to provide the lateral, domain-switching opportunities which a project manager may wish to pursue. In addition, the explosive growth of the project management profession over the past two decades has resulted in a surplus of qualified talent in many parts of the world. Yes, there are some regions where demand still exceeds supply, but the number of qualified project managers willing to relocate significant distances remains low, and the economic or political conditions within some of those regions might not make them suitable for many professionals.

In some respects, this is similar to the debate as to whether or not one should attain a project management credential. While there is no doubt that one can be a successful project manager without getting certified if human resources staff or recruiting agencies within your region are using the lack of a certification as a low-effort means to weed out candidates, the argument is moot if you have no other means of getting past these gatekeepers.

So what can you do?

First, make sure you really want to go through with this. Have you really exhausted the opportunities within your own domain? Is this more than just a “grass is greener” desire? Seek out an experienced project manager who can help you learn the good, the bad and the ugly of the new domain.

We all know that the majority of vacant positions are not advertised. Lacking the domain expertise which would elevate your visibility with recruiters, the next best thing is to have some influential advocates who can put in a good word for you when an opportunity arises. This is easier said than done, but here are a few ways to do it:

  • Make sure everyone in your network is aware that you want to go through with this transition
  • Join a community of practice or special interest groups for the new domain and actively participate in their events
  • Attend a conference or take a course

Knowledge is no substitute for experience, but you need to be able to talk the talk if you are lucky enough to be granted an interview.

Specific things to learn include:

  • Common sources of risk and risk events
  • Good practices specific to the industry
  • Rules of thumb such as parametric estimation models

Leverage peers in your network to learn which of your skills will be most transferable. If you get invited to an interview you are likely to be asked how you will overcome your lack of domain expertise, so be prepared with scenarios from your past experience which are applicable to the new role.

Geoffrey Moore’s 1991 book, Crossing the Chasm, addressed the challenge faced by companies who wish to sell disruptive innovations to a mainstream audience. His quote should resonate for all project managers wishing to cross the domain expertise chasm: “The number-one corporate objective, when crossing the chasm, is to secure a distribution channel into the mainstream market, one with which the pragmatist customer will be comfortable.

Forget Project Management and Embrace Project Leadership

Don’t pretend to be a project manager when what you really need to be is a Project Leader. In my experience, a Project Manager should only be a title you put at the bottom of your email signature. Project Leaders deliver successful projects.

A Project Leader is a person that puts aside self-interest in favour of the interests of the organisation, stakeholder, and team. A Project Leader does not try to manage the team by telling them the tasks that they need to complete or when to complete those tasks.

A Project Leader sets out the goal and then watches the team fulfil that goal. A Project Leader guides and nourishes a team in order to make sure the project is successful. A leader’s role is to support the project team and stakeholders in becoming self-sustaining and evolving in a positive manner. A Project Leader’s job is done when they are no longer needed, and the project, team, and stakeholders are running on autopilot.

Why we don’t need any more Project Managers

This world has enough managers – we need more leaders.

Unfortunately, I was once told that this world has 2 types of people. Those that are leaders and those that are followers. Which one are you? Which one do you want to be?

As a Project Leader, you must be able to guide from the front. It is about realizing the potential of the team and using skills and resources at your disposal to achieve the best from the team. A manager tries to manage the team by bending it to fit the project. A Project Leader will allow the team to bend itself to fit the project. A manager can, at times, stifle creativity by trying to box the team or stakeholders into pigeon holes just to get a project delivered.

Leading is not about dreaming

Project Leaders are governed by the same principles as a Project Manager. Do not think for a moment that Project Leaders simply run in front of a team. A Project Leader will run in front, side and behind a team when the moment requires.

A Project Leader will also be defined by the success or failure of the project and need to conform to the same boundaries of time, cost and quality as a Project Manager.
The one quality that separates a Project Leader from a Project Manager is the ability of the leader to guide the team and stakeholders. A Project Leader will allow the team to make decisions and hold each other responsible for those decisions. A leader sees the strengths and weaknesses of a team and feeds those strengths to bring confidence and coherence to the team while dealing with weaknesses head on.

Related Article: So You’d Like to be a Project Manager

Forego the fancy title

In favour of experience. It is nice to say you are a Project Manager, the title itself promotes seniority, trust, experience and success to the people reading your resume. What you need to put down on your business card is that you are a Project Leader. If you are currently a Project Manager stop and take stock. Are you doing right by your team by trying to manage them? Surely they are competent and self-sufficient to govern themselves. The team should know what is required and be able to commit to delivering against those requirements.

I say to all Project Managers, don’t make the mistake of believing a team needs managing. What it needs and desires is leadership. Someone to behave as a leader.