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
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.
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.
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
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
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.
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.
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,
Identification of required changes to interfaces or functionality
of best practices for design, build, and test
measurements to prove/disprove software approaches
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
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
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
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
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
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.
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
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.