One of the key phases on every project is correctly collecting requirements from the user. In the past 10 years I have never seen a project of relevant size that didn’t have changes requested, either during build/execution phase or during testing. Requirements Main Page
A rigorous waterfall project approach that firstly requires collecting requirements documentation to extreme details by users, and after analyzed by architects, designers etc., caused three negative side effects: First, the requirements collection phase has been lengthy, it consumed a big amount of resources, and time after time near the end, users tended to short-cut in order to respect the deadlines. Second, the users become too attached with their requirements, in some cases, unwilling to compromise even for the sake of respecting scope, time and budget. And last, the users were biased to go to much in details, mainly driven by the concern that this was their only chance, they might forget something and later be taken responsible.
The result was over-engineered projects, which after consuming all the budget and time, still had additional requirements and changes coming in later. In the worst case the project end phase became some sort of drama and blaming game. Main Requirements Page
To address this situation, the key was to find a balance with the users. To aim somewhere between no-details, to-vague, to-much and over-detailed. We successfully tried some simple steps to improve the overall project performance.
First, we started by demystifying the process and removing the mistrust from the involved users. We told everyone changes are part of life, they are not to be feared, instead they are to be managed.
Second, we switched from an approach of pure waterfall where we were expecting users to deliver a full list of requirements to the architects and designers, to an approach where users and the experts sit together in a “war room” and discuss and enrich each requirement.
Third we invested a lot in communication with the users to agree to leave apart requirements they were not sure of. Better leave something you are not sure out, then to add something you do not need in the project. This was done by explaining with details the costs of complexity, as a maintenance cost you bear for all of the system’s life. This cost in the end affects the end users.
Forth, we planned in the project a second revision phase, to address changes and overall improvements. It was planned as a ball park, and to be elaborated later, as PMI calls it rolling wave planning.
To date, after 4 years of using this technique, significant improvements in the project performance were achieved. In the past we had to work from time to time on ridiculously complex requirements that would have been used in rare circumstances, and yet the users insisted in having them, fearing they would lose their chance if it was left out. This new approach resulted in simpler solutions, a faster delivery to market, fewer rows of code written, meaning less defects.
In some aspects our experience may sound as it deviates from PMI best practices for thorough planning, yet it is related to rolling waive planning and in our experience has proven to deliver excellent results. More on Requirements