Printer Friendly

From IT Solutions to Business Results.

Spending on information technology is staggering. Over the past few years, the top 500 U.S. companies in revenue earned have collectively spent well over $100 billion on their information systems. For most firms, however, determining the actual yield on IT investments in terms of business value delivered is a hit or miss proposition. Consider these statistics:

* In 2000, almost three-quarters of IT projects failed, in the sense that they were canceled before completion or never implemented (23 percent) or were completed late, over budget, or below specifications (49 percent).

* American companies and government agencies spend an estimated $75 billion on failed IT projects annually, in addition to another $22 billion over budget for software projects that are eventually completed.

Clearly there is a huge opportunity for improving the overall return. Companies are often urged to strengthen their project management disciplines: implement a project prioritization process, avoid project-scope creep, ensure the proper level of business sponsorship. These are undoubtedly critical steps. Still, a key enabler of higher returns is often missing. Too often the focus and definition of IT project success are cast in terms of IT solutions and deliverables rather than actual business results. Reversing the logic to put results first can greatly boost the odds of success. But putting business results first requires a mental shift that many IT and business managers find hard to make.

For managers who have made the mental shift, the term "IT project" is no longer in the lexicon. They see only business projects, some of which happen to have a heavy dose of IT input. This mental shift and the changes it stimulates are enabling such managers to reap higher rewards on their investments in IT-intensive projects.

A case study of a project at the Federal Reserve Bank of New York can help illustrate this mental shift and its implications. It shows how a different approach can be used by business and IT managers to ensure a higher return on project investments. The authors collaborated on this project as part of a broader effort to introduce a more rigorous IT investment process in several parts of the New York Fed.

THE DATA WAREHOUSING PROJECT

The Markets Group of the Federal Reserve Bank of New York handles the implementation of U.S. monetary policy. It employs a cadre of professionals who analyze market trends and decide on day-to-day policy issues. This requires a continuous review of patterns in the short-term money markets and in the demand and supply of bank reserves. Judgment, intuition, and historical analysis are required to respond to these patterns.

In this environment, timely access to data is critical. Yet professionals in the Markets Group were spending an inordinate amount of time chasing the necessary data from various parts of the Bank and outside. The Group management team felt that work would be more effective if the data resided in one easily accessible place.

The time was ripe for an IT project. After several conversations between the units that prepared the forecasts, those that shaped and implemented policy recommendations, and IT staff, a "data warehousing" project was launched. It involved building a comprehensive architecture for feeding, storing, and accessing the data used to analyze patterns and develop strategies for the day-to-day implementation of policy.

The project seemed to have all the right elements. It was based on a clear business need. It had as a business sponsor a senior member of the management team who was willing to be its champion. It was scoped out in consultation with the user group. And the IT organization was willing and ready to apply the right resources and project management disciplines to it.

Nevertheless, signs of trouble arose early on. Despite the initial enthusiasm, representatives from the business side assigned to collaborate with IT on the project began to lose interest in the effort. The forecasting unit felt the effort was a net burden, requiring new ways of structuring and presenting their data with little direct payoff to them. Members of the implementation unit that analyzed patterns and trends and thus had the most to gain from the data warehouse were too caught up in their day-to-day work to dedicate time to oversee an effort that promised a potential yield many months down the road.

After the first month, business unit team members were making brief appearances at project meetings, if at all. And IT team members were naturally beginning to question the users' commitment to the effort. Users' participation in the meetings would improve each time the issue was escalated to management, only to atrophy again a few weeks later. Progress on the technology side began to slow down, and it seemed that the project was a low priority for all involved. Six months after launch, the Markets Group management team was ready to pull the plug on it. The allocation of scarce IT and business resources could no longer be justified.

Focusing on Results

Rather than abandoning the effort, the Group management team decided to experiment with a different approach. Three questions were put on the table:

* If the data warehouse were built to perfect specs today, what business outcomes would change?

* Under this scenario, what impact could be achieved on these outcomes within 60 days?

* Who was in the best position to take accountability for creating this 60-day impact?

