“Do you understand?”
It’s a simple enough question, but yet stakeholders and development teams consistently fail to adequately answer it during project development.
Too many projects fail because the stakeholders, business analysts, and technology team all have a different vision of the project requirements. Every participant of Information Concepts’s Requirements Roundtable had been part of several long, costly, and emotionally draining projects that were severely delayed or even failed because of miscommunication in defining the requirements. They were keen to learn more about visualization tools, which can help everybody involved in a project see the same software solution, before writing any code, making the process clearer, faster, and more affordable.
A representative from a public institution kicked things off with a situation everyone at the Roundtable had experienced, “people come knocking on my door after projects are underway,” looking to clarify or change requirements that should have already been defined. Nods went around the room and a few shared anecdotes of drastically increasing the price of a project just to make what seemed to the shareholders like minor changes.
Wayne shared similar experiences that led him to create the presentation, “Getting the Requirements Right…The First Time,” which drove the discussion for the Seminar. One of the points that had heads nodding early was pointing out that IT is the only industry where out of Timeliness, Quality, and Cost, customers are told to “pick two.” A representative from a consulting group said that he’d often heard development teams say to pick just one – a ridiculous and unacceptably low standard.
In the second half of the presentation, a representative from a company in need of better inventory management presented a project in need of an IT solution and Wayne mapped out the requirements on a white board, while Colleen used a visualization tool to create a prototype on the spot. The representative (like a true stakeholder) requested several design and functionality changes before arriving at a reasonable image of what she wanted. Colleen used the tool to produce a requirements document, including screenshots, notes, and exceptions. The entire process took less than ten minutes.
One of the consultants commented that “in the old days, this would have taken a day…if I could have gone in with a presentation and showed them what it would look like, it would have saved so much time.”
Another participant, who already has a lot of recent experience with visualization tools, said that his clients often mistake the visualization for a live product and, in concurrence, Wayne showed an example of a completed project that looks alarmingly similar to the initial visualization.
Dave from Information Concepts pointed out that visualization “gets you to the no surprises point between prototyping and testing,” while keeping the stakeholders involved.
It might have been the first time a group of developers was so excited about the prospect of stakeholder involvement.
If you are interested in scheduling a requirements presentation with the Information Concepts team, please contact Jack Fischl at email@example.com