If adding people to a late project makes things worse, what options DO work?

Question

I am working on a project with a fixed deadline (there are financial penalties if we are late or drop any features).

We are late.

My project manager keeps asking if we can add people so we can get back on track.

According to Brook's Law and the Mythical Man Month,

Adding human resources to a late software project makes it later

So I have to tell my project manager "No thanks" to the additional people. They do not accept that answer. What else can I tell them?

Are there any other options available for speeding up a late software project?

Answer 1

There are five ways to handle this:

• expand capacity
• renegotiate
• resign
• go down valiantly
• drop quality

---

As you are already behind the ball, you have no time to invest into increasing your overall capacity. But if you did:

• Expanding the team requires sacrificing one or more active developers to teaching and training. There is also an upper-bound on team size before this will start slowing overall development even once the new developers are up and running.
• Reducing red tape/removing limitations requires assigning one or more team members who understand what the red-tape is meant to do, and how it is not working, to remove or rework the red tape that is offering no benefits.
• Automating repetitive work loads. XKCD nails this, there is a trade off in how much time investing in this will pay off. As you are already close the payoff period is small, and as such probably not worth while automating.

Doing this can be beneficial, but they have their biggest pay off if done early, and consistently overtime.

---

Go back to the customer and be honest. We are not going to deliver this on time. Lets negotiate.

Yes there are penalties, they are going to be invoked. The earlier you acknowledge that this will be happening the smaller the fallout will be.

• The project might be written off and cancelled. A bad day but now you have two months to do something useful with that would have gone down the gurgler.
• You might negotiate a reduce scope to be delivered, with follow up deliveries. At least now you know what your customer finds important, schedule it and get it done. Then cleanup the mess and deliver the next feature set.
• You might negotiate a reduction in scope. Similar to before but you won't have to clean up.
• You might be given more time. Use it wisely.

Whatever the outcome, your reputation will include that fact that you pro-actively manage project failure early. Many business will see that as a sign of maturity.

---

Resign

If you choose to resign, the project will be further jeopardised, and quite likely you will:

• not get a good recommendation,
• do serious harm to your professional relationships, and
• possibly be responsible for some of the contract damages.

However:

• you probably were not going to get a good recommendation anyway as you were not performing as a superhuman,
• if you think your professional relationships aren't going to take a battering by delivering hot, burning, rubbish software - think again.
• not to mention that if this is do or break, you will likely go unpaid for time worked anyway.

So it comes down to whether or not you think somewhere else is better. It probably is at this point. But sometimes we do not even get this choice.

---

Go down with the ship.

• On the pro side, you get to keep your morals and dignity.
• On the cons side you are not going to make that deadline.

What you need to do:

• Be loud, be direct, be professional.
• Keep explicitly spelling out that you will not deliver on the deadline and project the current best guess with uncertainty. eg: 6 to 10 months if everything goes to plan. 8-20 months if more than x issues occur.
• Make sure you keep a printed and witnessed copy of every communication you circle around about the project.
• Do not agree, or ratify any schedule given to you, that is not commensurate with your sanely projected schedule. eg: can you demo monday? No, we are at least two months away from something that can be demo'ed. But your schedule says 3 weeks.. at the earliest, more likely to be two months.
• Read up on your company policies, particularly around your rights, and how to escalate issues that affect the business reputation. Follow those processes.

You will be put under enormous pressure. You may lose your job, bonuses, special parking spot. You will likely be paraded before and used as a scape goat.

You may become subject to law suite. This is why you have kept your communications to prove that you followed due diligence.

It will pay to get training in how to consider, and then express your argument to a hostile audience. Things like public speaking, debate, assertiveness training will be helpful.

---

Sacrifice Quality

This is the vilest answer, but if you are stuck between two unrelenting businesses that will not negotiate on time, or features... and you cannot quit for whatever reason, and for some reason you cannot take the moral high ground of going down with your ship.

I personally do not condone sacrificing quality. I point this out to outline why this solution, is NOT A SOLUTION.

