It's a scenario that has become all too familiar in many companies. After months or even years of work, the IT shop proudly presents a new application that the designers and architects believe exactly meets the business requirements provided them. Then end users tell them, "This isn't what we asked for."
One of the most common causes of such costly quandaries is a disconnect in the requirements process when user needs are not accurately relayed to the designers and developers. The quest to bridge this gap spawned an entire industry of vendors building tools that can better interpret requirements and ensure that they are infused into various cycles of the development process.
Some companies are opting for another alternative. For example, United Parcel Service Inc. has overhauled its process of designing user interfaces for all new and upgraded Web applications.
As part of the effort, UPS replaced its Microsoft Visio diagramming tool set with application simulation and authoring software from iRise Inc. about a year ago and now gets user approval on new user interfaces very early in the requirements-gathering process. That, said Guy Hamblen, project manager in UPS's corporate repository and architecture business unit, allows the company's 7,500-person IT unit to deliver better applications faster.
The iRise Studio definition and authoring tool is designed to create fully interactive replicas of Web application user interfaces that support user interaction and feedback before development work starts. Other companies, including CNA Financial Corp. and Wachovia Corp., also use iRise technology to simulate user-interface designs.
Visio, Hamblen noted, did not simulate how the user would interact with an application.
"The biggest challenge that an application development team has is eliciting the correct requirements at the beginning of the development effort," he said. "In the traditional software-development life cycle, oftentimes the user doesn't see the developed effort until the user-acceptance test, [which is] late in the development life cycle and only months away from deployment. If the user says, 'That's not what I wanted' at that late stage, you lose a significant amount of time correcting the problem."
By modeling the user interface in the requirements phase, the design team can be sure that it knows exactly what the user wants because it has used a simulated version, he noted. The simulation can then be an artifact for the designers and developers.
"That ripples throughout the whole development life cycle," Hamblen added. "That allowed us to improve our time to market with application-development releases. That is the fundamental business driver that iRise enabled for us."
In addition, UPS uses the iRise tool to support its offshore development projects. It "becomes a very valuable artifact where communications barriers are broken down and an offshore development team can see exactly what it is they need to deliver," Hamblen said.
For UPS, successfully rolling out the iRise tool to 160 users in seven business units was dependent upon the early senior management support of the technology, Hamblen noted. The company's CIO endorsed the initiative and held his direct reports accountable for rapid adoption of the tool.
In addition, UPS created a "just-in-time" training program to provide users with hands-on experience immediately after classes so the lessons would be fresh when they tackled the technology. UPS also kept iRise mentors on site following the training program to work with the business analysts who develop models, and it created webcasts to promote the use of technology. Newly formed user groups associated with each business unit were created to champion use of the iRise tool and to answer any questions that popped up.
"We set up a centralized deployment infrastructure to track the rapid deployment of applications and get immediate feedback from the user community as it was occurring," Hamblen said. "That whole process enabled us to deploy the application development tool very rapidly into business units."
Hamblen noted that it has been difficult to come up with hard metrics to measure the success of the new tool. In traditional software development, he said, "success is often noted in how many defects you have … and when you find those defects."
"By being able to simulate the UI, we've had many instances where the user would say categorically, 'That is not what I envisioned when I gave you my written requirements,'" Hamblen said.
An experienced iRise user can make the changes on the fly and demonstrate the new behavior to the user during that stakeholder meeting, which is a significant enhancement to a traditional development process," he said. "Obviously, in our old methodology, the user would not have seen that ambiguous requirement until the user acceptance test maybe three or more months later."