Author: Kevin Jacquier
I recently joined a project that just baffled my mind with respect to the amount of time and resources that had been spent prior to any true visual representation of the requirements and functionality. Unfortunately, my peers and I were brought in well into this investment. It’s all great work, but it has consumed over six months of time with more than four distinct groups (Business Users, Business Analysts, Architects, Quality Assurance, and now Design Architects). I understand the need for thorough requirements and design, but there is still a great deal of concern if the currently proposed functionality will satisfy the needs of the user community.
Allow me to step up here onto my soapbox. You see, I am a firm believer in early prototyping, especially on projects that involve significant user interaction.
Some feel that the prototype can’t happen until all requirements have been obtained. I feel much differently:
• Can you prototype without 100% of the user requirements? Absolutely.
• Can you prototype without 100% of the architecture design in place? Absolutely.
• Is the prototype throwaway? Most definitely not! A solid prototype can serve as the base for the actual project solutions.
Here are just some of the benefits of early prototyping:
• The user gets an early understanding of how the product will look and function. This levels expectations early, and it also shows users some additional capabilities that they may not have previously considered. This is obviously better from both the user and development standpoints than finding that a project does not meet user expectations eight months into the project.
• Design flaws can be detected early, not eight months down the road.
• Rapid prototyping affords developers and business users more frequent interaction. This iterative approach allows users to experience the look and feel as well as the proposed functionality earlier in the process, so their concerns may be expressed and addressed BEFORE such a significant development investment has been made.
• Rapid prototyping typically increases the speed of system development.
• Rapid prototyping assists in refining the end product. Different aspects of requirements can be tried and tested and immediate feedback is possible form the user.
• Better communication is enabled between the business and developers as there is clear expression of requirements and expectations.
• True requirements for nearly all Business Intelligence (BI) projects are not fully understood until user acceptance testing (UAT) is completed or a project is put into production. Many times users think they know what they want, but when they actually see it in action, different ideas are sparked and changes are needed. Changes to a completed project may require changes at all layers of the architecture — database designs, ETL, BI metadata, reports, dashboards, and so on. This will result in more time, higher cost, and higher risk of error, not to mention the reduction in its credibility.
• It is a very painstacking task to identify business requirements, translate them to functional requirements, and then into technical designs. In many cases, users, analysts, and designers don’t speak the same languages or they use very different terminology. There are a lot of back and forth meetings to understand and confirm these documents. Rapid prototyping can allow the user and designer to collaborate and actually see the requirement in effect without spending all those resources generating pages and pages of documentation.
• Having a working prototype provides a great tool to discuss alternatives or additional requirements. Many times it is hard to ask the right questions in meetings. Many times it’s up to the business users to articulate what they want and if they don’t do so, the end product will not represent what their real needs are. With prototyping, those needs are easier to see and discuss.
• Even when business users articulate their needs perfectly for IT, and even when the IT understands the language of the business, requirements are often still described based on theoretical needs and intangible designs. It is not until the user actually gets to use an iteration of the solution that they realize what they really need.
Prototypes provide a way for users to “kick the tires” of a solution early in the project life cycle. This can help avoid the costly rework that may be required after UAT or Production Implementation. This does not mean that Prototyping is easy. There are still many layers that need to be accounted for (database Layer, ETL, BI Metadata, Reports, Dashboards), but these can be done in iterations and the initial work doesn’t have to be “Production” code.
Okay, now I am off my soapbox!
For more information about effective prototyping as well as other Business Analytics topics, please contact FYI Solutions, a leader in information management and business analytics for over thirty years.
