What Value Does a PM Provide at the End of a Project?

The other day, I was challenged by a client to provide a description of why they still needed a PM at the end of their project. To understand their question, and my response, you need a bit of background information first.

This software development and package integration project had been running for several months, had completed the installation, custom development, and integration testing. Nearly all of the project team had been released from the project: only the lead programmer and a part time solution architect remained to deal with any issues arising during user acceptance testing (UAT), to answer questions from the client’s technical team who would be supporting the solution after the end of the project, and to provide some knowledge transfer to the client’s team on how to use the custom software solution. With such a small team (1.5 FTEs), low risk for failure, and only a few items left to complete with adequate hours remaining in the budget to complete them, the project was in a very enviable position.

The problem was that the schedule had been extended and while there had been additional hours added for programmers to develop and test new functionality for the custom application, additional project management hours were not added with each change authorization that was signed between the two parties. Instead, with only a couple of project management hours left in the contract, I was negotiating with my client to have additional project management hours added in another change authorization.

The client refused the suggestion of additional project management hours, saying “We have our own project managers handling our portion of the project deliverables – they can also manage your two team members, in addition to their current teams, meaning that we don’t need any extra project management time from you.”

How do you respond to a statement like that? I suggested the following items to the client’s senior management chain:

• Relying on Vendor Responsibility: The client had chosen my company as the vendor of services for this project because of our solid reputation in the marketplace and our long list of references. They were not just hiring a few of our staff members in a staff augmentation (a.k.a. “body shop”) mode; rather, they were buying our overall organizational expertise, tools, and processes to help them through the project. If they were to proceed without a project manager, and manage the resources directly, the client would in effect be absolving our company of further responsibility for the project, as our project manager ensures that issues of risk, governance, and our organizational commitment are being dealt with appropriately, including internal escalations, if necessary. With staff augmentation arrangements, such organizational commitment and responsibility rarely enter the relationship.
• Financial Reporting Support: This client had asked several times during the project for financial reconciliations such as invoiced hours versus hours authorized in signed contracts and change authorization forms. As the project manager, it was my duty to provide this information to the client, whether I provided the information directly, or through and assistant. The programmer and solution architect remaining on the project would not have access to the correct systems to access the information required to respond to these requests.
• Negotiating Changes: As we were in the final stages of the project (user acceptance testing and then deployment), issues and defects were arising that could have broader implications for the project as a whole. For example, one performance issue had a number of possible resolutions that needed to be evaluated, each with its own cost and benefits that need to be discussed in detail with the client before a decision can be made. Both the developer nor the architect have a technical focus, but the business impact of these resolutions spread more broadly than the technical impacts, and these technical resources didn’t have the business acumen to recognize nor to communicate these impacts effectively with the business stakeholders. Finally, as the services vendor, we would need someone delegated with the authority (and who has the right skills) to negotiate a solution that works for both parties, including writing up the change, gathering estimates, calculating cost and schedule impacts, and getting the agreement signed by the right authorized parties. The technical people assigned to the team did not have these skills, which are typically found in project managers.
• Focus on Customer Satisfaction: The personal performance of the resources left working on the project is measured with productivity metrics (like percent of worked hours billable to clients). This drives a certain behavior that is desirable in people building deliverables for a client: a single-minded focus on completing the solution. What is missing, is someone focused on customer satisfaction. In most organizations, customer satisfaction is used to evaluate project managers, who tend to have the most face-to-face interactions with senior business stakeholders (sponsors). The vendor’s sales staff (called “relationship managers”) are focused on customer satisfaction, as that is how they drive future sales; however, they are not typically focused on delivering contractual obligations and usually don’t have the authority and resources to make that happen. As the project manager tends to have stronger relationship-building skills, and the authority to shape the project processes to better influence customer satisfaction, it is in the client’s best interest to ensure that they still have some hours in the project for the vendor’s project manager.
• Internal Escalations: Some issues and defects that were arising (and that would likely continue to arise as the project moves through UAT and into deployment) would require the coordination of vendor, customer, and subcontractor resources. This requires someone like a project manager who has experience navigating the vendor’s organization and who has familiarity with the vendor’s management processes and also the procurement (subcontractor) management processes.
• Managing Vendor Resources: Even though the client thinks they can manage the vendor’s two project resources, what they are referring to are the work assignments and timing of delivery. There are other aspects to managing the vendor resources that they won’t want to do or that they cannot do: resolving personnel performance problems, approving vacation schedules, acquiring additional (or replacement) resources, resolving conflicts with the other projects being worked on by the part-time solution architect, etc. In many organizations, project managers take on broader human resource management roles than just task assignments.

  So, even in the final weeks or days of a project, when most of the work has been completed and most of the team has been released to other projects, it is in the best interests of the project sponsor to retain the services of a project manager from the delivery organization.

  ---

  Kevin Aguanno, PMP, IPMA-B, MAPM is a certified Executive Project Manager who has written many books on project management-related topics and who is an award-winning instructor teaching at universities and conferences around the world. Find out more about him at www.AgilePM.com.