Changing tactics on communicating delivery dates
I love Project Plans, don't you? You get into MS Project, or some other scheduling tool, you type in a boatload of data, balance resources, estimate task durations, and calendar days spit out for the expected delivery dates. Milestones, functionality, and EVERYTHING now has an expectation attached to it, which EVERYONE wants a copy of. So I ask, how are we expected to EVER come in on time? I mean come on, the date at the beginning of the project is erroneous at best - the Project Plan is always a best case scenario where no Project derailing risks show their ugly head and throw the entire Project off track. There are no resourcing problems or equipment procurement delays, or even any natural disasters! If you come in earlier than expected you can be accused of "padding" or overestimating task durations, if you come in late you get grief for not being realistic or understanding task durations, so what's a Project Manager to do? I have an idea
How about we give a range? From now on quote a date that gives us all a bit of wiggle room, and NOT share the granular details with everyone? I had a Manager once that insisted that I provide a copy of the completed Microsoft Project Task Plan to the client in its entirety and guess what? Since we no longer had any information that hadn't been shared, WE were being managed to the initial baseline even when there were adjustments that we made on our end to accommodate changes in requirements and functionality, ergo we failed at every turn. I have vowed to fight to the death to never have this happen again, from now on I'm going to go with a +/- 20% quote on baseline, tightening up the margin the closer to the deliverable dates we get. My experience has been that once the majority get a "finish" date in their head it stays there – that's the date they remember and expect you to meet. That's the date that comes and bites you in the tail, and what actually is that date anyway? A 24 hour period (eight hours of work time) that should be considered the target completion date that was formulated at the very beginning of a Project where the team had very imperfect information. It's a DATE people! An eight hour period which would represent 1/730th of a Project that spans two years. It would be great if we could hit that, but realistic?? – I don't think so. If all days are created equal, on a 2 year Project, off the bat we have 1/10th of 1% chance of actually finishing in that eight hour time period. A bit better odds than those of winning the lottery, but not by much and I think you see my point.
So moving forward, I'm providing "deliverable ranges" for milestones, and if they want the detail level of the work breakdown structure they'll have to fight me for it. Maybe even to the death (unless something else regarding Project Management kills me first)