Tag: PRINCE2

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

Written by Robert Wysocki on January 27, 2016. Posted in Articles. 3 Comments on 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

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.

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

Cost

Schedule

Resource Availability

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.

P2 Lean: Are You a Cook or a Chef?

Written by Robert Wysocki on January 13, 2016. Posted in Articles. 5 Comments on 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.

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.

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.

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

Written by Kiron Bondale on January 5, 2016. Posted in Articles. 2 Comments on 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

Written by Shane Vaz on December 28, 2015. Posted in Articles. 3 Comments on 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.

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

Written by Robert Wysocki on December 23, 2015. Posted in Articles. 4 Comments on 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.

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.