Over the past several years I have been a part of many such projects. To share a rough figure over 30 % of the projects have been in this so called “fire” because off other significant reasons but 70% (the biggest chunk) because of mismanaged “Requirements Phase” and the common excuse being “Client is not sure of what he wants”.

Often during the Business and Technology tussle we miss out the actual objective of the requirements exercise and end up catering to most of the unexpected and impromptu needs.

To begin with lets take a look at the simplified version of a typical project cycle as can be illustrated as :

Simple View of a Development Cycle
(Click on the image to see a full view)

For any project the critical phase is Requirements as it forms the basis of the entire activity for the remaining cycle. In most of the engagements when I analyzed I came across that most of the user requirement turned to be something not in scope (specific to the case where “Client is not sure what he wants”).

To find a cure for this recurring issue I tried a more objective approach for the requirements. To put it visually here it is

Requirements Phase – The New Approach

In the above illustration

1. Are the User Expectations (a.k.a. the wishlist)

(As a matter of fact whenever a business decides to design or redesign an Application they would like it to be more scalable in context to be able to make use of the same for a longer period of time before it calls for a re-engineering once again so they often try to visualize things in a time scale and come up with requirements which happen to be expectations a.k.a the wish list which is beyond the necessities )

2. The common area where some of the expectations are more or less treated as necessities to be able to give the scalability

(These are typical requirements which are covered under any project as a result of effective planning by Project Managers – the common term they use is “buffers”)

3. Necessities is a must have or the core basis of the project.

Trying this approach helped improve a lot of the time line and “out of scope” issues. Keeping a realistic view of requirements (2+3) helped plan the development activity accurately unlike “Guesstimates”

News Aggregator: A news aggregator is a software application or remotely hosted service that collects syndicated content from disparate sources and provides a single consolidated view. These applications can also be commonly referred to as a feed reader, feed aggregator or simply just an aggregator.
http://en.wikipedia.org/wiki/News_aggregation

News Syndicator: In general, syndication means the distribution a news article through a syndicate – in this case an RSS feed – for publication in a number of newspapers or periodicals simultaneously. Used in the context of RSS because RSS syndication is all about distributing content for reuse or redistribution on other websites.

http://www.rsstoolchest.com/rss-glossary.html

Some other definitions from Google -

News Aggregator: Aggregators, such as NewsGator and AmphetaDesk , allow users to subscribe to feeds from sources as diverse as the BBC, Sci-Fi Today, Slashdot and thousands of bloggers across the world. The services work by checking an Internet address at a regular interval, usually once an hour, to see if new content has been added. …

News Syndicator: The process by which a web site is able to share information, such as articles, with other web sites. It is an alternative means of accessing the vast amount of information that now exists on the world wide web. Instead of the user browsing websites for information of interest, the information is sent directly to the user.