Leadership

Keep the three management roles in an IT project separate

Rick Freedman explains why he thinks the 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.

More details to come

In future columns, I'll discuss how project managers can identify which projects may not require this level of oversight. I'll also review the interactions between relationship managers, technical managers, and project managers, and offer suggestions for best practices in building a cohesive delivery team in every engagement.

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

17 comments
jayl
jayl

My experience has led me to believe in three (3) roles as well. However I would classify them as follows: 1.) The Project Manager - the one who is in charge of the project, 2.) The Technical Manager - the one who is responsible for providing the technical solution, 3.) The Business Manager/Analyst - the one who is responsible for ensuring a business workflow solution is provided, and that it will work for the customer or business unit. Instead of a separate relatioship manager, all three (3) of these roles require relationship and communciation skills in order to succeed. Furthermore, these three (3) roles exist in every project, regardless of size. It simply is a matter of scale that determines if they are separate individuals. Typically small projects are fulfilled by the same person, and only a very large project can afford to have the three (3) roles as separate individuals. Most succesfull projects have at least (2) people filing a combination of these roles. My preference for succesful technical projects is that my technical staff (usually a Systems Analyst) be the project manager and technical manager, while the business unit provides a business manager/analyst to participate and ensure the new system is succesfully adupted by the business unit/customer.

oscar.lozano
oscar.lozano

Answering the most common concerns, the Project Manager, is the full responsible for any delivarables, and in fact the ultimate decision taker, under the "User Requirements" of clients and stakeholders. That said, the Technical and Relationship managers, comes as an aid and guidance in those specifics aspects. It is true, that project managers have too many to worry about, so if this theory is put in to practice correctly, it should be very useful on large and medium projects. Besides, the Technical and Relationship managers could be anyone in your already assembled team or the given management support team. That will help to keep your financial numbers on control.

fidlrjiffy
fidlrjiffy

As an example of a practice that should work the various project management roles being helmed by three individuals is certainly attractive. Surprisingly, this theory is being put in place by many companies large and small...mostly to the consternation of all involved. The missing link is who, by golly, is in charge? Common sense tells you that it's the project manager as the responsible party charged with bringing the project to a successful completion. Of course, this rarely happens because the project manager has schedules, budgets, and presentations, but the technical manager and relationship manager have people. The technical manager has a staff and the relationship manager has the client. This translates into power and influence. Organizationally there is usually no way for anything other than an ineffectual dotted line reporting structure to try and counter this. Give those responsibilities to one person and the problem goes away. It is becoming more common for project managers to not have the technical requirements but it is nearly 100% required that the project manager have SME experience. This makes no more sense then a project manager being technical in an IT sense; it substitutes "technical" in a business sense. If a project manager has too much to do to guide developers then that manager certainly has too much to do to guide accountants, to say nothing of the resentment they're going to receive from those accountants. The reality is that all that happens is an extra layer of management, conflict, and stress is created and the project manager surely has too much on their plate to handle that.

philr
philr

There are some projects so large that the division of responsibilty is inevitable. Good on you for picking the same need on smaller projects. The Change management role may also be required where large organisations are involved, but this is only an elaboration on your essential thesis.

tprensa
tprensa

This is an ideal solution to manage IT projects. However, how many companies can afford to hire various resources to manage a project? I would like to know if there is some research that support your principles. Thanks.

benboe
benboe

I love that the PM is referred to as a She, and the IT manager is referred to as a He.

jmarkovic32
jmarkovic32

Once again, theory and good practice will be trumped by dollars and cents. A CEO or CIO (most of whom are mainly bean counters) will have a difficult time comprehending why they should pay three different salaries for something that they payed just one salary for. Get your 30 minute PowerPoint presentations ready. I hope you're good with graphs and charts.

mark
mark

I see these are correlated with the 3 project trade-offs: 1- Deliver quickly 2- Deliver Cheaply 3- Deliver Quality Has anyone weighted these by time in particular activities ? Can we say what activities we should emphasis to shift the weight among (Fast, Good, Cheap) ?

PMPsicle
PMPsicle

