How to deal with projects being late

What are the steps that an Engineering Leader can do?

Introduction

Imagine a world where all product and engineering projects are finished on time. Those who have managed tech teams and led projects will have a hard time believing this.

It is very common that projects are late in the tech world. This doesn’t just mean that the software engineers are not working well, engineering managers are not managing properly, or product managers are not planning properly. Some of the reasons can also be due to communication gaps, stakeholders changing the requirements and scope, an unplanned absence of some team members, or other unforeseen things like pandemic disease or even war.

In this blog post, we won’t go deep into the reasons for projects being late, but instead, we will list a few possible actions that can be taken by the engineering lead and will explain which of them can result in a positive outcome.

Common mistakes when dealing with delayed projects

Extend the team with more people

Probably one of the first things that can come to mind in cases like this: Let’s get some engineers from the other teams in the company and add them to provide some help to our team.

Unfortunately, this usually doesn’t work, especially if we are very close to the deadline for the delivery of the project. Although these potential engineers would have similar technical skills, the team will need time to properly onboard them, especially around the business aspects of the project. Also, we have to keep in mind the energy in the current team, processes, practices they use, etc... Adding new people to the team can potentially jeopardise all of them.

So, this option is usually not very useful for the engineering lead on a short-term basis and can cause even more delays.

Hire external consultants

Another possible option is hiring external consultants from companies like Adeva. This would mean quickly opening a new job position, so the company can match a consultant in a very short time. This is possible in the real world, but this option is useful if the team is facing some technical challenge that is preventing them from making progress. In that case, the consultant can come, solve the technical issue and the team can continue working.

In all other cases, the team will face the same issue described above with adding more people to the team from the current company, on a short-term basis.

Hiring external consultants is a very good approach but only if properly planned upfront, not when the delivery is already late.

Work overtime

The team and the leader working together overtime until the deadline is also one of the things that come to mind and unfortunately frequently used.

This approach is not recommended at all, couple of reasons why not:

Software engineers, and generally people, can’t be really productive for more than 6-8 focused working hours a day. Forcing them to work more than that will result in a reduced quality of work and this can cause chained consequences. The next day, these engineers will arrive tired at work and continue working tired.
Probably this is not the last project that the engineering team would be working on, and the company will need the team after the particular delivery again. Burning the team out for one project delivery can have more long-term consequences, like team members leaving the team/company and in the worst-case scenario jeopardising their health.

Cancel most of the meetings and just code

At first look, this approach can sound like a brilliant idea: reducing the number of meetings generally means more time for coding and the team will be closer to reaching the delivery deadline. But is this necessarily true?

Although I am not a huge fan of meetings in general, reducing the number of meetings or having no meetings at all can cause even more delays than before. Coordination between the team members and between the engineering leader and the product manager with the team is crucial for the successful completion of the delivery.

Communicate, review and re-prioritize to deal with project delays

Most of the possible options that we reviewed so far seem like a not very good idea, on a short time basis. So there has to be something we can do, we can’t just sit and see our delivery becoming a huge failure.

From my experience, the best thing an engineering leader can do (together with the team) in this situation is: to review all the work that is left to be completed, prioritize it in logical and deliverable chunks and decide what really can be completed, properly tested and deployed until the deadline. It is always better to deliver a fully working product with some missing functionality instead of delivering a not working product with full functionality.

Another very important aspect in these situations is transparency and open communication. If the engineering leader is positive that the delivery will be late, he/she has to inform the product manager and the stakeholders immediately. Having the stakeholders properly and timely informed means more time to prevent potential damages and can give them more time to prepare and even help with the selection of which features should be completed and which to be left out for the next delivery.

So what are the steps that the engineering leader should take when the delivery is late on a short-term basis:

As a first step, the engineering lead should meet the engineering team(s) and confirm with them the status of the delivery and the possibility of late delivery;
Next, should inform the other people directly involved: product manager, project manager, scrum master, etc… immediately about the potential late delivery;
After that, the engineering lead should transparently inform the stakeholders involved in the project: internal stakeholders, clients, etc… and manage their expectations;
Next, the engineering lead should meet the team to review what is left to be done, then together with the product/project manager properly prioritize the items left and make a realistic plan for completion;
As the last step, the engineering lead should present the plan to the engineering team and the stakeholders involved and start with the implementation immediately;

Address delivery delays in the long-term

Once the delivery is completed, the next logical step is to do a complete review of the reasons why the delivery was late so the engineering leader and the team can learn from the mistakes and improve things for the future.

Generally, here are a few things that can be reviewed and are potential reasons for late delivery:

Split the responsibilities between team members

There are cases in teams where there is no clear definition and distribution of the responsibilities of the members of the team, especially at the engineering and product leadership level, so some crucial tasks are left behind. That’s why it is important to check if this can be potentially the case and do all needed modifications to fix this.

Processes and development methodologies

Another important step is to review the software development methodology that the engineering team is using and check how efficient it is. There are teams that prefer Kanban more than Scrum, or the other way around. Maybe the problem is with the git flow being used, or the QA process. All these things need to be carefully examined and modified if necessary.

Review the deployment process

The time needed for the code written by the engineering team to be deployed for the end users is a really important aspect when it comes to project delivery being late. Very often, the sprints are completed on time, the code is ready to be deployed and there is a huge time needed for deployment. This is also an important aspect to be reviewed.

Improve the communication in the team

How are collaboration and communication in the team? Are there any open conflicts that need to be resolved, is there a proper meeting framework in place for the team so everyone is properly informed in a timely manner? These are all questions the engineering lead should ask themselves when it comes to reviewing the communication in the team.

Learning and development plan for team members

The more experienced and skilled team members are, the better and faster their work would be. Engineering leads should always have a proper learning and development plan in place for all their team members with specific goals for the next period of time.

Hiring more people to the team

Hiring more people to the team should come as a last resort because if we don’t resolve the potential problems mentioned above, adding more people to the team will only make things worse and scale the problems.

Summary

Dealing with projects being late can be really stressful for the whole team, especially for the product and engineering leadership of the team. Although there is no one size fits all approach for this problem and the potential solutions can vary based on all circumstances and types of projects, I hope that the thoughts shared in this blog post can help the engineering leads in the future.

One thing is for sure: no matter how much we plan and try to do things right, there is always a chance that we would deal with delays in the projects, especially because of external factors.