About Us
Site Map
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Contact Us



Software Prototypes

Prototypes are used to test or prove a wide variety of products. The classic example is the car prototype which automakers use to test acceptance of various design innovations on the car buying public. While automakers use prototypes to test marketability, many prototypes are used to test design feasibility and learn things about building them that will help the manufacture process should they wish to produce the prototype. Software prototypes can be used to prove both marketability and feasibility, although the market the prototype is tested on is normally restricted to groups within the organization.

Don’t confuse a prototype with a pilot project. Prototypes are used to prove a concept, usually a technical or commercial one, while pilots are used to prove the delivery method. The concept cars auto makers show at car shows are a good example of prototypes, while the 10 Apollo missions which preceded the successful moon landing of Apollo 11 are good examples of pilot projects. Pilot projects can be used to prove a project approach and a technical concept but there is no direct connection between the two.

A software development project that includes a prototype as a deliverable will have plans for how that prototype is to be used and the building of the prototype will be a part of the design phase, or implementation phase of the project. User feedback will be used to refine the design of the final application or system before the actual build phase of the project.

Prototypes can be a great way to improve software development project results on two fronts: they can prove a software concept or improve on it, and they can teach the team valuable lessons about the best ways to develop the software system. Not all software development projects will be helped by producing a prototype however. The first step in determining whether to build a prototype or not is to determine how it would help the project.

Determining the Need

Software development projects which deliver new, custom, systems are prime candidates for prototypes. Let’s take the example of an automated order entry system which will replace an existing paper based system. The order entry clerks will use the system to enter orders into the system via a PC and the new systems order entry screens. Order takers downstream will be taking the orders from the system using PCs and their order processing screens. Your team has gathered all the requirements for the system, including the speed at which the clerks enter the order and the speed at which the order takers process the order in the system. This set of requirements will tell you the information that must be captured on the order entry and order processing screens and the information that is to be displayed to the order processors. These requirements are clear but what isn’t clear is the graphics that should display the information and how the information should be arranged on the screens. A prototype which will capture information from the order entry screen, display it on the order processing screen, and accept the keystrokes which will process the order can help the team determine the best layouts and graphics.

You are only interested in the effectiveness of the screens that your two groups of users will see in the example above. Screens don’t need to be functional to ascertain their effectiveness (beyond inputting data). This will allow the project to restrict development activity to a few screens and functionality to capturing and storing the data that is input and still obtain all the information they need to develop a system that will meet the project’s goals and objectives and be accepted by the user community.

Prototypes may also help development teams to determine the most efficient techniques and tools to use in development. Let’s stick with our order entry and processing example. This time, instead of creating an automated system to replace a paper based one, we’re leaving the screens in place and replacing the database and platform the system runs on. The current system supports a variety of orderable products which require different information to be captured and processed, depending on the product. A prototype will be useful for proving functionality can be reproduced efficiently on the new platform and learning the best development and testing techniques. This prototype should take a vertical slice of the functionality and reproduce it on the new platform, say taking the order for one product and processing that order.

The system won’t appear any different to your user community so engaging them for the prototype isn’t necessary. Your prototype must prove that the team can create the required functionality on the new platform and that the functionality is at least as responsive as the system being replaced. Your prototype should also provide you with information on the best techniques to use for development.

Prototypes can be useful for learning about new user interfaces, new systems, new software platforms, or new functions. Avoid using prototypes where you wish to learn the best approach to take to development or in projects that add to an existing system.

Designing the Prototype

Your prototype should be designed to meet a specific set of goals and objectives. Defining the screens or functions it should contain is not sufficient. Goals and objectives should include:


  • Measuring user acceptance (screen layouts, etc.)

  • Identification of required changes to interfaces or functionality

  • Identification of best practices for design, build, and test

  • Performance measurements to prove/disprove software approaches

Training for any new technologies or tools used. The training referred to is in-house training, not vendor training

The above list is not meant to be a complete menu of goals and objectives and you probably won’t need to meet every one of these in every project.

Choose the best set of screens to include in your prototype so that you get the maximum benefit from user testing. For example, where logging in is required across a wide selection of screens, include at least one with that function. The goal here is to produce a system with the fewest surprises for your user community. You may also want to choose screens that implement the most complex concepts.

Decide on whether you need to prove build methods or performance, or both, in your prototype. Proof that the new system can handle the transaction volume required and perform at the required speeds may be a priority, in which case the functions you choose need to demonstrate this. Choose the most commonly used functions in this case. Choose the simplest, least complex functions when you need to determine the best development approach and tool set. This is particularly important if you are dealing with a team with no practical experience working with a new platform. Choose the most complex and difficult functions for the prototype in the case where you are looking to learn the best practices for development and have an experienced team.