The problem is that the two parties are at war, and you are stuck in between them, which will inevitably lead to destruction around you. There are those whom intentionally or not will choose this action out of spite, pragmatism, or some other justification. It is certainly something to be aware and wary of in both yourself and in others.

Should this option be the one that is taken:

Please, place your dignity and morals in the bin - you cannot afford them. Welcome to a hell that you are personally tailoring for yourself.

You have a deadline, and a set of sentences that describe the end state of the system. Your role is to play the Genie of the lamp, you have been given an unreasonable request, your goal is to solve it with the least amount of effort, consideration, or thought while meeting the letter of the request. Don't mind the spirit of the request - it has already proven it cannot change the terms of the contract and can be sent to the same bin as your morals and dignity.

• Find every corner and take it. If your choice is between spending half a day or a full day on a "feature" spend half a day. Even if that will exact punishment on the next set of developers.
• If there is a fluffy requirement find a blanket solution. eg: must be secure. Define this as uses SSL. Presume that the server box is secure. Thus you can store password credentials unencrypted. etc...
• If there is a requirement that can be read two ways. Interpret it in the way that reduces implementation time. And rephrase the requirement in a stakeholder document that gets signed.
• If at all possible satisfy a requirement by doing nothing. A paragraph explaining how this is provided by someone/something else is 100x faster than actually implementing it.
• Don't bother with good engineering. Think novice programmer: code directly in the UI, spaghetti is king, always write more, never reuse.
• If you have satisfied all requirements, every remaining moment is your bonus.

As an experienced engineer you will be capable of guessing which parts of the code will bite you early. These are the only pieces of code you should care about enough to do well.

But seriously don't let yourself ever be placed into this position. Push for one of the other solutions, even quitting is better. At least it sends the message clearly to both sides that this is not on.

---

Make your choice.

Answer 2

It all depends on a lot of factors that you did not share with us. First, how did you determine that you will be late and by how much:

• How close to the deadline are you?
• How well defined is the work left to do?
• How reliable is your effort estimate for the unfinished work?

If you determine that you can finish in time with a moderate speedup (10-15%), you should look at the options for adjustments and factors that hindered your team reaching that speed.

