COURSE SUMMARY

MAJOR LESSONS & BEST PRACTICES IN INFORMATION TECHNOLOGY MANAGEMENT

In class, we covered the issues associated with the management of information technology (IT). Because IT is ubiquitous to almost every organizational process, you are (or will be) highly involved with IT.

You may participate in the identification of IT projects to enable business objectives.
You may evaluate IT proposals prepared by others.
You may define user requirements for new systems, or enhancements to existing systems.
And you will most likely be users of IT.

You will leave this class. Five years from now, what messages will still be relevant to your working life regarding the management of IT? How can you help IT help the business to succeed?

First, Remember that IT is not a homogeneous, but rather IT comprises a variety of activities. In general, these vast array of IT activities can be categorized into two major areas:

I.T. Projects

Typically Application Development or Infrastructure Projects
Often funded with capital budgets
IT proposals often compete with other IT and non-IT proposals

I.T. Operations

Daily running of infrastructure (data centers, networks, Pcs, telecommunications)
Enhancements & maintenance of current applications
End User Support
Data management
System Security

Management for the two areas are faced with the following challenges:

I.T. Projects:

Why are our I.T. projects late, over-budget, and/or lacking functionality?
What are best practices to help ensure success of our IT projects?

I.T. Operations

How do we balance the cost/service trade-off?
What are best practices to ensure success of our IT operations?

Successful IT begins with asking the right questions & diagnosing the right problems.

I.T. PROJECTS

Many IT projects fail based on the following definition of success:

On time
On budget
Delivered promise functionality

Why do information technology projects have this poor batting average?
Are IT projects inherently more difficult than other projects?
What can we do to increase this batting average?

PROJECT MANAGEMENT: LESSONS FROM NON-I.T. PROJECTS

During his career, Peter Morris (formerly at Templeton College, Oxford University) studied over 3500 projects world-wide in all types of industries, including IT and non-IT projects. (See, “Project Management, Lessons from non-IT projects” in Information Management: The Organizational Dimension, Earl, M. (ed), Oxford University Press, 1996.)

One of his first studies based on 1,444 projects, only 30 were delivered on or under budget.

Are we all this bad at project management? (any project, not just IT)

His main argument is that the definition of project success (on-time, on-budget, to technical specification) is largely influenced by factors outside the project. Thus, we need to attend to these non-project factors to increase the likelihood for success. Below is a comparison of external factors that influence different project types. IT projects are affected by more external factors than most projects:

INDUSTRY CHARACTERISTICS

Aerospace/Defense & Power

Stable Requirements
Long Development times (7 years)
Long Liftimes (20-30 years)

(Once an airplane or a power plant is built, organizations merely maintain the original design, they typically do not alter it.)

Petrochemical & Mining & Shipbuilding

Less protected from environmental factors, but factors are tempered by rising product prices.

Civil & Building Industries

Criticized for poor management but products last for years, and the designers and
builders are largely removed from end-user input.

(“End-users” of office buildings, bridges, roads, typically have no idea who designed or built them.)

Information Technology

Intimate user involvement before, during, and after development
Multiple user stakeholder groups--often with conflicting views and needs
Unstable requirements during development
Constant change after implementation, including both business and technical changes
Dropping prices(Thus, I.T. projects are affected by many environmental variables.

IT project requirements constantly change during development. IT projects constantly change after implementation. IT projects enjoy almost no stability in either the business or technical arenas.)

Best practices can increase I.T.’s success rate.

Academic and practitioner researchers have identified the best practices for maximizing the likelihood of successful I.T. projects. However, implementing these practices often requires authority and power beyond IT management. When these practices are absent, IT understandably “bats poorly.”

BEST PRACTICES FOR DEVELOPING I.T. PROJECTS

1. Business solutions drive technology selection.

Information technology is merely a tool to enable business initiatives. IT strategies that include phrases such as “state-of-the-art technology” are a real bellwether to mis-alignment. The question is not a matter of the newest or fastest, but the best-fit. The most successful IT projects arise from business task forces, such as business process re-engineering--Michael Earl describes this Strategic Information Systems Planning process as “Organizational”. (See Earl, “Experiences in Strategic Information Systems Planning, MIS Quarterly, March, 1993.)

2. Projects justified based on competitive analysis, fit with strategy, opportunity cost, not just cost/benefit analysis.

