| Date: | November 24, 2006 / year-entry #394 |
| Tags: | history |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20061124-36/?p=28913 |
| Comments: | 11 |
| Summary: | One of my former managers told me this story from a project he worked on many years ago. This project was broken up into multiple groups, and there was a weekly meeting where representatives from each group got together to discuss how the project was going. One of the groups was responsible for generating the... |
One of my former managers told me this story from a project he worked on many years ago. This project was broken up into multiple groups, and there was a weekly meeting where representatives from each group got together to discuss how the project was going. One of the groups was responsible for generating the reports and analysis. This was an important part of the project, but not a part that other groups depended on, since the reports were "pure output". At each meeting, the reporting and analysis group indicated steadily improving progress. Ten percent complete. Twenty-five percent. Fifty percent. The number increased week by week. Things looked good. And then one week they reported that they were eighty percent done, adding, "It almost links now." I don't know how everybody in the room reacted to this revelation, but I suspect it was met with stunned silence. It's a good thing nobody had a dependency on the reports. |
Comments (11)
Comments are closed. |
I take it someone was taken out back the way of old yeller?
I have to say the management should have had some share of being raked over hot coals for this.
You should never just accept that something is "50% done" or "95% done" without qualifying it in some way. How do you know what 50% is? In fact, how do you know what you’re aiming to in order to announce you’re 50% of the way there?
If you don’t do this you end up with things like this, or the Brillant Paula Bean(http://thedailywtf.com/forums/40043/ShowPost.aspx). Either way, nasty surprises.
Ah, the old strategy of code everything, then test it in one big hunk.
Invariably when I do this, I find that I’ve made an incorrect assumption right at the beginning that invalidates my entire design and I’ve wasted a week (or however long it took to write the code).
Do your work in small increments and test them as you go.
I think this almost makes sense. Let’s say your process is roughly "design, implement, compile, link, test". Once you’ve gotten your code to link, you’re 80% done. Right?
Ha, this needs to be sent to http://www.thedailywtf.com/
They probably meant "we are 80% done with typing error corrections so the code finally compiles".
I was recently involved in importing data from a former competitor’s database into our own database after we purchased them. We had a hard deadline that couldn’t be missed because the customer’s website was scheduled to be turned off on a certain date and the switchover to our site had to be finished by then. The night before we were supposed to import the data, my colleague, who until now had claimed that his import program was "finished", stunned me with the question "Should I be concerned that I haven’t tested my program yet?"
He and I ended up staying until 3AM and I basically re-wrote every line of code before the program worked. Luckily the task wasn’t that complicated!
% complete reporting is quite often finger-in-the-air stuff. A few places I’ve worked define what must be done before you can claim n% complete — this stops the headlong charge to 95% and the slow crawl towards 100%.
The real problem is management, isn’t it? –And I’m saying that as a project manager. You can’t get any visibility or predictive power out of a bare "percent complete" number, except maybe to assume that 50% of the work remains to be done from the first time a project is billed as 80% or 90% "complete." I lay down the following rules: 1. No task longer than 2 weeks, and 2 days is preferable. 2. Tasks are either complete or not complete–never a percentage. If you have to do earned value or anything like that, you take credit for 50% the moment you begin a task. For all other purposes, it’s 0 or 100. 3. Once we have a list of properly decomposed tasks (i.e., not "reporting module"), we pick out the riskiest tasks in terms of meeting the schedule, and do those as early as possible–preferably right now (like Mark Twain said about the frogs).
These three principles have helped me a lot in making estimates and hitting them.
Hrm, I was about to say just that – 50% done means that half the deliverables are done or something like that. More useful is having a schedule with tasks marked as complete or not and some not given to expected unknowns.