Risk Workshop and Risk Register

ThePCNetProjectB.pdf

Home >Business & Finance homework help >Management homework help >Risk Workshop and Risk Register

The PCNet Project (B)

Dynamically Managing Residual Risk

04/2005-5272

This case was written by Christoph H. Loch, Professor of Technology and Operations Management at INSEAD. It is based on real events, but the names of all companies and participants have been disguised. Any similarity with existing companies is accidental. The case is intended to be used as a basis for class discussion rather than to illustrate the effective or ineffective handling of an administrative situation.

N.B. PLEASE NOTE THAT DETAILS OF ORDERING INSEAD CASES ARE FOUND ON THE BACK COVER. COPIES MAY NOT BE MADE WITHOUT PERMISSION.

DO N

OT C

OP Y

INSEAD 52721

The unexpected events that worried Jack Muller represented “residual risk”. In a project of such complexity, no amount of planning can ever anticipate all events, no matter how thorough; there will always be some events that are not planned for. Therefore, it is key to build the capability of dealing with residual risk as it comes along.

The direct outcome of the 18 September meeting was a strengthening of the aggregate oversight body (for the entire merger), not in the sense of it exerting more pressure, but in terms of adding experience and enhancing its problem-solving and advice-giving capacity. First, the Integration Management Committee Meeting became the Performance Monitoring Meeting, with a dedicated manager (who followed up issues), expanded membership to add relevant areas of expertise, and a more systematic synergy follow up.

The Risk Management Office

At the level of the IT integration, Max Schmeling had already begun to build a structure for managing residual, unforeseen contingencies during execution. The Risk Management Office (RMO) was put in place as a complement to the Project Management Office (PMO). Whereas the PMO followed up on actions and on reporting, the RMO focused on responding to deviations. It was a central control point to which all teams were required to call in at least once a day to report on progress and problems that arose.

The RMO achieved two things. First, it represented a problem-solving resource – Metal Resources Co. had its own technical experts present in this center, plus experts on call from all technical areas at the main systems vendors (such as HP and IBM for PCs, Cisco for routers, Microsoft for operating systems, SAP for R3, EDS for the network operation, etc), and experts in culture and change management were also on call. Thus, when an unforeseen problem occurred, the center diagnosed it with the team in question and then helped to mobilize the expertise to bring about, or plan, a solution as quickly as possible. Second, the rapid information exchange helped to set off alarm bells (early warnings) as well as solution approaches, across the many parallel teams. As they were working on very similar issues at multiple sites, a problem occurring at one site might well subsequently occur at one of the others, and thus the transfer of solutions was efficient. The rapid communication of relevant warnings from one team to another was dubbed “the hotwire”.

Thus, at each local deployment, a representative of the next local deployment team (in another state or country) was present so that they could become familiar with the logistical as well as technical issues. The Latin American deployment went very smoothly as a result of this approach. Similarly, problems that arose in the application migration to the new platform in Singapore were subsequently avoided throughout the Southeast Asian region.

Both the PMO and the RMO also attempted to prevent certain risks by enforcing strict standards (thus reducing the complexity and number of things that could go wrong), such as all of North America having to move to a single SAP system configuration (there was a separate central control center for that project alone, which worked with all the organizational units to produce a common standard that satisfied most of the needs). Many technical and business software applications were standardized (such as statistical analysis packages,

DO N

OT C

OP Y

INSEAD 52722

geological expert systems etc.), which, in turn, reduced the number of different problems that could occur and facilitated the sharing of solutions across teams.

The activities of the RMO enabled the organization to work with budget and schedule variances (deviations) in a more sophisticated way, for example, by performing variance analysis. There was significant overspending in Phase 3, because some work originally foreseen for Phase 4 was in fact carried out at this point due to small “design changes” or improvements in protocols and processes as the organization learned during the project. The activities of the RMO involved providing explanations and documentation for residual risk and the respective actions required. Thus the organization had a ‘trace’ that offered a thorough explanation of deviations and an institutionalized effort to learn from such changes.

The following example illustrates the effect of such learning: the early PC deployments took several man days per person as the migration team was learning and stabilizing the components of the network, whereas later deployments required only a few hours (a reduction of 75%) and were much more stable. Overall, the project remained slightly under budget, although it took 6 months longer than originally planned.

Dealing With Individual Residual Risks

The problem of lost e-mails and corrupted e-mail capabilities had to be attacked at two levels. The first level was technical: when the lost file incidents were examined, the root problem turned out to be that Microsoft XP did not have a translator to automatically modify files. In response, the Microsoft developers made their own in-house translator software available which systematically eliminated the problems and improved the overall robustness of the network. Several similar fixes contributed to overall network stabilization. The second solution level concerned change management processes: over time, the merger team put such processes in place (“who can change what system features, after discussing it with whom”), and convinced employees to comply with them, which eliminated incompatibilities introduced by local changes.

The Sri Lankan government partner eventually came on board, although at its own pace. This contributed to a six-month delay but did not “stop the show”.