• Are there unrelated tasks/responsibilities that your team can drop, postpone, or delegate to others?
• Do you have some scope flexibility in the way features are implemented if you can't drop them? For example, if Excel exports are requested, you could either create xlsx files with nice styles or simple csv files. Guess which can be done in less time.
• Are there bottlenecks in your process that could be relaxed by new workers without significant introduction effort? (this is actually a place where your manager's plan could work)

If there are such factors, eliminate them.

At the end of the day, if you find that there's nothing your team can realistically do, your organization has to bite the bullet and pay the penalties. It accepted a project that was ill-defined or can't be done in time given available resources, failed to monitor the progress and adjust when there was still time, or whatever. Your team is not responsible for management failure.

If your manager insists that adding workers will make you reach the goal, you might as well accept his offer and prove him wrong. He might put the blame on you anyway, whether you refuse to accept new workers or you're unable to deliver in time with added workers.

Answer 3

You are in a bad spot, that is for sure, but there are some tactics that could mitigate your predicament.

Dropping or deferring features is perhaps the best tactic. Apply a cost/benefit analysis -- determine the set of features that can be implemented within the remaining schedule that minimizes the penalties for missed features, then do those features. Ideally, these should be negotiated with the customer who will be paying the bill -- share the list, if you are deferring a feature the customer regards as more valuable, you may be able to renegotiate the features and penalties.

This goes without saying, but offload all non-development activity from the team until the deadline date (or, by some miracle, the project gets back on track). Protect developers from doing any support, maintenance, bug fixing, trouble shooting, etc. that is not related to your project. Cancel mandatory department and staff meetings. Delegate administrative tasks. (For instance, if your engineers are filling out purchase requisitions and tracking deliveries and following up with suppliers, have you project manager assign administrative personnel to do those tasks instead). If the performance review period occurs before the deadline, defer the reviews until afterwards. Do not defer the raises.

Finally, adding resources to a project may not necessarily result in an overall delay -- it depends on how far behind your are, how much time you have before delivery, and whether there are potential team members already familiar with the framework and tools you are using. For instance, you have five developers, 25 remaining "one-month" tasks remaining, and 4 months left before penalties kick in. At this point, you may be able to bring in two developers familiar with your project, framework, tool set, etc. and meet your schedule. The keys here are to cross-train people, identify scheduling issues quickly, and address scheduling issues aggressively.

To really fix this, you need to go back in time and:

1. Identify schedule issues early in the project. If your velocity is 3 tasks per month, and you schedule calls for 4 per month, add resources.

2. If possible, negotiate features and deliveries with your customers as a collaborative agile development process.

3. Cross train your development team members -- wherever possible, use common frameworks and tools. Make it a goal that you can add developers to a projects without needing to extensive training and "coming up to speed".

Answer 4

Adding human resources to a late software project makes it later

This is a bit simplified. Adding more developers will improve productivity in the long run. But in the short term it will slow down development since more people have more overhead and require more planning, and the new devs will need information and assistance from the existing developers.

So it will take some time before productivity breaks even. Perhaps a month or more depending on the complexity of the project. If the new developers are inexperienced and need a lot of mentoring it will take a lot longer.

The quote is an important counterpoint to the naive "man-month"-thinking, where you think you can just increase productivity proportionally by adding more people. But obviously it is not true that adding more people cannot increase overall productivity.

Some factors affect how easy it is to ramp-up:

• How well documented the project is. If the only documentation exists in the heads of the current developers, then the productivity loss by introducing new developers will be more severe.
• How modular the architecture is. Can new developers start working on a module without stepping on everyone elses toes?

Problem is, if the project is already late there is a risk the existing developers have skimped on documentation and modularity in order to save time in the short run...

Answer 5

Unfortunately there are some sure fire ways to speed up a project.

1. Drop features
2. Drop quality

So dropping features is obvious, if you just cross off some features you havent started yet, but which are included in the estimate, then your estimate comes forward.

The problem is identifing features that you arent contractually obliged to deliver.

This where quality comes in. In any software project there is a whole bunch of stuff that "the customer doesnt care about" (enough to put down in writing). Gold plated stuff like for example security, performance, working outside of lab conditions etc etc

These usless things your developers will normally add out of some socialist nonsense like "work ethics" or "legal requirements". But the truth is you can totally cut it all out and the customer wont notice untill after you have been paid. If at all!

If your developers get uppity let them squeeze these things back in in the next phase of the project, or when the customer asks for (paid) extra features. No-one will ever know they were missing!!

Now there is one gotcha. Notice I said "havent started yet". Equally obviously, if you have allready done 90% of the work then you can only save 10% of the time. max!

Those pesky developers like to build this kind of gold plating in from the start. So you have to be tough and not let them put the whole project (your deadline) at risk!!

Make sure they only work on valuable features from the very start! tell them 'its only a pilot', 'just use a demo licence' and everyones favorite 'we can put that in phase 2'

Answer 6

You can reduce the amount that you deliver. Drop features, reduce quality, deliver an untested product. Nothing to be proud of, but if it lets you avoid penalties then this is something your management should consider.

From a software development perspective, how can you deliver more in the same time? There are many possibilities.

1. Add some really good developers. No matter what "the mythical man month" says, if these developers are really good, they can take work away from the others with no training and with a minimum of guidance. Of course they will be less productive than in better circumstances, but they will be productive.

2. Take any unnecessary work away from the developers. Absolutely no unneccessary meetings, and only for the shortest time necessary. Don't ask for daily status reports, the time can be used for producing things. If the developers have to do tasks that are not development related, drop them.

3. Enable the developers to work more. Have healthy food delivered to the company instead of them going out for lunch. Book them into a hotel next door instead of travelling home. If they have to do work at home, let the company organise that.

4. Paid overtime. This works for a short time but not in the long term. It works better if you take measures (see 3) to reduce the amount of work they have to do outside work.

Answer 7

Ask yourself: what are the incentives for your programmers if the project gets finished on time? Right now it sound like a little praise from you: "Great Job". Instead how about incentives like a $5,000 bonus or an extra month paid vacation?