What's Wrong With Wednesdays?
Computerworld -
Many 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.
![]() ![]() | |
| Johanna Rothman consults on managing high technology product development, focusing on project management, risk management and people management. |
Development
Additional Resources



White Papers & Webcasts
Extend, Replace, or Convert; which is the best way forward for COBOL Applications?
Download this white paper, free, compliments of Micro Focus!
Data Manager Report Excerpt: File System Inventory
Cut storage costs and boost operational efficiencies.
Key Strategies for Managing Data Growth
What are you storage challenges?
Reducing Storage Costs with F5 ARX
Save money- deploy ARX Solutions.
Extending Client Refresh - 11 Steps to Maximize Savings
Register Now!
Southern Company
Download Now
Lower the Cost and Complexity of a Mobile Workforce through Automation
Download This Resource Now!
Defending Against the Storm
Download Now
Managing Mobility: Improve Data Security, Compliance and Manageability
Download This Resource Now!


