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

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.

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 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?

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.

ENDNOTES

1. The Standish Group. “Chaos Manifesto 2013.”
2. IBM. “Capitalizing on Complexity: Insights from the Global Chief Executive Officer Study.” 2010.
3. 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.
4. Wysocki, Robert K. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. J. Ross Publishing (2014).
5. Wysocki, Robert K. Executive’s Guide to Project Management: Organizational Processes and Practices for Supporting Complex Projects. Wiley, 2011.
6. 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).