Requirements. We've all dealt with them as developers. Sometimes
I think we (developers) understand the concept of requirements because we use
them to development whatever software we are writing. Since it most likely
wasn't our idea we can't rely on our wants/desires on how it should
function. Too bad that a lot of PM's don't get this concept and for that
matter, customers don't either. I really don't expect customers to get it
as much as I do PM's but since PM's are usually the ones dealing directly with
the customers it leaves a lot of room for missed requirements.
Sometimes when I deal directly with the end user they think I'm
over thinking a task or concept they have for their app. If what they want
is so simple and/or easy, why are they seeking a professional for the
work? I do agree that somtimes all they want is easy but
there's nothing wrong with being thourough. I try to get from them
what they want in their words, regurgitate it back to them so they can verify
that I know what they are wanting, and then I provide a list of requirements
that I'll use as guidlines for coding the project. Pretty straight forward
as a concept.
Introducing
Project Requirements is a pretty good article on doing this. It's
short, to the point, and a good set of guidelines to use.
Wrap-up
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
- Nothing magical, no rocket science required. Just a simple process to
follow, and the biggest dragon responsible for project death is slain. And you
get to be a hero, which is nice.