Coping with Change
October 28, 2009One of the great things about software prototyping is its responsiveness to change.
Oftentimes, changes are requested without enough thought being given to how those changes might be received by the people who will use a system. The Requirements Prototyping approach allows our prototyping analyst to get involved at an earlier point to help establish the suitability and impact of a change before that change is given the green light.
So, when a business stakeholder comes in and tells you that he thinks the order screen now needs to use tabs rather than accordion-style panels, it’s not a huge effort to be able to put a prototype together to let him try it out ahead of that change being added to the project. The activity of building a model of the change focuses our minds on the impact of a change, and we can feedback realistic development estimates into the project planning. Tweaks to the proposed design are quick to make and the feedback cycle with the stakeholder is short, allowing expert design input to help influence and inform the business decision-making process.
Sometimes, after creating a prototype of a proposed change, we’ll collectively learn enough about it to reject it; on other occasions it might need refinement or even trigger additional change. What’s great about Requirements Prototyping is the way that it brings the various parties together in this process, allowing each individual to feel that their voice is being heard. This has a motivational kick to it too, and fosters additional ‘buy in’ from those involved at all levels.
Change is inevitable – it’s the pulse of business and something we can’t avoid. Better then to choose techniques such as Requirements Prototyping which allows us to handle change in a positive way.
