For example, suppose it historically takes me about four hours uninterrupted to write this newsletter. I diligently hold a half day on my calendar a week before the end of the month. Each day I try to hide long enough to get the newsletter started, and each day interruptions that are a higher priority that day consume me. I sit here today working on a newsletter due in two days still fighting interruptions.
Here's a scary question: how much heads down time can you get realistically in a day? My students tell me less than 2 hours. That means my newsletter should take me 2 days. It looks like that will be the case.
So, I've decided to get out of the estimating business. Instead, I lay out my projects back from an end date. My ultimate goal - what is the Drop Dead Date for each task I need to do? I start with milestones so I can manage chunks that aren't as overwhelming. I use these traditional milestones (IT and Training):
ANALYSIS - build the requirements, what do we need? This is divergent thinking. The sky's the limit. DESIGN - sketch out a blueprint. This is convergent thinking - make realistic choices on what's in and out.
DEVELOPMENT - build something resembling the design knowing some aspects have to change / evolve.
IMPLEMENT - get it successfully to the customer to meet their business need.
IT research (Capers Jones) indicates that there is a Pay Now, Pay Later truth to all development work. According to this research, the best allocation of time across these phases is 2/3rds for Analysis and Design, and 1/3rd for Development and Implementation. In most projects, it is the worse than reverse - 1/3rd for Analysis and Design and 4/3rds for Development and Implementation. Skipping through Analysis and Design guarantees that you will spend a ton of time in rework, especially implementation and testing.
I usually am given the end date of the project and I know what today's date is, so I can use my 2/3rds 1/3rd goal to allocate Drop Dead Dates for each milestone. Then, I can break down the tasks to get each one done, leveraging the arrows from my Scope Diagram to make sure I'm not forgetting any stakeholders and work (see 10 Steps to Successful Project Management, Lou Russell). I know the beginning and end date of each milestone, so working backwards is a math exercise. For some of my more chaotic projects, I build tasks two milestones at a time, rolling the next milestone out after completing one. This way I don't have as much reworking of the schedule.
At this point, I may legitimately find that my dates are not realistic. Time to negotiate a smaller scope, more help or more time. If it is possible, I put the tasks on my calendar, get the focus I need and shut the door. Just like I'm doing right now.
If this sounds like an approach you need to learn contact Brittney.