What’s Wrong With Wednesday?
© 2005 Johanna RothmanMany of the project schedules I review contain milestone completions on Fridays and new task or phase beginnings on Mondays. With a Friday or Monday milestone, what you’re really saying is that people can work overtime all week and all weekend to make the Friday milestone, so they won’t be late for the Monday start.Why? Why do we do this to ourselves and to our project teams?It’s convenient to think about project milestones ending on Fridays and new things starting on Mondays. But just because it’s more convenient from a calendar perspective, should we use Fridays and Mondays to end and begin project segments?I say no. Down with Fridays and Mondays. Let’s end and begin project segments on Wednesdays. Wednesday is a perfectly good day, and one that is possibly underutilized in project planning. Tuesdays and Thursdays are also good, and in my experience, underutilized. Here are the effects we might see if we choose a Wednesday to end a project phase or start a new phase.
- Improve schedule precision. We would know that our schedule estimations are wrong, and we might know more about how we estimate incorrectly. When we hide the actual milestone complete dates behind massive overtime, we encourage our project staff to inaccurately predict the next schedule, leading to even more overtime. Here’s why: When we schedule project phases to complete on Fridays, we allow ourselves to take the weekend to complete the pieces not quite done on Friday. Completing a phase on Friday really means the phase is complete by the time people get to work on Monday morning. If we don’t complete the work by Monday morning, then we’re honest-to-goodness late. But, if we completed the work on Sunday morning, are we truly late? In reality, yes! We have underestimated the work, and we need to know about that underestimation to improve our estimation the next time. Otherwise, we can continue to underestimate projects by however much we are underestimating them now.
- Adjust for schedule risk sooner. We would know earlier in the project that the project has a higher risk than we earlier believed of not meeting its release date. The earlier in the project you know that the project is in trouble, the more options you have. At the beginning of the project, you can still add more staff, change tools, drop features, modify your life cycle, change how you work to reduce defects, or choose to allow more defects. In the middle of the project, you may be able to add more staff, drop features, change how you work to reduce defects or choose to allow more defects. At the end of the project, you can drop features or choose to allow more defects. As a project manager, I want to have more options rather than fewer when I’m faced with schedule-related bad news.
- Avoid hidden overtime. We would have less self-induced project overtime. When we’re in the last couple of weeks of the project, it may make sense to ask people to work overtime. Many people can manage a week or two of overtime and still think carefully and make good decisions. However, allowing overtime for more than a couple of consecutive weeks is a poor management decision. People who work overtime for more than a couple of weeks stop thinking clearly because they’re too tired. Or they don’t have any new ideas because their brains are stuck on the same old ideas. Or they stop paying attention to themselves and their self-care, so they get sick and then pass the disease to everyone else, causing the entire project team to work at less than full strength. When we schedule for midweek milestones, the amount of overtime needed is much more obvious, and we can make conscious choices about how much overtime to use on the project. If you have numerous two-to-three-week minor milestones, and people are constantly working overtime to meet the milestones, you have an entire project of overtime. Constant overtime generally leads to staff burnout and software technical debt.
So if you’d like to see just how close your schedule estimates are, create schedules with milestones ending in the middle of the week. Track how closely you meet each milestone. At the end of the project, look at how much extra time you needed and see if you could have planned your project or estimated the tasks differently to have developed a more accurate schedule at the beginning. Make your project schedules honest and help yourself see the reality of the schedule sooner, say, on a Wednesday.
convert this post to pdf.If you enjoyed this article and want to learn more about the conference, sign up for our email newsletter. We'll let you know about new developments, conference discounts, and other news. And we'll never, ever give away or sell your name or email address.
Send to a friend