The evacuation instructions could be a form of paper prototype.

The evacuation instructions could be a form of paper prototype.

The most powerful single technique for generating requirements is showing users and stakeholders something and collecting reactions. There are numerous techniques for developing something to generate feedback, ranging from functional code that could implemented in production at one extreme, to functional prototypes in the middle, to paper prototypes at the end of the scale. Functional code is used to generate feedback to evolve the backlog in Agile projects, however showing techniques are not used as often as they should be to generate the initial requirements backlog. The reason these techniques are not used is the perceived level of effort needed to generate the prototypes or an impetus to begin building the solution immediately.

The power of the showing techniques is based on the theory that many people only know what they want when they see it. The process of generating feedback and requirements is also risk management. A prototype reduces the risk that the project will either build the wrong thing or build the right thing wrong. Functional prototypes also, to an extent, are useful to prove that a solution is at least conceptually feasible (prototypes are generally too small and not fully functional therefore do not truly serve to prove technical feasibility). Paper prototypes address generating requirements and reducing risk but are faster and cheaper to generate because there is no code or code related infrastructure. A very simple example of a paper prototype for a customer relationship management system (CRM) might be set of drawings of screens to show the rough flow of work.  Users to use the paper screens to imagine the process and discuss the flow. In comparison a functional prototype would have mock screen on a computer show system flow but typically without any background functionality.

The first issue with prototypes is that developing them requires time and effort. Project teams are often presented with a goal, a budget and a deadline. In most corporate IT organizations, performance against the project budget is considered a critical measure of progress (and in the longer term, project success). Therefore teams and project/program managers mercilessly manage the budget to improve the possibility of project success. Unless prototyping is built into the budget and the planned approach for the project, there will be pressure to use the less costly, albeit less effective, asking techniques to generate requirements. Teams, sponsors and project managers make a rational choice to manage the budget risk against the possibility of not generating a good enough backlog to get started. However, generating requirements using prototypes is a process that can used to balance requirements and budget risk. The higher the risk of not having a more through early backlog the more important techniques like prototyping will become to mitigate that risk.

The second issue that the use of prototypes face is what I call “starting fever.” In many methods, including Agile, the whole cross-functional project team is assembled to start the project. There are many individuals that don’t believe that gathering requirement is important, therefore unless there is something for them to build or test, they will find other things to do. There are numerous ways to deal with this type of structural slack; here are two extreme cases will illustrate the range. The first solution is to have a subset of the team (like the Three Amigos) generate the initial backlog before kicking the project off. The second solution is have the whole team spend a day as the project kicks off to generate a quick initial backlog and then use the demonstrations at the end of each sprint to continue to flesh out the backlog. I lean towards scenario one or variants in which the other portions of the team work on framing the technical and physical infrastructure.

Another way “starting fever” can be triggered is because of the panic a fixed budget, fixed scope and fixed date project that someone actually said yes to before requirements are known can cause. Before you protest, regardless of how much every developer, tester, BA, project manager or CIO believes in that this an irrational situation they happen ( I see this as the norm in some organizations) and they casue teams to abandon good  practices like prototyping. In the long run project teams have to pick up the pieces when these types of projects had problems. When teams are put under immediate schedule, budget and scope pressure, leaping into action and then creating and firming up a backlog later can look like a great solution. Action is still equated to progress.

Prototyping is an effective tool for driving out requirements that can’t be expressed until they are seen. The backlog building techniques that show the users and stakeholders something to react to also serves to mitigate the risk of building the wrong thing or the right thing wrong. The power of these techniques is offset by the cost and time required to generate prototypes and a fear that unless you are building something the project has started and the due date is at risk.