This article includes tips that I’ve learned from my experience working at Booking.com and Amazon EC2; all views expressed are my own.

Title picture: A train in the Netherlands goes off the tracks, to be saved by decorative whale tail sculpture, much to the surprised relief of the train driver. Courtesty ANP/SplashNews.com

Three levers you can pull when your project falls behind

So your project that was supposed to be finished in 2020 has spilled over to 2021.

The initial estimates were way off. The external team bailed on their commitments. The customers changed their requirements. Whatever the reason, the elements have conspired to put your project behind schedule. We’ve all been there. None of us wants a project that was supposed to be finished in 2020, continuing too long into 2021. Tying up our past commitments from the last year is a practical step we can take to give ourselves the clean slate we deserve, and put ourselves into a forward-looking mindset for the new year.

How can you put a project back on track?

When I hear that a project is falling behind schedule, there are three ‘levers’, or areas of action, that I consider first. Pulling these levers can help the project course-correct and get back on track.

The Three Levers

The three levers are scope, resources and time.

  • Scope: What is to be delivered by the project; e.g. features or functionality
  • Resources: Ways in which money can be spent to ‘accelerate’ the project; e.g. more people, better tools, ready-made solutions
  • Time: The project deadline, which is usually, but not always, fixed

These three levers are intertwined. Whenever you are considering one of these aspects of the project, you should also consider the others. An action plan to get your project back on track has the best chance of success if each of these factors is considered.

Three levers summary Summary of three levers

The first lever: Scope

Shedding scope

The first lever you should consider pulling is reducing, adjusting or reframing the project’s scope. ‘Shedding’ scope from a project could mean deferring some work until later, delegating some work elsewhere, or remove non-essential work from the project.

Minimum viable product

It is most important to deliver a something minimal but complete at the project deadline; that’s what is meant by minimum-viable product. Would you rather have a full bicycle or half of a car?

Work with your stakeholders to help them identify what is absolutely critical to project success. Often, stakeholders would prefer to have a working solution that they can use and give feedback on for the next iteration, and ‘nice-to-have’ functionality can be deferred until later

What MVP means What is meant by MVP. Courtesy brianpagan.net

Prioritise work items

The project should be broken down and grouped into tasks already. The next step is to prioritise this work, as P1, P2 and so on. The requirements for a task being high-priority should be clearly defined and agreed to by the team and stakeholders. The team should be guided to tackle all high-priority work first, minimising other distractions.

Incoming work to the team needs to be triaged and prioritised against the team’s existing high-priority commitments, and people requesting work from the team should understand the team’s existing workload.

I’ve found this approach useful on projects ranging from remediating the error rate of a hotel reservation booking engine, to delivering the question-and-answers functionality on Booking.com

Split project into phases

Another useful technique is to break the project down into phases, with the key milestones for each phase listed. This can form an invaluable tool for understanding and discussing project progress and key deliverables internally, and with stakeholders. These phases can then be scheduled separately.

This approach has worked well on projects such as integrating multiple new products with Booking.com’s internal customer support software and upgrading the maps and location experience on Booking.com’s apps.

The second lever: Resources

The second lever that can be pulled is to invest further resources into the project. For example, people could be added to the project, commercial solutions could be purchased, or superior tools could be acquired.

Adding people

There is an old saying in software development:

Adding people to a late project makes it later.

  • People will need to be onboarded while the existing team is already stretched.
  • The project may need to be restructured to accommodate multiple people working on it at once.

Does the project team even have capacity to onboard more people at this point? Is the project even structured so that multiple people can work on it? If the answer is no, then a plan to add people needs also to consider how to reduce workload and restructure the project. Otherwise you can expect the project to be delivered late despite the additional investment of people (and associated higher cost), and a poor employee experience for the people involved.

Hire an expert

If you cannot easily onboard people to the project, or you do not know how to restructure the project, try to enlist the services of an expert who is already familiar with the terrain – perhaps someone who has worked on a similar project in the past. Once onboarded, they will be able to permanently upskill the project team, or fundamentally improve the structure or vision of the project.

For example, at Booking, a developer working on the next generation location and mapping service, left the company. The team was stretched and the project looked to be at serious risk. By bringing in a developer very experienced in service creation to help full-time, the project was brought back on-track. Then the team had enough capacity to onboard a new hire.

Structure project for parallel work

