Prototyping a Solution

Many times a client cannot visualize what the prospective IT system or product will look like until the very end of the project, and this logic leads to changes to the solution, making things complicated for all parties. It is, however, common practice for a project team to develop a prototype or demonstration model of the IT solution early during the design phase.

It may also be the case that the project design team needs to understand the solution, and insist on building a prototype before committing themselves to the project. Prototyping activities usually begin during the (a) requirement or (b) initiation phase and are usually finalized by the end of the design phase.

A prototype is an early exploratory model of the software solution that contains enough capabilities for use in establishing or refining client requirements. It even solves many of the development problems, and by the time the actual development begins, the process is much easier to understand. When developing a prototype model of the proposed system, the project manager must ensure that the prototype reflects the true environment in which the solution will be implemented. The technique used to start the development of the prototype is called rapid application development (RAD). Some of the immediate benefits of prototyping a solution for a client are

• Higher acceptance level from the client

• Client involvement from day one, thus improving relationships

• Restrictions of constant changes downstream (as in a conventional project)

• The client becomes familiar through knowledge transfer

I WISH I HAD KNOWN THAT

There are several precautions that project managers can take to help make sure that the project will reach its fullest potential. Project managers can keep the schedule up-to-date and make sure it reflects the latest design changes. They should be aware that working with new or unfamiliar technology makes estimation less accurate. They should be sure that the scope of work is very clearly defined and agreed upon before doing the work. There should be clearly defined functionality and quality requirements, as well as agreement about the cost for delivering against these, adjusting as appropriate. If major changes to the project are the result of outside influences (e.g., market changes), then it is essential to review the business case for any change in approach. The following are some useful tips that will help project managers detect early warning signs that a project is unlikely to deliver the business benefits.

• Users and project managers do not know (or do not agree on) how every part of the solution will be used to deliver business benefits.

• The project sponsor, business managers, or project manager are not clear about mutual responsibility and accountability.

• Plans do not include sufficient time to carry out the appropriate business analysis of risk.

• No plan exists for accommodating scope change or new requirements.

• The scope for the work is incomplete, hence scope - creep, which increases the time and cost of delivering the solution.

• New functionality simply does not work, and time and cost increase as effort is expended to make it work.

• Insufficient time, money, or resources are allocated to the project.

0 0

Post a comment