Rapid Prototyping
Rapid or "evolutionary" prototyping is another effort to overcome the difficulties of the linear approach. Essentially it says, forget all that up-front documentation and, working with the users, get right into the development. It is also known as "Joint Application Development". The idea is to talk to the customer, build a prototype, display it to the customer, get their reaction and modify accordingly. Repeat the process, correcting errors and gradually adding functionality, until the customer is happy with the product. The underlying concept is that it is more time and cost effective to work with the product than to spend it getting the requirements documentation exactly right.
Good features
- The cost of intermediate deliverables is eliminated because time is spent on creating product rather than a lot of paper.
- Software development documents are difficult for users to interpret anyway. This is unlike architectural building design and working drawings, from which most people in the construction business can get an idea of what the constructed work will look like.
- Right away, you get the programming team working „ and enthusiastic.
- You bypass the business of establishing accurate project assumptions.
- Direct user involvement leads to a high level of "buy-in", even to the extent of overlooking some things they may not like.
- Thus, user "requirements" evolve as the project progresses.
Not so good features
- No one knows how many build-and-display cycles will be required.
- Hence the approach is difficult to plan and establish a schedule and budget for executive control.
- The approach breaks down when large complex systems are involved where many development teams may be involved in the entire system.
- It may also break down where many different stakeholders are involved.
- In the end, all you may end up with is still a prototype.
- It is difficult to bring the project to a close because there is always the temptation "To do just one more cycle."
This looks like a good practical technological approach and works well provided that money for the work is plentiful. However, from a project management perspective, the customer may never be satisfied, and the project just never ends because the project manager has no leverage to make it so.
The short-comings described all represent serious project management schedule and cost risks.
|
Introduction to Part 2
