Help! My software project is behind schedule

You have 4 months to deliver your software project. After 2 months you’ve only completed 1 out of 3 milestones. The project is behind schedule. What do you do?

If this situation sounds familiar to you, this post shares some of the difficult lessons I’ve learned to use.

The Iron Triangle

To get the project back on track, you have three levers: time, resources and scope.

Time

How much time are you allocating to the project?

Resources

How many people (internal or external) are you allocating to the project?

Scope

What is the functionality of the final deliverable?

These levers form the iron triangle. To get a project back on track, adjust these levers. If you cannot change time, resources or scope a late project is guaranteed to be completed late.

Work with your project stakeholders to determine which levers to pull. As the project manager, you can make recommendations, but you are not the decision maker. Whoever requested the project (client, product manager, etc.) is the decision maker.

To improve everybody’s decision making, see my other post: 4 tips to make faster and better decisions at work.

When to adjust the timing of your project

The biggest reason a project is behind schedule is because it was misestimated. The easiest way to get the project back on track is by acknowledging this. Give the project more time to complete.

Nobody wants to delay the project delivery date, but sometimes you cannot change the scope or resources levers. In this case, you will have to change the time lever.

You should delay the completion date when there are no expensive secondary costs. Secondary costs are costs that follow the project’s completion.

As an example, you are working on a building the software for a self-driving car. You need to complete the project by August. The company has already agreed to lease 1,000 cars as of that completion date. If your project is behind schedule, the secondary costs of the car-leases will start to come in. An expensive cost if these delays prevent the cars from being put to good use!

To prevent future timeline slips, be conservative. Acknowledge things go wrong and build that into the project timeline. Use the timelines of similar projects as a reference.

When to adjust the scope of your project

Adjust (reduce) the scope of the project if it contains non-essential functionality. When a project starts to slip, certain functionality is no longer as essential as originally assumed.

To discover what can be dropped from the scope, ask the following:

• If we do not deliver this functionality, is that a launch blocker?
• What is more important? Launching on time or launching with this feature?
• Can we launch with only some functionality, and deliver the rest at a later date?

When to adjust the time lever Adjust the time lever (change the project delivery date), if:

• The only reason the project has a date is because “someone wants it done by then”
  • Have that “someone” decide whether scope or resources should change instead.
• There are no/low secondary cost when delivering the project later than expected.
• The project’s scope is non-negotiable

When to adjust the project’s resources

Add more resources to the project, if the cost of delays are higher than the costs of allocating more resources. This is especially noticeable for projects with high secondary costs. The costs you pay as of the original completion date.

An easy mistake is to add more engineers to a late project. If project development is running 50% slower than projected, you can double the number of engineers and get it back on track, right? Sadly, this is not true.

Why adding more people to software projects does not make them faster

One assumes that adding more people to a project makes it go faster. This only applies if the work is repetitive and can be done by anyone.

As an example, a project to plant 1,000 trees fits this category. The people who plant these trees: tree planters, can each plant trees without coordinating with eachother. If you double the number of tree planters, you double the speed at which you deliver the project.

This is in contrast to software development, which is sequential work. An example of sequential work is building a home. You cannot lay a new floor, until the foundation has set.

Software development is not a set of tasks that can be completed in any order. Software development is sequential work. Certain tasks need to be completed, before one can proceed to the next set of tasks. You cannot create the infrastructure, if you don’t have an architecture designed.

Before adding more software engineers, identify the parts which can be done separately. This is the maximum amount of engineers you can allocate. Any more and they will wait on eachother. As you allocate more engineers, the coordination costs increase.

In addition, adding engineers is not free. You either need to hire more engineers (financial costs) or move them away from other work (opportunity cost).

Once these engineers join the project, you need to onboard them. To onboard them, the experienced engineers need to stop project development. Until the new engineers are onboarded and completing tasks, the project continues to slip.

Killing the project

There is also a nuclear option: killing the project. Sometimes the trade-offs around time, scope or resourcing are worse than the project not being delivered. This is especially relevant if requirements or strategic value of the project have greatly changed.

So what can you do?

When projects slip, make people aware of it as early as possible. Drive the conversation around the three levers: scope, resources, and time. Present the risks and have decision makers decide what needs to change to keep the project on track.