Author: Robert Wysocki

PRINCE2 – A New Brainstorming Model for Client Involvement

Written by Robert Wysocki on November 10, 2015. Posted in Articles. 6 Comments on PRINCE2 – A New Brainstorming Model for Client Involvement

Every PRINCE2 Project is a response to a Project Mandate. The Mandate can arise from anywhere in the organization but is usually the result of a senior manager or sponsor bringing an unsolved problem or untapped business opportunity to the attention of the organization. Underlying that mandate is the expectation, or even the insistence, that something be done. In response to that request, a team is commissioned to identify and prioritize a number of responses to that mandate. That can be of minor difficulty or a major STEP into the unknown and everything in between.

The ECPM Framework includes a comprehensive Brainstorming Process that handles the unique requirements for Project IDEATION. Project IDEATION begins with a short description of an unsolved business problem or untapped business opportunity (equivalent to the Project Mandate in the PRINCE2 world) and ends with a one page statement called the Project Overview Statement (POS) that will be proposed (equivalent to the Project Initiation Document (PID)). To reach that proposed project a comprehensive brainstorming process has been designed for the ECPM Framework. That process takes the project team through the identification of ideas (the Divergent Phase) to the definition of affinity groups (the Emergent Phase) to a list of prioritized projects (the Convergent Phase) and finally to the one page statement of the project (the POS). The process described here is easily integrated into the PRINCE2 process that generates the POS version of the PID.

The major benefit of using the ECPM Brainstorming Process is that it is designed to foster early engagement by the Client. See Article 1 (Establishing and Sustaining Meaningful Client Involvement: Improving Delivered Business Value in a PRINCE2 Project) for more details on establishing meaningful and sustainable client involvement. An unsolved problem or untapped business opportunity (the Project Mandate) starts the Project IDEATION Phase of the ECPM Framework using the language of the Client. The Brainstorming Process concludes with a prioritized list of projects that address the problem or opportunity. Business Cases accompany each prioritized project and are often used as the criteria for prioritizing the final choices of potential projects. The IDEATION Phase concludes with the creation of the Project Overview Statement (POS) of the ECPM Framework.

This article offers the ECPM Framework POS as the deliverable from the IDEATION Phase and as a more definitive and structured version of the PRINCE2 PID.

ECPM FRAMEWORK BRAINSTORMING PROCESS

The IDEATION Phase of the ECPM Framework is usually not part of the linear project life cycle as commonly understood. In fact, PMI has little to say about the Business Case and the elicitation of requirements in preparation for gaining project approval (PMI, 2013). More common practice is to begin the project life cycle with some form of project charter statement. The project has already been decided all that remains is its formal definition and planning. The ECPM Framework takes a more holistic approach. Including IDEATION in the ECPM project life cycle provides an understanding of how the project aligns with the business of the organization and its priority with respect to the generation of that business value. You will come to realize that it is a powerful tool for complex project management decision making that is shared only by PRINCE2 and the ECPM Framework. This uniqueness gives the ECPM Framework a powerful and far more effective capacity for successfully managing any type of project from inception to the end of the useful life of its deliverables. It is also a good segue into complex project portfolio management.

A PRINCE2 or ECPM project begins with a need to solve a critical yet unsolved problem, or to take advantage of an untapped business opportunity, but it can also begin with nothing more than knowledge that there is a problem or untapped business opportunity. Figure 2.1 highlights the three STEPs that are executed during the IDEATION Phase of a complex project. The approach discussed below is simple and intuitive. Once an idea is submitted: 1) a business case is developed; 2) high-level requirements are elicited; and, 3) a Project Overview Statement (POS) is prepared.

Figure 2.1: ECPM Framework IDEATION Phase STEP 1

Few project management books discuss the decision processes and practices over the entire project life span. A complex project is a dynamic entity that changes for all sorts of reasons, both predictable and unpredictable, and for that reason the best management approach will also be dynamic and change along with the changing project conditions that arise. This places several challenges on the sponsor, the project manager, the client manager, the client team, and the development team. They must be constantly vigilant and ready to embrace change. The purpose of these changes is to maintain alignment between the changing nature of the project and how it is managed. The IDEATION Phase provides that checkpoint during the project EXECUTION Phase. The goal of the ECPM Framework is to deliver maximum business value with respect to the strategic plan of the organization.

Project IDEATION Phase STEP 1: Develop the ECPM Business Case

Most project management methodologies start with the project as given, and proceed from there. Those methodologies often start with writing the Project Overview Statement (POS) or an equivalent short statement of the project. The ECPM Framework is not like other project management methodologies. The ECPM Framework is a holistic framework and embraces the entire project life span. That begins with the very roots of a possible project—with an idea where a problem or an unmet need is identified and analyzed for business feasibility. STEP 1 ends with the identification of a specific project as described in the POS.

What Is an ECPM Business Case?

A business case is a document that identifies an unmet need, and provides evidence and justification for initiating or continuing a project investment to address that need. An ECPM business case typically includes:

A statement of a critical need and the overall justification for a project to address that need
A description of the product, process, or service that the project will deliver
How the project aligns with the business strategy
A financial analysis comparing alternative project ideas
A prioritization of the alternatives and the preferred option
The scope of the project and its deliverables
The incremental business value that will result.

There are several models and processes that could be used to develop the business case. I have adapted the model developed by (Maul, 2011) to accommodate the range of projects in the ECPM Framework.

The ECPM Framework Brainstorming Process

Figure 2.1 includes the brainstorming process that drives the development of the Business Case beginning with a Project Mandate that is a call to action to solve a critical problem or exploit an untapped opportunity. The typical brainstorming process and mapped it across the IDEATION Phase. Figure 2.1 is the ECPM Framework adaptation of a model originally developed by (Gray et al, 2010).

The ECPM Brainstorming Model consists of four parts:

Definition of the problem or business opportunity
Divergent Phase
Emergent Phase
Convergent Phase

Definition of the problem or business opportunity

ECPM is designed so that an idea can originate anywhere and be submitted by anyone in the organization. The person proposing the idea must get the endorsement and support of a manager, who will often become the sponsor. This is the first STEP in the process of developing a business case. A sponsor (usually an executive from the client organization who will fund the project) makes a request of senior management to undertake a project to solve a mission critical problem, or take advantage of a significant yet untapped business opportunity. Whether it be a problem or an opportunity, the organization is presented with a major challenge. The challenge arises from the fact that the problem has remained unsolved despite any prior attempts at resolution and it is unclear how to take advantage of the untapped business opportunity. That uncertainty is a fundamental characteristic of complex projects.

A representative from the development organization is assigned to work with the client sponsor. In keeping with the principles underlying the ECPM Framework, this individual from the development organization will become one of the co-project managers, and someone from the sponsor’s business unit (the client) will become the other co-project manager (Wysocki, 2014b). That could be the sponsor or a responsible business analyst, but it usually is a line manager from the affected business unit(s). Whoever is chosen, they must represent the sponsor’s interests and have decision making authority for the business unit(s) they represent. These co-managers are equally responsible for the project from inception through completion (i.e., the project life span).

