I’m late, I’m late!
Even when you’ve done something many times before, sometimes you forget something or make a mistake.
This morning I was on my way to visit a client and realized I’d forgotten something. It seemed to me important enough to do something about it, so I went back home and got it. The unanticipated delay threw my schedule into disarray. I wasn’t going to arrive by the time I wanted. I was frustrated and unhappy with myself.
I see similar things happen all the time in software development projects. Something throws off the schedule. People get unhappy.
This morning, I could have made excuses about why it happened. It was darker than it has been, as the sun is rising later. I was distracted by other matters. What would it have gained me to direct the blame elsewhere? For that matter, what would it gain me to blame myself? I acknowledged what I’d done and, after a little bit of human self-reproach, set about deciding the best way to handle the situation.
My original plan had been to take a bus into D.C., but the delay meant I would miss the last bus. It was obvious to give up that intermediate milestone. It was never the goal; just a marker for being on target with my original plan. I started devising a new plan, discarding the benefit of reading while someone else did the driving.
I considered various alternative paths. I judged them not only by their expected speed, but also the risk of further delays. I chose one that seemed reasonably prudent, and fairly well known. This was not a good time for me to experiment with something brand new.
I considered driving faster. In fact, I may or may not have gone a little faster at times than the posted speed limit. I’m not going to say for sure in print. But, under most circumstances, the posted speed limit has a margin for safety. It’s possible to push that a bit. But how far? I was late enough that the speed required to make up the time would have clearly been dangerous, both to me and to those around me. (On the way home tonight, I saw an SUV that apparently pushed that limit and ended upside-down on the shoulder of the road.) Besides, the bottlenecks that start as I near D.C. would be what mostly determined the length of the trip.
I drove prudently and competently, and arrived a little late rather than the little early that my original plan predicted.
Does this story make you think of your software development projects? When you know you’re behind schedule, how hard do you work to catch up? Do you take risks that might cost even more time and leave you further behind, or worse?
I understand the stress the situation caused. On the other hand, it strikes me as a good analogy for unexpected delays in software delivery. In that context, as long as stakeholders learn about the delay early enough to deal with it, the impact can be mitigated. In the situation of late arrival, as long as we notify others that we will be late, there’s usually no major impact.
Good post! I also agree with Dave about the value of notification. My worst failures in managing projects have come more from not notifying customers/stakeholders of the delay earlier in the process. It’s a very hard, but very valuable lesson in humility for young leaders.
Working hard to catch up and fulfill commitments is an important part of the story. However there is a risk that under pressure developers may cut quality. (Usually) What customers do not want is a product that is delivered on time with “less than enough” quality. Like Dave and Randy, I agree it can be life-saving to make the delay visible, so that timely action can be taken to avert a crisis later. And maybe+hopefully the customers are open to a schedule or scope change, depending on their situation and the project.