RAPSoD©
– Rapid Application Prototyping
for Software Development
Reduce the risk of failure on software
development
projects while keeping costs low
Ruven Gotz.
Anilet Inc.
Abstract
Implementing new software applications can make companies more profitable. However, the cost of a software project failure is high, making it difficult for decision-makers to take the risk of investing in needed solutions. We describe RAPSoD (“rhapsody”), the methodology we developed over the past ten years that greatly reduces risk while cost-effectively producing results that exactly match customer needs.
Introduction
Most businesses today understand that technology can make them more efficient and productive. They can save money, or improve customer relations by adding systems that require less staff, and that improves customer relationships and satisfaction by giving them more rapid access to information about their business and customers. All of this translates to bottom-line improvements (i.e. more profit).
If a business owner, or CEO understands this, then why are so many of them reluctant to start projects that can lead to great results? The answer is FEAR.
Not fear of change, or fear of technology – it’s nothing as “psychological” as that. No, the fear is a very practical one: Fear of project failure.
We have all heard of those multi-billion dollar disasters of software project failure. But more importantly, we’ve all also heard about business owners who have purchased computer systems that have fallen far short of what was promised, that have taken many times longer to get working than expected and that have almost (or actually) caused the company to go under.
In order to for a decision-maker to agree to undertake a project that has a promising upside, they must first know what the “worst case scenario” is on the downside. Because no matter how valuable a potential solution is, if there is a risk of company failure, or a risk that the whole project will have to be thrown out and written-off, then the project has very little chance of getting done.
The key benefit of RAPSoD is that the it reduces risk by allowing the customer to see exactly how the final product will look and work, for about 10% to 25% of the cost of the full project.
In this paper, we will describe RAPSoD (pronounced: rhapsody), the methodology that we have developed over the past 10 years that has resulted in dozens of successful projects.
How does RAPSoD work?
There are five main elements to the RAPSoD process:
- Get started quickly
- Prototype everything
- Develop the database at the same time
- Keep the customer involved along the way
- Don’t throw it away
One of the biggest problems experienced in software development projects is the lack of communication between customers and software developers. It is very difficult for the customer to exactly describe all the details of what they need. The way people try to solve this problem is by the creation of large specification documents that try to capture every detail of the project. When the customer signs off on a specification document, they cross their fingers and hope that they have not forgotten anything and that the developers have fully understood what was needed.
We once read a great analogy for this: Imagine that you had to create a specification document for your car before the factory would build it and deliver it to you. When you get the car, you notice after a while that it has no “turn signals”. You ask the car company why, and they tell you that it wasn’t in the specification document. You may rightfully say that you expected them to know that every car needs turn signals, and that they should have done it anyway. They point to the contract that stated that both you and they agreed that the specification would describe exactly what had to be delivered.
Specifying software is much harder than specifying cars because in the case of cars the manufacturer know that you need to have turn signals, and they should warn you that you left it out of the specification. With software, the developer will probably never understand the customer’s business as well as the customer does, so he may not realize what has been left out of the document.
The goal of RAPSoD is to eliminate those large spec documents that no-one can fully understand while at the same time making sure that EVERY part of the software solution has been understood by the developer and the client.
Here’s how this is done with RAPSoD
Get Started Quickly
The system designers meet with the stakeholders for one or two in-depth meetings where they gather as much information as possible about their needs. They also collect any existing reports, paperwork, rules, etc. to understand how things are currently being done.
The essence of the RAPSoD system is to start creating mock-ups of the required input screens and reports right away, so that any missing elements or misunderstanding can be fixed very early in the process.
Prototype Everything
The most important element of RAPSoD that contributes to successful projects is that EVERY report and screen is prototyped. By clearly defining every element of the interface, the customer is absolutely sure about what they are getting.
When the screens are created, they are filled with sample data. It is important to understand that the screens are not operational: They are like snapshots of sample screens from the finished product. However, the screens are linked together so that navigation through the application is as similar as possible to the finished product.
Develop the Database at the Same Time
One of the best ways to understand where the “hard parts” of a project lie is to develop the data model for the project. This means that while the screens and reports are being developed, the database structure is being built at the same time. If a report is sorted by Date or by City, where will those fields be stored, what format will they be displayed in, etc.?
The development of the database helps to bring out all sorts of tricky issues, and get them in the open before actual development begins.
Keep the Customer Involved Along the Way
In older types of development systems, the customer wouldn’t see very much until the completed system was ready for testing. At this point, any changes or misunderstandings are very expensive to fix. With RAPSoD, the customer must look at the prototypes as they are being developed, point out changes as required, and check back to view the resulting updates.
While this system works well for almost any type of business software project, it works especially well for Internet/Intranet applications. This is because customers are able to see how things are progressing and how the screens look via a password protected web site).
Don’t Throw it Away
Prototyping is a concept that has been used in the past in software development. There were special “tools” that have been developed for creating prototypes that can be easily modified. Once the customer had approved the prototype, it would be “thrown away”. The developers would start over, developing the final product in the actual system that would be used to deliver the project. The prototyping tool did not allow for the production of the final product.
Newer development tools make it possible to build a flexible prototype in the same tools that the final project will be developed in. This means that nothing is thrown away and therefore the prototype has not added any overhead cost to the project.
What Happens Next?
When pricing software development projects, there is always an issue between the customer and the developer: The customer wants an exact price quote before the project starts and the developer is reluctant, because it’s hard to tell how big or complex the project will be until all the information is known. The RAPSoD methodology gives both parties a compromise that they can work with. Experienced software developers are very good at estimating the “ball-park” for a project. They can tell the customer this is going to be a $15,000 - $25,000 project, or a $100,000 - $150,000 project. Admittedly, these are pretty wide ranges, and most customers are not comfortable with them.
When using RAPSoD, the developer gives a ballpark range as well, and then gives a fixed price quote for the prototype. This is usually between 10% and 25% of the total project cost. So the first example may have a prototype cost of $5,000 and the second one may be quoted at $12,000.
Once the prototype is finished, and the customer is satisfied that the result will meet their needs, a fixed price quote is provided for the entire implementation of the project.
RAPSoD provides the customer with a two stage process that reduces risk by letting them know what they will be getting at each stage, and what the price will be.
At the end of the prototype stage, the customer owns the prototype. If they feel that the application will not really do what is needed, or will cost too much, they can delay or cancel the project at that point with a much lower loss than if they had completed the project.
The customer also has the option of getting other developers to bid on completing the project, if they feel the final quote is too high, or if they are not comfortable with the developers. [NOTE: These options have been available to all of our customers over the years, and none has ever taken us up on it. We have implemented every prototype that we have ever developed.]
When NOT to use RAPSoD
The RAPSoD methodology is not appropriate for every software development situation:
The projects that we have worked on using these techniques have ranged in value from $5,000 to $500,000. The RAPSoD method is one that works very well for projects in this price range because it is very efficient for small development teams (less than 5 developers on an individual project). There are additional, more complex methodologies that can and should be used for larger, extremely complex projects, where the work of many developers must be monitored and integrated.
The problem with the more complex methodologies is that the overhead cost they impose will overwhelm the cost of the actual project for all but the largest systems, making the project too costly to justify the effort. The advantage of RAPSoD is that it adds NO additional overhead to the project.
Conclusion
The benefits of a successful software project can be great, resulting in a significant impact on the bottom line. The risks of a failed or inadequate software project can also be significant – and serious. The RAPSoD methodology allows decision makers to take advantage of the benefits of new solutions while managing the downside risk. This is a methodology that we have applied and refined over a decade, resulting in successful projects that may not have otherwise happened.
Anilet Inc. is dedicated to solving business problems via the effective use of technology. Ruven Gotz, the founder of Anilet has over 25 years experience in the world of Information Technology, with experience in hardware, software, training and management.
To find out more, contact Ruven Gotz at ruveng@anilet.com 416-781-1170.
© 2004 Anilet Inc.