PROCESS IMPROVEMENT, PROJECT MANAGEMENT The Fundamental Reason Why You Fail to Deliver on Time

Interview Preparation Management
#1

Businesses across the globe fail to deliver on time. In the early days of prison warfare, a deadline meant a line that was drawn around a prison to deter prisoners from crossing. If they did, they’d be shot dead on sight! Nowadays, although you won’t get shot if you run over a deadline, it might still have a severe impact on your business.
In fact, 4 of the top 6 challenges faced by companies, as outlined in the 2020 MHI Annual Industry Report relate to faster delivery and higher customer expectations, including customer demands for lower costs (51%), customer demands on response times (48%), rising customer service expectations (47%), and customer demands for customization (41%).
In times of a saturated market and fierce competition, it’s critical to meet these expectations and deliver on your commitments. So, if you’re still trying to get on top of overdue tasks, it’s worth taking a step back and analyzing the root cause of failing to deliver on time.
Тhe most common reason behind failing to meet your commitments and deliver on time is setting unrealistic expectations.

A case study conducted by Calleam Consulting demonstrates how inaccurate estimates led to the significant delay of the completion of the Baggage Handling System of Denver International Airport during the 1990s. The unreliable predictions were off by 16 months, a delay which cost the city of Denver an eye-watering $560 million. Just two decades later, the system has been decommissioned.

This is just one of the many projects that failed due to unrealistic deadlines.

The Sydney Opera House was supposed to be completed in 1963, for $7 million. A scaled-back version opened ten years later, in 1973, with a final price tag of $102 million.

Managers fall victim to our inbuilt tendency to underestimate how long it takes to complete our work. And how can we possibly predict our exact delivery times with the unpredictability of knowledge work? Are we actually capable of foreseeing the exact time that a feature will take to go through the whole process while handling the rest of our work in progress at the same time? Do we know for sure that there won’t be any additional work coming in between, any dependencies, defects, bottlenecks, or external blockers that might cause a delay?

The problem is rooted in the expectation of answering our customers with a single certain delivery date. Yet, that tends to be the norm in practice. It seems that we’d rather come up with a single certain commitment that ends up being wrong than express any uncertainty.