Project is late, how should PM act?

Question

There's a project where:

• In the middle of project it is already late
• Initial estimates were done by development team
• It looks like estimates were too optimistic
• Development team says it's client who changes their mind all the time, but it's just how the client interpret project scope
• Project sponsor says they expect to have the project finished on time without additional investments (like adding people to the project team) and if estimates were wrong estimators should feel accountable for that

In short, there's pressure for development team to take all the consequences of the slip on their chests, while they don't feel it is their fault. How should PM act, considering limited options they have left by the project sponsor?

Answer 1

First of all, I think there are two external, important factors, to be kept in mind:

• Type of contract, how the contract was created, who created functional requirements and technical proposal and to which extend

• Interests of company management in that particular customer as current and future customer. If management considers that customer or project to be of high importance for the entire company, maybe you can convince them of considering that project as some type of 'investment' where maybe they should make further funds available. Maybe there are also other stakeholders on that project which might have their say.

Having said that, what seems to be the core of the problem is interpretation of project scope, and that's also what I would mainly focus on in discussions with the sponsor.

My main argumentation line would be that it was impossible to plan that project in more detail in advance, because otherwise you would have to charge him just for that pre-planing tasks already. Given his agreement on that project approach (I assume there was some type of agreement on that in advance), it is natural that there are deviations in expectations, and that you and your estimators simply could not take everything possible into account in advance.

Keeping in mind the above said regarding company management, I think the least you should ask for is extension of time.

Answer 2

if estimates were wrong estimators should feel accountable for that

This is going to guarantee that sponsor will never hear estimates again from that group.

Project sponsor says they expect to have the project finished on time without additional investments

The only solution to this is to cut back on features. Sit down and analyze which features can be cut to get the remainder of the project finished on time, and if scope changes happen, defer them to the next version.

Answer 3

Stop - if the project is late, and you know what the causes are, stop the project for long enough to replan and reestimate after bringing the analysis to the governing body and the sponsor.

The solution may be cutting back on features, as Tangurena says, but it could also include extending the deadline or changing the team.

I'm adding on another comment- as I read the responses it seems to me that there is a lot of 'who takes accountability' discussion. I think it's more productive and professional to first look at 'how does this get fixed' and 'how do we learn from this' than arguing where the responsibility lies.

Answer 4

In the middle of project it is already late

If the project is already late then the cost implications are very important. The only options are scaling back the project or someone taking a financial hit. The client or the company will have to have to pay to complete the project in its current form - so a serious discussion with the client needs to start on de-scoping some areas if the project is to continue.

It looks like estimates were too optimistic

Estimates are usually too optimistic, developer estimates are often wildly optimistic. The other day a developer questioned the need to integrate a CMS into a project with the standard line 'why integrate a third-party CMS when we can write one from scratch in about 10 minutes'. An experienced PM would have to know a developer very well before they can gauge the accuracy of any developer's estimating. Add 100% to any finger-in-the-air guesses masquerading as estimates.

Project sponsor says they expect to have the project finished on time without additional investments (like adding people to the project team) and if estimates were wrong estimators should feel accountable for that

It is perfectly reasonable for a PM and Project Sponsor to accept a developer estimate, but from that point on everyone is the joint owner of that estimate. If a Project Sponsor sees an estimate that looks too low initially, then it probably is - its no good simply ignoring it! If its a bad estimate then it is everyone's responsibility.

Answer 5

The PM should escalate the issue of the perceived requirements change to the change control board and governing body, including representatives of both the client's and supplier's contracting folks, to iron out and come to an agreement about those changes. The client is only one party to this two party agreement so they cannot simply dismiss this accusation as different interpretations. They have an obligation to sit back down at the table and argue their case, and hear the supplier's case, hopefully to arrive at a mutually beneficial result. Even if only 50% of the perceived change results in a retroactive change order, then the team will get some relief in time and cost.

The project sponsor can have all the expectations he wants. The hard truth is, if targets were placed competitively on a project's time distribution, this project had a good 40% to 50% likelihood of overrunning its time target, and the sponsor needs to deal with that as an adult. Things happen outside of a capable PM's control, including stochastic events--pure chance--that both favorably and unfavorably affect a project's outcome.

No matter the outcome of the change effort, the PM needs to report factually the project's current health and predicted outcome, alternatives, and recommendations, and then let the sponsor make some decisions, let the chips fall where they may.

(I do not know the contract type under which this project was let, so this plays into it, too. If it was a firm fixed price deal, then time is the only piece to discuss. However, it sounds like this is not the case since the sponsor apparently had a vote in additional resources. If it was FFP, I would still pursue the retroactive change piece but I'd also bring in additional resources to try to crash the schedule if I thought that had some likelihood of working.)

Answer 6

As the PM you may need to escalate this issue to the Project Board.

I would recommend you to document the impact of these delays to the final derivable and, most importantly, to the client or final customer.

The end customer is a key element to take into account since it could jeopardise the future project portfolio so it's a very powerful weapon to get attention from Senior Management, specially the Senior User.

Try to run some numbers and find out if there is any other competitor that could release this project earlier. You could use your risk log or project chart to convey this message. The sponsors are always concerned about the money invested so highlighting dramatically the risks can be helpful to trigger the question of holding the project for further estimations.

Answer 7

You alread have a lot of wisdom in all posted answers.
I will add : take the current shift in delay and extrapolate in the future. You will have a better estimate of the real deadline. Don't count you will recover the delays neither stabilize the delays.

Now, we all know that what you described is quite a common situation, and it is time to earn your PM salary. You have to :

1. make best use of available resources
2. provide visibility on true status of the project
3. propose realistic options to stakeholders

Options are as usual :

1. more resources (? refer to the mythical man-month)
2. negotiate delay
3. reduce scope

If you can do that, you did your job. If you can't (because your boss don't want to hear about it), you will reduce test phase which will proove a bigger catastrophe.

Answer 8

I agree with all previous answers. I would like to add one additional suggestion. Don't agreed any additional wishes as gifts because of late. Please try to move this things to next version or milestone. From my experience gifts are really nice in case when project is going well. Please keep in mind that gifts have to be especially specified very precisely.

Answer 9

As per the standrads, variation will fall under +- 3 sigma. If it is falling under that, then I don't see any objection from the organization you are working for. Perhaps, as a PM you need to forward the issue to the PMO which will reflect your accountability, honesty and respect towards the project.

Once you reported the issue, now you need to find the float in your project and determine the task/work pakages are on the critical path. If they are not on the critical path you can float them based on the leads and lags available to you in the precedence diagraming method.

Ok, if the above is failed then your real challange starts. You need to communicate the issue to the sponsors and to the "most effected" stakeholders. Do not worry about less deviation. If you are able to explain them the issue you are half done with your problem.

It is not appropriate to force the development team or any other team to put extra effort to complete the task, that is definetly an action of a bad manager.