Are You Really Done?
May 26, 2008 – 8:34 amJohanna Rothman over at Managing Product Development wrote a short series of great posts on what it means to be done in a project.
The first article, Why You Don’t Need a Schedule, not only brings up a great alternative to effectively managing a project (and I daresay more effective than a lot of methodologies), it brings up an important reminder. If you don’t know what the completion of a task means, then a line item on a gantt chart or ‘project plan’ is useless. Items must have success criteria. What does the line item “Development” mean? Does that mean completion of code? Deployment of code? Code passed QA?
Not only must you have completion criteria, more importantly, you must know who is going to perform the task, who is the recipient of the task’s deliverables, and make certain that both parties agree on what completion of the task means. Failure to do so will invariably lead to great pain during your project. Imagine, for example: “We finished development. That’s what the task said. You wanted it to pass QA too?!? We haven’t even talked to the QA department, but I hear they’re backed up a month… you’ll have to get in line…” This is not a conversation you ever want to have.
The logical extension of this is her post, What does done mean to you? is all about definition of done in general. How do you decide that your project is ‘done’? Do you have valid criteria defined in your charter? If you do, does it meet the business’ goals on the project? For example, delivering a software project to production does not guarantee success- there’s training to consider, adoption, communications, possibly marketing… what were the Sponsor and Business Owner’s original goals, and are you making sure that you fulfill them?
On the other hand, if you did fulfill them, are you being allowed to walk away where appropriate? Helping the business with its problems with the IT Operations team to keep the product running and updating smoothly after the product is deployed may be viewed as good by the business unit, but is that really part of the project, or are you supposed to be moving on to other project now?
A gantt chart with a date and a name on each task is not enough. Be sure you have your five W’s down in your project: Who does the task, when, what the task is, and so on. Without success criteria and ownership of that criteria, an item on a gantt chart is just a line of text.
Like this post? Buy me a cup of coffee.Popularity: 34% [?]
