michael eaton

this.  Mitch Denny has another great post.

These two paragraphs really hit home with me:
”The point is that when you have a scope that is so large it is effectively impossible to survey all the requirements and expect them to be stable for the duration of the analysis phase. The larger the scope, the harder it gets.

I guess this is why I am skeptical about project methodologies that advocate nailing everything down to the nth degree before getting started on getting some value back to the customer. Methodologies that seem to work are the ones accept this volatility and set some broad visions but try to constrain detailed requirements analysis until just before implementation.“

When I worked for a consulting firm, the standard methodology included 4 pretty heavy phases: Requirements, Design, Coding and Testing.  The customers never knew quite what to expect from the first two phases and were never really happy to receive a huge amount of paper and the accompanying bill (from the thousands to the tens of thousands of dollars).  After spending ridiculous amounts on the requirements document, they would inevitably change them anyway.  Of course, we always tried to be hard-core when they wanted to change something, but it never worked.  No matter how many times we said “but it's not in the requirements“, it all came down to the fact that they were paying us to perform a service.  Noone wants to be told they're wrong or that they can't do something when they are shelling out huge amounts of $$$ each month.

It is my opinion that you *must* be flexible to changes in requirements.  The goal, after all, is “getting some value back to the customer”.  I would add “ in a timely manner” to that statement.  I have taken to writing a light requirements document and then using prototypes to help flesh out exactly what they want.