Too bad your article can't be made required reading in all HR, recruiting and management offices. I have yet to meet a project manager who can or should take on the technical role (myself included) as well as his/her own. The skills and characteristics of a project manager and those of a technician (especially a programmer) are incompatible. Very, very, very few people can switch between the two ... and I've never met anyone who could do both well at the same time. (Very small projects excluded). Unfortunately, as someone has already observed that has not stopped clients from asking it of their PMs. Like several others who have commented, I'm not sure I agree with separating the PM and relationship roles. To me the PM role is primarily a relationship role -- building a team and moving it through storming, forming and norming as quickly and effectively as possible. The process role is simply the technical portion of his/her job. Perhaps, you need to expand on how you perceive the PM role versus the relationship role. Certainly, I can understand the need for a "supplier sponsor" in order to remove that conflict of interest from the PM. However, I'm not certain how that would work in the real world of internal projects where multiple suppliers exist. Or perhaps you were referring to the reporting and administrative role which is often turned over to a project coordinator/administrator. Glen Ford, PMP http://www.trainingnow.ca

ngoodreau
ngoodreau

I am so glad that you were able articulate what I have been trying to convey to my clients and prospects for years: that the PM role(s) is(are) too important to be bogged down with unrelated tasks. I would modify your three legs of project manager, technical manager, and relationship manager to just two, combining the roles of what you?ve described as ?project manager? and ?relationship manager? since those roles more closely align with the PMBOK. I have seen time and time again, clients looking for a ?Project Manager? and in the description of the role, they list a whole assortment of technical skills that are required. What that tells me is that they want a resource who will roll up his/her sleeves and start coding, configuring or converting AND who will also maintain the project plan, monitor issues and manage stakeholder communications. Sorry. It ain?t gonna happen. There are not enough hours in the day. Any time that a PM is spending up to his/her elbows in the technical details is time NOT spent on true PM duties. This is not to say a client needs to have multiple, full time PM resources dedicated to a project. I have worked on projects where the software vendor supplied a technical PM who divided his time amongst multiple clients. I have also managed scope/schedule/resources for multiple, simultaneous smaller projects. Thanks for a great article! Nelson Goodreau, PMP

Vicki.Beckman
Vicki.Beckman

I agree all three roles must be present in a successful project. A technical lead can certainly manage the content in the background. I am not so sure the relationship manager role can be separated from the project manager, unless the project manager is just the admistrator of process and forms. I've witnessed too many relationship managers that are not close enough to the details to know what's going on. Misinformation is another project success killer.

andrejs.berzins
andrejs.berzins

I agree completely that these have to be kept separate, even though they don't appear simultaneously in all projects. There is a huge difference in the relative weight of these roles, depending upon whether you are an IT company providing these services or an internal IT department. You still have to fill the three roles, but not with the same emphasis. The technical role would probably be underrepresented in the IT company, because everyone expects that the journeymen have at least one expert in their team, while the internal IT department might have to focus on securing the expert, but neglect the customer side since they might apparently or really have a monopoly on services within the company. More interesting perhaps would be to look at the organizational model within a project suitable for promoting (enforcing?) these roles within an engagement team...in the medium term (projects over 3 months in length). Next article?

helmutsk
helmutsk

I would agree to Oscar`s position that real life bring changes in a theory. Optimization is important not only nowadays. If we look from role perspective then sure there is a technical manager, process manager and communications manager in almost all IT projects. But at the end of the day Project Manager is responsible for delivering project results within defined resource limitations. I would rather look at this question from risk perspective. Besides understanding his team`s strong and weak sides PM should consider areas his skills are not on the level project requires. When that is done PM organizes his team so that there is a full time or part time technical expert who is also capable of organizing team. Regarding relationship management. After planning part is done it is all about relationship management with ALL stakeholders and decision making. I would rather avoid separating these two roles on two people. Sales person involvement is important on certain level surely. That keeps client comfortable and sales people feel responsibility on ?life after sales?. PM`s need to be multidimensional people and ?experts? in everything. It is up to them how to orginise that ? learn or get help.

lolsen
lolsen

Thank you, benboe. Women may be accustomed to identifying with a "neutral" male subject, but the gender roles assigned in this article caught my attention also. Full disclosure- in my immediate working group the technical leads are male and the PMs female, which fits the prevailing pattern. Wonder why this is? I'd like to see the author present a gender-neutral position.

chjohns
chjohns

You wouldn't necessarily pay three additional salaries. If you are talking about playing to strengths, you can increase the number of projects that your PMs, RMs, and TMs work on to achieve a higher efficiency rate. They know their job better, so they work faster! It also creates an opportunity that someone who has career goals to learn more could be an entry level PM and an intermediate RM, etc.

mneville
mneville

I know I'm picking a fight, but if the author had used He for the PM and She for the TM the same argument would have come up. If he had made both males or both females, same debate. You can't win. But I would point out that at least he tried. Would you rather he used the androgenous construct "s/he"?

Editor's Picks