The answer to the first question was clear: The quality of the analysis was the key outcome to be affected. The answer to the second question was less obvious. Managers speculated about possible ways to narrow the focus, but decided to leave this to a team that was closer to the day-to-day operations.

The discussion led to an assignment for Spence Hilton from the analysis and implementation unit to launch a team whose goal was to create a business impact related to the quality of the analysis within a 60-day time frame. Representatives from the forecasting unit and from the Statistics and Research Group were asked to be on the project team, along with members from the policy implementation unit and IT staff. Rather than mandating data warehousing as a "solution" for the team, the project team was challenged to create a real business impact, leveraging whatever solutions its members felt were necessary.

Defining the precise impact they would create in 60 days was a critical first step. After much deliberation, the team decided to focus on a goal of reversing the ratio of time spent chasing versus analyzing data from 2:1 to 1:2. Even though the goal was a step removed from the real desired outcome, the team was convinced that achieving this goal would have a direct impact on the quality of the analysis. The team also decided to focus on one policy implementation decision that always posed a unique challenge: reserve operations at the end of each calendar month.

To get the effort under way, the team scaled down the scope of the data warehouse it was going after and implemented innovative approaches to compiling and displaying the data. It also became aware that accomplishing its goal required others in the Markets Group and in various parts of the Bank to work together in a different way. So it took steps to motivate others and engage them in the process.

The team members from the Statistics and Research Group acted to ensure that the reports they generated were organized for easy electronic access by the implementation team. To accommodate the ambitious time frame of the project, IT team members recommended the use of off-the-shelf database programs that could be patched together with the Bank's legacy databases to simulate the look and feel of an integrated data warehouse. All efforts were made to fashion the initial system out of existing software resources, and selected members of the implementation group were trained to use these databases.

The result was a successful 60-day project in which the ratio of time spent on data collection and analysis was reversed, contributing directly to more robust analysis and decision making. The effort also made it possible for the thinking behind the decisions to be more transparent--a fact that did not go unnoticed by the head of the Markets Group and other senior officials involved in the policy implementation process.

The staff responsible for the project proceeded quickly to apply the IT component of the project--the newly created "data warehouse"--to other business activities, using the initial application that was part of the original project as a model: Finally, the initial success was leveraged into broader business gains.

THE ANATOMY OF RESULT-ORIENTED PROJECTS

The first part of this story, as many business sponsors and IT professionals would attest, is quite typical. Business managers lobby hard to get IT investments committed. After the initial euphoria and flurry of activity, the projects take on a life of their own, often with waning interest from business users. When the IT tools are built, and users continue operating in the same old mode, the war dance begins. IT managers blame business sponsors for not leaning hard enough on their staff to "change their behaviors," and business sponsors counter that "if the tool had been designed properly, business users would have flocked to it." Too often, management consultants cheer both parties on from the sidelines and advise them both to start by reengineering business processes and altering the culture and behaviors before making IT investments.

This case study demonstrates that two seemingly minor shifts in project configuration can lead to profoundly different outcomes. The first shift is to cast the goal in terms of achieving the actual result that is being sought, rather than in terms of delivering the technology (or other) enablers of this result. The New York Fed's data warehouse, as initially envisioned, was a potential enabler for the staff to spend more quality time doing analysis. But by shifting the focus of the project from this enabler to the actual desired result, the effort and the team pursuing it were infused with the accountability for delivering a real benefit, rather than merely the promise of that benefit.

To achieve the result, dimensions of work flow, behavior, and skills needed to be woven into the project, in addition to the IT work. The project team was free to develop the right mix of solutions, and it was jointly accountable for integrating these solutions to achieve the desired result, rather than being given the task of implementing the manager's view of the "right solution." Bottom line: The effort shifted from a one-dimensional technology project to a multifaceted business improvement effort.

The second shift was to accelerate the time frame on the initial project. At the project launch session, the team spent a few hours discussing the merits of the different paths for narrowing the scope of the effort. It decided to tackle the time allocation goal rather than the broader and more amorphous goal of improving the quality of the analysis. And it focused on only one analytical application: the market behavior that occurs at the turn of a month. By doing this, the team was able to deal with the full complexity of the issue, but on a small and manageable scale.