Divergent Phase

The purpose of the Divergent Phase is to elicit as many ideas as the brainstorming group can produce. No evaluation is done at the time, except for clarification. The more ideas that can be generated, the better the final result. No idea is too extreme to be rejected. One idea might not be used, but it may be the catalyst for other ideas. The best way to start the Divergent Phase is with a brainstorming session. What is presented here is a variant of the familiar brainstorming session that most people will be familiar with. This variant is far broader and comprehensive than you may have experienced so far:

BRAINSTORMING GROUP OPERATING RULE:

When a group member puts an idea on the table for consideration,
they surrender ownership of the idea. It becomes the property of the
entire group. It no longer makes any difference where the idea came
from, and that should not even be part of any later discussions
regarding the idea.

Assemble any individuals, whether they are team members, consultants, or others, who may have some knowledge of the problem or business opportunity area. A team of 8-12 should be sufficient. They don’t need to be experts. In fact, it may be better if they are not experts. You need people to think creatively and outside of the box. They may not be aware of any risks associated with their ideas, and that is good at this early stage. Experts tend to think inside the box and focus on why something can’t be done, rather than on why it should be done. How it will be done is a decision better left to the SET-UP and EXECUTION Phases.
The session begins with everyone recording an idea, reading it to the brainstorming group, and placing it on the table face up so everyone can see it. No discussion (except clarification) is permitted. Silence and pauses are fine. This allows any group member to think about the suggestions that have been submitted, and what they have heard and seen, and maybe that will spur another idea. Families of ideas can be generated like those shown linked together in Figure 2.1.
After all the ideas are on the table, and no new ideas seem to be forthcoming from the brainstorming group, the Divergent Phase is declared closed by the facilitator. A Divergent Phase can be completed in less than two hours.

Emergent Phase

The purpose of the Emergent Phase is to collect and consolidate the brainstormed ideas into packages of similar ideas (i.e., affinity packages) as a prelude to defining specific action items:

Discuss the ideas that have been submitted. Try to combine ideas, or revise ideas based on each member’s perspective. Ideas are grouped into affinity groups, or packages of similar ideas, if you prefer. Some ideas may not be similar enough to be placed in a package. Don’t discard any ideas. They might have value that has not yet been recognized.
In time, primitive solutions will begin to emerge from these packages. Don’t rush this process, and by all means test each idea with an open mind. Remember that you are looking for a solution that no individual could identify, but that you hope the group is able to identify through their collective efforts. There is a synergy that comes from a well-run Emergent Phase.
An Emergent Phase can be completed in 2-3 hours, but don’t cut it short if it is still producing good affinity packages.

Convergent Phase

The purpose of the Convergent Phase is to use the affinity groups or packages as the foundation for projects, and perhaps group similar packages into projects, and then to analyze, prioritize, and finally select the project to be proposed. Referring to Figure 2.1, the Convergent Phase consists of these activities:

Define the ECPM project or projects (P1 through P4).
Analyze (P1 and P2 become P5) and prioritize alternatives (P5, P3, P4).
Select the first project to be proposed (P3).

The Convergent Phase is the first time that projects begin to take shape. Even though a single project is chosen, the list still can have residual value if the chosen project does not appear to be delivering business value. You may want to come back to this list for another pick.

Define the ECPM Project or Projects

Whether you use the ECPM Brainstorming Process or some type of Feasibility Study approach you should have generated a few alternatives, and it is time to explore them in more depth in your search for the best alternative. There are several variables that you might use to profile each alternative project. Here are some suggestions:

Risk
Duration
Cost
Team size and skills
Expected business value

Analyze the Alternative Projects

The analysis of alternative projects examines their business value. The objective is to prioritize them and select the best. There are several approaches to analyzing the financial aspects of a project. While the sponsor should perform this analysis, it is often done by a project manager. The approaches I have chosen are easily understood and give enough insight into the financials of the project at this early stage in its life span.

Some organizations require a preliminary financial analysis of the project before granting approval to perform the detailed planning. Although such analyses are very rough because not enough information is known about the project at this time, they will offer a tripwire for project-planning approval. In some instances, they also offer criteria for prioritizing all of the POS documents that senior management will be reviewing.

At one time, IBM required a financial analysis from the project manager as an attachment to the POS. At the time, they were my client and allocated 4 hours for the project manager to complete the financial analysis. Project managers are typically not professional financial analysts, and 4 hours is not much time. So, the resulting analysis will be cursory at best, but it does lend some information relevant to financial feasibility.

Following are types of financial analyses you may be asked to provide. Keep in mind that the project manager may not be a financial analyst, and requiring an in-depth financial analysis may be beyond their ability.

Cost and Benefit Analysis
Breakeven Analysis
Return on Investment
Cost-Benefit Ratio

For further details refer to (Wysocki, 2014a and Wysocki, 2014b).

Prioritize the Alternative Projects

The first tactical STEP in every portfolio management model involves prioritizing the projects that have been shown to be aligned with the portfolio strategy. Proposed projects are usually grouped into funding categories or aligned under Objectives, or under the Strategies that align under Objectives.

Each group defines a potential portfolio. When finished, each group will have a list of prioritized projects. Dozens of approaches could be used to establish that prioritization. Some are nonnumeric; others are numeric. Some approaches are very simple; others can be quite complex and involve multivariate analysis, goal programming, and other complex computer-based algorithms. My approach is to identify methods that can easily be implemented without any pre-requisite knowledge or experience, and which do not require a computer system for support, although sometimes a simple spreadsheet application can reduce the labor intensity of the process. This section describes the models commonly used for establishing priorities:

Forced ranking
Q-Sort
Must-Do, Should-Do, Postpone
Criteria weighting
Paired comparisons
Risk/benefit matrix

For details on each of these models see (Wysocki, 2014a and Wysocki, 2014b).

Select the Project To Be Proposed

STEP 1 ends with the selection of a project to take into STEP 2. Several prioritization lists may have been created for the potential projects identified in the affinity packages. The decision will be based on both quantitative and qualitative data. In the final analysis, these data are guidelines for a decision that is first a good business decision. It would be unusual if all prioritized lists have the same project as highest priority, but it has happened. It is in keeping with the ECPM Brainstorming Model if more than one project were proposed. Let the best project survive the approval StageGate.

The Business Case is the foundation and referent for all project
decisions in both PRINCE2 and ECPM Framework projects. It
maintains alignment of the project to the expected business value
validated for the project.

PUTTING IT ALL TOGETHER

In this article we described the ECPM Framework Brainstorming Process which spans STEP 1 of the IDEATION Phase. It is a robust process that will have application in several contexts during the PRINCE2 project. In this first part we take an idea expressed as a problem or business opportunity and decide on the specific project to be undertaken.

REFERENCES

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

Maul, June (2011). Developing A Business Case: Expert Solutions to Everyday Challenges, Harvard Business Review Press.

