Columnist Tom Mochal receives dozens of e-mails each week from members with questions about project management problems. He shares his tips on a host of project management issues in this Q&A format.

A coworker and I were discussing the benefits of prototyping. We both agree that building a prototype makes sense for many projects. We had a disagreement on the time to invest building the prototype. My friend says that you want to get as much value as you can as quickly as possible. He advocates spending very little time on a prototype, so that you have wasted as little time as possible once the prototype is thrown away. I advocated spending more time on the prototype and possibly using the prototype as the basis for the actual solution. What are your thoughts on the question of how much effort to apply to a prototype?

—Glenn F.

A prototype represents the shell of an actual production application. Prototypes are built early in the development lifecycle and they are used to provide valuable insight into look-and-feel, and the general workflow of an application. (Sometimes people call the first production implementation a prototype, but that is not correct. If you have multiple implementations, the first one is more aptly called a pilot.)

In a traditional waterfall project, we move from analysis and design, to coding and testing. The first time the clients have a chance to look at an application is typically during the integration and system testing. If the business requirements are well understood up-front, this approach can still make a lot of sense. However, on a typical project, the client does not always know exactly what they want ahead of time. In this case, it can be very valuable to gather an initial set of requirements and then build a prototype that the client can see. The client is then in a much better, and earlier, position to tell you what they like and don’t like. Based on that feedback, you could begin to build a production application, or you could enhance the prototype a second (and third) time to hone the requirements in even finer detail.

Prototypes start off as empty shells
Prototypes are typically a feature of an online application, since they allow a client to visualize what the final solution could look like. The prototype is a shell that contains the online screens. There would be very little programming of the core business processes. The user would have a screen that they can use to input information. The logic would then go to the next screen(s), passing whatever information made sense. User input could just be ignored, and screen values might be hard-coded, rather than require a database call to a table that may or may not exist yet.

Prototype guidelines
Here are some guidelines that will help you understand how much effort to put into building a prototype.

  1. You need to build the first prototype quickly. I think this is a pretty hard and fast rule. The purpose of building a prototype is to get something in front of the clients as quickly as possible. This philosophy is defeated if your prototype is very elaborate and you build lots of the core logic. If you do that, you have invested too much effort in case the client does not like the direction that the prototype is taking.
  2. Typically, if you were using a traditional waterfall approach, you would not need to build a prototype. However, if you do, I think a safe approach is to plan the project as if the prototype is going to be thrown away. But when you actually build the prototype, do it in such a way that much or all of it can be reused in the actual production application. I have seen applications where the development team built a prototype that convinced the client that they were moving in the wrong direction. The specifications were all updated accordingly, and the prototype was thrown away. I have also seen projects where the prototype solution was close to what the client wanted. Some tweaks were made to account for new requirements, but the prototype was then used as the basis for building the complete solution. In this case, the prototype worked double-duty, and the project could be completed earlier than planned.
  3. If you are using a Rapid Application Development (RAD) approach, the first prototype should still be put together quickly, but more and more work needs to go into subsequent versions. When you use RAD, you need to build the prototypes with an understanding that you are incrementally building the final solution. Therefore, your approach to design and architecture must be flexible enough to change and build upon. If you have to throw away a RAD prototype, I think you are defeating the purpose of using that approach.
  4. Document as you go. Sometimes a development team thinks of a prototype as a way to document the requirements. I tend to see a prototype as a way to gather requirements. If you build a prototype based on an initial set of requirements, you will show it to the clients to validate what was done so far and to gather additional feedback. When you get that feedback, you should document it, the same as you do with the more traditional requirements-gathering techniques. If you don’t, you will still be susceptible to the typical communication mix-ups and misunderstandings.

Glenn, I think I provided some insight into your question with the second and third points above. If you build a prototype as a part of a traditional waterfall project, you should probably plan to spend as little time as possible on it. The purpose is to give your clients a quick peek at what the solution would look like, but the general thought is that the prototype will then be discarded. (If you can subsequently use it as the basis of the final solution, then great.)

On the other hand, if you are using a RAD approach, I think you definitively want to take more time on the up-front and subsequent prototypes, since you are building the solution through subsequent iterations of the prototype. The last prototype is basically the production solution.

So, depending on the type of project, you are both correct.