Cost/benefit analysis during a project proposal is limited because the scope of the project almost always changes (functionality is often added, which increases original cost/time estimates) or external factors affect the project.

In proposals we have seen, the cost savings (benefits) can rarely be verified. For example, consider the proposal which estimated that a new order entry system would increase sales by 3%. The system was implemented and sales did rise, but how can we possibly credit IT? There are a million other variables operating simultaneously.

Instead of just relying on cost/benefit analysis, the questions to ask are “What happens if this system is not developed?” “How will this system help my relationships with customers and suppliers?” Of course cost/benefit analysis is one consideration, but confidence intervals must be calculated to express uncertainty, and a proper risk analysis is needed to identify the possible influence of environmental variables outside the control of project management.

3. Secure top management support--a champion who has faith in the system & the power to overcome organizational resistance and obstacles.

Information technology is neutral. How IT is implemented is political. IT can be used to centralize, decentralize, or make no changes to organizational processes and structures. Therefore, all IT projects need top management support, not only to identify IT projects that support the business strategy, but to enforce the changes needed to the organization to make IT work. IT projects need cheerleaders, head coaches, czars, zealots, change agents, renegades:

Champions gain support across the organization.
Champions keep momentum going as project deviates from proposal (including cost & timing).
Champions overcome resistance to change.
Champions suppress the “this won’t work” attitude.
Champions reward innovation.
Champions embody the vision.

(See Beath, C. “Supporting the Information Technology Champion”, MIS Quarterly, 1991, pgs. 355-373. )

4. “Freezing” user specifications during the system development life cycle.

During the past 10 years, IT has significantly increased user participation on project development teams. The upside is the obvious--better understanding of business requirements. The downside is the increased and growing identification of more and more functionality. At some point in time, user requirements must be frozen, and the system designed flexibly enough to start enhancements just after implementation.

5. Implement incrementally.

Many studies show that smaller projects are more productive (in terms of functionality delivered/person hours) and of a higher quality (number of defects per unit of functionality) than larger projects. The challenge is this: how to develop large, integrated systems, so as to reap the productivity and quality benefits of small-sized projects? Research shows that three strategies work well.

(1). Phased implementation for systems in which functionality can be divided and delivered separately.

(2) Prototyping for systems that are irreducible...i.e., you must develop all the inter-related pieces at once. The prototype may be established in a “mock office” for users to interact with during development.

(3) A pilot site for systems that are irreducible in which the system is fully developed and implemented at one site, then “rolled-out” to other sites.

The benefits of incremental implementation include:

Verify user requirements
Reduce risk
Recover from mistakes early
Demonstrate value to secure management approval for full-scale implementation
Gain user acceptance of the system
Higher productivity and quality

(See Janson, M., and Smith, D. “Prototyping for Systems Development: A Critical Appraisal”, MIS Quarterly, 1985, 305-316.)

6. Staffing the best people.

A CIO once said, “a positive attitude & willingness to learn accounts for 90% of success.”

The morale of the IS staff, users, and other participants are vital to the success of any project. People must be empowered to do their job, to feel they have the full support or the organization, and to be rewarded for success. Constant empowerment must be provided through training, tooling, and resourcing.

What should be done when a system development effort involves new technology for which our people have no experience? Researchers have identified a successful model in which the project is managed internally, but vendor expertise is brought in to work side-by-side with the project team. In cases we studied, the internal project team had the requisite business understanding, the vendor had the requisite technical understanding. During development, technical skills were transferred to the internal staff.

(See Willcocks, L. and Fitzgerald, G., A Business Guide to Outsourcing Information Technology, Business Intelligence, London, 1994; Lacity, M., Willcocks, L., and Feeny, D. “Information Technology Outsourcing: Maximizing Flexibility and Control,” Harvard Business Review, May-June, 1995, 84-93.)

In other cases we have studied, outsourcing the development of a new technology was risky because (1) the customer could not sign a sound contract due to high uncertainty and (2) the customer was not able support the project once it was delivered in cases where no organizational learning about the new technology occurred.

Some customers and suppliers are developing contracting mechanisms to minimize these risks, such as co-sourcing, performance-based contracts, value-added partnerships, and joint ventures. The success of these contracting mechanisms will likely depend on whether strengths of both partners create a product or service that can compete in the marketplace, or whether two organizations with complementary goals can structure a contract to meet dual objectives.

