Over the last 15 odd years I have been involved with dozens of IT projects of all shapes, sizes. Recently I have been reflecting on why some of these projects were a dream and delivered successfully, whilst others were a complete nightmare and went horribly wrong.
An obvious factor is the size of the project but that does not ring true. I have been involved with huge projects that went like clockwork and small projects that just couldn’t seem to get off the ground. The same is true for projects with complex or simple domains; projects with untried technologies or projects with proven technologies.
So what was the differentiator?
After much pondering I have come to the conclusion that those projects that were most successful had a good deal of clarity. Clarity in what needed to be done, why it needed to be done and how it was going to be done.
So I’ve come up with a new catchphrase (which I intend to bandy about at every opportunity):
“CLARITY leads to FOCUS, FOCUS leads to DELIVERY”
Actually I really wanted to use VELOCITY in there somewhere and DELIVERY is just so so unsexy so perhaps its still a work in progress but I digress.
So what do I mean by clarity ? Well pretty much exactly what it’s definition says “The state of being clear in thought”.
Of course this isn’t a new concept, which is why we have the waterfall process with its BDUF (big design up front) approach. Unfortunately this process actually has the opposite effect because it tends to silo the project members around particular phases and then uses big fat documents as a means of communication between these silos. At each step of the way clarity around the why, what and how is typically eroded or even (as I have seen in some cases) corrupted, all of which leads to the classic customer reaction ,when they see their software for the first time, of “What the hell is that, thats not what I wanted”.
This of course is where agile processes come into play with their sleek processes that allow a project to deliver efficiently and successfully. Of course without clarity an agile project degenerates into a mess, with quality going out the window in an effort to meet iteration deadlines, constant quick fixes, a stressed out team and a failed project.
So how do you about gaining clarity?
The best approach I have seen is to get as many of the people who are going to be involved with the project into a room to work out the why, what and how. The group should include the stakeholders, end-users, subject matter experts, architects, UI designers, testers, business analysts, developers, project managers, infrastructure bods. Pretty much anyone who can add value to the process.
Don’t panic, even for large systems the effort involved for this is measured in hours and days, not weeks and months. I would however, suggest you find a good facilitator to keep what is typically a fairly large group of people focused.
Here are some techniques that I have used or seen used to nail down the why, what and how:
To capture the why, write a vision statement. It doesn’t have to be book. In fact put a limited on the length of the statement such as “25 words” or “3 sentences” or if you want to be particularly nasty: “7 words”.
To capture the what, you can uses any number of techniques. I find that visual ones work best (and are easily done on a whiteboard) so use-case diagrams, storyboards or UI wireframes and entity or domain models are the order of the day.
In a similar vein, to capture the how, nothing beats a deployment model and some sequence or activity diagrams (all in UML of course).
So to make your IT project a success make sure you have clarity and remember
“CLARITY leads to FOCUS, FOCUS leads to DELIVERY” :)
Check out Scott Ambler’s Agile Modelling site which covers some of the techniques above and has a bunch of other practical and interesting ideas.