What really is “done?”
Recently I came across a new blog, Herding Cats, where recent posts have shed light a subject that you know is around you, but you don’t know its really there. In any given project, does anyone really know what “Done” is?
“What is done?” It seems like a simple answer, but when you really start to think about it, what really is done? Letting this idea spin in my head for a few weeks and having discussions with peers, the issue really isn’t not knowing what done is, but the lack of definition when you start. Really, how do you measure success if you have no base to compare to? So done becomes, “lets just get this wrapped up, we need to deliver something and we need to get this project done!”
The main problem is that, to many of us, pre-planning seems like a useless effort. The task comes across as “not getting anything done.” We just want to get in there and start hashing out code so at the end of the day we can say that we got something “done.” In reality, we are so far from the truth. When we skip the pre-planning process, it is to easy to gloss over the details and move forward with to little definition or actual direction. What it is we are actually doing? Now, I am not saying that we go all out with waterfall and plan the whole thing out with every little detail, but using the agile approach, plan out what it is we will actually be doing before we do it, that is where the magic is.
With any project and any project management style, we need to stick to some basic disciplines. We need a project charter. We need a starting discovery phase. We need a starting design phase. I have never been a part of a successful project where these initial steps were not completed and given their proper respect. Once we have that kick off and the team knows what they are being asked to do, now we take some time to work out the details. Take one chunk at a time, define it, deliver it. Call that “done.”
I recently read an online book from 37Signals, “Getting Real“ the idea is, ‘done is when you have a functional model that you can deploy.’ Are there opportunities to increase performance? Are there opportunities to revise the design or workflows? Are there opportunities to add new features? Of course there are. But you can’t do them all now. Also, the sooner you can get a version out, the sooner you can get users involved and get their feedback. As they say, hindsight is 20/20, so all of those other features that you “had to have” may not be the case after all?
Now the hard question, when does the client think it is done? This is a questions that has no simple answer. This requires discipline and work on the part of the account and project manager. The account manager needs to have that definition as to what the scope of the project is. To a certain extent, the fulfillment of that scope is a definition of done. But if the client has some unmet expectation that could be interrupted from the project scope, “Done” becomes a slippery slope. So how do we address this?
Iterative scope review and work definition. For each phase of a project, the portion of the scope that relates should be reviewed again so that all the stake holders are on the same page. The scope definition needs to be refined into a deliverable. This deliverable, or spec, needs to include increased level of detail so that an effective work plan can be produced. The more vague the definition at this point, the more opportunity for assumptions arise. The approved deliverable, by the client and the account manager, can now be decomposed into an effective work plan by the development team.
SImply put, the less the pre-planning, the more opportunity to overlook the details. There is not checklist of events that need to happen. There is always the question, “Is there anything we forgot? Are we done?”