Schedule Delays Should Not Surprise You

When do you plan to talk about that crucial albeit uncomfortable topic? You know, that you are not going to hit your release date.

Often, awareness about delays surfaces only when we are near our release date and our boss asked the dreaded question “Are we going to make it?”. In reality, delays don’t happen near the end - it happens numerous times in the middle.

You got pulled on an unscheduled meeting. Your project is now delayed by an hour. You left the office early to buy that toy for your daughter’s 7th birthday. Add 4 more hours. You worked on that nasty bug from the previous release. Make that 3 days and 5 hours. You got sick. Now, you are delayed by a week. You procrastinated. etc. etc.

These seemingly little things happen all the time yet we don’t usually consider them as contributors to our schedule delays. Often, we attribute “major” things like a developer quitting in the middle of the project or big requirement change midway as causes of delays. Yet these little slips accumulated over time can become your major cause of delay.

One of the first things you can do is to have enough granularity with your deliverables that progress is obvious over a period of just couple of days as much as possible. When your commitments span weeks and there is no clear progress over a long period, you won’t have any idea if you are near or far to your target. And if your job is to manage delivery, that feeling of not knowing sucks. But if you make commitments over short intervals and you failed to deliver, you know if you need to make up for a day or two, which is more manageable. If you let a week go by without knowing what is happening, that is too long already and you could be facing a delay that is a challenge to compensate for.

The second step is to make sure your team understands who depends on those deliverables. If Alice is working on that API that Bob needs, and Bob is working on the shopping cart that Charlies needs to test, and Charlie needs to give the test results to Alice, every one should understand the interdependency among the individuals. This dynamic is repeated hundred times prior to hitting a milestone. When you think about it, hitting your deadline is all about making and keeping hundreds of small vital promises.

If you keep tab of those hundred promises, delays shouldn’t surprise you. When your team failed to deliver on this week’s promises and then four weeks later you learned your project is now late, then that is a problem. Most likely, people are not talking to teach other, not aware of the impact of a broken promise, or worse, have no sense of mutual accountability.

Every delay will cost your team some credibility points, and each one can costs more than the previous. On the bright side, there are positive things to be gained out of it. Delays are uncomfortable topic but these often trigger new insights, alternative views, and previously unimagined possibilities. As new information comes in, you are now closer to reality and your team can course correct towards the best results instead of blindly sticking to plans and schedules that were set when you still have a long list of unknowns.

Flexibility is software’s greatest asset and quickly adapting to changing environments is characteristic of excellence in software development. You can add time, subtract features, add resources, or do some combination of the three. You have heard this a million times - the famous triangle of features, resources, and time. At the end of day you only have those 3 things to work with.

There will be pressure to give a new end date but don’t give in. While it is uncomfortable knowing you already have a bad date, wait until the cause of the delay and extent are totally understood. This is not the time to estimate how much you’ve slipped and tack it on to your current schedule which is already proven to be wrong. This is the time to think through all the new information and possible remedies.

Delays are commonly viewed negatively and much of it stems from our desire for things to be predictable. Software development is an experiment of putting together a diverse group of people to perform a creative endeavour. Even after decades of experimenting with different practices, is still not an exact science — it’s more of an art form sprinkled with technical fairy dusts

Every software project, no matter how successful they were, started with a large number of important things that were unknown. It is undesirable to have many unknowns but not unusual. Given each software development project is unique with its own personality and combine that with new technologies and new approaches, you end up with high degree of uncertainty — the odds are against you.

However, attempting to eliminate all the unknowns at the start is not only unrealistic but spending more effort on planning has diminishing returns. Instead, one of your primary job is to make every one embrace uncertainty and guide your organization so it thrives in an uncertain environment. Your team’s mindset is not to follow a plan to perfection but to make the right decisions every day as the unknowns become knowns.