I’m currently working on a trading software project that got me thinking about the importance of prototyping. The process of software creation all starts with an idea. The ideas are coming from what other people envision, and the vision is likely to vary when multiple people are involved. The main goal of prototyping is to gain insight into ‘how’ and ‘why’ (“how should this work?” and “why do you do it this way?”).
A prototype serves as a malleable interaction tool used to create consensus.
Working through the prototyping phase will help uncover process gaps, understand stakeholder expectations and define success.
Uncover Process Gaps
One of the goal’s of the technical team is to gain insight into the underlying process. Typically, stakeholders will have a good understanding of the business process and how software will facilitate or work with the business process. Yet, it is important to understand that stakeholders may not know the finer details or consider alternate ways for the process to work. Asking questions will help gain insight into the business process workflow and uncover enhancement opportunities.
A simple example:
Stakeholder: “We receive the files via email, then we upload them to the software, then the software modifies the file and stores in a database.”
Technical: “Who is emailing the file?”
Stakeholder: “The customer.”
Technical: “Is there sensitive information in the file?”
Stakeholder: “There are optional fields that may be sensitive if filled-in.”
Technical: “Is the customer technical enough to log in to a simple portal and upload files themselves?”
Technical: “We could consider allowing customers to log in to a portal to upload files. This would eliminate the need for you to upload the files, and eliminates the security risk of sending sensitive data via email.
This is a simplistic example that highlights a technical person gaining insight through questioning. As her understanding builds, she is able to recommend a solution. Her solution has addressed a process gap, sending sensitive data via email, along with an enhancement, allowing customers to upload files via a portal.
Stakeholder Expectations and Success
This is one of the most important purposes of the prototyping process. Creating the perfect software means nothing if it doesn’t meet stakeholder expectations. Similar to uncovering process gaps, understanding expectations comes from asking the right questions. Where this differs from identifying process gaps, is the line of questioning should focus on business motivation.
As the technical team, you are excited about the process of creation – taking an idea and building something “tangible”. But keep in mind, your motivation for software creation is not the stakeholder’s motivation. The stakeholder’s motivation is outcome-driven; the need to create a tool to achieve a certain business outcome. The technical team’s job is to understand the business motivations driving the project and the desired outcome (success).
An interesting point here is there may be several motivations held among stakeholders. In this case, it is extremely important to recognize if there is conflict among the motivations. As an example, suppose one stakeholder expects the software to increase the speed a business process by 20%, and another stakeholder expects the software to work with 5-times more data than the current business process. In this case, it could be that the software will either maintain a similar processing speed while working with more data or increase processing speed while working with a similar amount of data as the current process. It is the technical team’s job to understand all motivations, communicate motivations back to stakeholders, and continuously measure motivations against the project decisions.
Here are few less obvious benefits to prototyping:
Camaraderie – working through the prototyping phase gives everyone a voice and allows individual contribution. This helps build rapport amongst participants that should be fostered throughout the project.
Builds trust – a great deal of trust is created when a technical team prioritizes understanding business motivations and desired outcomes. This allows for a common business language and trust that the technical team understands the problem.
The level of detail and amount of time put into a prototyping phase will vary, but I believe all software creation should start with a simple visual tool to communicate the problem, functionality and outcome.