Project Management Institute, (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition, Project Management Institute, Inc.

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

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

Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model – Part 2

Written by Robert Wysocki on October 28, 2015. Posted in Articles. 6 Comments on Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model – Part 2

In Part 1 the author discussed the importance of establishing meaningful client involvement throughout the life span of the complex project. In Part 2 the author discusses a tested model for establishing and sustaining that involvement. It is a team structure introduced in the ECPM Framework book [1]. The Co-Manager Model is the infrastructure upon which joint ownership of the deliverables is established and meaningful involvement of the client is assured.

THE BACKGROUND

I have long been an advocate of using the project characteristics and the internal and external environment to drive the choice of project management model and its necessary adaptations to create a best-fit project management environment for a given project. That adaptation extends to the project team as well. In Part 2 of this article, I introduce a new complex project team model. It consists of co-managers — one from the process side and one from the product side. They work collaboratively and equally to share responsibility. I have used a co-manager team structure for over 20 years and wouldn’t do otherwise. I harbor no expectations that this change will be easy, especially for those project managers who are used to a model where they are in charge. In my model, they must share that responsibility.

If I could choose and deliver on only one CSF for managing a complex project, it would be meaningful client involvement. In the complex project world, the client is the best subject matter expert (SME) when solving unsolved problems and exploiting untapped business opportunities. Beyond their SME roles, the experts are the owners of the project deliverables. Their meaningful involvement produces a vested interest in the success of the project. In a sense, their reputation and credibility are at stake. Project success is measured first by the business value that the solution delivers and secondly by the successful execution of the process that created the solution. There is no better way to assure their contribution, commitment and participation than to fully involve them in the process of managing the project. That is the underlying strategy that drives the ECPM Co-Manager Model.

The PRINCE2 project team organization has a number of similarities that may not be too obvious and the PRINCE2 practitioners and professionals will see those similarities. The ECPM Co-Manager Model presents those in its intuitive structure.

Please keep an open mind as we explore these variations of the management model. Remember, the delivery of acceptable business value is the success criterion that drives the project, and the ECPM Co-Manager Model is just another tool for generating that business value. I will always consider this Model as a work in progress as I continue to learn from successful client engagements.

THE COMPLEX PROJECT TEAM

One aspect of establishing meaningful client involvement begins at the team level. The collaborative efforts of a development team and a client team working in partnership creates synergy. This collaboration begins within the management structure of the project team. We begin this discussion with the structure of a typical complex project team (see Figure 1.3). This figure was introduced in Part 1 and is the beginning point for a more detailed discussion.

Figure 1.3 Complex Project Team Overview

A more detailed view of the complex project team is shown in Figure 1.4. This view reflects the team structure described in the PRINCE2 and ECPM Framework documentation. The most notable feature is the level of collaboration that exists among the complex project team. It begins at the project manager level. The typical project manager is named “Process Manager.” The other member of the co-manager team is called the “Product Manager.” As a team, they share equally in all decision making and have equal authority over all project activities.

Figure 1.4 should be considered the full view of the complex project team. It identifies the roles that must be present in the complex project team for a project to be successful and deliver the expected business value. Roles may be combined. For example, the Business Systems Engineer and Development Team Leader roles might be combined into a single position. Implied in this team hierarchy are several positions from a project manager position family. That lends itself to a variety of career and professional development assignment to move an individual through the levels of the project manager position family as a result of their participation on complex project teams.

Figure 1.4 The Complex Project Team

First, observe that a complex project team bears little resemblance to a traditional project team. The traditional project team consists of the development team members and a single project manager. Such a team will not serve the management needs of a complex project.

Second, there are two PMs for every complex project. The co-managers have separate areas of responsibility but share equally in decision making. One co-manager handles the tools, templates, and processes used for the management of the project. This is similar to the traditional project manager. The other co-manager handles the deliverables that the project will produce. The deliverables could be a new or improved product or a new or improved service. For those who are Scrum aficionados, this co-manager is quite similar to the product owner.

The important characteristic to note in Figure 3 is the degree to which the members are interlinked. It is very much like a nonhierarchical structure. An open and honest working relationship among all of the members is essential. The problem being solved or the business opportunity being exploited is complex, and an acceptable solution is not guaranteed. The more complex the project, the higher the risk of failure. Any barriers to success are unacceptable, and that includes the project team organization. So this team structure is very supportive of the interactive nature required for the successful execution of a complex project.

The business systems engineer and the business analyst are consultants to the team. Both of them are familiar with the parts of the business that affect or are affected by the project deliverables. One of the variations promotes both of these consultants to respective co-manager roles. These situations are rare but appropriate for the most complex and uncertain of projects.

The development team needs no further explanation at this point, but the client team can be more complex than you might first envision. The client team can consist of those in a single business unit, and the activities of those teams are quite straightforward. Where multiple business units are involved in the same project, the situation can become far more complex. The complexity begins at the requirements-elicitation phase and continues to the end of the development efforts. Competing and contradictory requirements often arise. In extreme cases, multiple interfaces or user views can resolve contradictory requirements. It takes a village to successfully deliver a complex project. Whenever I refer to “the complex project team,” it is the team shown in Figure 1.4 that I’m referencing.

The co-manager model is the most effective management model for achieving and sustaining meaningful client involvement. I’ve used a co-project manager model since 1991 and will not take on a complex project without using this model or one of the variations discussed in this report.

Use a Co-Project Manager Model

The first and perhaps most important advice I offer is to adopt a practice, where the complex project is co-managed by you and a client representative with decision-making authority. That includes the design and implementation of the complex project methodology and all the projects that utilize the methodology. For that to succeed, the co-manager should be the highest level executive recruitable from the client-side of the enterprise. That person must be capable and willing to meaningfully himself or herself. Token representation is not going to work. Unfortunately, the higher you go in the enterprise, the greater the risk that you will end up with token representation. That would be the death of a complex project. Treat each case as unique and proceed accordingly. You need someone who can provide ideas and visible support. This co-project manager model is a founding principle of my consulting practice. I use it in every project my company undertakes. One manager is myself or one of my consulting partners, and the other is a high-level manager from the client-side. LOB managers, functional managers, and resource managers are often good choices as well. Both managers are equally involved and authorized to make all decisions and share in the success and failure that flow from their decisions. If you put your reputation on the line in a project, wouldn’t you participate in the project to protect your reputation and your business interests? You bet you would.

So the project is technical and the client is not, and they want to know why you want them as your co-manager. That’s easy. Before the project was a technical project, it was a business project, and it needs a business person as a major partner and decision maker. The project team should not be forced to make business decisions. As the technical project manager, you want every decision to be the best business decision possible, and your client is in the best position to make that happen. My client would hear me say that I wanted to do the very best job that I could, and it would not happen without their meaningful involvement as my co-manager on their project. I want my client co-manager to participate in all decisions. They provide the product and business expertise while I provide the process and technical expertise. We do this as co-equals!

Keep the client in the best possible position to make those business decisions in a timely way. Given the need for a business decision, the project team can often present alternatives, maybe rank them, and even offer costs and benefits. Give the client whatever information you can to help them decide. Then step back and let them decide based on whatever business criteria they wish to use.

In the complex project world, holistic decisions — those that balance task feasibility and business value — are even more important and critical. In these projects, either the goal or solution or both cannot be clearly defined at the beginning of the project. The search for an acceptable business outcome drives the project forward. Again, the client is in the best position to choose the alternative directions that lead to the deliverables that produce acceptable business value. Present the feasible technical alternatives to the client and let them choose the best alternative. These iterations are repeated until there is convergence on a goal and solution that achieves the expected business value, or the client terminates the project because it isn’t heading in a fruitful direction. The remaining time, money, and resources can be redirected to a more likely goal and solution. This strategy speaks of a team/client partnership. Without it, success is unlikely.

ESTABLISHING MEANINGFUL CLIENT INVOLVEMENT IN A PRINCE2 PROJECT

The complex project is a high-risk project. The Client is the best SME for an overall mitigation plan to manage and contain that risk. Integrating agile practices such as the ECPM Framework benefits PRINCE2 in a number of ways:

Improved scope planning and requirements management at Client Checkpoints
Early realization of business value through Incremental product/service delivery
Leverage client product/service expertise and create client ownership of deliverables
Efficiently support iterative solution discovery and maintain a lean process

The lessons I learned from the projects discussed in this report are clear. No one can claim a corner on the knowledge market (i.e., more than one SME may be needed), and the client and every team member must be given a chance to contribute openly in a brainstorming fashion to the solution. Creativity is a critical component and must be openly encouraged and practiced. The development team and the client team can form a formidable team, if given the chance, and exploit the synergy that results. Ownership of the resulting solution can only come from giving all of the stakeholders an equal opportunity to meaningfully participate in the development of the solution. I also learned that through ownership of the solution, comes ownership of the implementation. Since it was their solution, they wouldn’t let it fail. The Client took the lead. How often can you claim that?

Implementing these practices takes project manager leadership and courage. For some clients, that requires selling the idea because they were the ones who responded to my request saying they were not technical and couldn’t contribute to a technical project. My selling proposition is that even though they may not be technical, I am not an expert in their line of business or business function. So by combining our separate expertise, we can produce an effective solution and create the expected business value that justified approving the project in the first place. They bring the business knowledge and experience to the table, and my team brings the technical knowledge and experience. Together, we create the synergy needed to find creative solutions in the midst of a complex project world.

PUTTING IT ALL TOGETHER IN A PRINCE2 PROJECT

To begin with, PRINCE2 shares the involvement principle with ECPM. The basic figure is identical.

Figure 1.5 The PRINCE2 Organization Combination

On the surface, comparing the ECPM project organization with that of PRINCE2 there may seem a number of differences, but let’s explore the two organizations in depth. Let’s start by looking at the basic PRINCE2 project organization.

Figure 1.6 The Standard PRINCE2 Project Organization

As emphasized in the earlier text, the involvement of the client and the users of the end product is essential. Let’s see how the standard PRINCE2 project organization deals with this. As figure 6 shows, the client (customer) is involved at the top in deciding who should take on the various roles. The Project Board contains the three decision-making roles for the project. The Executive holds the budget and is ultimately responsible to the client for the successful delivery of the end products. In almost all cases, this role is filled by a manager of suitable seniority from the client. The role corresponds exactly with the ECPM Sponsor role.

The Senior User role is a manager from the client area where the end products will be used. This role confirms that the specification accurately describes the user needs and at the close confirms that the end product meets that specification and the acceptance criteria. There is a strong link between this PRINCE2 role and the ECPM Product Co-Manager.

The PRINCE2 project team has a Project Assurance role. This, in fact, is a ‘team’ of roles; Business Assurance, User Assurance, and Supplier Assurance. It is the job of the User Assurance to monitor the project on behalf of the user, and can directly relate to the Business Analyst role in ECPM. The User Assurance role works with the Project Manager but reports to the Senior User. Between them, the roles of Senior User and User Assurance combine the ECPM roles of Product Co-Manager and Business Analyst. The PRINCE2 role of Senior User on the surface of it has more authority and may be more remote than the ECPM Product Co-Manager, but sensible professionals can establish a good working relationship.

The ECPM role of Business System Engineer matches the PRINCE2 role of Supplier Assurance. There is, of course, no barrier to including business systems engineers as development team members.

The PRINCE2 role of Team Manager corresponds directly with the ECPM role of Task Leader. PRINCE2 has teams and it is normal in complex projects to have a client team working on the specification, working with the develop teams in creating a design that will meet the specification and co-operating in all work. Whereas figure 4 shows separate teams for developer and client, PRINCE2 simply looks at them as teams. They could be separate client and developer teams, as in ECPM, or be a combined team. Keeping them separate as in ECPM means fewer management problems.

Looking at the ECPM argument for SMEs, PRINCE2 offers the roles of Senior User and User Assurance to provide SMEs for all user tasks, such as product specification, migration planning, and quality verification.

Improved scope planning and requirements management at Client Checkpoints
Early realization of business value through Incremental product/service delivery
Leverage client product/service expertise and create client ownership of deliverables
Efficiently support iterative solution discovery and maintain a lean process

The lessons I learned from the projects discussed in this report are clear. No one can claim a corner on the knowledge market (i.e., more than one SME may be needed), and the client and every team member must be given a chance to contribute openly in a brainstorming fashion to the solution. Creativity is a critical component and must be openly encouraged and practiced. The development team and the client team can form a formidable team, if given the chance, and exploit the synergy that results. Ownership of the resulting solution can only come from giving all of the stakeholders an equal opportunity to participate meaningfully in the development of the solution. I also learned that through ownership of the solution, comes ownership of the implementation. Since it was their solution, they wouldn’t let it fail. The Client took the lead. How often can you claim that?

ENDNOTES

The Standish Group. “Chaos Manifesto 2013.”
IBM. “Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study.” 2010.
Figure adapted from Hass, Kathleen, and Lori Lindbergh,(“The Bottom Line on Project Complexity: Applying a New Complexity Model, Proceedings of PMI Global Congress 2010 Proceedings, Washington, DC.) and used with permission.
Wysocki, Robert K. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. J. Ross Publishing (2014).
Wysocki, Robert K. Executive’s Guide to Project Management: Organizational Processes and Practices for Supporting Complex Projects. Wiley, 2011.
Wysocki, Robert K. The Business Analyst/Project Manager: A New Partnership for Managing Complexity and Uncertainty. Wiley, 2011.

NOTE
A more complete version of this article will be published in a forthcoming book:

Combining the Best of PRINCE2 and Agile: Using Selected Artifacts from the ECPM Framework (Wysocki, Robert K. and Colin Bentley, J. Ross Publishing, forthcoming summer 2016).

Strengthening Client Involvement in the PRINCE2 Process: Using the ECPM Co-Manager Model

Written by Robert Wysocki on October 14, 2015. Posted in Articles. 4 Comments on Strengthening Client Involvement in the PRINCE2 Process: Using the ECPM Co-Manager Model

PART 1: Establishing Meaningful Client Involvement

This is the first of a two part article. Part 1 discusses the importance of meaningful client involvement to the success of the PRINCE2 process and its deliverables. Part 2 discusses how the ECPM Co-Manager Model can be the enabler of that success.

Meaningful client involvement and the Co-Manager Model are unique to the ECPM Framework and the infrastructure upon which joint ownership of the deliverables is established and expected business value delivered. This is particularly important because many complex projects are often characterized as journeys into the unknown. A solution to a significant problem is not known and so the best resources available must be used to maximum benefit. The complete solution must be discovered through iteration and must deliver the expected business value in order to be acceptable. For the most complex of projects this can only happen in an open and creative team environment. That places a burden on the project team to embrace an infrastructure that supports and encourages meaningful client involvement and a challenge to senior management is to provide the infrastructure to support that involvement.

Remember that the client is often the best qualified Subject Matter Expert (SME) when it comes to an in depth understanding of the business process or product under consideration. While the client has a prominent role in the PRINCE2 team structure, there are some significant improvement opportunities that can result from incorporating the ECPM Framework Co-Manager Model into the PRINCE2 team structure. Maximizing client involvement in all aspects of the project will be the best strategy.

THE BACKGROUND

Not too long ago, client involvement required nothing more than the client signing off on a lengthy and confusing functional specification loaded with unintelligible acronyms. This signing was more an implied threat of project delays than an agreement on content. Fortunately, those days are history. Technology is more user-friendly, clients more technologically savvy, and satisfying their needs requires a participatory process. That’s the good news.

The bad news is that client involvement doesn’t come without challenges. As complexity increases and uncertainties surrounding solution discovery grow, meaningful client involvement becomes a major critical success factor (CSF). The project manager (PM) must be more attuned to the management processes they use and how those processes impact solution discovery and the subsequent generation of business value. The client or their business analyst (BA) must be more attuned to how the product deliverables contribute to business value. Both parties must create an open and honest relationship in order to improve the likelihood of achieving project success and delivering acceptable business value. Synergy is found through those cooperative efforts, and without it, the likelihood of finding acceptable solutions is at risk.

Keep in mind that the client may be the best subject matter expert (SME) when solving unsolved problems and exploiting untapped business opportunities. Beyond their SME roles, they are the owners of the project deliverables. Their meaningful involvement produces a vested interest in the success of the project. In a sense, their reputation and credibility are at stake. Project success is measured first by the business value that the solution delivers and secondly by the successful execution of the process that created the solution.

A QUICK VIEW OF COMPLEXITY AND UNCERTAINTY

Complexity and uncertainty are two characteristics common to most contemporary projects. Furthermore they create a challenge to the success of even the most sophisticated management approaches. To be successful PRINCE2 processes and practices must take full advantage of available tools, templates and processes designed for just such situations.

Increasing Complexity

All of the simple projects have been done. They left a rich heritage of recorded experiences for use in future simple projects. Remaining projects become more complex every passing day. Situations that have never been encountered are more the rule than the exception. As problems become complex, they also become more critical to the success of the enterprise. They must be solved. We don’t have a choice. They must be managed, and we must have an effective way of managing them. Integrating lean artifacts from the ECPM Framework into PRINCE2 is the recommended strategy.

Increasing Uncertainty

With increasing levels of complexity comes increasing levels of uncertainty. The uncertainty relates to the organization’s ability to find acceptable solutions. Adapting project management approaches to handle uncertainty means that the approaches must not only accommodate change, but also embrace it and become more effective as a result of it. Change will lead the team and the client to a state of certainty with respect to a viable solution to its complex problems. In other words, we must have project management approaches that expect change and benefit from it. Increasing levels of complexity and uncertainty means the project management approaches must allow for creativity, flexibility, and adaptability on the part of the complex project team. That is the new reality. The complex project team must be staffed with subject matter experts (SMEs) who have the deepest understanding of the project situation and can investigate possible solutions.

An intuitive way of graphically presenting complexity and uncertainty [2] is shown in Figure 1.1.

Figure 1.1 Traditional Projects versus Complex Project Landscape

Quadrant 1 (Q1) is familiar territory as it houses the traditional projects. All types of Waterfall and other linear and some incremental models are used for projects in Q1. Quadrants 2, 3 and 4 are the domain of the complex projects. While a simple taxonomy it facilitates the mapping of project types and requirements to the best fit project management model. In practice it has proven to be comprehensive in scope and inclusive of all known project management methodologies. As project execution continues the project management environment adapts to changing conditions. This approach is a unique feature of the ECPM Framework and has contributed to significant increases in project success and the delivery of sustainable business value.

THE COMPLEX PROJECT TEAM

One aspect of establishing meaningful client involvement begins at the team level. The collaborative efforts of a development team and a client team working in partnership creates a synergy. This collaboration begins within the management structure of the project team. We begin this discussion with the structure of a typical complex project team (see Figure 1.2).

Figure 1.2 Complex Project Team Overview

The Complex Project Team is fully discussed in Part 2 and not further described here. For now it is sufficient to know that the Co-Manager Model to be discussed in Part 2 is unique to the ECPM Framework and in it are features that are easily integrated into PRINCE2 that will improve process performance.

THE IMPORTANCE OF MEANINGFUL CLIENT INVOLVEMENT

The complex project landscape is populated with unsolved problems and business opportunities not yet exploited. None of these are easy projects. Some have been worked on before with less-than-satisfactory outcomes or no usable outcomes at all. If these projects are critical to the business, they must be successfully executed and produce the results for which they were undertaken. So the best approach for an enterprise is to utilize a complex project management approach that brings the appropriate parties together into a true team environment and turns them loose to find the sought-after solutions. The team must be self-sufficient. It isn’t sufficient to just put them together in the same room and hope for an acceptable business solution. There must be guidelines, tools, templates, and processes from which they craft a “recipe” to manage such challenging projects. That is a role for the complex project co-managers supported by an effective complex project management framework.

In its 2013 CHAOS report, the Standish Group cited lack of client involvement as the second most critical factor for project failure.[2] In fact, without meaningful client involvement from the start of a complex project, failure is certain. It’s not just important to involve clients — that involvement must be meaningful. Simply getting a sign-off on an implementation, some arcane specification, or confusing test plan is not meaningful involvement. For over 20 years I have utilized a simple homegrown practice in my consulting practice that fosters an ownership position and encourages the client to do whatever they can to make the project successful. Remember that an ownership position puts reputations on the line to deliver business value just as the project manager’s reputation is on the line to create and manage an effective process. Meaningful client involvement is an acquired practice and is purposely designed into the entire complex project lifespan.

Meaningful client involvement begins before the complex project has even been formulated. It begins at the point where the enterprise defines the desired end state and extends through to implementation planning and execution. In other words, meaningful client involvement is an effort that extends across the entire complex project from conception to birth to maturation. To get the continuing full benefit from these projects, the enterprise must commit to this effort. For most organizations it will be a complete evolution of how they approach the management of their projects, programs, and portfolios. It is one of the enabling factors for the strategic plan of the enterprise.

THE CHALLENGES OF CULTIVATING MEANINGFUL CLIENT INVOLVEMENT

Early in my career as a project manager I invited my client to work with me on a particularly complex software development project that my team was ready to start for them. The solution we sought had been elusive for a number of years and had reached the stage where it affected the business. The need was now critical, and something had to be done. Despite our best efforts, the risk was high that we would fall short of meeting the sponsor’s objectives and their expected business value. We knew that we may not be able to create the best solution, but as a minimum, it had to be an acceptable solution. Later solutions could improve the original solution. We faced a particularly high-risk assignment due to the complexity of the business processes involved. If I was going to be successful, I knew I would need the participation of the client far beyond the common practice of the time. So I extended an invitation to the client to get meaningfully involved with the development team. I didn’t know what reaction I would get.

The client’s first reaction was that they didn’t know anything about software development and didn’t understand how they could help. They balked at my invitation, and it took some reassurance from me that I would need their expertise if we were to be successful. Fortunately, I built a trusting relationship with them from previous project successes and at least I convinced them to participate. It was clear that I was in a “show me” situation.

What If You Can’t Get the Client Meaningfully Involved?

This is a tough situation to face and history is not on our side. Not having meaningful client involvement in a complex project is a show-stopper. In my earlier days, I might have said I would find some work around and do the project without the meaningful involvement of the client. Now with several years’ experience to draw on I just wouldn’t do the project until the client was willing to be meaningfully involved. I’ve tried both the workaround and the delay strategies and had a few successes but left a lot of blood on the trail. I often won the battle but lost the war. In general neither strategy met with my satisfaction. Now I tend to follow a more diplomatic route. The success of the project is critical to the continued operation of the business and is beyond your authority to cancel or postpone. On the assumption that the project will go ahead what would you, could you, or should you do? Of prime importance is finding out what barriers to meaningful involvement exist in the mind of the client and put a mitigation program in place. Two barriers come to mind, but there could be others.

What If the Client Was Burned by Prior Project Experiences and Is Hesitant to Get Involved?

If this is the problem, the technical professionals have inherited some significant baggage from their grandfathers. In those days, the customer wasn’t really encouraged to get involved. Just get the requirements document written and approved and turn the project over to the development and delivery teams. The prevailing attitude was that the client would only slow the process down. Fortunately, that attitude hasn’t survived but the memory of it has. The client is much more comfortable minding their own business and leaving technology to the technical folks. The client gets involved but only when the development and delivery team offers them a comfortable way to get involved.

The burden is on the project team to change this attitude. Depending on the particular circumstances that the client faces, different initiatives on the part of the project team can be employed. Workshops, seminars, site visits, conferences, and other venues are productive. One strategy that I have had excellent results with is to engage the client in concurrent workshops and seminars that are imbedded in their complex project and to use actual project team exercises based on the project. This is an effective twist on the “learn by doing” principle that underlies all successful complex projects.

What If the Client Wants to Get Too Involved?

Yes, I have encountered this situation too — but not very often. Taking a cue from the days of end-user computing, there will be clients who aggressively promote their solution. They want to get too involved. They push hard to get their own solution on the table and are reluctant to consider other ideas. You don’t want to discourage them from sharing their ideas, but you don’t want to risk missing a better solution. They can be an effective team player and the best SME you might have, but their eagerness must be channeled.

I have borrowed process ideas from prototyping and brainstorming as appropriate. For example, you might start solution design with their solution and discuss ways it might be improved with other features and functions. Often, the client will not be aware of other systems and processes that can be used to their advantage. Both prototyping and brainstorming can be used here to include these systems and processes in the client’s solution with good results. Assuming the client offers good suggestions, exploit this with discussions about more sophisticated solutions that cause them to generate even greater business value than their solution affords. Capitalize on the knowledge that the client displays through their input.

Clients come in all sizes and descriptions. Some are a veritable fountains that spew ideas and changes. This may seem like an enviable situation, but don’t overlook the need for convergence to a solution. Their behavior can cause the team to spend too much time on non-value-added work as they do their analysis of the scope implications and contribution to business value.

Others don’t seem to have any ideas to share or maybe the project manager hasn’t created the open and honest team environment that is needed. This is a dangerous situation and calls upon all of the skills of the project manager and the development team. Change is critical in every complex project. Here is the list. It is explored in the forthcoming book (see NOTE at the end of the article):.

Always Use the Language of the Client
Maintain a Continuous Brainstorming Culture
Use a Co-Project Manager Model
Establish an Open and Honest Team Environment

ESTABLISHING AND SUSTAINING MEANINGFUL CLIENT INVOLVEMENT IN A PRINCE2 PROJECT

The complex project is a high risk project. The Client is the best SME for an overall mitigation plan to manage and contain that risk. Integrating agile practices such as the ECPM Framework benefits PRINCE2 in a number of ways:

Improved scope planning and requirements management at Client Checkpoints
Early realization of business value through Incremental product/service delivery
Leverage client product/service expertise and create client ownership of deliverables
Efficiently support iterative solution discovery and maintain a lean process

The best way I have found for establishing and sustaining meaningful client involvement is by using the ECPM Framework Co-Manager Model. That is the topic of Part 2 of this article.

NOTE

A more complete version of this article will be published in a forthcoming book:

Combining the Best of PRINCE2 and Agile: Using Selected Artifacts from the ECPM Framework (Wysocki, Robert K. and Colin Bentley, J. Ross Publishing, forthcoming summer 2016).

ENDNOTES

The Standish Group. “Chaos Manifesto 2013.”
Wysocki, Robert K. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. J. Ross Publishing (forthcoming 2014).

New Series – PRINCE2 and the ECPM Framework Comparison

Written by Robert Wysocki on September 18, 2015. Posted in Articles. 4 Comments on New Series – PRINCE2 and the ECPM Framework Comparison

Integrating ECPM Artifacts to Improve PRINCE2 Performance

Since its introduction in 1996 PRINCE2 has expanded to where it is now being used in more than 150 countries including the U.S. It has established itself as the de facto project management standard in the EU and elsewhere. It is now gaining a footprint in the U.S. as validated by the growing number of training offerings available. As the PRINCE2 community grows in the U.S. there is an unmet need to share with them how some of the agile artifacts that have worked so well in the U.S. can improve PRINCE2 performance. PRINCE2 predates the agile movement and, while adaptable, it is not based on agile, lean principles. There is a clear synergy to be gained from that integration.

My intent is to bring that integration to the attention of the global PRINCE2 community through this series of articles. My purpose is to help you improve your PRINCE2 project management performance regardless of which side of the pond you call home.

My efforts have been reinforced through my collaboration with Colin Bentley. He first authored PROMPT II in 1975 and was also a major contributor to PRINCE2 in the 1996, 2005 and 2009 editions of the PRINCE2 Manual. Upon his retirement he was the Chief Examiner of PRINCE2 examination papers. Colin is still active in the profession and a constant source of advice and inspiration to me.

RATIONALE

PRINCE2 and the ECPM Framework (Wysocki, Robert K. 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing) are similar. They are both adaptive and designed to produce best fit project management models tailored to the project characteristics. Quoting from each of their descriptor documents:

PRINCE2 is not a “one size fits” all solution. Rather it is a Flexible Framework that can readily be tailored to any type or size of project.
ECPM is not a methodology. Rather it is an Adaptive Agile Framework that utilizes robust decision processes to build best fit management models driven by project characteristics and the internal/external environments in which it is executed.

These are very high-level similarities. But there are differences as well. For example, the ECPM Framework is designed around the “Lean Principles”. PRINCE2 is not. That difference is significant in today’s competitive marketplace and opens a number of opportunities to improve PRINCE2 performance through integrating selected ECPM Framework artifacts. In fact, many of the ECPM Framework artifacts can be integrated into PRINCE2 with minimal disruption. That allows the PRINCE2 community to pick and choose from among the recommended artifacts for maximum business value and performance improvement. There is a great deal of synergy that can result from such integrations. The ECPM Framework has a long and successful history based on over 20 years of U.S. client experiences. The ECPM Framework was designed around these successful client experiences. So we know that the ECPM Framework works because Bob was there to see that it worked.

Figure 1: A Side-by-Side Comparison of PRINCE2 and the ECPM Adaptive Agile Framework

THE ARTICLE SERIES

There is a clear synergy to be realized by integrating certain artifacts from the ECPM Framework into PRINCE2. Such is the rationale for this book. The ECPM Framework grew out of over 25 years of EII client experiences and provided the concept and design of the ECPM Framework. This book brings those experiences to the forefront. The strength of these experiences is that they not only identify “WHAT” must be done (as does PRINCE2) but also “HOW” to do it. This takes PRINCE2 to the Practitioner and even Professional levels and much closer to defining how to accomplish performance improvements. To that end the article series discusses the 10 topics summarized below.

Strengthening Client Involvement in the PRINCE2 Process: Using the ECPM Co-Manager Model

Meaningful client involvement has been cited (Standish Group, 2013) as a critical success factor to project success. The best way to accomplish this is to give the client a leadership role in project planning and execution. Having them as a co-manager of their projects is the most effective way of achieving that involvement.

Project Initiation in PRINCE2: Using the ECPM Brainstorming Process

Among the most effective ways to get a project headed in the right direction is a project formation process that is an open and honest process for validating the project. This begins with the IDEATION Phase. It is a three step Phase that begins with a unique Brainstorming Session, High-level requirements elicitation and the brief description of the project.

Lean PRINCE2 Stage Planning in the Face of an Incomplete Solution: Using the ECPM High-level Requirements Definition

Project management thought leaders are in unanimous agreement that defining and clearly documenting complete requirements at the initiation stage of a project is not possible. The world is dynamic and so are the deliverables from a successful project. But what is possible is the definition of high-level requirements that identify “WHAT” a successful solution must include without any conditions placed on “HOW” that solution will be achieved. Stage Planning is based on high-level requirements.

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

The Iron Triangle (cost, time, scope) does not work in the complex project landscape. Rather the ECPM Scope Triangle (cost, time, scope, quality, resource availability, and risk) define a project as a system in balance. When changes occur that put the system out of balance, problem solving and decision making processes are invoked that restore that balance.

Lean PRINCE2 Change Management: Using the ECPM Bundled Change Request Process

Change management processes are notoriously “not lean.” In the ECPM Framework project space this is unacceptable. PRINCE2 is not a lean process. The ECPM Framework utilizes a Bundled Change Request Process designed specifically to preserve its lean principles and assure better decision making with respect to analyzing, approving and prioritizing change.

A Lean Planning Tool for PRINCE2 Stage Management: Using the ECPM Scope Bank

In the complex project landscape a project is a dynamic environment looking for a previously unknown solution in the face of complexity and uncertainty. To effectively manage such a high-risk situation a clearinghouse is a requirement. In the ECPM Framework that clearinghouse is the ECPM Scope Bank. Think of it as the documented history of how the solution has evolved. As such it contains all of the information needed to make good business decisions regarding the future course of the project’s journey.

Lean PRINCE2 Stage Planning: Using ECPM Probative & Integrative Swim Lanes

A complex project is a journey in search of an unknown solution to a critical business problem or untapped business opportunity. As such it is high-risk. An acceptable solution may not even exist given current knowledge and technologies. Such projects must be founded on lean principles and nowhere is that more critical than in how resources are spent looking for that solution. Those “looks” are based on a sequence of “investigating feasible ideas.” But the project team must be frugal in how and where it spends its limited resources. Such is the nature of the Probative and Integrative Swim lanes that are the components of a single ECPM cycle.

Ending a PRINCE2 Stage: Using the ECPM Lean Strategies

The ECPM Framework cycle planning process includes establishing the cycle duration. There are several ways of doing that but once it is set it does not change. If the cycle duration has expired and the planned tasks are not all complete, the cycle ends and all incomplete tasks are returned to the Scope Bank for reprioritization and scheduling for a later cycle.

There are situations that occur and these are discussed in this article.

Improved PRINCE2 Stage Planning: Using the ECPM Client Checkpoint

The Client Checkpoint can be described as the traffic cop for an ECPM project. One of three decisions are possible: the project is complete and is ended, the project is not complete but should be terminated or the project should be continued to the next cycle. All three decisions are supported using data in the Scope Bank.

Improving PRINCE2 Project Manager Flexibility: Using the ECPM Vetted Portfolio of Tools, Templates and Processes

Every organization is unique with respect to the portfolio of tools, templates and processes that it uses to manage project and other business processes. The portfolio contents are vetted usually by the PMO. Once vetted the ECPM Framework gives the co-managers the authority and responsibility to choose how to use the portfolio to best manage its projects.

NOTE TO READERS

My intent in this article series is to integrate several artifacts from the ECPM Framework (Wysocki, 2014) into the PRINCE2 Framework. To date PRINCE2 AgileTM (AXELOS, 2015) is the recognized authority on the agile version of PRINCE2. Under the leadership of Keith Richards, AXELOS has taken a bold step forward. The next step is to augment that progress with several artifacts taken from the ECPM Framework and integrated into PRINCE2 Agile.

Through the integrations defined in this series I hope for two results:

To offer ProjectTimes readers some ideas to further enhance the performance of their PRINCE2 projects,
To encourage an exchange of ideas and other suggestions among the PRINCE2 community on both sides of the pond.

There is much to be gained from such exchanges. To that extent I welcome your comments below.

ENDNOTES
1. AXELOS, 2015,The Stationary Office
2. The Standish Group. “Chaos Manifesto 2013.”
3. Wysocki, Robert K. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. J. Ross Publishing (2014).

A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Written by Robert Wysocki on July 28, 2014. Posted in Articles. 3 Comments on A Fresh Look at Requirements and Requirements Elicitation in Complex Projects

Wysocki July28 It is widely accepted that the elicitation of complete requirements during project ideation is very unlikely except in the simplest of projects. There are a number of internal and external factors that affect the solution and its clarity that often change during the project life span that accounts for this. The environment is dynamic. It doesn’t stand still just because you are managing a project! These factors create process challenges that can be mitigated by a simple change in the definition we use for a requirement. This simple change of definition simplifies many of the project management process problems and improves the likelihood of delivering the expected business value.

THE REALITIES OF THE COMPLEX PROJECT LANDSCAPE

As part of the Ideation Phase of a complex project we can define
“WHAT” an acceptable solution has to contain and the business
value it is expected to generate.

At the start of a complex project we may “NOT KNOW HOW” to
achieve an acceptable solution.

The resulting incompleteness is a logical consequence of the
Plan-driven definition of a requirement. That incompleteness can
be removed by using a Change-driven definition of a requirement.

Using a Change-driven definition of requirements implies that an
iterative project management approach will be required.

Most project management processes use a Plan-driven definition of requirements. That will not work in the contemporary complex project landscape. This article introduces a Change-driven definition of requirements. That simple change eliminates the obstacle.

A SOLUTION TO INCOMPLETE REQUIREMENTS

To a certain extent we have become trapped by our own view of requirements and their elicitation. The IIBA definition may fulfill its objectives but at what price? The IIBA definition of requirement is a Plan-driven definition and it tries to define both the “what” and the “how”. In independent projects that works. But in complex projects that seldom works. The Effective Complex Project Management (ECPM) definition of requirements proposed below is a Change-driven definition. It focuses only on the “what”. The “how” is developed within the Work Breakdown Structure (WBS) and the project execution phase.

THE ECPM DEFINITION OF REQUIREMENTS

The IIBA definition is all well and good and I’m not going to challenge it. I assume it accomplishes what its creators envisioned. But let me offer a different perspective for your consideration. I believe we execute projects to solve critical problems or exploit untapped business opportunities with the ultimate goal of generating business value.

The need to deliver business value

Using cost, time and scope as the variables for measuring project success misses the point of doing a project. The success of a project is measured by the achievement of business value – the more the better. The total cost of the project is measured against the business value generated to calculate Return on Investment (ROI) and compare against other projects competing for the same resource pool.

Complexity and uncertainty

The IIBA definition of requirements is a one step Plan-driven definition. That gives rise to incomplete requirements except in the simplest of situations. The definition of an ECPM requirement given below is a two step Change-Driven definition. In the first step the requirements definition focuses on the “what”. At this level requirements are complete. Think of them as defining an ideal end state. With requirement defined the focus of the solution turns to the second step – the “how”.

DEFINITION: ECPM Requirement

An ECPM requirement defines a component of the desired
end state and when integrated into the solution meets one
or more business needs and delivers specific, measurable
and incremental business value to the client business unit.

The set of ECPM requirements forms the necessary and
sufficient set needed to establish the desired end state and
attain the planned business value.

Adapted from: Wysocki, Robert K, (September, 2014), “Effective Complex
Project Management: An Adaptive Agile Framework for
Delivering Business Value”, J. Ross Publishers

“How” is usually not known at the outset of the complex project. It can only be discovered through successive learning and discovery iterations that build upon a solution that is converging to the desired end state. So at the start of the complex project the definition of “how” is incomplete. Very little of the solution might be known at the outset or most of the solution known with only a few details missing but the solution is not completely known at the outset. So the “how” is the second step of the ECPM requirements definition and its discovery is imbedded in the Work Breakdown Structure (WBS).

The necessary and sufficient conditions statement means that all requirements are needed in order to achieve the planned business value and none of the requirements are superfluous. This is important because the project was justified based on the expected business value as described through the success criteria in the Project Overview Statement (POS). Linking requirements to the success criteria provides a basis on which to prioritize requirements.

This definition of a requirement is quite different than the IIBA definition but in its simplicity and uniqueness it puts the connection between requirements and the business value in a much more intuitive light. I have no particular issue with the IIBA definition but I believe that a working definition linked to business value is a better choice. I will use the ECPM definition throughout this article.

An example of an ECPM Requirement
from a project to establish a
Workforce and Business Development Center

A Business Incubation Center (BIC) (Figure 1) to support the needs of students, workers, entrepreneurs and local businesses for career and professional development and business growth.

Figure 1: The Business Incubation Center (BIC)

Requirements will be the causal factors that drive the attainment of the success criteria as stated in the POS. Every requirement must be directly related to one or more project success criteria stated in the POS. This definition results in a small number (less than 12 for example) of high level requirements at the beginning of the project, whereas the IIBA definition generates hundreds and even thousands of requirements which can never be considered complete at the beginning of the project. The last time I applied the IIBA definition resulted in my client and team generating over 1400 requirements! The human mind cannot possibly absorb and understand that many requirements. To expect that a decision as to completeness can be made in that example is highly unlikely. Subject to the learning and discovery that may uncover other requirements, the list generated using the ECPM Requirements definition can be considered complete at the beginning of the project. An ECPM Requirement is a more business-value-oriented definition than the IIBA definition. The learning and discovery derived from completed project cycles will clarify the requirements through decomposing them to the function, sub-function, process, activity, and feature levels. The first-level decomposition of a requirement is to the functional level and can be considered equivalent to IIBA requirements but in ECPM parlance it is no longer a requirement. It is a function that must be present as a condition of achieving the requirement. So while you can identify all requirements at the beginning of the project you cannot describe the details of the requirements at the functional, process, activity and feature levels. This detail is learned and discovered in the context of the cycles that make up the project.

BENEFITS FROM USING ECPM REQUIREMENTS

Framed in the language of the client
Relate directly to the generation of business value
Helps create and maintain client ownership and meaningful involvement
Integrates all of the steps that define effective complex project management
Reduces the number of requirements from hundreds to less than 12.
Become the basis for solution development
Related directly to project success criteria

PUTTING IT ALL TOGETHER

Current definitions of requirements include both the “what” and the “how.” This leads to incomplete requirements specification for every project except the simplest. The result is confusion and problems associated with the execution of the chosen complex project management process. The ECPM Requirements definition focuses on the “what” and with few exceptions will be complete. Choosing the best fit complex project management process becomes a well-defined decision. The “how” is identified incrementally through a Work Breakdown Structure (WBS) derived from the set of requirements.

Deploying this ECPM Requirements definition across the project life span introduces changes to the project management process that have every reason to significantly improve project performance and reduce the risk of project failure. The discussion of those changes is beyond the scope of this article.

Don’t forget to leave your comments below.