7. Planning for life after project development.

We saw in the Morris table that IT is one of the only project categories where the product begins to change the day it is implemented. Ensuring flexibility and maintainability are major goals of IT projects. Best practices include proper testing to ensure product quality (unit, string, system, and volume testing), minimizing customization of packaged solutions where possible, focusing on data captured rather than on outputs (such as reports), following standards, and re-using code.

Most IT projects are budgeted only through implementation, then an operating budget is granted for support once the project is implemented. There are significant trade-offs as a result of the budget structure. It is always cheaper to fix design flaws during development rather than fixing them after implementation, but such changes during development cause projects to be delivered late and over budget. Thus, some senior level manager must make life cycle decisions--which changes should be made during development and which changes should be made after implementation?

Summary:

IT projects are challenging because:

IT projects require input from many different stakeholders, often with conflicting agendas
IT projects typically require significant changes in business processes and structures, which requires a senior level sponsor/champion to overcome organizational resistance
IT project requirements are unstable--requests for product changes begin the day after implementation.
IT projects costs and benefit estimates are often just educated guesses, because benefits are often intangible, external project factors influence cost and development, and often there is little/no experience for developing a new project, i.e., IT managers never develop the same project twice (thus there is a high degree of uncertainty).
IT projects only consider the development costs, not life cycle costs. There is a trade-off in what gets delivered during development and what will be delivered after implementation. Because development and support are typically managed by different people, a senior level manager must assume the “life cycle” view and make decisions on the trade-off.

I.T. OPERATIONS

“Perception is all there is...manage it! There is no reality. There is only perceived reality.” --Tom Peters, The Pursuit of WOW!, Vintage Books, 1994.

An understanding of the challenges facing the IT managers is a prerequisite for ensuring that IT operations succeed.

Rudy Hirschheim and I believe that there is a significant cost/service trade-off in IT operations. Centralized service is associated with lower costs due to economies of scale, but typically centralized products and services are perceived as providing lower service levels than decentralized services. Standardized IT products and services are associated with lower costs, but typically viewed as providing lower service levels than customized IT products and services. Consider the following examples:

Standardized software is cheaper than customized software, but idiosyncratic user needs are not met through standardization and therefore standardized software is perceived by users as providing a lower level of service than customized software.
A centralized data center is less costly than multiple, decentralized data centers, but users prefer local data centers--they can personally interact with data center staff, pick up emergency reports, hand-deliver special requests, etc.
Supporting only one version of software is less costly than supporting multiple versions, but every user may not be accommodated. (For example--is every user ready to upgrade from Windows 3.0 to Windows 95?)
On-line reports are less costly than hardcopies, but users miss the portability/convenience of paper reports.
A centralized pool of IT staff is less costly than a local, dedicated IT staff, but users may not perceive that their unique business needs are properly met.
Business hour support is less costly than 7 days a week, 24 hour support, but some users may not be adequately supported after hours. For example, manufacturing may run throughout the night.

In the companies Rudy Hirschheim and I studied, we found that senior executives, business unit managers, IT managers and end-users often hold different perceptions and hence different expectations for the performance of IT. In general, senior executives tended to view the entire IT function as a commodity rather than a strategic asset or core competency. Some senior executives compared IT to "utilities", "electricity", "heating", and "cafeterias". With metaphors connoting IT as a commodity, senior executives often mandate that IT be run more cost efficiently. Usually couched in a larger business context of a general downsizing and restructuring, senior management may tell IT managers to trim the budgetary fat along with other support functions. On the other hand, business unit managers tend to take a more territorial approach. They often view their own IT activities as critical to business success, but dismissed other units’ IT activities as commodities. For example, when IT managers propose to consolidate data centers, business unit managers may often agree in principle, but only agree if their data center is selected as the consolidation site. Like business unit managers, end-users tend to view IT as a critical contributor to daily business processes. As such, users demand differentiated services, such as custom-tailored applications, a devoted staff of analysts and programmers to respond to daily needs, and locally run data centers to immediately submit runs (and re-runs). IT managers were caught somewhere in the middle, trying to juggle the conflicting IT priorities set by senior management and the business units.

Based on our case studies, we have characterized the following stakeholder expectations and agendas for IT. In general, senior management often perceives the entire IT function as a utility, and therefore often sets the IT agenda to be cost minimization. In general, business units and end-users perceive that IT critically contributes to business operations, and therefore set the IT agenda to be service excellence. These two stakeholder groups set a conflicting agenda for IT because IT managers cannot provide a “Rolls Royce service at a Chevrolet price.”

Given the cost/service trade-off, what are the best practices associated with IT operations?

BEST PRACTICES FOR SUCCESSFUL I.T. OPERATIONS

1. Stakeholders must align the IT strategy with the business strategy, including determining the cost/service trade-off for each IT activity.
This will dictate:

Organizational Structure for IT activities

Centralization (low cost) verses decentralization (high service)
Recall the five forms: (corporate service/internal bureau/business venture/decentralized/federal.
Strategy will typically identify a combination of centralization and decentralization

(See Earl, Edwards, and Feeny, “Configuring the IS function in Complex Organizations, in Information Management: The Organizational Dimension, Earl, M. (ed), Oxford University Press, 1996.”

Operating budget.

Although most IT budgets are typically set historically (this year’s budget is a function of last year’s budget) budget cuts or increases will be determined by the resultant strategy.

Chargeback System

General allocation chargeback
Usage allocation chargeback
Price-based chargeback

Service Levels

Standardization (low cost) verses Customization (high service)
Service Level Agreements--IT's contract with users

2. Empowerment of IT Management

High-level reporting structure of CIO
CIO is a charismatic business manager-- Strategist, marketer, educator, innovator

3. Empowerment of IT staff

The IT staff is not just the greatest cost of IT, but the greatest asset (unfortunately we haven’t figured out a way to put human assets on the balance sheet)

Hire positive attitudes
Training (business and technical)
Tooling (computers, workbenches, etc.)
Employee participation in management decisions: How can we improve service? How can we cut costs?
Trust and respect employees: For example, “No drug testing!” Says Tom Peters
Job mobility/security (promotes cooperation & communication)
Flex time
Personal accountability where possible
Team accountability where possible
Create marketing mentality (including competition through selective sourcing)

4. Sourcing to maintain flexibility and control

Buy-in vendor resources to gain expertise & transfer organizational learning
Outsource IT activities where appropriate, to save money, to meet temporary resource shortages, to focus IT staff on value-added work, to create products and services that cannot be delivered without an external partnership.

5. User Prioritization of Requests

I.T. Demand is always greater than I.T. Supply
I.T. managers cannot be “traffic cops”
Backlog of requests needs stakeholder prioritizing

6. Benchmarking & evaluation procedures in place

“You can’t manage it if you can’t measure it”
Not as punishment or a report card, but to monitor and improve performance

(See Lacity, M. and Hirschheim, R., "Benchmarking as a Strategy for Managing Conflicting Stakeholder Perceptions of Information Systems," Journal of Strategic Information Systems, June 1995 pp. 165-185.)

7. Slack resources for environmental scanning to assess organizational fit with emerging technologies

Summary:

IT operations are challenging because:

IT is ubiquitous, i.e., integrated throughout the organization and is therefore affected by multiple stakeholders, often with different IT agendas
IT managers face significant cost/service trade-offs in virtually all IT operations
IT managers cannot succeed without power, support from top management, and cooperation from many factions.

Leslie Willcocks and David Feeny (Oxford University) have taken a unique approach to characterizing best practices for IT operations. They focus on the core capabilities required to deliver IT products and services. In their working paper, “Configuring the Information Systems Function: A Core Capabilities Approach”, (available through working paper series, Templeton College, Oxford University), they identified the following none core capabilities:

1. IT governance.
2. Business Systems Thinking
3. Relationship Building
4. Designing Technical Architecture
5. Making Technology Work
6. Informed Buying
7. Contract Facilitation
8. Contract Monitoring
9. Vendor Development
Their model is powerful because it simultaneously focuses on the who, what, and how of managing IT operations. Central to their model is the skills and talents required to deliver IT, that people are indeed the most important IT asset.

We leave the semester with one last thought: Everyday, we honestly earn our daily bread, strive to understand each other, find the common ground, treat ourselves and those around us with fairness, kindness, dignity, and respect. At the end of the day, we must be at peace with ourselves.