On communicating why software is late

Software projects are always late, no matter how hard we try and how good the engineers working on it are.

This is especially true for software that is being written for the first time, when technical problems are such that no amount of money can actually fix them.

No amount of money will make a syscall return something different from EPERM if it does not have the right permissions.

For engineers and stakeholders, it is necessary to know how to navigate this situation and how to communicate effectively.

The main underlying point is that both engineers and stakeholders are on the same team. We all want the software delivered on time, or as soon as possible. We are all trying to make it happen in the fastest possible way. We are all juggling multiple contrasting priorities.

However, the project is late, and now we need to communicate it.

Understand the impact

The very first thing is to understand the impact of the project being late.

Is there a big, public presentation that will not happen because the product is late? Or will an internal customer need to create their business intelligence report manually this month?

The impact must be clear to both engineers and managers alike.

Ideally, a short-term solution or patch can be found to avoid the lateness of the project being as impactful as it could be.

Maybe for the public demo, we don’t need 100% of the project, but the first 80% would be enough, and this is the moment to cut development and start polishing the new feature.

A quick communication from the team with the stakeholders often allows mitigating the negative impact.

No negative surprises

Projects get late one day at a time.

In order to avoid unpleasant surprises, projects are split into milestones or deliverables.

Suppose a 3-month project, with the first milestone planned to take 1 week.

If the first milestone took 2 weeks to be delivered, you can already start planning that the whole project will take a total of 6 months.

While nominally the project is only 1 week late, it already took double the amount of time it was supposed to take.

A tight communication loop with the stakeholders will keep everybody informed and allow defensive actions.

Communicate progress often and early

Similarly to the point above, progress should be communicated early and often.

Ideally, you don't want to wait for a formal weekly meeting. Stakeholders should be able to autonomously access information about the delivery of the project and its status.

Early communication allows for efficient course correction and resource allocation.

Moreover, it avoids the negative surprises mentioned above.

When, What and How

When you break the news that the project is going to be late, those three things are what stakeholders want to hear:

1. When is the new date?

2. What went wrong?

3. How are we improving?

Be mindful to communicate the new date. Experienced stakeholders know well that if you are 1 week late in delivering the first 1-week milestone in a 3-month project, you are not going to deliver the whole project in 3 months + 1 week. They may smile, but they know that you are not going to deliver it and that they cannot trust you to deliver on time.

In order to trust the new date, there should be an explanation. Maybe a few key people were unavailable to work on the project, or the project encountered unexpected technical difficulties. Or an upstream dependency was late in delivering its own project, causing a cascade effect. Or simply the estimate was wrong. Make sure to communicate it.

Finally, stakeholders want to know why the new date is now more reasonable. You should now be able to remove or account for the source of lateness.

Communicate uncertainty

Whenever we communicate a date for delivering a project, there is always some uncertainty associated with it.

Something planned may encounter a roadblock, some dependencies may not be delivered on time, some key resources may be unavailable, some work may not be estimated yet, and we are just guessing.

When communicating with stakeholders, it is beneficial to communicate not only the date but also the associated uncertainty.

It is important to recognize that ANY delivery date will come with uncertainties, even if you don't communicate it. Experienced stakeholders know this, and they will automatically associate the date you communicate with the uncertainty derived from the previous interaction they had with you.

I like to use a color scheme:

1. 🟩 Green

2. 🟨 Yellow

3. 🟥 Red

🟩 Green: Everything is on track; we expect to deliver by the date, if not earlier. Dependencies are on track, we don't foresee blockers, and the work is well understood.

🟨 Yellow: Some uncertainty. We can still make the delivery date, but some dependencies are running late. Or we are discovering new work due to a scope increase. Or there could be blockers along the way. Or some key resources may be allocated to a different project.

🟥 Red: We are definitely running late. We don't think we will make the date. We will follow up with the new When, What, and How.

A project should not be 🟩 green if all its dependencies are 🟨 yellow. At the very least, it should be 🟨 yellow as well. If not, 🟥 red.

If we were not able to estimate the delivery date for the dependencies of a project (which usually are small pieces of work), how can we be confident about delivering the whole project, which is much bigger and has more complex interactions?

Showing the colors of all the dependencies of a project gives a very good visualization of how well the project is doing.

As time moves on, delivery dates tend to move from green to yellow and finally to red. Experienced teams will have all their deliveries in green, good teams will have a lot of yellow, and inexperienced teams will have mostly red.

This should not be read as a judgment call to the teams. It reflects the intersection of team AND problem space. A team that has never worked on a problem will have a very hard time hitting all greens, even if made up of the best developers.

Conclusions

This is how big corporations work and deliver tech products regarding date management. It is a standard model used by several teams.

It is not a perfect model, since work is often late even in big companies.

But this highlights that it is usually not just about money or resources, but also about skills. Even small companies can compete fairly when delivering their products.