During the 1990s, spending on IT, both in insurance and in general, grew steadily. Since 2000, however, the trend has been toward flat or declining budgets. Many valid reasons have been offered for the slowdowna weak economy, concerns about terrorism, the bursting of the dot-com bubble, and the end of Y2K-inspired spending.
There is another factor that has not been given enough attentionmanagement has lost some of its faith in the ability of IT to deliver reliably worthwhile results. In this case, the pain is self-inflictedIT projects have earned a poor reputation by failing too often to meet expectations.
IT professionals should not wait for the economy to recover and assume that funds will flow freely again. A proactive effort is needed to convince management that investing in IT is the appropriate response to many of the problems a company faces. Executives must be convinced this time the rate of success of projects undertaken will be higher and the promised returns will actually materialize.
During the 1970s and 1980s, most of the focus of the IT function was on building systems to handle basic functions such as underwriting, claims processing, investment portfolio management, and accounting for results. Automation of these functions was essential to keep costs and product offerings in line with competitors.
During the 1990s, much of the energy of the IT function went into adding graphical interfaces to applications, building informational Web sites, and making sure everything would still work when January 1, 2000, arrived. These things were necessary to do, but all added to the cost of IT. Unfortunately, they generally did not generate a level of obvious benefits to management that were in line with their cost. On top of this, the rate of project failures remained at unacceptably high levels.
The need to prepare for Y2K became an opportunity for most financial institutions to upgrade their core applications. As a result, few now have an urgent need to replace them. Many are still figuring out how to take full advantage of packaged software that was rushed into production in the late 1990s. This does not mean there is nothing left to do, only that the nature of the next wave of projects will be different.
The best opportunities for improvement now seem to lie in taking further advantage of the Web, building data warehouses as the foundation for improved reporting systems, and achieving higher levels of integration between existing applications. Selling management on these types of projects can be difficult because benefits are not always instantly obvious. In addition, predictable and rapid payback has become the first criterion for approval.
A New View
Before the next generation of IT projects is launched, it is appropriate to rethink the approach taken. The huge projects involving dozens of people for years at a time that were the norm in the 1990s are no longer practical. The all-too-common situation where projects start out small and then blow up in size also has to be avoided.
How can this new approach be achieved? Organizations that enjoy the greatest success view IT projects differently. Rather than thinking of a project as a single attempt to solve a problem once and for all, they view improvement as an ongoing and never-ending process. Individual projects are small steps toward long-term goals that continually shift and that will never totally be satisfied.
Under this view, a project is successful if the value it creates provides an adequate return on the investment made in it. Conversely, the project is not a failure if it does not solve every aspect of the problem at hand or if what is delivered differs from the original plan.
Small, fast, and worthwhile projects that attack only one facet of a problem are preferable to slow, resource-intensive efforts that strive for perfection.
One of the main reasons ambitious projects fail so often is the refusal of problems to remain stable while they are solved. A great design for a wonderful new system can be created, but if a long time passes between the completion of the design and the implementation of the resulting system, it is highly likely changing conditions will make the original design obsolete.
Limit the Scope
The only practical way to resolve this dilemma is to limit the scope of individual projects to a size that will allow them to be completed before environmental changes make their design irrelevant. This is best done in what seems like an arbitrary wayfirst determine the end date of the project and the resources that will be dedicated to it, and then let them drive the scope of what is undertaken.
Letting time drive scope only works if there is a belief that each project is a single step in an ongoing processthat the issues that remain after one project is completed can be addressed in the effort that follows. If management continues to insist a project is not successful unless everything is perfect when it is done, then no amount of cajoling or aggressive date setting will keep the scope from creeping upward.
There is another reason scope has a strong tendency toward constant increaselimiting scope usually means giving up something of value. Management admonitions to keep things simple are not enough unless a good mechanism is put in place to make the unpleasant but necessary trade-off decisions.
A typical example of a difficult decision is where end users insist building a new user interface for their claims-processing application will increase their productivity by at least 10 percent. On the other hand, doing so will add six months to development time. Without a good trade-off mechanism in place, the natural tendency is to give users whatever they ask for. The combined result of many such nondecisions is a large and long project.
The most effective way to force worthwhile trade-offs to occur is to make a single person totally accountable for every aspect of the project, including its cost, capability, timeframe, and the delivery of benefits. This totally accountable person should not be someone from the IT function or, even worse, an outsider. Such people cannot ensure the resulting system actually will deliver valuable improvements. It must be a person from the user community.
Yet another common cause of excessive scope in projects is the natural inclination of project teams to attempt to innovate more than necessary. Successful projects make maximum use of proven ideas and only innovate where it really matters. There must be no shame in effecting an improvement within your organization by exactly imitating something that has been done elsewhere.
Technology continually makes im-provement via imitation easier. Using packaged software effectively is the best and simplest way to incorporate improvements proven elsewhere. Building software on top of object frameworks is another option that is growing rapidly in popularity. The emergence of Web services will provide an even more powerful choice.
Never-ending Improvements
In summary, improvement needs to be viewed as an evolutionary processa never-ending series of incremental improvements, achieved as rapidly as possible, making maximum use of building blocks proven elsewhere.
During the 1990s it became obvious IT had the potential to transform the way business was conducted. This was especially true in information-intensive industries such as financial services. There was a wildly optimistic belief this transformation would happen quickly and easily. When it didnt, disillusionment set in and the rate of innovation slowed down dramatically.
Ironically, the passage of time has made the potential payoff from IT projects greater than ever. As an example, in the early days of the Internet, it was easy to spend a million dollars or more building a modest Web site. The tools available today have cut the cost of creating high-quality Web sites to a tenth of what they once were.
The same thing is true with data warehouses. Only a few years ago, storing a terabyte of data in a warehouse was something only Fortune 100 companies could afford to do. Sophisticated business intelligence systems now can be rapidly put in place at a modest cost for organizations of almost any size.
Being good at turning technological capability into practical business benefit has become a prerequisite for survival in the financial service industry. The only way to do so is to be good at managing projects. The best way to become better is to learn as much as possible about how those who are successful do it. The secret to their success lies in following a set of principles that help to avoid long and overly complex undertakings. Adopting these principles could help convince your top management to get back on the horse and undertake the high-payback IT projects that are waiting to be started.
David H. Andrews is founder of Andrews Consulting Group and co-author with Kenneth R. Johnson of Revolutionizing_ITThe Art of Using Information Technology Effectively (John Wiley, October 2002). The ideas in the book are explored further at the Web site www.riteapproach.com. Andrews can be contacted at dandrews@andrewscg.com.
© Arc, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to TMSalesOperations@arc-network.com. For more information visit Asset & Logo Licensing.