The short time frame coupled with the insistence on a result-based goal forces a project team to start by tackling a microcosm of the overall project. Success of the initial effort produces a real result-an end in and of itself-but also a rich learning experience about what it takes to achieve the broader project ambitions.

Migrating to the Result Domain

Figure 1 shows a number of projects, or project elements, mapped along two dimensions: scope and orientation. Scope may be thought of as a continuum, anchored at one end by high-level, long-term projects and at the other by focused and sharply defined projects. Even though there is a continuous spectrum from activity orientation to results orientation, there is a crossover line separating activity and result domains. To the left of the line, project elements hold a promise of benefits to the firm. System development, training, and other "staff function" activities belong in the activities domain. To the right of the line, project elements are defined in terms of actual benefits to the firm. These are usually driven and led by managers in the line organization.

Generally, IT teams are commissioned to implement projects in Quadrant I (such as building a data warehouse) in the hope of yielding actual, broad-scope results in Quadrant II. Savvy IT managers engage line managers and executive sponsors in a dialogue on what it takes to ensure that their broad-scope activities translate into broad-scope results. Invariably, the issue of senior line management "commitment" and "sponsorship" is invoked, and additional broad-scope activity project elements are commissioned, with business managers acting as project leaders or sponsors. These elements might include redesigning the work flow, training staff to use the new system, changing policies and procedures, and educating customers, among others.

Alternatively or concurrently, IT managers might lobby to get "focused activity" projects commissioned to pilot-test the technology and see whether it will yield the promised results, even on a narrow scale. The piloting approach is tantamount to shifting from Quadrant I to the corresponding activity in Quadrant IV in Figure 1 (build prototype data warehouse).

Both approaches raise the chances for a higher return. But they also carry unnecessary risk. With the first approach, in which business-related, broad-scope activities are commissioned to complement the IT project elements, benefits and results accrue only after a large investment has been made. Meanwhile, there is no guarantee that the right combination of broad-scope activities has been identified, or that the firm can knit these together to achieve the desired results.

The piloting approach risks launching a pilot that is too technology-dominated to be a true test of whether the benefits will accrue. It also diffuses the accountability for achieving the business results. The sponsor can insist that the staff use the data warehouse to do its work, but this is not likely to generate the same enthusiasm, creativity, and results as challenging the staff to actually improve the quality of the policy analysis or the ratio of time spent analyzing versus chasing data. In fact, when managers specify the tools and the means, more often than not they inadvertently undermine the accountability and commitment of their teams for outcomes and results.

The rapid-result approach minimizes these risks. It requires business sponsors and business/ IT project teams to operate in Quadrants II and III (in the result domain) first, before moving into Quadrants I and IV (the activity domains).

THE CYCLE OF RESULTS

Undoubtedly, many business sponsors and project teams instinctively operate in the result domain. What we outline here is a structured approach that can help make this a conscious and consistent pattern of shaping and managing IT-intensive projects.

This approach calls on business sponsors to always start in Quadrant II, and challenges teams to move first from Quadrant 11 to Quadrant III as they define their rapid-result goal, then from III to IV as they create and execute their project plan. After the initial rapid results are achieved, business sponsors should cycle back and decide on additional investments in Quadrants III and I as they begin to scale up the effort and go for broader impact. The four steps below describe how this approach can be implemented.

1. Starting with Results: The Sponsor's Mental Shift

The first and most critical challenge for business sponsors of IT projects is to make the mental shift from activities to results, from Quadrant I to Quadrant II--the result domain, where senior line managers belong. Bottom line: This should always be the starting point for thinking about business improvement and commissioning project teams to pursue improvement and innovation opportunities. Making this shift requires asking such questions as "What will the IT investment help staff do?" and "If the investment is successful, what will be the business impact?"

