Planning for Delays
© 2000 Gerald M. Weinberg, www.geraldmweinberg.com
As some of you know, a group of consultants are producing a conference for our colleagues and clients. It's called AYE, for "Amplifying Your Effectiveness." One of the main goals of this distributed project is to apply our own methods of amplifying effectiveness to the project itself, and thereby to learn what works and what doesn't.
My first big learnings have been in the area of unplanned delays. The project members are distributed all over the United States, and often travelling from their home base -- a situation that's more than familiar to many Contract Professional readers. I was concerned about the difficulties of conducting distributed projects, but one advantage of this potential handicap is the availability of an email record of what's happening. So, when I started being aware of delays, I surveyed my email and came up with a list of what had been holding us up and frustrating me.
I suspect the list itself will be a nice reminder to me for future planning, so I also thought it would be useful to many Contract Professional readers. After laying out all the delays and what we're doing about them, I'll present a few general principles that might also be helpful to others:
1. One project member's email is somehow delayed in cyberspace for 2-3 days, without anybody knowing it. The result is messages arriving in the wrong order, and producing confusion that produces more confusing messages. We vow to notice dates on email.
2. Rick's color monitor fails, and Rick is our webmaster (a single point failure). We talk back and forth for a week, and by then his monitor is fixed. We lose a week.
3. I forget to sign one of two signature lines on a bank form establishing the project bank account. This delays the payment of bills for 10 days, which might have caused rippling delays -- but didn't because people had their own budgets and could pay the bills and trust they would be reimbursed.
4. Kevin breaks his hand, which is especially tough because he can't use his Braille reader. This delays lots of things Kevin is involved in, but the primary delay is in delivering his article for our pre-conference book. This turned out okay, because he wasn't the only one whose article was delayed.
5. Dave, who is developing our wiki-web site, gets the flu. This delays the entire wiki testing for a couple of weeks, but it's not yet on the critical path.
6. Some security certificates (whatever they are) expire on my browsers, and my attempt to update them crashes my system. This non-understood bug delays many tasks for several days (but the effect was somewhat ameliorated by having an alternative browser).
7. Several people take vacations they've been planning for a year or so (how inconsiderate of them!). This wouldn't have been much of a problem if we'd thought to put these vacations in our plan.
8. Naomi has a serious family situation, so she decides she must cut back on her participation until it's resolved. This adds extra load to several other people, but we were not overloaded, so the schedule effect is minimal once Johanna, our project manager, reallocates the tasks. We are able to reduce Naomi's participation to the one area where her contribution is least replaceable, and we can do that because we know exactly what Naomi is best at (helping other writers).
9. People who were not at our initial planning meeting have to be brought up to date -- not just on our plans, but on the logic behind our plans. We haven't planned for this, so it's a real delay -- but has an excellent side effect of making us rethink some of our logic before it's too late to change.
10. James joins the team and has to be brought up to speed. Again, more delay, but with the benefit that James is a talented tester, and subjects many of our plans to tests that we haven't thought of. James is also an excellent writer/editor, and can take up some of Naomi's tasks. So, we paid with some delay, and were repaid with some later catching up. In other words, educating James about the project turns out to be a sound investment. Late in the project, however, it wouldn't have had time to pay off.
11. Our phone and email lists are somewhat out of date at the start of the project, causing irritating delays until we stop and fix it. This contact information should have been done at the very beginning, as it is a core competency for a distributed project. Also, we needed plans for updating this information, because the project is about a year long, and over that period of time, some contact information will undoubtedly change.
12. Marie's son gets sick, which takes her attention away from AYE business for several weeks. I begin to wonder why all these people are being so inconsiderate of our conference's problems!
13. I find a strange new mole on my neck, and have to have what the doctor calls minor surgery. (Minor surgery is surgery done to someone else.) Then she finds another suspicious mole, and I have more minor surgery. Then I have a dental emergency (I'll spare you the painful details). I begin to understand why all these people are being so inconsiderate of our conference's problems.
14. We are putting together a book of essays by the conference hosts, to introduce people to our work. By definition, we have to have an essay from every one of us, but a few people are at the tail end of the curve with respect to personal pictures, bios, and essays. There are a variety of fine reasons for their delays, but the fundamental reason this is so troublesome is the structure of that part of the project. Since everybody has to have an essay in the book, finishing is like trying to get that last Pokemon card, or last number for a bingo. The mathematics of this kind of requirement ensures that such a project will cause anguish, and we eventually decide to relax the requirement that everybody contribute. If a few are missing, we can live with that. Relaxing this requirement relaxes those of us who are responsible for the book sub-project -- and curiously enough, seems to cause all the pictures, bios, and essays to arrive on time.
15. Unfortunately, some of the articles submitted aren't up to quality standards we had set, and they have to be recycled. We could save quite a bit of time by lowering our quality standards, but we decide against this, since quality is one of the key goals of our conference. What good would it do, we reason, to preach quality when we ourselves don't practice it.
16. There are lots of typos in the material we prepare for our web site (ayeconference.com), but unlike many web developers, we believed that web sites do have to be tested. Therefore, these delays were anticipated and planned for by the web and project teams, and so fit within the schedule.
17. From time to time, some team member panics about some item or another -- which takes time and effort to soothe. Our perfectionism is a major cause of these panic attacks; satisficing (learning to think about what was acceptable quality, rather than perfect quality) is a major cure.
18. Then there are holidays, delaying things in a variety of ways. Why couldn't Jesus have been born in August, we ask? Poor planning, we concluded -- was it by God or by us? Probably us.
19. And of course there is bad weather, which turns out not to hurt us as much as we expected because our travel is mostly virtual. We are lucky there, because the infrequent travel is more by personal preference than project planning. Most of us travel much of the time, and we've learned Freedman's First Law of Consulting: Don't fly on the East Coast in Winter.
20. We are hurt much more when my ISP (Internet Service Provider) starts delaying delivery of my email by 1 to 7 days. We are hurt even more when Steve's ISP, which hosted our email lists, starts failing intermittently. Once we realize what is going on, though, we are able to bypass the convenience of group lists and simply maintain our own teams' lists until Steve gets things straightened out with his ISP. Steve eventually realizes, though, that he had chosen his ISP because they were the low-cost provider -- a lesson for next time.
21. Then, once we have all the essays and bios and pictures, we realize that some people haven't kept the paperwork concerning their articles that they had previously published elsewhere. As one contributor says, "It just didn't seem important to keep those legal things -- at the time." Lesson obvious, and lesson learned -- I hope.
Conclusions
Well, there are lots more than twenty-one, but I think I'll stop here. Some of us will publish the entire project's delay list in the future; it will probably be a book. And we're planning to conduct a retrospective at the conference itself. For now, though, I think you might like to look over the list once more and compare some of your conclusions with mine.
God may have other priorities higher than your project. Leave some slack for Acts of God.
Perfectionism kills schedules; reasonableness saves them.
Certain project structures make success as likely as winning the lottery. Search out and eliminate this lottery effect from your project plan. Not only does this eliminate "bad luck," but it also lowers psychological pressure on participants, which leads to "good luck."
Quality is negotiable, but not infinitely negotiable.
Plans are predictions; plan to test them early and often, and then adjust them.
Machines fail. Software fails. People are even less perfect, but they're more adaptable, so they're handy to have around to back up the machine systems.
If you have a single point of failure, it will fail at a single point in time. After that, if you have any brains at all, you'll remove it.
Cross-training is one of the surest ways to protect against those single points of failure. So is a good asset control system for all your project's assets. If you fail to follow this system because "it doesn't seem important," you're sure to lose your assets.
You won't be aware in advance of all possible single points of failure, but if you do some risk analysis, you'll be aware of many of them, which will leave you more time to deal with the ones you weren't aware of.
You won't appreciate other peoples' delays until they happen to you, but try to learn to grant them a generous interpretation. This may calm you down sufficiently so that you can actually become part of the solution, rather than adding your blaming to the problem.
And, finally, I often hear my clients telling me that their project will make its schedule "if everything works out right." Well, I've been in the project business for over forty years now, and I've seen several thousand projects. I've never seen one where "everything works out right." This has led me to formulate Jerry's Iron Rule of Project Life:
It Always Takes Longer
Defy this Iron Law at your peril. Plan for delays, and plan to be adaptable and forgiving when delays occur that aren't part of your plan. You'll be more successful, and you might even be happier. As of now, we're on schedule for November, and we're rather happy about it.
Email this article to a friend.
Comments to:
