Proof of Concept: Benefits & Risks of Prototyping in Business Analysis
/I once worked on a project that involved a series of discussions and consultations on whether to build or buy software. After extensive analysis, the decision was made to build the system in-house. To get started however, we had to prove that it could be done. We did this through a proof of concept (POC).
A proof of concept (POC) is a demonstration aimed at verifying that certain concepts or theories can be achieved. A prototype is designed to determine feasibility, but does not represent the final deliverable.
Having a working prototype assisted the team in visualizing requirements and refining unclear areas. We were able to deliver the prototype, identify its shortcomings and experiment with it until we had something functional. Subsequently, we organized demonstrations with stakeholders as a way of saying, "Yes, we can".
Developing the POC system with key functionalities successfully gave everyone the confidence that we could deliver the goods. The POC system also gave us the opportunity to carry the users along by communicating what the final system would like. According to Eeles' 2006 paper, design mistakes are cheaper to fix earlier in the lifecycle than when detected further down the road. The POC system gave us a chance to understand the capabilities and limitations of our system and thus select only the processes that could quickly be automated, with minimal development hassles and quick business returns.
A POC is a prototype and does not represent the final deliverable; it is usually delivered quickly and without extensive testing. Though some advise that the POC system be thrown away and the real system built from scratch, our POC system was refined and evolved into the final system.
There is some advantage to moving beyond a paper prototype to a “working model”. This working model may be considered crude or incomplete (since it is often created speedily) but it does have the key capability to highlight the most important characteristics of the system.
People use prototypes for different reasons. While some use it for elicitation and validation, software/hardware evaluation or facilitating user involvement, we used it majorly to demonstrate our competence to develop software.
How do you define a prototype?
A prototype is a small-scale, incomplete but working version of a system.
It is usually devoid of finer touches like error checking, input data validation, security, user help menus and the like. Prototypes are built using rapid application development tools because project teams are often faced with schedule constraints and need to deliver prototypes quickly.
So, if prototypes are so great, what are the cons you should be aware of?
Users may focus prematurely on design issues instead of functionality. Prototypes can also create a premature commitment to design thereby eliminating creativity. Prototypes can prevent designers and users from coming up with alternative ways in which the final system can be represented.
Users may also be led to believe that the real system can be completed just as quickly. The analyst should always be prepared to manage user expectations concerning the length of time it would take to develop the real system.
Prototyping is also prone to scope creep. How do you know exactly when to stop?
Caveats
Prototypes do not negate the need for extensive systems analysis; a prototype can still solve the wrong problem if proper analysis is not done from scratch.
You still need specifications to develop a prototype. The software, in our case, could not have been developed without a specification. Prototypes are only a complement and not a complete replacement of recommended development practices like written specifications, though the level of detail in the specifications may vary.
Prototyping should not replace model-driven designs. Models and design should be done before prototyping in order to guide the development of prototypes.
Design by prototyping does not fulfill all user requirements. The analyst still has to specify performance criteria, storage constraints, security details and critical non-functional requirements.
So, if you’re faced with a new technology and you’re uncertain of its feasibility, why not prove that you can by using a POC?
References
Eeles, Peter, "The Process of Software Architecting" . April 15, 2006.
