Tag: PRINCE2

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

Five Signs That You May Not Want to Become a Project Manager

Written by Kiron Bondale on September 30, 2015. Posted in Articles. 7 Comments on Five Signs That You May Not Want to Become a Project Manager

Sustained demand for skilled project managers continues to attract newcomers to the profession – some are just starting their careers while others are looking to start a new phase of their working life.

Job shadowing, information interviews, online sites and volunteer work are all great ways to learn something about the profession, but these avenues are unlikely to provide you with sufficient insights into the daily life of a project manager to determine if this is the right career path for you.

Given this, you may wish to review the following list to see if you exhibit any of these warning signs.

You are not comfortable with change and ambiguity

Project management is the medium by which strategic changes get realized, so one might reasonably assume that most project managers would be thriving on change.

Unfortunately, change resilience is a continuum and not a binary attribute.

I’ve witnessed project managers who are quite comfortable with the magnitude of the change that will be implemented become defensive and even aggressive when shifts from within or without their organization result in scope changes. A plan is just a model of reality based on a foundation of assumptions and when reality shifts, the plan needs to shift with it.
If you are someone who prefers to have all the information required before making a decision, the uncertainties that are part of the DNA of projects are apt to drive you crazy. Yes, you can try to engage more and more stakeholders and subject matter experts to fill in the gaps for you, but there is a tipping point after which further delays and costs of analysis will outweigh the impacts of a bad decision.

You prefer working with tools than with people

Hard skills are table stakes for project managers.

I realize that creating a perfectly optimized, fully resource-levelled project schedule might be a euphoric experience, but that should just be a means to a greater end.
Your ability to align multiple stakeholders with competing agendas or to cultivate a performing team made up of diverse personalities and egos all with little or no formal authority are orders of magnitude more critical to succeeding as a project manager than your expertise in wielding the multiple tools of the trade.

When working on a project, if you find yourself frequently saying it would be much easier if you were the only person involved with it, project management may not be your thing.

Related Article: 10 Must Have Skills for the Project Manager

You avoid difficult conversations

I’m sure that all of us have wished for the following scenario: fully aligned stakeholders, a team of subject matter experts who all work well together, generous cost and schedule constraints, and a well understood and easy to deliver set of deliverables.

The reality of project management doesn’t quite fit this vision.

Many times over the life of any moderately complex project you will need to have a tough conversation with someone. Perhaps a deadline is in jeopardy, the project will cost more than expected, or a team member is not performing up to expectations.

Your ability to analyze the situation and situationally react to it may be the difference between a customer who is peeved for a few minutes but gets over it quickly or project failure.

Yes, we all want to be liked, but if you shy away from difficult project conversations, you will end up as a likable but ineffective project manager.

You have to be the smartest person in the room

Staff who are suddenly moved into a project management role face a common challenge. They might make excellent subject matter experts but make poor servant-leaders.

Unfortunately, for some SMEs no amount of training or coaching is sufficient for them to put aside their desire to be the center of attention.

There’s nothing wrong with this need, but it is the wrong ingredient for succeeding in project management.

A good project manager finds a way to effectively leverage all the skills on the team, positions the team front and foremost for recognition & reward while shielding them from criticism or negative feedback.

You can’t multitask

Over the life of a project, there are always multiple critical activities needing to be handled by the project manager. The demands and actions of stakeholders and their team members heavily influence a project managers’ days

You might have preferred to have finished publishing the minutes from your last meeting, you need to meet this very moment with two team members who are getting into a heated philosophical argument. Telling them, “Sorry I’m busy” sends the message that you don’t care about them or about the impacts this disagreement are having on the project.

If working on fifteen different activities, but not completing any of them leaves you feeling unfulfilled at the end of the day, stick with the role of an individual contributor.

Project management has become a very popular profession so it’s quite understandable that you’d want to pursue it. As the Rolling Stones sang so well: “You can’t always get what you want”.

New Series – PRINCE2 and the ECPM Framework Comparison

Written by Robert Wysocki on September 18, 2015. Posted in Articles. 10 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).

The Promise of PRINCE2 Agile TM

