I feel that if I publish a project plan that shows completion on date X, I can't very well push for completion at date (X - 3 weeks). But If I publish a plan that shows date (X-3 weeks), how can I track the "most likely" completion date (which is likely date X)?
asked Apr 6, 2012 at 14:13
Add a comment
|
4 Answers
When you build an estimate, the end result is a range of finish dates, or costs, with a probabilistic distribution that sits on top of that. When you set a target, the end result is a SINGLE number that lives somewhere in that distribution. You would establish that target based on risk appetite. Move it to the left, like your X-3 scenario, to challenge the team and take on a more aggressive stance. Move it to the right and make it consistent with your most likely. Or move it even further right if you need to build in contingencies due to a ton of environmental unknowns.
On most scheduling tools, you can set multiple baselines. Your baseline zero can be the official one that is priced and sold to your customer. You can set baseline one, using a more aggressive target as your team challenge, and set measurements and awards based on that. During the course of the project, measure against both. I would not "punish" the team for missing the challenge under any circumstances. This would be an award-type scenario and I would set it up to be more fun, competitive, and a morale boost versus anything else.
answered Apr 6, 2012 at 14:55
Try to implement the evidence based scheduling in your first project. If you collect the evidence quite regularly and update your schedule, you'll see when you can start your next project. They key here is the regular update. Don't commit to the second project - try to defer your decision using real option - until you feel safe to set the finish date of the first project.
I second David's answer, and would like to add a simple method to implement this in your planning.
When estimating time for each task, you should do a very aggressive estimate without any slack built in. The slack for each task is then combined into one big "buffer" block you put at the end of your plan.
A Simplified Example:
Traditional "probable" estimates without buffer:
Task01[10days] > Task02[3days] > Task04[7days] > END
Aggressive estimates with buffer added:
Task01[7days] > Task02[2days] > Task04[5days] > Buffer[6days] > END
During the project, you keep the final date static but change the buffer duration according to progress; i.e. if a task is completed before estimation, you add to the buffer, and if a task goes beyond, you subtract from the buffer period.
This gives you a single 'health' metric for the project to communicate, and create bonus/incentives around. This also makes it simpler to make tough decisions earlier in the project. If you've used 33% of your buffer, during the first 25% of you project, you can easily communicate and discuss this issue with team and project owners.
It takes courage and perseverance, but you can keep schedule contingency separate from the critical path. The hard part is your customers will fight for a commitment to deliver at the earlier date.
In your case it means working to a T-3 and keeping the 3 weeks on your back pocket.
This is more efficient than distributing the slack because you will most likely need it for one or two big areas rather than all over. (If every estimate was missed you have a bigger problem.)
