
After 30 years in application development, with 15 of those being in the insurance sector, I would like to think that I have seen it all when it comes to development projects. Sometimes you get it right and other times, well, you miss the boat completely. However, regardless of the success of a software project, the one thing that can always be counted upon is change. Whether it is an off-the-shelf policy admin product or a homegrown solution, a new feature will always need to be added, a process enhanced or a modification to an existing characteristic will be required simply because it does not quite meet the customer’s expectations.

Through much trial and error along the way, I discovered the key to managing the scope of software projects for both the customer and the vendor is through the process of prototyping. It is a very efficient method for clearly establishing change requirements, with the biggest benefit being that the requirements are presented in a medium everyone can relate to, and is directly comparable to the delivered end product. An early preview takes the surprise out of the end product, supports rapid development and contains development costs.
What is Prototyping?
Prototyping, in a nutshell, is the simple process of creating a graphical presentation of the new feature in a form that the business user can actually see, interact with and experience the final end product of the proposed application or application feature. Well developed prototypes will allow the user to visually verify content and interactively verify application flow much like the end product to validate work flow.
With a variety of great development tools available today, prototypes can be easily constructed to represent the finished product while providing users a very real experience of the functional usability very early in the project rather than at the end of the project. Users feel much less intimidated by change, take greater ownership and a very willing to be accountable for requirements they signed off on.
Prototyping as a Tool for Rapid Application Development
Today, when companies want change, they want it completed yesterday. Schedules are tight and budgets are low. The expectation is Rapid Application Development (RAD), especially in an environment where it is affordable to deploy an army of technical resources from off-shore development centers. RAD is the formal methodology to define, design, develop and deploy computer applications in significantly less time than conventional development methodologies. It does not change what needs to be done, but rather provides a structure and a toolkit to ensure that unintended slips and compromises are not made when working under the pressure of crashed schedules. With a RAD schedule, it is imperative that the change requirements are complete and accurate prior to any development activity. Under these circumstances, prototyping is critical as it validates the understanding of the written requirements gathered from the users.
A well executed interactive prototype becomes the playbook for the technical team to validate development. It is possibly the most powerful tool which almost guarantees that the developer and the user groups share the same vision of the end product. Very often the need for further changes is identified while interactively working with the prototype. RAD requires a full understanding of requirements prior to starting the development phase of the change to meet stringent delivery schedules while keeping the costs under control. Prototyping clearly demonstrates if the requirements have been understood and the proposed solutions are acceptable to the project stakeholders.
Prototyping Success Factors
Creating a good prototype is easier said than done. Several factors influence the successful execution of a development project through the use of prototyping. It is very important to let business objectives drive the design of the change, rather than present business processes. That being said, a few key aspects to keep in mind when taking this approach:
Make it actionable. The most important objective of a prototype should be to present and verify the work flow of the new system. A static visual display of the contents of an application screen is important, but not as important as how if fits into the workflow of the business process it supports. Take the effort to create the expected outcome to enhance the user experience. Demonstrate the expected outcome in the prototype, such as displaying visible results in a window when the user enters data or simulating the actions of the system when the user clicks on a button. Put in the effort to present actual business examples and business data of the customer on the visual prototype to demonstrate new functionality. Remember the user relates a visual aspect of the system to their business process through the information they see on the screen. It is such a simple aspect, but often overlooked and is key to the user validating a business function.
Involve the actual business users. In my experience, I believe that with actionable prototypes, users find it very easy to pretend that they are using the system to conduct live business transactions. It is also very important to get the actual end users of the new function to validate the prototype. There is no better judge than the actual end user of the application feature to confirm if the new application meets the requirements and objective of the change. It is not uncommon that the actual end users of the system are first exposed to the new feature or application after it is developed. This aspect alone has trashed many projects.
Do not forget to understand what the application should not do. Particularly when applications are developed within a very short time period, the focus remains on what the application should be capable of doing. Often, we forget to focus on what the application should not do or should not allow the user to do. This is not just in terms of business edits, but since the application will now drive business processes, checks and balances of the business process should be contained within the application. These aspects should be demonstrated in the actionable prototypes.
Keep the prototype current.The prototype should always be an accurate representation of the end product. There are bound to be changes, particularly after the original project has been implemented, so it is important to incorporate any changes to project scope in the prototype by periodically updating and versioning changes, no matter how small the change. Properly executed, this process should serve as an accurate reference point for business requirements and is a great tool for accounting project scope and validating the finished product.
Case Study
After selecting SimpleInsure as their policy administration system, California Mutual Insurance Company sought to provide their appointed agents with a better method to submit applications to their underwriters for consideration. Up to that point with their legacy system, California Mutual could only accept applications via email and fax. The underwriting team would then enter the data into their legacy system to produce a quote for the agent to consider. This simple process could take up to a day and any changes requested only extended the time to return a quote back to the agent.
SimpleSolve worked very closely with the users at California Mutual to clearly understand their vision of an efficient agency submission feature. Based on many discussions and actual onsite interviews with agents, we came up with a concept of what the new feature should be. Taking the knowledge gained through the process, SimpleSolve developed an online web based prototype for evaluation by the users at California Mutual which was also shared with a select group of agent users.
With the prototype, the users were able to experience the process of data entry, the transition from window to window, the validation rules and workflow process in an environment that simulated the actual behavior of the intended functionality in the final product. Several modifications were identified as being necessary and since we were still in the prototyping phase, they were quickly incorporated into the prototype for consideration. The result of this exercise was very firm set of requirements that supported rapid application development of the agent’s web portal.
When asked about the experience of prototyping the process prior to development, Steve Miller, President of California Mutual had this to say, “In the development process SimpleSolve provided us with a prototype on the web application’s screens and tabs. From this prototype we were able to determine which data and fields should be on each screen. And, importantly, experience the look and feel of the workflow. We also took the prototype to our agents for their comments. The prototype, being easily changeable, greatly reduced development time and once developed we had very few additional changes. And, our web application has been well received by our agency plant. We were able to avoid the common problem of having something developed and then having to change the design or concept.”
If a picture is worth a thousand words, then a well created prototype is worth a million. How often has it been said by the users after a system is developed and deployed that the outcome has completely missed the mark? With prototyping, these situations are avoided.
About SimpleInsure by SimpleSolve, Inc.
SimpleInsure is a fully integrated software solution specifically designed to manage the book of business of insurance carriers and MGAs. This end-to-end insurance administration system rates and issues policies, invoices premiums, tracks receivables, records claims and manages agents and commissions. It is configurable for multiple product offerings, states and issue companies. Intuitive web interfaces allow agents to easily submit business to your company and to inquire issue status online.
For more information about SimpleInsure, visit out website at www.simplesolve.com or email us at sales@simplesolve.com.
About Antony Xavier
Antony Xavier is the President and Co-Founder of SimpleSolve. His experience is comprised of designing, developing and supporting computer-based solutions for commercial enterprises. The variety of roles and exposure to various applications and technologies over the past 30 years has afforded him the adaptability to changing business practices and technologies. He has actively worked in the P&C insurance space for the past 15 years. Contact him at axavier@simplesolve.com.