17 June 2009

Keep management roles in a project separate

Clear separation of three distinct roles--project manager, technical manager and relationship manager--gives projects a better probability of success and client satisfaction.

I've been on both sides of the desk in IT projects; I've provided services to corporate clients as an IT project manager and consultant, and I've worked for large corporations as an IT executive.

Something I learned from these varied experiences is that, whether providing IT services as an insider or an outsider, every IT initiative is an engagement. Every IT effort requires that the service provider play three distinct roles: project manager, technical manager, and relationship manager. While many independent project managers and consultants attempt to play all three roles, they do so at the risk to themselves, the project and the relationship.

Requirements of a successful IT engagement
Every engagement, inside or out, must have: a clear business meaning, a defined success criteria, a technical plan, and a project plan, as well as sponsorship and stakeholder participation.

Whether you're engaged as an outside project manager to manage the development of a huge data center, or you're an inside IT tech migrating users from Windows XP to Windows Vista, these requirements are constant. These unchanging elements of a successful IT engagement require project managers to think carefully about how many hats they try to wear and to separate their roles into different, often conflicting, responsibilities.

On tiny projects, such as replacing one worn-out server in a departmental data closet, it may make sense from a financial and an efficiency standpoint for the project manager (if she's got the technical chops) to assume all three roles. Once projects get any bigger, my view is that it's good practice to have three individuals in the roles of project manager, technical manger, and relationship manager.

Three elements to manage
I often tell my clients that every engagement requires the superior management of three elements: the process, the content, and the relationship. Here are more details about each element:

  • Managing the process is the project manager's role. She must ensure that a clear scope has been written, a meaningful estimate has been derived, and a complete project plan has been developed, along with all the other process elements required by her chosen methodology.
  • Managing the content includes all the technical decisions: the technical specifications, the materials list, the software stack, and the integration of all these components.
  • Managing the relationship requires that the needs, expectations, emotions, and politics that are an inevitable part of every human endeavor be successfully managed so that the perception of the end product matches the client team's vision.

I'd wager that every working project manager has a horror story to tell about an engagement that circled the drain, or outright failed, because at least one of these elements was mismanaged.

Three roles of management
So why do I believe so strongly that it's a mistake for the project manager to try and take on all three roles (except in the smallest engagements)?

First, it's a skills and temperament issue. My experience is that project managers who excel in the process elements--following their chosen methodology and focusing on the details of time, scope, and function--often haven't developed their technical and relationship skills to the same degree.

The never-ending debate in the project management community over whether project managers must be technical proves that this is still perceived as an issue. There are exceptions, but developing strong project manager skills, getting certifications, and keeping those certifications current is challenge enough without also trying to stay ahead of the surging wave of technology developments.

More important than the skills and temperament issue is the simple fact that trying to play all of these roles is an irreconcilable conflict of interest.

I tell my students that project management is not a popularity contest; the project manager's role is often to play the "bad cop". The project manager needs to be the one to tell the client that the inside IT team is not pulling their weight, that the bug list is growing instead of shrinking, or that their genius developer is not such a genius after all.

While it's important for project managers to use diplomacy when delivering these messages, they must ensure that the client gets the message.

The technical manager must take ownership of the entire technical design, which is a daunting task, especially as projects grow in complexity. He doesn't need (and is often unprepared) to deal with the process and relationship issues that arise from his recommendations. The necessary actions of the project manager and the technical manager can lead to strained relationships if not handled with subtlety.

This is where the relationship manager comes in. In a contractor relationship, this manager is often the salesperson who introduces the contracting organization to the client and must keep that relationship on an even keel in order to get the current engagement delivered and to mine for additional projects in the account.

In this case, the relationship manager has a financial incentive to closely manage the relationship. Yet, even in inside IT initiatives, someone needs to ensure that the client and the stakeholders are satisfied, are getting the results they expect, and are willing to trust the IT delivery team to do future projects.

There are practical issues to this separation of roles. For instance, not every engagement can afford to have three team members doing these duties, and not every engagement is complex enough to require them.

No comments: