Risk Management for IT Projects

Bennet Lientz, Lee Larssen

• Publisher: Routledge
• Year: 2006
• eBook ISBN: 9781136368042
• Topic: Business
• Subtopic: Business General
• Index: Business

The rate of failure of IT projects has remained little changed in survey after survey over the past 15-20 years—over 40-50%. This has happened in spite of new technology, innovative methods and tools, and different management methods. Why does this happen? Why can't the situation be better? One reason is that many think of each IT effort as unique. In reality many IT projects are very similar at a high, strategic level. Where they differ is in the people and exact events—the detail. If you read the literature or have been in information systems or IT for some time, you have seen the same reasons for failure and the same problems and issues recur again and again. In this book IT Management experts Ben Lientz and Lee Larssen show you how to identify and track the recurring issues leading to failure in IT projects and provide a proven, modern method for addressing them. By following the recommendations in this books readers can significantly reduce the risk of IT failures and increase the rate of success. Benefits of using this approach: • Issues are identified earlier—giving more time for solution and action. • Issues are resolved more consistently since the approach tracks on their repetition. • You get an early warning of problems in IT work—before the budget or schedule fall apart. • Management tends to have more realistic expectations with an awareness of issues. • Users and managers have greater confidence in IT due to the improved handling of issues. • Since the number of issues tends to stabilize in an organization, the IT organization and management get better at detecting, preventing, and dealing with issues over time—cumulative improvement. • Giving attention to issues make users more realistic in their requests and acts to deter requirement changes and scope creep.

Issues and Risk Management

DOI: 10.4324/9780080462509-1

Introduction

DOI: 10.4324/9780080462509-2

Common It-Related Problems

Information systems (IS), or information technology (IT), have been around for over 50 years. The goal of most IS or IT efforts has been to effect change and improvement in business processes and management information. People have been working at this for thousands of years. With all of this experience, you might think that IT work and projects would be very successful if completed on time and within budget.

Too bad. This is still not the case. In the 1980s people were writing that over half (50%) of IT efforts fail. Moreover, among those that are successfully completed, even fewer have resulted in change and improvement. Some recent surveys and one by the authors point to a percentage here of about 30–35% that resulted in tangible, measurable benefits. This is not very good. One disaster story in 2003 was that of a major Japanese bank that had undertaken a major IT project. It was a colossal failure — US$110 million was written off. No salvage. There appears to be little improvement.

Why does this happen? One reason is that technical staff and managers view each IT effort as unique and individual. System development is often viewed as an art or a craft. Lessons learned are gathered, if at all, at the end of a project, when most of the people have vanished to work on other projects and tasks. The experience and lessons learned that were collected were not organized, used, or updated.

The same issues recur again and again. We, the authors, with over 75 years of combined IT experience, have found that the same 100–300 issues or problems are present repeatedly. Here are some examples:

• 110 issues: major logistics firm in Asia
• 145 issues: luxury goods manufacturer
• 209 issues: government agency

If you doubt this, think about the number of times you have heard of the following issues:

• Scope creep
• Changing requirements
• High management expectations of IT
• Lack of user participation

Do these sound familiar? They should. They are just some of the more frequently recurring issues.

Here an issue can be either a problem or opportunity. If work has substantial issues, it has high risk. The issues are the underlying cause for the issues. If you resolve the issues, you mitigate the risk. That is the reason for this book — to provide pragmatic guidelines for managing risk and identifying, preventing, addressing, and measuring these common issues and problems.

If you begin work in IT with a high level of awareness of issues, then life is easier. There are fewer surprises. In IT, we have found surprises are largely negative. The proactive management of issues has proven to provide many benefits for IT organizations we have managed or consulted with.

• Having a common list and approach for many issues means there will be fewer surprise issues.
• There is cumulative improvement, in that a standard issues database is a repository that can be related to any IT effort or project. New issues can be added to the database. If you apply the experience in this database, you can solve issues faster and easier. Moreover, the issues are less likely to recur.
• Having a standardized risk and issues management approach can aid all IT activities — regular work, planning, small projects, support, and large projects.
• Tracking IT work through issues management can provide a much earlier warning system than standard measures of budget versus actual and scheduled versus actual plan.
• Issues awareness can make users, customers, managers, and IT staff more realistic as to what is possible given the purpose and scope of an IT effort.
• Issue detection and resolution improve and are more consistent over time.

Why It Efforts Fail

IT efforts fail often for the following reasons.