Written by Jane Marshall-Nichols on June 10, 2015. Posted in Articles. 12 Comments on The Promise of PRINCE2 Agile TM

A perfect storm of circumstances in public sector project management is helping open the door to agile methods.

First, some projects have not been as successful as expected – either not delivering a product or not meeting stakeholder expectations. Combining those issues with the likely continuation of Government austerity measures and greater scrutiny makes it highly appealing to have access to methods that will help run projects more effectively.

In addition, there has been significant spending on PRINCE2® training and certification in the public as well as private sectors and organizations want to ensure their investment is achieving maximum return. Practitioners who have gained both Foundation and Practitioner certification could be using their best practice expertise to even greater effect by applying more widely the methodology they learned to pass the exam.

This means taking the use of PRINCE2® beyond knowledge to tangible application and increasing return on investment as a consequence. And this is why the creation of PRINCE2 Agile will provide a winning combination of methodologies to projects; adding agile to the PRINCE2® approach makes it more flexible, practical, and valuable.

It’s about having a project management approach that’s already trusted and adding the new ‘suitability test’ to ensure the approach adopted is right for the project in question. This will help project managers develop their ability as professionals to choose the best approach for a project and make the right judgments rather than be constrained by the use of a single method.

Why blend PRINCE2® and Agile?

Blending PRINCE2® and Agile will take practitioners beyond simply ‘having knowledge’ and equip them with practical techniques to get underway. The advantage of bringing both approaches together means the project managers are not ‘going back to scratch’ but are building on their existing knowledge.

From an organization’s point of view, this will help realize the investment made in PRINCE2® and address the areas where, in some instances, it doesn’t quite fit. In simplistic terms, it will enable organizations to be more agile by using approaches that help deliver what the user wants without expecting the user to say up-front “I know what I want.” Instead, the project can present the possible outcome in smaller pieces and test them with the user to demonstrate what’s possible without having to decide in detail on a final product from the outset.

This way of working enables fast learning, helps manage user requirements more effectively, controls spending and is more likely to deliver the right product in the end.

Going beyond method

Within both PRINCE2® and PRINCE2 Agile, the use of the MoSCoW approach, (project requirements Must, Should, Could, Won’t be included for now) is a practical way to give practitioners the capability to go back to their sponsors and be explicit about what the deliverables and the priorities are.

The project manager and team are therefore more certain about their resources, the project deliverables and how it all aligns with the business case. This, in turn, makes the performance of the project more predictable, safer and ultimately more successful.

In some PRINCE2® training courses, the MoSCoW technique may not be focussed on unless the project managers are in a position to be making greater judgment calls and therefore, the approach may be new to many. PRINCE2 Agile will bridge the gap between theory and a practical approach by for using it within projects which should make it easier and more likely to be deployed.

Having the ability to go beyond following a method or discipline and to begin using experiential learning is extremely valuable for successful project managers. In fact, it’s about building a greater, long-term professional capability across the Project and Programme Management community as a whole.

The ‘70-20-10’ learning model used across the public sector translates to 10% classroom-based learning, 20% learning from others and 70% learning from experience. That means project managers developing the ability, through their experience as well as study and gaining qualifications, to handle more complex projects with greater confidence and effectiveness. PRINCE2 Agile is a good bridge to start project managers on that journey to applying what they know.

Focusing on the future of project success

A new approach, such as PRINCE2 Agile, will increase the opportunity for the right products to be delivered to meet a business case. The approach builds on existing learning and should take both the process and the achievable results a step forward. For organizations considering such a new approach the criteria is simple: obtaining return on investment.

But the willing adoption of such a methodology will require the co-operation of two quite distinct practitioner communities and their perceptions of each other. The agile community may consider PRINCE2® to be inflexible while PRINCE2® practitioners wonder about the level of control in agile delivery principles.

But with an understanding of the mutual benefits of control and flexibility, based on clear communications of those benefits, both camps should recognize the value each can bring to project success.

Clearly, change management involving cultural change will be important in persuading project professionals that blending PRINCE2® and Agile will have a positive impact on their work in the long-term.

Don’t forget to leave your comments below.