Comments are closed.
How To Avoid Trying To Deliver The Moon On A Stick
March 29th, 2005
Here’s a useful approach for requirements gathering, courtesy of Martin Burns:
Without a doubt, the most significant thing you can get wrong in running a web development is to mess up the requirements. Get this wrong, and every thing you do after that is doomed. This article will teach you how to avoid this poison chalice and be on the first step of the road towards consistently delivering effective projects.
It’s a straight-forward process (the best ones always are, after all) of gathering, documenting, validating and baselining requirements:
The result of all this is that you’ll have Requirements that:
- Are understood by everyone
- Are agreed to by everyone
- Are documented such that there is no room for arguments
- Are the basis for accurate planning of work and budget
- Are capable of being strongly defended against the “This week’s wizard wheeze” type of request
You could also combine this process with one that I’ve used successfully in the past: sanity checks for feature lists - to close the circle. You can then sleep a little easier knowing that your requirements are complete, agreed, documented and sane.
Filed under Project Management, Working smarter |3 Responses to “How To Avoid Trying To Deliver The Moon On A Stick”
> 1. Are understood by everyone
> 2. Are agreed to by everyone
> 3. Are documented such that there is no room for arguments
> 4. Are the basis for accurate planning of work and budget
> 5. Are capable of being strongly defended against the “This week’s wizard wheeze” type of request
Here’s the thing: those goals, like objectivity in journalism, are wonderful ideals that are impossible to achieve in reality. Language is fuzzy. Agreements are subjective. People are always going to argue. You can’t estimate unknowns in advance. And you don’t have the right information until you start actually working on the problem.
Frequently, you don’t know enough when you design the spec, at the beginning of the process, to understand the best way to build a product. And sometimes (not often, but somtimes) an out-of-the-blue feature addition turns out to be the right thing — no, the critical thing — to do for the business.
Web projects, in particular, exist in a rapdily changing environment. My advice?.
- Get real fast. ( http://www.37signals.com/svn/archives/001050.php )
- Embrace change. ( http://c2.com/cgi/wiki?ExtremeProgramming )
- Run with less mass. ( http://www.37signals.com/svn/archives2/2005/03/getting_real_le.php )
Create a process and a culture that eschews bureaucracy and focuses the maximum percentage of energy on producing business value (that means working code).
Indeed, language *can* be fuzzy. However, it’s not necessarily so. Use it in the right way, and requirements can be surprisingly clear and non-reinterpretable. Remember that requirements are often contractual terms, so you really want to get them solidly defined.
Of course there’ll always be changes… but that’s OK as you’ll have a Change Control Process in place, won’t you? Changes in requirements result in a contractual amendment. But you’ll anticipate this, so the CC process will be all you really need.
That’s the main advantage of couching requirements in contractual terms, IMHO - the fact that they’re likely to have undergone sustained and indepth scrutiny…