To shift fully into the result domain, another more radical step is required. Instead of building the answers to these questions into the business case for making the IT investment, the IT project needs to be set aside. A team is commissioned to shape and execute a business improvement or innovation project, led by a line manager, focused on the actual result. To illustrate, we will follow the thread of an example many firms are grappling with: IT investment to create a more appealing and informative Web site. Consider the case of a professional service firm offering a number of services to midsize and large clients. To get started, the Web enhancement effort needs to be anchored in a broad business result. In this case, the dialogue between IT and the business heads converges on improving the sales pipeline by leveraging the firm's Web site.

2. From Broad-Result to Rapid-Result Projects: The Team's Challenge

The effort is sponsored by a business leader in the firm, who assembles a cross-functional team to shape a project that will yield rapid improvement in the sales pipeline via the Web. Team members quickly consider the market appetite for the firm's various service offerings, and narrow their focus to one. They then engage in intense dialogue to zero in on a goal that could be achieved in 100 days. In effect, the team is traveling in the results domain, from Quadrant II to Quadrant III.

Figure 2 shows how to increase focus on the project goal while moving from Quadrant II to Quadrant III. There are many equally effective routes from a broad-scope result to a sharply focused goal. But giving the team the latitude to explore various options and come up with its own benchmark of success fosters a strong sense of project commitment. And in the process of defining and shaping their goal, team members crystallize their understanding of the situation and the issues.

The key is to maintain an unwavering focus on actual results at each stage of the dialogue, as the focus narrows. In this case, the goal the team settles on is to generate four new sales leads via the Web in the next 100 days.

3. Moving into Action: From Rapid-Result Goal to an Action Plan

Only after the focused, result-oriented goal is defined does the team shift to thinking about the narrow-scope activities required to achieve this goal. At that stage, and after the sponsor signs off on the set goal, the team begins to develop a work plan. In doing so, it crosses from Quadrant III to Quadrant IV. All the good disciplines of project management can then be applied to ensure that the action plan yields the expected outcome. The power of the rapid-result goal the team defined is that it provides focus for the Web enhancement effort while forcing the integration of the multiple streams of work required to achieve the business result.

So how is the focus of the Web enhancement effort achieved? The team quickly realizes that the only way to deliver an actual result is to develop the Web site one module at a time, starting with a single type of sales. This helps them settle quickly on the site's overall architecture, with service offerings as a main organizing principle.

The content and organization of the focused sales module is geared to three objectives: reinforcing the credibility of the firm in this area; tempting visitors to e-mail the firm with specific questions or queries; and getting them to come back to the site to gain new insights on the topic. This quickly focuses the mind in terms of content, cutting months out of the usual soul-searching on the look and feel--let alone content--of the site. Perhaps as critically, the short-term business goal forces quick decision-making on the language to be used to describe the firm, its clients, its members, and its services.

In addition to focusing the site development effort, the rapid-result goal forces the integration of several streams of work that are potentially critical for achieving the goal. For example, the team implements steps to drive traffic to the Web site using broadcast e-mails and e-mail links from other business sites. It experiments with creating a discussion group to make the site "stickier." And it implements a quick-response system for answering inquiries received through the site. Of course, all these work streams could have been launched as broad-scope activities in Quadrant I. But here, the investment in each activity is disciplined by the limits of what is needed to achieve this particular goal in the time available.

4. From Rapid-Result Project to Broad Results: The Scale-Up Challenge

Many managers and IT professionals, although recognizing the value of this approach, tend to dismiss rapid-result projects as "small change" compared to the "real goals" of the overall efforts major IT projects are intended to support. Without doubt, IT development times often dictate longer time frames for the initial rapid-result projects. So what happens after the initial goal is achieved and the sponsor is faced with the challenge of scaling up?

The first couple of rapid-result projects yield both initial results as well as learning about what it takes to achieve the broader desired results, both in terms of IT and other investments. Effectively, those initial projects lower the risk of investing in long-term Quadrant I activities. After each project, the sponsor needs to assess the situation and decide on the mix of additional rapid-result projects as well as longer-term activities to launch. By calibrating this mix of Quadrant III and Quadrant I projects, sponsors can navigate toward the desired long-term results at minimal risk and cost.

