What Is a Project Manager – Part 2

In a previous article, I drew the analogy between a project manager and an orchestra conductor. I attempted to do a deep dive into the parallels between the role of the conductor and the manager of a large project. Like the conductor of a 100-piece orchestra, a great project manager is intimate with all the project components and provides a firm guiding hand to ensure that they all add up to a great final product. 

But what if a project is so complex, touching on so many critical technical and business process domains, that it’s beyond the expertise and capacity of a single project manager to control and deliver? Finding a single person with the combined talents and capacities of a Leopold Stokowski or a Leonard Bernstein may be an unrealistic endeavor. 

When Two Project Managers Are Better Than One

In my experience, large information technology projects that require significant and critical business process and business model transformation, along with “greenfield” technical platform deployment and interoperability requirements, can often be beyond the capabilities of a single individual to manage. This is particularly true when there is a consulting partner and other contractors with unique skills engaged on the project and both internal and external staff need to be coordinated and managed. 

Deep knowledge and understanding of current business processes, people, relationships, desired business goals, and project outcomes will require internally sourced staff to execute certain aspects of the project. This part of the overall team will have ownership and accountability for developing business and functional requirements, business process design, training, and business implementation. A project manager with broad internal business knowledge, credibility with staff and operations managers, and accountability to senior company leadership is needed to own this domain. 

Additionally, large projects that require significant technological transformation almost always require a consulting partner who can bring a proven methodology within to structure and manage the project. The consulting partner will also bring experience with the applications, tools and technologies to be deployed, industry experience, knowledge of best practices, and a fresh perspective to envision outside-the-box solutions that may exceed the capabilities of internal staff. The consulting partner can bring an experienced project manager to lead this domain of the project and to work jointly with the internally sourced project manager. 

Key Organization Characteristics for Dual Project Managers

Some key characteristics within a project’s organization structure and personnel that are necessary to make dual leaders at the project manager level successful are: 

Experience With the Organizational Model – Having project managers who have successfully worked within a “2-in-the-Box” org model at the project manager level isn’t necessarily mandatory, but it sure helps. I’ve found that consulting partners are more accustomed to this arrangement since their jobs, by definition, require collaboration with clients on complex projects of this type. They can typically take the lead in putting the arrangement on a collaborative path.  

Clear Lines of Authority – It’s important that the project managers within the business and consulting partner domains have a clear understanding of their specific responsibilities, team structures and accountabilities. This doesn’t mean that each has blinders on relative to the other’s space or are not aware of dependencies and interoperability needs across the entire project. They each should have specific expertise within their own space but a broad understanding of the points of collaboration existent on the entire effort. Staff under the two PMs should also understand and respect the need for dual management.  

Ability to Collaborate – Regardless of how well responsibilities are delineated between the two project managers, there will always be overlaps and gray areas. For example, alternatives and trade-offs need to be considered when changes in functional requirements impact system design and performance. Functional and technical considerations will merge, and alternatives will need to be evaluated, communicated and decided upon jointly by the functional and technical teams. Collaborating PMs will jointly own and be accountable for these decisions. In addition, post-deployment support is a collaborative effort. Troubleshooting and correcting defects or anomalies in performance or function require close cooperation between business and technical teams. 

This is when straight-line and dotted line reporting relationships with and among project staff become important. This might best be depicted within the context of a RACI matrix that identifies individuals whose roles require that they be either Responsible, Accountable, Consulted, or Informed, or some combination of the four, regarding different aspects of the project. These relationships can be clearly articulated and reinforced within the context of the project and communication plans and status meetings. 

Mutual Respect Without Egos – “Two-in the Box” works best when PMs recognize that they complement each other in skills and experience, can rely on each other to admit what each doesn’t know, respect boundaries, and recognize where complexities require boundaries to be erased and collaboration to take over. As a project progresses, deep trust will be built and relationships created that will last beyond project completion. 

To summarize the analogy, some projects need two strong project managers working in concert, so to speak, to manage the complexity inherent in large projects with diverse teams.