The prototype must be carefully chosen to fit the system architecture where that prototype will be used in the final product. This may mean that the prototype must deliver the core functionality upon which the rest will be built (e.g. transaction processing, messaging, etc.). Consult with the architect for the new system on the decision. They should be able to direct you to a core set of functionality that can stand alone, meet the goals and objectives set for the prototype, and be re-usable.

Building the Prototype

Start by choosing the right software development methodology for building the prototype. If your prototype will only consist of a few screens without functionality it won’t matter what methodology you choose because the build time and effort will be negligible. Choosing the right methodology becomes important when the build will require significant time and effort. Building the prototype will be a different activity from building the production system so doesn’t necessarily have to use the same methodology as that chosen for building the production system. There are 2 methodologies that lend themselves to developing prototypes because of their focus on rapid delivery and learning from the build: Srum and RAD (Rapid Application Development).

Scrum relies on an iterative approach to development, where the iterations are called "sprints”. Scrum also has no place for a project manager so you can hand the responsibility off to a senior developer or analyst who is called the Scrum master.

RAD is particularly suited to developing prototypes because the methodology is based on using a prototype. RAD is based on prototyping and modeling replacing an intensive requirements gathering phase. RAD works best where the development teams are relatively small. Since you won’t have the entire development team on board at this point, RAD is particularly well suited for the purpose.

Quality Assurance should be a part of the prototype build. Building a prototype which cannot be manipulated by the user community will add unnecessary time and effort to the project, frustrate the user community, and end up prejudicing the stakeholders against the project. Developer testing and system testing should utilize the tools and techniques established for the project. You may acquire a testing resource or two from your QA group or assign the QA function to a developer on the prototype team. Test cases should simulate the way the user community uses the system and exercise all the screens, fields, and functions in the prototype.

The prototype should be delivered to schedule. If building the prototype exceeds the schedule a root cause analysis should be performed to determine the reasons for the delay. Reasons may indicate a different approach to development, or that original estimates for the effort are inadequate. The reasons will trigger changes to the project plan in either case.

There are companies that specialize in building prototypes to order. Prototyping is a core competency for these companies so you may want to investigate outsourcing the build of the prototype to a company that specializes in building prototypes on the software platform you are using for your project. Your "build or buy” decision should be made using the best Procurement Management processes described in the PMBOK® Fourth Edition. Learn about these best practices by taking a PMP® Course or other PMP® Exam Prep training, then passing your PMP® Exam for your certification.

Prototype Delivery

The prototype should be subjected to User Acceptance Testing, or QA testing, or both. QA testing should precede User Acceptance Testing where both are indicated. User Acceptance Testing should provide a feedback vehicle and narrative type feedback, including suggestions for improvement, likes and dislikes. QA testing should be done using the test suites and test cases designed for the prototype during the build phase. These tests should include performance tests which will measure the prototypes ability to perform at the benchmarks established for it. This testing may require special tools or environments to be available for load, stress, and performance testing.

User feedback should be collated by screen and function (where a screen is shared by more than one functional group) to help with analysis. Systems analysts should exam the feedback and make changes to the screens as appropriate. The feedback should also be evaluated for its implications for screens not in the prototype. Common functions such as the login feature may need to be altered on other screens as the result of user feedback on the prototype. You may want to conduct a second iteration of testing to prove the changes. Don’t plan for more than 2 iterations of UAT.

Use the projects issue tracking/bug reporting system to capture test results from the QA team. A failure of a test exercising prototype functionality should be corrected and the test re-executed. A failure of a test for performance, stress, or load should be analyzed for its implications. The fix to correct the failure may be simple, in which case it should be made and the fix tested. On the other hand, the fix may be very complex, or even impossible. There are companies that offer UAT services for prototypes. You may wish to outsource UAT to a company specializing in that area if you have difficulty rounding up actual users or you are prototyping a commercial web site.

The implications should be examined in this case. Can the fix be implemented in the prototype and still allow the project to finish on budget? Is there another way of building the system which would avoid the problem? Does the problem have any implications for the functionality not delivered by the prototype? The answers to these questions will have a bearing on whether the project is to proceed to the next phase.

The issues, problems, and learning derived from building the prototype should be gathered and analyzed by your systems analysts for their impact on the development phase. The results of the analysis should be an input into the planning process for the implementation phase of the project. Look for indications that additional tools need to be purchased or existing ones replaced. Examine the results for their impact on effort estimates for the rest of the development and testing tasks in the project. Learning from the prototype may indicate that building the system is indeed feasible but the cost will now exceed the benefits so rewrite the business case based on any implications for project costs.

Your prototype has gone through QA testing and may have also gone through UAT. You need to ensure that work isn’t duplicated so will need to indicate the software has been tested before archiving it, if your prototype will now become part of the new system. You’re now ready for your "go/no go” decision on whether to proceed to the implementation phase of your software development project.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP® courses and other PMP® exam preparation training products. If you haven't been certified as a PMP® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.