A Team Built for Collaboration [Guest Post]

Over 25 years ago, I was approached by a loyal client who wanted my team to build a complex application whose goal was an ideal end state (or maybe a dream state to be more accurate) for their business model but how to achieve it (its solution)  was mostly undefined. The continued success of their business was threatened by technology and new competition and depended on the success of this very high risk project. I told my client that we would do the project if he would appoint one of his senior managers to our team. They should understand the business model requirements and be able to represent and make decisions for their business. I would want that manager to join our team as a full time member. I argued that I could not assure success unless the client provided that level of commitment.

co-manager graphic


The manager was appointed and the project was a success. That was an awesome learning experience for our team and began what would soon evolve into our Co-Manager Model. I have never taken a client project engagement since then without using this Model. Over the years the Model has matured and become an essential tool for my version of Collaborative PM. It has become pervasive across several project management processes which are topics for other articles. This article describes that Model. It is only the outer layer of a multipart tool. The Co-Manager Model has since been used in 2 books. The first book introduced a new framework for Complex Project Management (1) and the second was one that I co-authored with Colin Bentley to create a PRINCE2 Lean Framework (2) designed around artifacts drawn from the first book. We have developed a powerful tool to support Collaborative Project Management and I am pleased to have been invited to share it with you.



EII has long been an advocate of using the project characteristics, the internal organizational environment, and dynamic market situation to drive the design of the best-fit project management model for a given project (1). That design encompasses the project team as well. This article introduces 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 share responsibility and decision making authority for the project and its deliverables. The Co-Manager Model was designed and matured over the course of a number of client engagements. It has been used it for over 25 years and has become indispensible. It is the most powerful tool in the EII arsenal to assure the establishment of an effective Collaborative PM culture. We harbor no expectations that this change will be easy to implement, especially in those strong matrix organizations whose project managers are used to being in charge. The challenges to the client side co-manager arise from their elevated position and newly acquired project responsibility. They have been taken out of their comfort zone. To use the Model effectively, both co-managers must learn to equally and openly share project responsibility.

If I could choose only one Critical Success Factor (CSF) for managing a complex project it would be meaningful client involvement. In the complex project world, the client may be the best subject matter expert (SME) you could have on your team for solving unsolved problems and exploiting untapped business opportunities. Beyond their SME roles, these experts are the owners of the project deliverables. Their meaningful involvement results in a vested interest in the success of the endeavor. 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 Co-Manager Model. There are some initial obstacles to overcome but the effort is worth it and the Model does work.


The Complex Project Team

Figure 1 is the full version of the co-manager complex project team. It identifies all of the roles that might be present in any complex project team. Just as the project is unique so also is the best fit management model including the team structure. Think of this team structure as a template. Expect to adapt this model as appropriate to the project.

The Complex Co-Manager Project Team
Figure 1: The Complex Co-Manager 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 is responsible for the tools, templates, and processes used for the management of the project. This is similar to the traditional project manager. The other co-manager is responsible for the deliverables that the project will produce. The deliverables could be a new or improved product, process or service. For those who are Scrum aficionados, this product co-manager is quite similar to the product owner. Having product expertise on the project team means that more decisions can be made by the team without the need for the PRINCE2 Project Executive involvement. The result is a “leaner” PRINCE2; less need for documentation; decisions made nearest the point of competency; less wait time for  decisions to be made; better decisions; a higher quality solution, and greater business value.

The important characteristic to note in Figure 1 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. Is this not the very heart of a Collaborative PM environment? 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. Given the risks, 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. They are the team members that receive all change requests in the Bundled Change Management Process but that is for another article. Their involvement allows the Client and Development Team Members to focus on the work of the project and not be diverted away by evaluating change requests.

The development team needs no further explanation at this point. It is not unlike the traditional project team. 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 is quite straightforward. Where multiple business units are involved in the same project, the situation can become far more complex. Either the project is elevated to a program level or there are multiple product co-managers assigned to the project. The net result is that you have a project run by a committee. Clearly, there is added management overhead for such situations. That creates other operational problems that must be taken into account. 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 multiple business unit complex project. Whenever I refer to “the complex project team,” it is the team shown in Figure 1 that I’m referencing.


The Co-Manager Model is the most effective management model for achieving and sustaining meaningful client involvement. EII has used variations of the Co-Manager Model since 1991 and will not take on a complex project without using this model or any of the variations that might arise to align to the project.


Using the Co-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 involve 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. 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. As Figure 1 illustrates, we do this as co-equals! This is a challenge in the strong matrix organization mentioned earlier.

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 Co-Manager Model benefits PRINCE2 in a number of ways (2):

  • 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
  • Centralize and increase decision making authority of the project team


The lessons I learned from the client projects 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 to 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 

The Co-Manager Model is an essential aid to establishing a Collaborative PM culture. It is the foundation for requirements elicitation, stage planning, change management, decision making, problem resolution, the role of generalists and specialists, collaborative brainstorming and continuous process/product improvement programs. Embedded in the project team are several position types so that career planning and professional development can be facilitated within the Co-Manager Model. We have just scratched the surface here of describing the Collaborative PM environment and the benefits that can emerge from the Co-Manager Model and leave these topics for future consideration.

In my experiences implementing the Co-Manager Model among my client base can be a disruptive cultural change to a project management environment. Every organization is different. Implementing a Collaborative PM into an organization where the critical role and value of the client in projects has not been recognized is not to be taken lightly. It is a major project with lots of unknown unknowns! The effort is worth it though because it works.




  1. Wysocki, Robert K. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value. J. Ross Publishing (2014).
  1. Wysocki, Robert K. and Colin Bentley. Global Complex Project Management: An Integrated Adaptive Agile and PRINC2 LEAN Framework for Achieving Success. J. Ross Publishing (2016).


Image credit 



Homepage discussions A Team Built for Collaboration [Guest Post]

This topic contains 0 replies, has 1 voice, and was last updated by Profile photo of Robert Wysocki Robert Wysocki 1 month ago.

You must be logged in to reply to this topic.