The structure of the project and software development practices of the team need to allow for additional people to be added. In order for development capacity to scale proportionally to the number of developers added, the work needs to be broken down into sensible chunks that can be implemented by different people simultaneously. This is one reason why it’s so important to plan projects thoughtfully upfront and break large tasks down into smaller pieces.

Remove bottlenecks

Adding people won’t accelerate a project if there is some other bottleneck. Very often, the bottleneck is a specific person, for example, a “star” developer without whom no progress on the project can be made.

  • This person will be busy.
  • They may have limited time to onboard and help new joiners.
  • They are likely to be a bottleneck.

The fact that there is a bus factor of ‘1’ is a major project risk and means that the entire project is riding on one person’s shoulders.

What can be done in this case?

  • Bring more people up-to-speed with the project, so that the work is more evenly distributed.
  • Help the person scale themselves, for example, by:
    • Producing documentation and FAQs rather than answering many questions individually
    • Setting up regular office hours
    • More efficient communication channels or group meetings, rather than ‘ping me on Slack’
    • Self-service tools to replace manual work and stakeholder management
    • Automating their work to reduce toil
    • Insisting on support where needed and setting a high bar of expectations for others to help

These are all examples of how you can help the person improve their time management; of course, this person might be you!

Purchasing solutions or commerical services

Rich uncle pennybags

Rich Uncle Pennybags, more commonly known as the Monopoly Man. Courtesy of Parker Brothers

It may be the case that a significant part of the project already exists and can be purchased or licensed commercially.

Many times, an open source solution is available, which can be ‘upgraded’ to a commercial tier of support. At Amazon, my team was administering the historical database fleets for EC2. Managing complex trees of MySQL database was a major, daily challenge, which was ultimately overcome by purchasing a commercial solution from a vendor who provided many of the open source tools we already used for database management.

If you can solve a major part of a project’s requirements for an affordable cost, then this has to be weighed against the total cost of any alternative; in terms of peoples’ effort, ongoing maintenance, infrastructure, etc. Fight against the fear of not-invented-here (NIH) syndrome.

The third lever: Time

The persistence of memory The persistence of memory (Soft watches), Salvador Dali, courtesy of MOMA

Negotiating deadlines

A project’s deadline is normally non-negotiable. Sometimes, however, it is. And it is worth knowing when this is the case.

Respectfully inquire as to the criticality of the deadline. Is it internally or externally set? Is it real or artificial? Sometimes deadlines are set as a sort of motivational tool, for which they can be effective. Sometimes they are set with the goal of posting a result at the end of some business cycle (e.g. quarterly, annually). Sometimes a tight deadline really means ‘ASAP’, and what the stakeholder really wants to know is that the work is priority 0, and they want to be kept informed up-to-the-minute. Another question is, did you commit to the deadline, or did someone else “commit” on your behalf?

If there are no real dependencies on the project completing on an exact date, and there will be no real-world impact of adjusting the the deadline slightly, then you may have room for negotiation here. Proceed with caution and use your judgement when broaching this topic with your stakeholders because you do not want to jeopardise your relationship, and above all, be sensitive to their needs and concerns.

For example, at a Booking.com kick-off event, an ambitious technology modernisation initiative was announced, with an aggressive deadline for the end of the year. This was a great initiative – but unfortunately, the deadline was infeasible. We were able to set, and achieve, a more realistic goal, by doing the groundwork to understand the actual scope of the work, current resources, and how long it would take. Then we worked with senior leadership to set achievable milestones on the topics they most cared about.

Create an action plan

Be sure to explain what other measures you are taking, beyond requesting more time, referring to the other two levers: scope and resources. Remember that you are only buying time and so it is what you actually do with the time that is critical. No one likes a delayed project and repeated delays are never received well – so its important to present a plan that makes maximum utilisation of the additional time, with a high confidence of completing at the end. In other words, avoid just asking for more time.

A multi-facted plan will most clearly lay out the different considerations and options, facilitating collaboration with your stakeholders to arrive at an optimum solution.

Keep stakeholders informed

Most importantly, if your project is at risk of falling behind, inform your stakeholders and partners as soon as possible. Firstly, this is their business and they deserve to know. Secondly, they may be able to help in unexpected ways.

Conclusion

There are three easy levers to pull when your project is falling behind: scope, resources and time. Drawing these as a triangle will help you remember them. A good action plan will cover all three.