The refining manager who refused the deployment was won over with a combination of carrot and stick. On the one hand, the IT organization conducted a security audit at his site, which exposed serious vulnerability to external attacks and other breakdowns. This allowed the team to show him how badly it might get for him locally (carrot) and make it clear that he could not be permitted to pose a risk for the rest of the organization (stick).

The cajoling and convincing of the refining plant manager was then generalized to a standardized, prepared, compelling argument that was used with operating managers who thought they had no time for off-line activities like IT migration (Exhibit 1). The argument again combined carrot and stick – on the one hand it explained the benefits to the operating units themselves and emphasized that they could get help; on the other it threatened them that their network would no longer be supported if they did not migrate. This standard argument was, of course, complemented by personal visits and face-to-face explanations.

DO N

OT C

OP Y

INSEAD 52723

Overall Project Success

“You guys will have to learn how to walk, whistle and chew gum, all at the same time.”

Martin Folz, CEO

The ITC organization did learn to “walk, whistle and chew gum at the same time”, as the CEO demanded. They took the metaphor seriously enough to define it: walking meant to not disrupt ongoing operations, whistling to lead the project with state-of-the-art methods, and chewing gum stood for status reviews and dealing with residual risks. At the end, no unexpected event was serious enough to break the project. The thorough planning, combined with the flexibility of the RMO and the hotwire, was so powerful that the huge IT merger became a convincing success. The total IT merger project beat its target by $20 million, producing $230 million of synergies in the first year, and the PCNet project made a significant contribution to this overfulfillment (partially driven by an extra $10 million in PC discounts that came out of the proactive negotiations).

Critical to this success was the support and constancy of purpose of top management: the CEO listened to the business case and stayed the course. No IT migration budgets were cut, in spite of the lean economic times, and the project was able to maintain priority and focus.

DO N

OT C

OP Y

INSEAD 52724

Exhibit 1 Communication Document for Operating Company Compliance

The PCNet Deployment Consultant team presents……..

The Top Ten List of “Reasons why you should quickly and carefully decommission your legacy IT environment”

10. Dual environments will make it more difficult to maintain IP compliance, particularly once Microsoft ceases support of NT 4.0.

9. Dual environments are impacting our networks due to unnecessary traffic from the legacy infrastructures such as file replication, Exchange Global Catalog replication, SMS inventory and package traffic, as well as WINS and DNS traffic.

8. Increased vulnerability to security attacks and viruses as vendors start dropping maintenance support for Win9x, NT4 and W2K, and our internal centralized efforts are no longer funded for these environments.

7. Increased cost for support as troubleshooting by support staff becomes a lot more complex due to having to follow separate processes and using different tools in order to support two environments. Cost also increases due to reduced reliability and increased break/fix calls as hardware has lived long past its planned life-cycle.

6. Legacy Master Account NT4 and AD domains will be decommissioned, leaving resource domains with no trusts. The old PC and workstation environments will lose connectivity. There will also be performance issues as Master Account domain controllers are removed one by one.

5. The decommissioning effort is part of Metal Resources and RBD synergy cost-savings and the realization of these savings now becomes our responsibility.

4. The business case for the synergies will be compromised by having to support dual infrastructures.

3. Manpower can be redirected towards strategic projects once deployment and decommissioning efforts are completed (and we can take our vacations now!).

2. Old computing standards monthly costs will be increased by x2, x4 and x6 the longer you keep your old hardware. Costs to maintain old infrastructure will be divided by the number of remaining old standard users.

And the #1 Reason is …

1. The old desktop has been declared “non-standard”. Yes, it is true. The sun has set on the old standard, with the IT design team only providing Anti-Virus updates and major security patches.

Having old standard machines at your site makes your site “Non-Standard”. ----------------------------------------------------------------------------------------------------------------------------------------

Here are three documents to help you in your efforts to decommission: Decommission Legacy Systems Guide Decommissioning Server Assets Decommissioning Workstation Assets

*** If the thought of pulling the plug on your favorite Compaq Proliant server is giving you nightmares and sleepless nights, then please email me back about getting the PCNet Deployment Consultant team to offer decommissioning consulting services at your site.

DO N

OT C

OP Y

To order INSEAD case studies please contact one of the three distributors below:

ecch, UK and USA Centrale des Cas et de Médias Pédagogiques

ecch UK Registered Office: ecch USA Registered Office: www.ecch.com www.ecch.com www.ccip.fr/ccmp/ Tel: +44 (0)1234 750903 Tel: +1 781 239 5884 Tel: 33 (0) 1.55.65.65.97 Fax: +44 (0)1234 751125 Fax: +1 781 239 5885 Fax: 33 (0) 1.40.54.06.93 E-mail: [email protected] E-mail: [email protected] E-mail: [email protected]

Boulevard de Constance, 77305 Fontainebleau Cedex, France. 1 Ayer Rajah Avenue, Singapore 138676 Tel: 33 (0)1 60 72 40 00 Fax: 33 (0)1 60 74 55 00/01 www.insead.edu Tel: 65 6799 5388 Fax: 65 6799 5399

Printed by INSEAD

DO N

OT C

OP Y