Posted on

Prototyping in Project Management

Prototyping in project management can be effective in many situations is very attractive to users.  Phototyping consists of planning and then developing a sample deliverable for the users to review and modify.  Prototyping reduces the pressure on users to specify all of their requirements before works starts.  So we would talk to the user and make a plan then produce it. The user would review with make changes and then we would produce another prototype for the user to review and modify.  Producing one prototype after another allows us to iteratively, prototype by prototype, developed the deliverable.  Depending on the deliverable, prototyping can be very expensive and time consuming. But is a user or client wants you pay for this approach, a good project manager can accomodate them.

The classic waterfall approach where we finalize the whole plan IN a lengthy planning effort, and then execute the plan,  is cheaper.  It does however require the client or user to commit to exactly what they want during the planning process.   It also limits the changes the client can make once we begin to execute. The prototyping approach allows for changes during exams iterations.

Prototyping Communications is the key

The issue with Project Requirements Prototyping is a communication. 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.

Example Requirements Prototyping: 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 late, 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.