Continuing the thread of the Web development effort, the next 100-day project might focus on generating leads in another service offering, creating an impetus to develop the next module of the site. However, rather than manage the effort to drive traffic to the site separately for the two service offerings, this becomes a long-term Quadrant I activity that supports both rapid-result projects. Naturally, the quick learning that occurred in the first rapid-result project is used to select and shape the appropriate Quadrant I activity After the second rapid-result project, the firm might decide to launch two more Quadrant I activities: staff training in advancing the sales process via e-mail, and a continuous process of updating the service offering modules with new information and insights to ensure value delivery at every repeat visit.

The emerging picture of the effort looks different from a string of rapid-development IT projects. Using this approach, each major IT contribution is woven into a rapid-result business-driven project. And these projects, in turn, get woven around longer-term activities that cut across and support multiple business projects. This evolving tapestry of projects and web of accountabilities ensures the continued relevance of each additional IT investment and helps the business sponsor deliver on the overall business goals at minimal risk and cost.

So how can business leaders help their IT and line managers make the shift to a result-oriented mode? Here are a few ideas:

* Insist that no commitments to IT investments are made before one or more related rapid-result projects are undertaken--not pilots and prototypes, but projects that have a clear accountability for achieving an actual business improvement or innovation requiring some aspect of the IT investment.

* Create a framework and methodology in the organization for shaping and launching rapid-result projects-within the context of the broader desired result. This reduces the transaction costs associated with getting these projects under way.

* Train an internal cadre of consultants, possibly within the IT organization, to help managers navigate through the result and activity domains appropriate at the various stages of initial experimentation and scale-up.

Bottom line: Whether IT projects involve onetime small investments or large-scale multitiered investments, starting with a focused project in the result domain helps business sponsors and IT managers strengthen the link between creating IT tools, using them, and leveraging them to achieve business results.

Nadim Malta is a senior partner at Robert H. Schaffer & Associates, Stamford, Connecticut. He can be reached at nfm@rhsa.com. Sandy Krieger is a senior vice president with the Federal Reserve Bank of New York.

References and Selected Bibliography

Barbara J. Bashein and M. Lynne Marcus, "A Credibility Equation for IT Specialists," Sloan Management Review, Summer 1997, pp. 35-44.

K. Ohlson, "IT Projects Are Succeeding More Often, Researcher Says," InfoWorld Electric, June 19, 1998.

Howard Rubin, Rubin Systems Inc., "1995-96 Worldwide Benchmark Project on IT Spending, Practices and Performance," cited in Allan Alter, "Top Firms Move on IT," Computerworld, June 2, 1997, p. 74.

Robert H. Schaffer, The Breakthrough Strategy: Using Short-Term Successes to Build the High-Performance Organization (Cambridge, MA: Ballinger, 1988).

Standish Group, "Extreme CHAOS 2001," reported in J. Johnson, K. Boucher, K. Connors, and J. Robinson, "The Criteria for Success," Software Magazine, February 1, 2001, p. S3.

[Figure 1 omitted]

[Figure 2 omitted]
Here are other examples of Broad System Project and the Corresponding
mental shift to Broad Business Results:

Broad System Projects                Broad Businesss Results

Implement faster dial-up connection  Improve productivity of
system, train remote users, and      bank supervisors operating
and mandate usage                    in remote locations

Implement knowledge management       Increase underwriting
system to facilitate cross-          premium coverage from
business communications and          high profitability accounts
best practice flow

Implement tracking and monitoring    Increase customer satisfaction
system for customer requests         and retention rates
COPYRIGHT 2001 JAI Press, Inc.
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2001 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:information technology
Author:Matta, Nadim; Krieger, Sandy
Publication:Business Horizons
Article Type:Statistical Data Included
Geographic Code:1USA
Date:Nov 1, 2001
Words:4223
Previous Article:Why Engineers Strike--The Boeing Story.
Next Article:Are Your Secrets Safe? Knowledge Protection in Strategic Alliances.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters