For Banks, Application Development Can Be Faster and More Efficient

By Maurice Martin, iRise

"Fail early!" may seem like an odd rallying cry for banking CIOs tasked with developing new applications. But, with reduced budgets and ever-increasing demand from the business for efficiency and innovation, it's no wonder today's IT leaders feel the need for speed. New applications-initiated by application consolidation or by modernizing legacy systems-increasingly top the CIO's agenda as the banking industry faces an unprecedented level of mergers and acquisitions.So what does "fail early" mean and how can "failure" actually have a positive affect on the bottom line?

Simply stated, "fail early" means discovering as soon as possible-before you invest in expensive coding-if your new application does what it's supposed to do. If it doesn't work, the "fail early" approach helps to make sure you have enough time and budget to make the necessary changes.

Rolling out live applications to customers should never be an acceptable way to test drive applications. It's crucial for stakeholders-business analysts, business owners, customers, users and developers-to be able to visualize the application before it's rolled out. Problems need to be identified on the front end-early in the production cycle-before mountains of expensive and time-consuming code have been written

Today's banking CIO needs faster application development with lower cost and, most importantly, better processes to ensure the right application is being built in the first place.

In the race for the finish line, let's take a look at three ideas for preventing projects from spinning out of control.

1) Ditch the Paper-Use Fully Immersive Visualizations: Up to 70 percent of all project failures are directly related to requirements issues. There are two main reasons for this:

• Business people don't know what they want until they see and interact with it. Without a way to test drive applications early in the process, business people have to wait until applications are designed, coded, tested and released for review before they get that crucial first look. All that expensive coding and time can easily be wasted when it becomes obvious that what has been built is not what was envisioned in the first place.

• Business people do not understand text, static screen shots or use case diagrams. Yet these tools are exactly the way that most business applications are defined. Business stakeholders often sign off on giant requirements documents without reading or understanding them. Instead, they take the attitude; "I'll know whether it's right when I see it."

A different way of doing this is by using fully immersive visualizations. These are created by business analysts to give the business a way to experience and test drive complex business systems without any coding and to do so early in the process. The ability to simulate and model products before building is commonplace in most other industries and now it is becoming a standard practice for business software.

2) Transform the Process: IT leaders can make a material difference to project outcomes by also focusing attention on improving the efficiency of the application definition process. Market research studies by organizations like IAG Consulting show a direct relationship between the maturity requirements processes of IT organizations and project outcomes. The more mature an organization's application definition process, the more likely that projects will be completed on time, on budget and with all the features needed by the business. This is especially true when organizations develop applications using global sourcing models, when normal processes are complicated by time, language and cultural differences.

Most successful IT organizations have adopted a rapid, iterative definition and development process to overcome fundamental inefficiencies in how business applications are defined. Cross functional teams composed of business analysts, business stakeholders, developers and quality engineers, in addition to training that leverages collaborative tools to share information and visualize the end state of projects are the state of the art for requirements definition. Requirements elicitation and validation can be dramatically improved by involving the business with the right tools and process throughout the project lifecycle.

IT leaders must also measure improvement by tracking key metrics like defects related to requirements issues and time spent in requirements cycles.

3) Focus on the People: A true transformation of an IT organization is more than just a process and technology opportunity. The business analyst is now at the front lines of the battle to improve requirements definitions. But how does an IT leader assess the quality of the BA team and improve their skill sets?

For the first time, a modern professional ecosystem now surrounds the business analyst function. A professional society (the International Institute of Business Analysis) is thriving that has driven a body of knowledge for the BA function. Certification and training programs are springing up at universities all over the world that focus on improving BA soft skills. And business analyst consulting firms are expanding staff augmentation and process improvement opportunities for many IT organizations.

Many companies are also now experimenting with global sourcing models that include a mixture of offshore and onshore business analyst resources co-located with development teams.

CIOs must understand that IT organizations at all levels need to communicate better with business people. The old view of IT purely as a service organization simply won't work in the 21st century. IT leaders and business must now work in a collaborative partnership toward a common goal: modernizing business systems and driving efficiency-fast. And to get these projects done successfully will require high degrees of communication.

Maurice Martin is president, COO and founder of iRise a company that develops tools for prototyping software.