How To Avoid Project Delays?

Project delays in IT are more common than not. Despite adding beefy timeline paddings to absorb surprises, projects still fail to live up to their promises.

That's because padding is not the solution, it's just a relief. It gives more time to write code, but not necessarily the right code.

More build time without feedback is a gamble.

To ensure that we're building the right solution, we need continuous feedback. Following a scope document that was written many moons ago doesn't mean we're on track. Track is where the customers are.

Otherwise, teams are stacking unvalidated assumptions (risky!) on top of each other and tying a large chunk of operating cash flow to unfinished work.

If this all sounds familiar, let's delve into the mitigation options.

‍

Establish Transparency

Make work small and visible

Bigger the work, larger the unknowns. Chunking the work down into valuable pieces minimises risk by enabling rapid feedback and adaptation.

Plan incrementally, deliver continuously

Upfront plans house a lot of premature assumptions. Those assumptions snowball throughout a project's lifecycle, and becomes an avalanche by the time projects reach their final stage.

Foster collaboration

Build systems that are capable of end-to-end delivery (e.g. ideation to completion) so the dependencies don't create idle time.

‍

Enhance Flow Efficiency

Limit Work In Progress

Dropping the ball is no surprise when juggling multiple priorities at the same time.

Reducing (and limiting) the amount of work in progress reduces the time it takes to complete each work item.

Little's Law by John Little explains this with the following equation.

Little's Law
L = λ x W

Let's put this into an IT project perspective and evaluate it from a delivery standpoint rather than queueing theory. (Note the differences in the table below)

WIP = Throughput  x  Cycle Time

Say your team completes 10 requests a day (Throughput), and each request takes 10 days to complete on average (Cycle Time). There would be 100 requests in progress (WIP) any given day.

If you halved the WIP, cycle time would have been halved assuming that the throughput remains unchanged.

50 = 10 x W

W = 5

Reduced WIP means juggling less, finishing more.

It channels the capacity towards completion, reduces context switching, and forces a change in team behaviour called "swarming".

‍Important Note: Little's Law is descriptive (explaining how things are currently related), not predictive (not guaranteeing what will happen if you change one variable).

Eliminate Dependencies

If a skill, knowledge, or a process is needed often, making it easily accessible boosts flow like no other. Silos and red tapes are the biggest culprits of troublesome dependencies and excess idle time.

‍

Fix the behaviours

This is where most delays are born. Organisations that focus primarily on processes and technology face immense resistance from people. Eliminating delays require transformational change in behaviours.

“I’ll check with the business” bottlenecks
Build cross-functional teams and empower them with more autonomy. Get decision-makers in the room. Having designated individuals that talk to stakeholders is not collaboration, it's a communication dependency.

Make problems visible immediately
Good teams escalate early; weak teams hide issues until it’s too late.

Build psychological safety
People should feel safe to speak up as soon as things drift. Eliminating eleventh hour surprises improves predictability, eliminates intense firefighting and delays.

‍