Editor’s note: This article was originally published October 7, 2002.
My company is a very large organization with more than 45,000 employees worldwide. We operate in a typical market characterized by continuous change and intense competition. During our worst years of recession, in the late ’80s and early ’90s, we had to focus on planning more effectively and becoming more efficient in executing the work we planned. During this period, our IT department faced a dramatic increase in the demand for services to enhance, support, and develop our core business.
Management’s expectations crystallized for the IT delivery functions. Increased quality, decreased delivery time, and continuous improvement in service levels were receiving higher emphasis. In addition, we had to meet these objectives within tighter sets of constraints (schedules, resources, and technical performance).
These additional demands on IT also increased the level of risk we faced as a department and as a company. Identifying and addressing those risks was the first step we took toward implementing a risk management program.
Sources of risks
Because of the size and complexity of our organization, we had to face many sources of risks:
- The continuous change in our customers and end-user requirements
- The continuous increase in the complexity of the IT systems required to develop our core business, compounded by the need to deliver these systems faster and cheaper
- The continuous change in the structure of our organization due to the nature of our core business
- The introduction of new management processes and standards within our organization
Symptoms of the problem
Our IT projects were failing frequently. The following are examples of the symptoms that made us realize the necessity for implementing a risk management program across the board:
- We frequently found it difficult to identify the relationship between our information systems (IS) strategy and the IT projects that we were undertaking.
- Our IT projects on many occasions were delivering systems that did not meet our end-user needs and their expectations.
- Our IT projects were often falling behind schedule.
- Our objectives were frequently ambiguous or not clearly defined.
- We had become more reactive — as opposed to proactive — over the years.
Although there were no direct threats to the viability of our organization, we recognized the need to overcome these pitfalls in order to increase our competitiveness. We were fully convinced that we needed to make the transition from reactive management — such as fire fighting and finding workarounds — to proactive management, where we perceive risks as potential threats or opportunities.
Questions needing answers
At that point, we had many questions, but we were unsure of the answers:
- What did we mean by a risk?
- What did we mean by risk management?
- What did we need in order to implement a risk management program across the organization?
- What skills and training did we need to staff this program?
- How could we measure the benefits?
- How much time did we need before we could recognize the benefits?
- How could we ensure that we did not increase bureaucracy?
- How could we secure support?
- How could we ensure that the program did not limit innovation?
- How could we devise a flexible program that could deal effectively and efficiently with the diverse range of projects that we encountered?
- How could we secure resources to deal with risk management if these resources were already engaged in problem management?
These were a few of the concerns that we had. We realized that we needed to implement a systematic risk management program across the enterprise to make the transition from problem management to risk management. We decided to undertake a problem definition approach that would enable us to articulate clearly the needs we had to address.
The main objective of problem definition is to further clarify the problems that we needed to address in our risk management program. The procedure that we followed in this stage consisted of three steps:
- 1. Solicit the input from cross-functional representatives.
- 2. Analyze the information gathered.
- 3. Document the information gathered in a problem definition report.
We used several tools for gathering information such as interviewing, questionnaires, workshops, and discussion forums.
We recognized that finding a high-level sponsor and securing funds and other resources was critical to the success of the risk management project. The critical success factor behind securing top-level support was the problem definition report. The report depicted views at all levels of the organization and pointed out the missed opportunities and problems that needed to be addressed. The report provided upper management with a justifiable business case that paved the way for financial and political backing. The project rapidly gained full support from our vice president of operations, who was instrumental in helping us move forward and overcome implementation-phase obstacles. His commitment to the program was also key to the continuous improvement and endorsement of the program throughout the company.
We used the problem definition report to identify these goals for our risk management program:
- Establish a common language and understanding of risk across the organization by using standard definitions for risk and the terminology associated with it
- Agree and document our policy on risk management
- Develop and implement a systematic, robust process for risk management that is flexible and compatible with our existing culture
- Ensure that the process was fully supported with the required tools and techniques
- Ensure that anything we implemented added value rather than increased our administrative overhead, further depleting already stretched resources
- Ensure that we had a set of well-defined metrics that would enable us to determine whether the perceived benefits were achieved
Planning the risk management project
The first challenge that we faced in beginning the project was the lack of internal experiences in dealing with risk management programs. Our experiences with risk management were vertical and focused on a particular type of risk — for example, the technical risks associated with a specific development tool or a specific commercial-off-the-shelf component. We needed access to individuals who were well versed in implementing risk management programs across organizations. It soon became apparent that we needed external support.
We were very meticulous in selecting the external consultancy. We needed external consultants who had the relevant skills and competencies, were willing to share their knowledge, and able to provide a high level of knowledge transfer. We knew that the program could not survive if it was dependent on external support for a long period. The candidates had to demonstrate proven experiences of what we wished to achieve.
The second challenge was the project organization. This project had a company-wide impact. It required representatives from all functional areas. These representatives had to be able to make decisions relevant to their functional processes, and solicit the commitment of their staff. The “Risk Management Program Steering Committee” was composed of representatives from all of our functional areas, including information systems, business development, operations, human resources, and procurement.
The project team consisted of the external consultant, two full-time technical writers, and the project manager, who reported directly to the vice president of operations.
We divided the program into the following phases:
- Developing: Developing the contents of the risk management framework
- Piloting: Limited implementation of the framework in order to gather first-hand experiences
- Reviewing: Enhancing the framework by incorporating the experiences gained in piloting
- Deploying: Implementing and rolling out the framework across the organization
- Supporting: Providing the infrastructure for long-term support and continuous enhancement
These phases were iterative and overlapping. We had to go through several iterations of developing, piloting, and reviewing before we deployed the framework. The supporting phase provided us with valuable comments that we used in the continuous process of enhancing the framework.
In the second part of this three-part series, George Sifri will explain how the company developed and implemented the risk management framework.
Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!