When it becomes apparent that your project is running behind, what considerations should be made when deciding to cut scope, push back the timeline, or ask for overtime? Or is it purely up to the customer?
One of the best decisions I've seen when it comes to this situation is to cut scope wherever possible. Sometimes, this is possible, and this is the best approach.
Why the best?
- Overtime is demotivating for team members (especially in the long-term) and burns them out
- Pushing back may not be possible if the company made promises to a customer
Asking the customer is good (if they say yes and are understanding); if they say no, you're in trouble.
The best thing is to communicate status early, and not get into a last-minute situation where you're "suddenly" three months late. Projects don't suddenly fall behind schedule; they fall behind one hour at a time.
I would strongly advocate against overtime unless it's for a very short period. The hidden costs associated with staff burnout will bite you.
By hidden costs, I mean such things as (but not limited to):
- Reduced work quality
- Impaired judgment
- Increased time do anything
The other two options will come down to your customer really.
It depends on what's really important
I cannot agree with the multitude of comments suggesting that the right answer is to cut scope. All projects are a balance of technical, cost, and schedule, the less colloquial version of NASA Administrator Goldin's famous mantra: faster, better, cheaper.
So if a project is running behind that means that the negotiation between these constraints that is reflected in the specifications/design, budget, and schedule is no longer valid. The "right" answer for how to re-balance them depends on which of the three is most important, when you've reached the point that something's got to give.
These priorities are influenced by many factors: the customer to be sure, but also the company, the team, the contract, etc.
It's easy to say cut scope, but cutting scope isn't always the right answer. Not all projects have the luxury of a Phase 2. Some things have to work right the first time and some products have non-negotiable technical specifications. If you ignore that potential reality and cut a critical feature to make a deadline you risk putting out a subpar product that will ruin your reputation.
Ultimately, being able to weight all of these factors to decide what to do is the crux of program management. The answer always depends on the circumstances and telling yourself any different is self-delusion looking for a bromadic solution to an intractable problem.
When "a project is behind" there are many more options than you've listed in the question.
The project is a trade-off between constraints, typically cost, scope, time, and quality. If and when you understand that "the project is behind" it means that one of the constraints (or few of them) are already invalidated. Your job as a project manager in this situation is to get the project back on track, and make sure all constraints are valid again.
You can't change constraints, since they are baselined by the project sponsor. What you can do is to propose a new version of constraints, and him/her to re-baseline them. Your options are:
- "we need more time"
- "we need more money"
- "we will produce lower quality"
- "we will deliver less features"
You need to present the customer with your recommendation for the best path to get the most important aspects of the project complete within the shortest period of time for the least budget.
Be prepared with analysis of how changing one variable would impact the other s though they can make intelligent choices.
Every hour of overtime equates to an hour of under-time somewhere further down the line
Cutting scope is certainly the best option when possible - this ensures you still deliver on time and that you focus on the most important deliverables. This can then be followed up if necessary with a phase 2 project - and priorities will have often changed in the interim.
Pushing back time scales can have adverse effects - not least cost. By delivering on time but with reduced scope, the client can get the immediate benefit
Cut scope. You likely had too much in the beginning, which contributed to the current problem. Projects fall behind on the front end, with contributions from weak requirements, inflated scope, and lack of ramp-up allowance. Scope reduction may not solve the problem but it's clearly your first option.