• Issues are detected too late. Management and staff may not be aware of issues or be looking at the glass as “half full.” Here is a lesson learned. Always look at the work as “half empty” — you will achieve more success.
• Issues are not managed well. Typically, issues are managed in an unsystematic, ad hoc manner. Moreover, different managers and leaders may deal with the same issues in different ways. Inconsistency leads to more problems.
• Issues are not tracked using the same measurements of both IT in general and IT project management in particular. This leads to more surprises.
• Experience in resolving issues, doing work, and completing work is not used to improve the management of issues in the future.
• People tend to make the same mistakes again and again with the same issues. This makes measurement, management, and estimation difficult at best and impossible at worse.

There are also problems with the traditional system life cycle. Here are some of them.

• When gathering requirements, it is assumed that users are supportive of the effort and change. This is often not the case. You need to get users to see the need for change.
• Traditionally, you seek to involve a few senior users (called here king and queen bees). These people are often the ones who are most resistant to change.
• After the requirements are gathered, users are asked to sign off and approve them. These approvals, as users have learned, are not legally enforceable. We have seen many cases in which users later state that they did not understand or that things have changed. Only with involvement can come commitment to the requirements.
• Users are left alone, sometimes for months. They have seen no results. The requirements gathering could have generated new ideas, resulting in change of scope.
• There is often a disconnect between the training and the implementation of the new system and the current business process. How to get from A to B is not made clear.

Many of the problems stem from a lack of understanding of users and business departments. Let’s examine the world from the user point of view. Users each day show up for work and try to get through it. Regardless of IT and projects, the user supervisors still want the employees to get their work done. There is not much incentive to do well in the project or to change.

Then there are the senior users who have been in their departments for years. We will call these individuals queen and king bees. They seldom take vacations and have vast knowledge of exceptions. As such, they have tremendous informal power. In some departments the supervisors and managers rely heavily on them to informally manage the work. They are seen by management as a great source of strength. Too bad this is flawed. The king and queen bees often act as barriers to change. In a number of ERP (enterprise resource planning) implementations they supply the business rules to the consultants and IT. If they put in all of the exceptions, the new system may work fine. However, it works just like the old process. What does this add up to? No benefits. However, the king and queen bees as well as the consultants win. Why? King and queen bees get all of their exceptions; consultants get more money, more billable hours.

What is an exception? An exception is a transaction that requires special handling or rules. An exception tends to be a rare event. An example in a standard bank branch is a very large deposit of money or foreign exchange in a strange currency. King and queen bees are often needed to handle this work. Exceptions make king and queen bees important. The more exceptions there are, the more power the king and queen bees have. However, the more exceptions that exist, the less productive and efficient is the department.

To IT, the visible process is seen through the systems provided and supported by IT. However, there is frequently more to the picture than meets the eye. Everyone develops his own shortcuts, tips, and tricks to get things done. It is the same with business departments. When an IT system does not meet their needs, they have to invent solutions. These spreadsheets, databases, or manual systems will be called shadow systems. Shadow systems are very important to many users, who may have a substantial investment in them. Shadow systems can also be created to handle new work on an ad hoc basis.

Your body, car, clothes, and apartment or house deteriorate over time. It is the same with business processes. When a new employee is hired, that person is often put into the work and not properly trained in the work. Deterioration sets in. Efficiency drops. Moreover, the new employee can easily fall under the (evil?) influence of the king and queen bees. King and queen bees may create new exceptions to deal with situations. When there are changes in the work, it may be easier to generate a new or modified shadow system than to call on IT and go through another life cycle.

Now you can connect the dots in the foregoing to get an overall picture.

• If the shadow systems are not included in requirements, the users may have to carry them over and even make changes to them to adapt to the new process. What incentive do the users have to do this on their own? Not much.
• If the king and queen bees are able to implement all of the exceptions, then there will be less or no benefit from the new system and process.

Does this sound too cynical? Perhaps, but all too often these things occur. Of course, there are times when the users want change, when the king and queen bees are willing to give exceptions, and when the shadow systems can all be incorporated into the new system. Experience, however, reveals these to be rare events.

It Differs From Other Types of Business Work

People in IT probably don’t think about this much. But it contributes to misunderstandings by management and business employees about IT and IT work. Figure 1.1 shows a table with some of the differences. Let’s comment on this table. A business unit employee typically shows up and starts to work. During the day the person completes groups of transactions. Each transaction is a single task. The transactions often are not related. In IT the staff member can be interrupted by questio...

Table of contents

• Cover Page
• Half-Title Page
• Title Page
• Copyright Page
• Table of Contents
• Preface
• Part I Issues and Risk Management
• Part II Internal Issues and Risk
• Part III External Issues and Risks
• Part IV Issues and Risks in Specific IT Activities
• Appendix A: The Results of a Survey on IT Issues
• Appendix B: The Magic Cross-Reference
• Appendix C: Websites
• Bibliography
• Index