In 2003, Citigroup’s mortgage lending group launched a new retail banking product and then found itself mired in what would become 8,000 hours’ worth of software fixes and enhancements.
That result wasn’t unusual, says Michael Chandler, director of user experience and product design in the consumer lending division of Citigroup’s North American IT unit. So Citigroup decided to change its mode of operations for application development. One goal: improve the requirements definition stage and speed up prototyping, with the help of simulation software from iRise.
The results: After Citibank’s mortgage division relaunched that retail application in November 2006, IT made just 120 hours of post-production changes, most of them minor. Chandler says that iRise clearly helped: “We’ve taken out paper-based prototyping and manual, text-based requirements, and moved it towards the electronic medium.”
Welcome to the world of software simulation, an emerging area of application development tools. Don’t think of flight simulators, though: Think of CAD/CAM tools that eliminate paper-based tasks.
Tools like iRise “allow you to build the simulation of what you’re going to get at a really low cost,” says Carey Schwaber, an analyst at Forrester Research, who calls poor requirements definition the root cause of bad software. IRise claims that it can cut requirements time in half and cut reworking time by 75 percent, numbers that Schwaber says sound reasonable.
At a time when businesses are asking CIOs to help deliver innovative changes quickly, old-world application development schedules simply may not fly. Simulation tools, targeted mostly toward business analysts, offer a novel solution. They also fit in well with the agile programming trend.
Citibank changes tempo
But simulation software, intriguing as it may be, won’t be a Band-Aid you can just slap on your current process. To pick up the pace of its software development, Citigroup went after its root problem in defining project requirements, which involved various business partners just “throwing requirements over the wall,” Chandler says. Developers got a large list of functional specifications but lacked a sense of what the ultimate product should look like. Then, “when the production version comes, you’ve got 10,000 hours of changes,” Chandler says.
So Citigroup adopted a user-centric design approach for all consumer mortgage lending products. Whether the ultimate users were employees or customers, the user needs helped define the requirements of the project.
Creating this culture in Citigroup IT was a big step forward, Chandler says, but IT found two big development inefficiencies remained — around prototyping and effective requirements gathering. As at most firms, prototypes came out of meetings where requirements were put down on paper. Models were also built on paper. “Paper prototyping is lengthy and it’s not connected to anything else. You prototype it and you throw it away,” Chandler says.
The firm had previously tried to build prototypes using Microsoft’s PowerPoint and Visio tools, as well as coding in HTML and XML. But these were kludgy, as were the results. About 18 months ago, Chandler started looking at simulation tools, settling on iRise, a product that makes it simple to build prototypes of software interfaces and collect the associated requirements. (Helpfully, another group in Citigroup IT had been using iRise with success, and Chandler was able to forecast potential time-savings with the tool based on that group’s experiences.) His team started with five licenses on a 90-day trial basis, using the tool on several types of development projects, including a Web-based job, a client-server effort and even a mainframe project. Today his group has 20 licenses in consumer lending and another 21 throughout other Citigroup divisions (and hosts the iRise server edition for other Citibank development groups.)
The iRise tool has helped Chandler’s group of 34 usability engineers (whom he describes as business analysts, in effect) to work about 42 percent faster at creating requirements specifications, Chandler says. For prototyping, they’re now working between 66 percent and 80 percent faster, depending on the application. However, Chandler cautions that Citigroup’s shift to user-centric design means that it’s hard to say how much of the increased speed comes from iRise. “We spend more time on definition and design” than in the past, he says. Still, while he can’t say that they’ve cut project time in half, “we have reduced our post-production enhancements and fixes.”
Better talks with customers
At Bally Technologies, a leading maker of equipment for the gambling industry, another simulation tool has helped IT pick up the pace as the company strives to create its next generation of products. Bally’s IT group adopted Serena Composer (originally made by Apptera) in February 2006 to help better define requirements in its application development process.
Ron Beck, director of software development at Bally, says that Composer is turning doubters into believers in the IT group, by improving communication between IT and its internal business-side customers.
“I can take the tool out to the customer, talk to them and model their process while we talk,” says Beck. “We put a user interface around each of their various functions and then we can say, ‘This is what you said, and here’s an interface. Is this what you want?'”
The customer gives feedback while Beck, or more often a business analyst, is onsite. Beck or the analyst goes back to the software development team and the business team members who will be involved in developing the new product, and shows them the requirements and the model. At this point, they’ll do a technical assessment, then start the project. Since Bally uses an agile programming environment with 30-day development cycles, this prototype process fits in comfortably.
Bally Technologies has not been using the tool, which costs US$3,000 per license, for long enough to have statistics on its ROI, Beck says. But he has his anecdotes from customer meetings, and he knows that his quick prototypes get his documentation team started on manuals weeks earlier than was previously the case.
At BMO Financial Group in Montreal, the IT group similarly hopes simulation tools can help improve its requirements process. BMO’s Jesse Hanspal, director of development technology services, calls his challenge the “elephant problem,” in reference to the old tale of blind men who each had their own interpretation of an elephant. Requirements development suffers from the same thing, he says: Marketing, IT, the project’s users, the product managers, audit staff and other stakeholders all have their own perspectives. “The English language is better for prose and poetry than modeling,” says Hanspal.
A simulation tool, on the other hand, can force people to speak the same language, by showing them a model of what they say they want, he says.
So BMO has begun using the Profesy tool from Sofea. (Profesy costs in the range of $10,000 per license.) Hanspal says that Sofea helps him model entire software systems, to dynamically simulate what customers might see at a branch, for example. It will help reduce the number of software defects, he hopes, by improving the requirements process.
Hanspal’s group is still in the early days of using Profesy, with just a few business analysts using it. Profesy has already sped up projects, Hanspal says, but he can’t say by how much, partly