I read an interesting article today which broadly considers the use of prototyping in a data-centric context (ERP systems).
As mentioned previously, software prototyping tends to lend itself more readily to visual, interactive systems, but can be used effectively in the design of data-orientated systems such as ERP. I thought I’d pick up on a few points to link them into a requirements prototyping context, and expand with my own thoughts:
If you’re the project manager waiting to show executive management that “quick win” from your project, there’s nothing like a performance report out of the prototype, formatted exactly with your data and their requirements, when management thinks you’ve barely started on the project.
Whilst I agree with this in ‘spirit’, in practice this can be risky as management may not always appreciate the difference between a prototype model and an actual built system. They may jump to conclusions about your ability to deliver, and their expectations may then be unrealistic.
There is a lot of information available on Choosing the Right Software. The clincher, the decision maker, should be the prototype. Before 100% commitment to the software purchase, before all personnel are trained, and before processes and customized components are re-designed, we advocate the prototype.
Absolutely right – the prototype serves as a conduit to consensus, and ensures everyone who is involved in a project understands what it is that is being developed and agrees on its form and function.
So how do you balance the value of the prototype with its cost? Choosing the size and makeup of the subset of data for the prototype is a first step. Too much data slows you down; too little data misleads you if something significant is missed. A subset of data makes your prototype nimble so you can test alternative settings quickly.”
Once again, a good observation. We call it ‘responsiveness’ – in other words, a ‘responsive’ prototype being one that minimises the delay between idea and realisation of that idea into a prototype. By being ‘responsive’ one can work much more closely with our business stakeholders and refine ideas much more quickly and accurately, with far more timely feedback.
we’ve developed unique prototyping concepts that help us lower the cost of an implementation so much, it’s obvious the prototype pays for itself. You avoid missing the details; you can re-use the prototype for part of the live implementation
This is exactly what we’ve been preaching here all along – the power of prototyping is that it brings overal savings, and allows us to deliver projects more effectively. However, re-use of the prototype is a contentious issue: I’d stress that the very things that allow ‘responsiveness’ in a prototype are the same things that may fundamentally flaw a ‘real’ system if built upon the foundations of a prototype. It’s certainly possible to do so, but often the effort involved to shore-up the foundations of the prototype to production standards outweigh the benefits, and whilst we love prototyping-directed design and implementation, we wouldn’t want to jeopardise the actual build by using a prototype as a foundation unless we were totally comfortable with the risks involved and the effort required.
It is great to see the principles of prototyping being used outside of the mainstream ‘interactive’ model, though, and we hope to be able to follow up on this at a later date.
