Project Requirements Prototyping

A study by project management consulting company, PM Solutions, in 2011 examined 163 companies to identify top causes of IT projects failure, and requirements ranked right at the top. Requirements Main Page

The issue with Project Requirements Prototyping is a communication issue. We humans express our thoughts and needs using a biased, misunderstand able medium, the spoken language. The information is warped using our biology, emotions, past experiences, culture. This message is transmitted using our communication skills (often limited), and is in its turn unwrapped by other humans that add in the mix their own experience, biology, emotions, experiences, culture. The result, as you all might have experienced, is very often distorted. People discussing the same topic, walking away with different pictures in their mind. During the collection of project requirements, this risk, inherent from the deficiencies of our spoken language is considerable. In my experience, the communication gaps have been the key reasons for failure. For the same reason mathematicians, physicist has used formal language for hundreds of years.
Few years back, acknowledging how problematic are the misunderstandings in requirements we decided to invest some resources in preparing a prototype, before starting the work. The team of business analysts would be responsible to prepare it.

Requirements Management: Business Analysts

It would work like this; the BA would start with something simple as soon as they could, without waiting for the full set of the requirements to be prepared. The prototype would then be showed to the business users and technical teams. The comments from both sides would be incorporated to the prototype and then showed back for discussion. We went for up to 10 iteration until a stable and final version emerged. The target was to keep it simple, meaning the prototype did not have to be fancy or based on some complex platform. It was enough if they just sketch it on paper and then sit with the users and the technical team to shape it until reaching a satisfactory state for all the parties. In the end, the prototype would be signed upon as the final agreement between all stakeholders.

The first project we applied this concept was the automation of teller system for a bank. The result was very bad, and good at the same time. The analysis phase finished more than a month in delay, as the prototype seemed to be changing repeatedly. On the positive side if these changes were coming in the testing phase, it would create a huge mess. On the user’s side, they loved it, as they had the certainty important parts were not left out, and could immediately picture the product. It gave the possibility to visualize the requirements allowing all the involved stakeholders to reach an agreement, narrowing the gap between the need and the technical capabilities. As well, it helped the business users to more critically assess their thoughts and as it resulted, often adapt part of requirements.

Of course, it’s not always easy to choose and prepare the right prototype. In data processing systems like data warehouse the prototype could be an excel worksheet with the input data and the transformation formulas. For interactive, user based systems it was more about GUI design, validation rules etc.
Through the years, the process has been refined, and users got more capable at it. We currently do use tools that are more advanced, still the concept is the same simple one and every time we find the complexity of a tool limiting, we go back to drawing on whiteboard.

Powered by WordPress. Designed by WooThemes