| QUESTION & ANSWER |
Why business analysts are application development key players today |
 |
By Jan Stafford
27 Oct 2009 | SearchSoftwareQuality |
|
|
Tight budgets, tough competition and changing software development methods, such as agile, demand improved communication between, users, business analysts and software development teams, according to Emmet B. Keeffe III, CEO of El Segundo, Calif-based iRise. In particular, business analysts must be deeply involved in application requirements elicitation and testing.Today, businesses just can't afford cost overruns, missed deadlines and user dissatisfaction with faulty and inadequate applications, said Keeffe, who's also co-founder iRise, which makes visualization software for business applications. In this interview, Keeffe talks about causes of faulty applications and how CIOs are pushing business analysts into application development to improve efficiency and drive new revenue opportunities.What key trends are you seeing in the CIO community?
Keeffe:: I've met with hundreds of CIOs over the last 12 months. Many have been affected by the economy as you might expect; so, for the last 18 months, CIOs have turned their attention to the next big opportunities to cut cost: application rationalization and extending global sourcing models.
What exactly does application rationalization and extending global sourcing models entail? Could you elaborate on the problems that are driving CIOs to adopt these measures?
Keeffe:: In good economies, companies invested in lots of new business systems; which often turned out to be redundant. Multiple CRM systems, accounting applications and the like are just boat anchors on IT budgets. CIOs are now focused on consolidating these redundant systems to cut cost and improve business efficiency. They are also looking to extend global sourcing models deeper into their organizations as a strategy to cut cost.
What is the most common and surprising issue that comes up when you meet with CIO's?
Keeffe:: Without a doubt it is the amazing -- almost disturbing -- level of failure IT leaders have grown to accept when it comes to application development. It is well documented that over two thirds of all projects fail; they go over budget, are late or are delivered without the functionality needed by the business. The impact on IT budgets is enormous, but the impact on business efficiency and innovation is even larger.
What are the results of these failures? For example, how long does it take for applications to truly be ready versus how long it should take? What types of cost overruns do you see on a regular basis?
Keeffe:: Projects that suffer from poor communication often are delayed by months or even years. It's common to hear about projects taking twice as long as originally forecasted to complete, with budget overruns of 50% - 100%.
In your opinion, what causes such a high failure rate?
Keeffe:: The single biggest reason I see for this epidemic of failure is poor communication between the business and IT teams around requirements.
One issue driving this bad communication is that business people don't know what they want until they see and interact with it. If you have to design, code, test and deliver an application before users can see and interact with it, making changes gets expensive and time consuming.
Another problem is that the artifacts we use to define complex business software today are antiquated and hard to understand. Business people fundamentally don't know how to interpret text, use case diagrams and screen shots that only display what I call the "happy path." You wouldn't dream of designing a new car, airplane or building with a drafting board anymore; so why are we still designing software with the equivalent of drafting boards?
How do those initiatives and the current state of application development affect the role of business analyst (BA)?
Keeffe:: Most IT leaders I speak with now recognize that they need to invest in the BA role. Business analysts are now on the front lines of the most important transformation going on at most large companies. Fixing the project failure problem is going to involve a people, process and technology revolution, similar to the adoption of computer-aided design in the 1980s
Obviously, your company is addressing this problem with visualization tools. How does visualization help?
Keeffe:: The solution is to do what other industries have done, which is visualize before you build. You can think of it as CAD for business software. Enterprise visualization can empower organizations to see and interact with a fully immersive mock-up of a proposed system early in the process. The entire requirements cycle time can be dramatically shortened when teams rapidly iterate to the right answer quickly. And downstream organizations like development, QA, documentation and training all get a head start on their work by seeing the application in action visually, accelerating delivery even further.
How would a business analyst use visualization?
Keeffe:: For the first time business analysts are now empowered with technology that can help them do their jobs at a whole new level. BAs leverage visualization during requirements elicitation and documentation from the very beginning of the definition cycle. Visualization gives the opportunity to quickly iterate to the right solution at low cost and low risk.
You mentioned CIOs' current initiatives earlier. How does iRise's approach impact them?
Keeffe:: With visualization, IT leaders can also now take the risk out of extending global sourcing options and also improve the quality of the resulting systems. When you get the requirements right the first time it means you are eliminating rework, which is a significant cost for most IT organizations. With over 300 customers using our products now, they are telling us they get to market twice as fast with 30% less cost.
Have you seen visualization lead to the discovery of process problems or team inadequacies in the requirements and other phases of development, testing and QA? Could you describe some? What process or team changes have resulted?
Keeffe:: Absolutely. We have consistently told our customers that transforming application definition is a people, process and technology change that must be driven from the highest levels of IT organizations. Visualization can be adopted in all kinds of methodologies (waterfall, Agile, or a hybrid approach) on a project basis. Many of our customers then take the learning from their initial projects using visualization to make process improvements; usually by moving to cross-functional teams in a rapid, iterative environment. Many customers also move user experience design and user acceptance testing the front of the development cycle, further speeding up the process.
What does your crystal ball tell you the application software market in 2010 and beyond?
Keeffe:: We're not out of the economic woods yet, but we're seeing a ton of pent up demand for new business systems. We think that CIOs will be mashing the throttle on application development in the first half of 2010. Projects will be started around initiatives that not only rationalize to drive business efficiency, but finding new streams of revenue. Of course, the global systems integrators will be getting involved in many of those projects.
|
|
|
|
