Skip to main content

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

Comments (5)