Small vs. Big: Highlight of Main Differences:
On the whole, it’s not a question of which method, level of fidelity, or orientation but to what proportion of each used within a project. It’s unusual for a project team to be exclusive to one method in completing an objective. It is from this aspect of prototyping that the main difference between small and large projects can be determined. Smaller projects are more likely to lean on one form of methodology, whereas larger projects are almost certainly going to use a hybrid of prototyping techniques to accomplish set goals. In the future, both smaller and larger projects may begin incorporating the currently disruptive operational prototyping methodology which is simply an overlapping rather than a simple collaboration of either approach. Operational prototyping is still nascent as there is a higher demand for more coordination between design and management teams as well as more demand for innovative project management. [9]
As well, from a more general perspective, failure as a learning tool has a stronger place within smaller projects than larger endeavors. The lack of resources and time within smaller projects fits comfortably with trial-and-error rapid prototypes doled out in express fashion. Rapid prototyping has a weaker position within larger projects due to the higher chance for inefficient code being reused in primary prototypes or the final product itself. [2] That isn’t to say that prototype failure has no place at all within large projects, but that they play a secondary role instead. In smaller projects, they help foster ideas and general concepts needed going forward with functionality and/or user interaction testing.
In respect to fidelity, smaller projects typically involve prototypes of lower fidelity whereas large projects will enlist prototypes with a wide range of fidelity. Small projects involve lower fidelity due to the interconnected reasons of smaller budget and the rapid prototyping methodology that works as an adaptation of that smaller budget. Large projects, on the other hand, will use prototypes ranging from low to high fidelity, not solely due to the better access to funding, but because of the higher complexity usually associated with the needs of larger projects. [4]
Already inherent to the aspect of project size, is the likelihood of issues increasing with the size of a project. Parallel to this, prototypes not only give significantly more problems as they increase in size but also as their respective projects increase in size. Basically, prototypes, if not properly managed, will compound issues within a project rather than alleviate them as per their original purpose. [12] In one case study a project “exceeded the original budget by requiring almost 300% more man-hours than expected and the time schedule was exceeded by 15-20%.” [12] Granted the escalation in project scope within this case study was due to mishandling of the prototype process rather than the prototypes themselves. The potency of this issue primarily resides within large projects. To that effect, smaller projects face fewer risks as there is less coding and design mistakes to accelerate the issues at hand.
Prototyping as a form of communication is useful to a project regardless of its size. However, the necessity of communication is better served within larger projects. Prototyping complements large projects with a model or series of models that works as an outline for the project at large. [15] These can help group members of different roles and different cultures better communicate with each other. As a communication tool, prototypes do have a role in small projects but mainly as an interlocutor between the design team and users. [15]
The Link between Small and Large Project Prototyping:
In spite of differences in finances and workforce, projects of different sizes are linked by some commonalities in prototyping. Both small and large projects involve varying orientation. This is perhaps based on how vertical orientation within prototypes compliment horizontal orientation and vice versa. [12] Many projects, independent of size, are typically going to want to test both a system’s front-end as well as the back-end of prime subsets. Differences in orientation between small and large projects often occur when orientation overlaps levels of fidelity.
Another similarity is the prevalence of the evolutionary technique within projects big or small. [14] Tor Guimaraes states that approximately two-thirds of companies within his study were moving towards the non-disposable or evolutionary prototyping methods. [11] Given the dynamic and versatile aspects of evolutionary prototyping, it often serves as a main engine for testing within various projects. It is a technique that can be carried out rapidly within the confines of a smaller project while also being a bigger conduit for more complex prototyping in larger projects. Despite the higher level of maintenance required, the benefits are strong enough to warrant it in any project. [2]
For better or for worse, prototyping’s effect on the relationship between users and the design team is also independent of project size. Research that looked at 12 software development projects of varying size highlighted the link between prototyping and user/designer relations. [21] The research had shown from a positive angle, prototyping fosters better feedback from users, serves as a conduit of communication, and builds user confidence. [21] Alternatively, prototyping can over-inflate user expectations and result in an abundance of unrealistic user requests. [21] Indeed, users can misinterpret both the level of completion of the product as well as the speed of its development from a misunderstanding of the prototype’s inevitably different dimensions. [15] These attributes were consistent with all twelve projects regardless if it were the $5000 accounts receivable project of 3 person-months or the $630,000 chemical product cost/reporting project of 88.9 person-months. [21]
Outside the aspect of user interaction, users in themselves were indispensable to either small or large projects. A positive correlation was found between the number of users and the success of the project regardless of its size. [8] With proper interaction, users will inevitably enhance any project regardless of their parameters. [16]
Recommendations:
While different tendencies exist between different sized projects, there are areas that could be improved on as organizations develop products in the near future:
[2] Hekmatpour, S. "Experience with Evolutionary Prototyping in a Large Software Project." ACM SIGSOFT Software Engineering Notes 12.1 (1987): 38-41. Print.
[4] Arnowitz, Jonathan, Michael Arent, and Nevin Berger. Effective Prototyping for Software Makers. Amsterdam: Elsevier, 2007. Print.
[8] Hardgrave, Bill C., Rick L. Wilson, and Ken Eastman. "Toward a Contingency Model for Selecting an Information System Prototyping Strategy." Journal of Management Information Systems 16.2 (1999): 113-36. ProQuest. Web. 14 Nov. 2013.
[9] Davis, Alan M. “Operational Prototyping: A New Development Approach.” IEEE Software (1992): 70-78. Print.
[11] Guimaraes, Tor. "Prototyping: orchestrating for success." Datamation 1 Dec. 1987: 101+. Business Insights: Essentials. Web. 18 Oct. 2013.
[12] Granlien, Maren, Pries-Heje, Jan, Baskerville, Richard. “Project Management Strategies for Prototyping Breakdowns.” Proceedings of the 42nd Hawaii International Conference on System Sciences (2009): 1-10. Print.
[14] Budde, R.; Zullighoven, H., "Prototyping revisited," CompEuro '90. Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering , vol., no., pp.418,427, 8-10 May 1990.
[15] R. Van Buskirk, and B. W. Moroney. "Extending Prototyping." IBM Systems Journal 42.4 (2003): 613-23. ProQuest. Web.
[21] Alavi, Maryam. 1984. “An assessment of the prototyping approach to information systems development.” Communications of the ACM. ACM 27.6 (June 1984): 556-563. DOI=10.1145/358080.358095 <http://doi.acm.org/10.1145/358080.358095>