Taking Charge of Your Requirements
Are requirements ripe fruits that need to be gathered from the ground once they fall off? Or are they seeds of change that are sown, nurtured and harvested? Interesting as it is, project teams usually wait for the requirements to be ripe before they attempt to collect them. Instead of gathering them, would it help the organization if the project team collaborated with the business teams to identify, prioritize and prototype the project requirements? The answer is a resounding yes.
The process of waiting for requirements to be generated and supplied by the stakeholders to the project team is an arduous one. Most of the time, the business team is busy doing what it is supposed to do--perform business tasks that bring in profit, reduce costs and help their organization to be industry compliant in an ever-changing marketplace. But they might find it a bit challenging to translate their current pain points to the clear, succinct and prioritized requirements that the project team usually demands.
The paradigm shift
Generally, project teams who have the unenviable task of developing information systems for their business units expect the business requirements to be rock solid before starting the development. This is probably a good idea if your project team is new or if you are a consulting organization implementing solutions in an unfamiliar domain.
However, most of
Please log in or sign up below to read the rest of the article.
|
"Thus the metric system did not really catch on in the States, unless you count the increasing popularity of the nine-millimeter bullet." - Dave Barry |




