“More money has probably been lost by investors holding a stock they really did not want until they could ‘at least come out even’ than from any other single reason. If to these actual losses are added the profits that might have been made through the proper reinvestment of these funds if such reinvestment had been made when the mistake was first realized, the cost of self-indulgence becomes truly tremendous.” — Philip A. Fisher

Software projects regularly underestimate the complexity and effort needed to create software and compound the problem by getting into a spiral of replanning. The actions they take to fix the problem of missed deadlines make the problem worse, and the project takes longer.

Software projects get into a sunk cost problem. They have spent too much money to give up but need to spend more to finish.

Software projects underestimate the complexity of creating software and delivering the software into production. They miss deadlines but have soon invested too much money to quit.

For most software projects it’s not if the project will overrun but when and how will you respond.

Not if the plan is wrong, but when

Software projects forget estimates are guesses. They give an indication, it would be more effective if developers estimated a range (good, average, terrible estimates) or they should be based on a similar project (which would be more accurate and bypass planning fallacy)

The standard approach to creating software is to underestimate the complexity and overestimate the benefits. An ambitious plan is created with multiple teams all working to a deadline that everyone would like to finish on (not when they finish on).

“I love deadlines. I like the whooshing sound they make as they fly by.” ~Douglas Adams

This creates a situation where it’s almost impossible to create the software to the deadline. The project crashes through the plan and the delivery team feels it’s going to get harder.

This is the standard template for projects

Below is a common script for projects

1. Company creates high-level requirements
2. Software companies respond with a quote the time and money to deliver requirements (e.g. team size and length of delivery).
3. Whilst creating the software more requirements are found, mistakes are made and problems occur
4. More requirements are discovered as the project progress but the plan and deadlines are not changed.
5. Development team realises the software won’t be delivered on time — Management pushes their head in the sand and hopes for a miracle — When Software Development Goes Wrong, Leaders Hide Under the Covers and Hope
6. The project realises the deadlines are going to be missed (often only when deadline are in the past) — emergencies meetings will raised and replanning begins.
7. To deliver on time, you have to one of these

a. reduce scope

b. add more people

c. add more time

8. The project replans and changes either to scope, resources or time.

This is a tough decision because the outcomes involve more money or reduced functionality (and not delivering on your promises). All the choices involve leadership taking a hit to their reputation.

Reducing scope is not delivering what you promised and can get a bad reception from the users (e.g. the new system isn’t as good as the old)

Adding more people is treating the symptom not the cause. It costs more and can make the project later. A Cautionary Tale of Parachuting Cats Helps Explain Why Adding More Developers to a Project Can Make It Later or Why adding more people to a project doesn’t make it go faster.

Adding more time is admit you underestimated the original and project estimate was incorrect.

The cost of replanning and replanning

When requirements change in a software project, the plan should change. Often the plan gets out of sync and doesn’t show reality. What can push a plan out of sync with it’s environment?

• Change in requirements or new requirements are discovered
• Mistakes — people make mistakes
• Problems (technical, people leave, design problems, replanning)
• The project complexity was underestimated
• Ineffective project leadership (changing directions, plans and priorities)
• Slow governance (e.g. decision making — no decision is a decision).

Missing a project deadline is a symptom of some part of the software development system going wrong. If you treat the symptom and tackle the problem with short-term solutions, this will create future problems.

You need to look at the software project holistically and identify what part of the system is slowing it down and what is the cause(s) of missing the project deadline.

Issues on software projects are like turning on the light and seeing a cockroach running away. There is rarely one cockroach. There are usually a bunch of them, but you only saw one.

Treating the symptom like adding more developers to go faster, if the requirements are constantly wrong or the developers are creating low quality code, then this won’t fix the project.

The short-term approach, tries to get the project back on track with the smallest/cheapest action. This rarely works because it leaves the underlying problem untouched. The short-term solution could create a different problem tomorrow.

The common result from the quick fix is the project cannot meet another deadline.

This involves more re-planning and pressure grows with repeated missed deadlines. The leaders of the project lose credibility because they have multiple deadlines and trusts depletes.

The developers at the bottom aren’t convinced because apart from re-plan and extended time, nothing has changed. If you approach the project in the same way, you get the same results.

Why is replanning costly

You would think that replanning would not be that costly, it’s just extending the current plan, except that’s not how replanning works.

When a software project flies past the deadline there is panic, emergency meetings and the need for action.

Emotionally reacts bypass clear thinking.

Like someone who has made a bet at a casino and lost, leaders try to win back their losses by creating an aggressive plan that gets them back on track. This approach forgets what got you into this situation

1. Under estimated original plan and underestimating the complexity of the task
2. Some area in the system that’s reducing quality or slowing down the project
3. Short-term thinking and solutions that don’t consider the whole system of software development.

Decision are emotional, we make them to move away from pain or towards pleasure.

When you plan, you assume success. A software project has many teams that need to be onboarded (licences, time, knowledge, relationships). When projects get delayed, you pay for everyone even if they cannot work. Software development teams depend on other teams, e.g.

• Requirements → developers create software
• Developer teams → need other development teams to finish dependant parts (e.g. integration, data migration, different functionality).
• Testers → need software to test
• User → need finished software to test
• Trainers → need documents, test scripts and bug free software

After multiple iterations of replanning, the project pays for more people than it needs or you would have if you knew how long it was really going to take.

Dead-end and switching costs

Dead-end cost is like making a wrong turn in a maze and going down a dead-end. You Walk down the dead and then turn back and walk back to the part of the maze you took a wrong turn.

You lose time going down and coming back, a double whammy. When you change plans, developers often need to take out the half finished code (which could be harmful to the whole solution)

I worked in a project that involved 4 replans and by the end of delivering the 4th replan we had delivered 70 percent of the functionality. If we had stayed to the original plan and kept going, we would have finished all of it with the extra time.

This creates switching costs you get when you switch you between tasks. Focus on new things, get up to speed, work out what to do and then start.

Short-term thinking

Short-term thinking focuses on symptoms and not root causes. Software development is a system and short-term solutions create tomorrow's problems and shift problems from one problem to another rather than solving anything.

Software Development Is Misunderstood — Quality is fastest way to get code into production, Quality is the shortcut in software development. The Best Decisions in Software Development Have Long-Term Benefits Not Immediate Benefits.

Software development is a marathon, aim for quality and make smooth progress. The faster you try to create software, the lower the quality and the more problems this creates.