Rapid Prototyping Or Simply Over-hyping
Author - Joseph
- November 1, 2003
Installing software using the rapid prototyping technique offers significant benefits. Results are realized sooner. You are able to visualize the working software early on in the process. A project can be divided into more manageable, doable pieces.
depicted in the model (Figure 1), in the best of all worlds, rapid prototyping
should deliver benefits quickly without extending the life of the project. So
why isn't rapid prototyping the de facto implementation practice of choice?
Rapid prototyping requires unique attributes of the project sponsor, the project
team, and the user community. These attributes include full accountability,
environmental conditions, understanding the process, and user expectations.
Knowing the impact of these attributes on a project can help you evaluate the
effectiveness of rapid prototyping for your organization.
Having someone in charge is important to any project but even more so with rapid prototyping. We are not talking about the project manager, who is responsible for executing and monitoring a plan. Rather, we are referring to the project sponsor, who is the single focal point and 100% accountable for the success of a project.
Whether motivated by a bonus, meeting a MBO (management by objective), or just the desire to succeed, the project sponsor must be empowered and able to make the hard decisions. This individual must be able to keep the project on target toward meeting its immediate short-term goals without being temporarily detoured by the ultimate destination. Accordingly, the sponsor must be able to make trade-offs between time to complete, availability of resources, intended capabilities, and perceived benefits. For example, a sponsor can have resources shifted from another project; can hold the line of the capabilities to be delivered with the first release; and can define realistic, tangible benefits, as in dollars and cents, to drive home the completion of the project and clear away obstacles.
Do not underestimate the difficulty of this role. Typically, effigies of the sponsor are strewn in the hallways and, like famous artists, sponsors are only appreciated well after a project is completed.
because of the narrowness of the scope and the short duration of the projects,
determination of the functionality of prototype software is greatly influenced
by environmental conditions. Accordingly, first you must gauge how long the
environment will remain stable. Six months? Nine months? Then, you can assess
what can be accomplished during this stable period. Because of a somewhat short
period of stability, the long-term vision must be created rapidly and put into
action even quicker. Hence, less planning and more doing. Be assured that change
is inevitable. The best we can do is estimate the period of stability, maximize
what we can complete in this period, and hang on for the bumpy ride.
that you need to know what you are about to do seems somewhat obvious. Knowing
how you are going to do it is another matter. Violation of this concept is tantamount
to knowing that you are about to shovel a driveway but have only a spoon to
do it with. It's a matter of understanding.
Rapid prototyping is an iterative process that the project team and user community need to understand to avoid frustrations and disappointment. In rapid prototyping, the software being placed into production is typically only the initial release, thereby satisfying the short-term objectives of the organization. The project team should not consider their jobs done just because a system is running. Nor should the users think that the functionality presented by the software is what they have to live with. After you have rapidly created the long-term vision and assessed the stability of the environment, in prototyping you must:
Define the scope based on the timeframe allowed.
- Put what works
- Fix the minor
bugs and imperfections.
- Repeat the
While there may be a temporary lull in the implementation frenzy, the project team should not be disbanded and the party favors should be put on hold. Because of the smaller project scopes, in prototyping less time can be spent on planning and more time on doing. The Type A personalities can finally come out of the closet. While maintaining a glimpse of the ultimate goal of the software, the project team and the users must understand and stay focused on achieving the short-term and more immediate functionality gains. If they don't, it's like the soccer player who gets excited by seeing the open goal before securing control of the ball. The project will not be successful and the shot will be wide.
Two universal truths of software implementation projects are: (1) Users do not know exactly what they want and (2) Users want everything now. The first statement actually works to the advantage of prototyping. This is not to suggest that it is OK for a user not to have a concept of the required functionality of the software. However, working with a sketchy outline of the requirements, progressive stages of prototyping can bring the requirements into focus and avoid locking into a position that could take time and resources to undo.
The second truth can cause problems for prototyping projects. If the user's appetite for functionality cannot be curbed, you will not be prototyping. Furthermore, you will most likely not make your schedule and short-term deliverables. As IT professionals, we can bring this on ourselves. The users' perception is that, once the project team completes the first phase, nothing else will get done. IT will be enticed by the latest and greatest technological advancements. Users need to be assured that this will not be the case although past history may make this difficult to accept. If the users are to stay the path with prototyping, so must IT.
In prototyping, the user requirements are analogous to having a blueprint for a house. Starting out, you need to know the location and dimensions of the rooms but not necessarily the color of the rugs, lighting fixtures, or placement of the electrical outlets. Nailing down the specifics of the placement of fields on an order entry screen can be appropriately done in prototyping. Knowing which fields are required should be determined beforehand. Finally, users must be confident that their vision of the application will be realized even if they accept an interim process. For example, they can go live on an order entry system with single tier pricing, knowing that promotional pricing will be available in the next release by an agreed upon date.
Rapid prototyping offers significant advantages when user requirements are not fully defined and interim results are needed sooner rather than later. However, unless this type of project has strong leadership and the project team and users have a complete understanding of the process, disappointments may be significant and could sound the death knell for future prototyping projects. Some warning signs of a rapid prototyping project going a stray are:
Designing never stops.
Prototyping never ends.
User wants it all now.
IT cannot help itself; the tinkering syndrome.
Nothing gets implemented into production.
And finally, the never-ending work in process.
If you are considering using rapid prototyping for the first time, consider a business area which has ample low hanging fruit. In so doing, you will be able to evaluate the merits of the process and not the difficulty of the solution.
I would be interested in hearing about any prototyping success stories and what you did to meet your ultimate software objectives.
J. Strub has extensive experience as a manager and senior consultant
in planning and executing ERP projects for manufacturing and distribution systems
for large to medium-size companies in the food & beverage, chemical, and CPG
process industries. Additionally, Mr. Strub was a consultant and Information
Systems Auditor with PricewaterhouseCoopers and an applications
development and support manager for a Fortune 100 company.
can be reached at JoeStrub@writecompanyplus.com.