Select Page

If you are a successful Project Manager (PM) with a solid track record, it is only natural that you aspire to get promoted soon. In software services organizations, this promotion often means donning the role of a Delivery Manager (DM).

While your project management experience is doubtless a strong foundation for performing as a DM, that alone does not suffice.

There are additional role dimensions and associated competencies that are crucial for your success as a DM. You may even have to un-learn some of the things that you made you successful as a Project Manager.

If you come to know of these aspects ahead of time, you would be better prepared and avoid the pain of having to learn everything the hard way.

This article is to make you aware of the “terrain changes” in the PM-DM transition and provide pointers for you to prepare and learn on the job.

image

In our experience, we have seen some typical role characteristics (refer diagram above) and role transitions (“points of discontinuity” in the diagram above) in software delivery organizations.

We have assisted a significant number of DMs in such role transitions and effectiveness on the job through a combination of contextual workshops and one-on-one coaching sessions.

This article is based on our experiences in working with DMs and our own learning in the process. But first, let us understand the two roles better as summarized in the table below:

Project Manager (PM)

Delivery Manager (DM)

PM typically manages a single project

Typically provides oversight for several (often unrelated) projects

PM is directly responsible for achieving project goals – scope, schedule, cost & quality

Plays an assurance / support role. Is also the first level escalation point

PM is highly visible to the customer

DM is not as highly customer-visible as the PM

PM’s main/sole aim is to deliver the project goals (scope, time, cost & quality) to the satisfaction of the customer

DM is typically responsible for

·         Delivery assurance

·         Growth of accounts in revenues & margins

·         Organizational development (creating new service offerings, people development, delivery improvement initiatives etc.)

·         Operational support for projects (staffing, infrastructure, travel planning etc.)

PM’s task focus is sharper than people focus

DM’s people focus is sharper than task focus

PM’s role comes to an end when the project is completed

DM’s role is ongoing

Keep in mind the above role comparison when we cover the “terrain changes” below to “learn” and to “un-learn” while making the PM-DM transition.

Terrain change #1: Portfolio diversity

image

Learn: A DM is often responsible for a portfolio of projects in diverse customer, solution, services & technology domains as shown above.

Learn to add value to all projects even if you have not had hands-on experience in some of the domains.

Of course, you need to have proven domain experts as needed in the project team but you yourself need not have detailed domain knowledge. However, you need to have adequate knowledge to validate for yourself that project decisions are made with due diligence, process adherence and rigorous reviews of technical aspects.

This is critical for your success in “delivery assurance”, the most important component of the DM role.

Unlearn: If you approach projects outside your “comfort zone” in terms of domain & technology with diffidence and be very hands-off as a DM, you are not doing justice to the role. Also, stay from adopting one “standard” approach for delivery assurance not considering the diversity of projects.

Terrain change #2: Dynamic aspects of “delivery assurance”

image

Learn: As a PM, there is usually a definitive & common understanding of your responsibilities. But as a DM, what exactly is meant by “delivery assurance” is often “situational”!

There should, of course, be a planned rhythm for delivery assurance – bid review, review of project plan, progress reviews, and governance reviews with senior management & customers. ‘

But depending on project status and escalations, you may need to “dive deep” as required for effective corrective & preventive interventions. At the same time, “deep diving” as a rule would burn you out and dilute the role of the PM.

This dynamically changing level of DM involvement in projects is arguably the most difficult terrain change for a PM to adapt to.

Unlearn: The big tab item here for un-learning is not to solely rely on formal channels of project communication and information (formal reviews, status reports, metrics etc.).

Proactively sensing when to “deep dive” is a fine art developed through being part of the project’s “social” organization, “walking around”, surprise visits to project meetings, spot checking working code, sampling customer-team interactions etc.

You develop this critical ability to sense over time. Without that, the “DM comes to know last”!

Terrain change #3: Enabling rather than controlling

image

Learn: What does “enable” actually mean? Broadly speaking, it means providing an environment for the project to succeed.

Enabling covers assisting the PM in selecting the right people & developing them, ensuring that the right processes & tools are made available, asking the right questions in reviews rather than prescribing answers, hand-holding the PM in crisis situations and so on.

Surely, the PM is responsible for the project but you as the DM are ultimately accountable for it.

Remember, the key to success is learning to balance terrain changes #2 and #3.

Unlearn: The enabling aspect of the DM role implies that you should be comfortable to “let go” as appropriate – you do not have to make all the project decisions yourself or issue instructions on how to decide. Your direct involvement in a given project should be the exception rather than the rule.

There are some more terrain changes to cover such as:

          Terrain change #4: Greater focus on people & their development

          Terrain change #5: Change in stakeholder context

          Terrain change #6: Increased operational support & cross functional coordination

Read about these in Part 2 of the article.

About the author:

Subramanyan Sivakumar (“ShivK”) has over 25 years experience in software development, project and software delivery management. Since 2006, he has trained and coached several hundred project managers and delivery managers in IT/software organizations. ShivK is a founder-member and Principal Consultant at PM Power Consulting, Bangalore (www.pm-powerconsulting.com). He holds B.Tech and M.Tech degrees from IIT, Madras and also the ITIL Manager Certification from EXIN, Netherlands.