The Consequences of Project Delay
Meeting regularly with project managers gives me an opportunity to see and hear patterns that might escape the notice of others. We talk about deadlines and due dates, and I review what they are working on, help build estimates and schedules, and determine what (if anything) they might do to accelerate their schedules or defend targets from delay.
One of the patterns I’ve observed is that newer project managers can be a bit myopic about their schedules. They track their dependencies and the impact on their deliverables and schedules, but often haven’t learned to look at the bigger picture: the consequences of their schedule slips on others. Knowing the larger context of your undertaking is important.
Let’s look at a nonsoftware example.
My mother-in-law and I often patronized a coffee shop whose big selling point was that it’s walking distance from my house. In September, the shop was sold and closed “for a month” for remodeling. Weeks later, there was no apparent progress. In November, we decided to drive to a different shop farther away. It has better coffee and pastries and friendly operators, and my mother-in-law and I have become regulars there. The old coffee shop is expected to reopen soon, but I think they have lost our business.
Imagine you were the person who bought that local shop. You saw that it needed some paint and polish but thought you could improve the product, so you did the math and assumed you could get the remodel done in a few weeks. But there were delays. It might have been permitting with the city, it might have been the availability of contractors—there are a thousand reasonable explanations for the delay. Regardless, the shop’s regular customers won’t care, and it won’t help recover lost business.
I imagine you are thinking, “What does this have to do with my project?”
If you familiarize yourself with the consequences that delays to your project will have on the mission of your organization, you will be able to support better business decisions and improve outcomes. This flows from understanding your project’s context.
When someone tells you they want your project done October 31, don’t just agree and wander off to build a schedule. Instead, accept that 10/31 is the desired delivery date and seek to understand what is driving that date.
There are several possible responses:
- “We have a contractual requirement to deliver the product to one of our largest customers on that date.” If that’s the case, requests for additional resources might be received favorably, if needed to assure the schedule.
- “We need some of the functionality you are building to support another project, starting in November.” Your organization might be amenable to delivering only the needed subset of functionality by then. This might also inform the sequence that you build features.
- “We just wanted to get it wrapped up before the holidays.” This sounds like a somewhat arbitrary target. If your most aggressive schedule suggests a November 10 delivery, this is probably negotiable.
Knowing context and the implications of a delay gives you more options and improves your problem-solving. That’s what project management is all about.
