bad requirements management

Author: No Comments Share:

one thing that ticks me off is when any particular issue is promoted into production and people forget about it. what’s even worse is when it is acknowledged as a valid baseline when the next iteration of the project comes along.

in every iteration of a project, a set of core requirements should be defined. The definitions should all be based on the three basic components of a website, content, look & feel, and user experience. aLIl three should go hand in hand. though one may stand above the rest but the degree of separation shouldn’t be that far.i

Now, the question is how do you do you hold on to those core requirements even when a majority of a products functionality has been staved off because a fix can’t be done in time for a release?

One route that I’ve seen is to look at the lessons learned for a project and evaluate the state of a product. for something like this to be effective, the primary stakeholder in charge of the product should have an overall idea on how sucky the product has become after the functionalities have been staved off due to time constraints. if the product manager is not even remote familiar of what the product should be, then that project is doomed.

I strongly believe that a stupid application that has gone through 8 iterations of testing, is still a stupid application.

Previous Article

a man and his swissknife

Next Article

Gift Ideas for Em