Based on the case study, please answer the following questions:

Question 1: How can you correlate the financial impact of the most and least likely scenarios mentioned in the case study?

Question 2: What financial protections can you implement if the project is not successful?

On 18 September 2003, Jack Muller, the project manager of the PCNet project, was preparing for the Integration Management Committee Meeting scheduled that afternoon. The PCNet project involved the merging of the entire IT network infrastructure, including routers, telecom lines and 40,000 PCs, following the takeover of RBD Inc. by Metal Resources Co. The IT merger promised net present value (NPV) savings of $142 million over four years at a cost of $146 million. The team had carried out an extremely thorough planning exercise and felt that they had gained a good understanding of the drivers and contingencies. The project had got off to a good start, closely watched by upper management because it was so important for the entire merger and subject to a number of significant risks.

But recent events were threatening to throw them off track. Unforeseen problems had dogged implementation, such as files lost in the migration to the new operating system, and unexpected requirements for local content in newly installed PCs by the authorities of several countries including Angola. Moreover, the plant manager of a major chemical plant was refusing to migrate (jeopardizing the migration of 900 seats), having originally agreed to the migration. One major partner, the Sri Lankan government, had suddenly decided to further study the matter before proceeding, threatening the migration of 2,000 seats. To top it all, the world economy was sliding into the severe post-9/11 crisis, and there was even talk that the combined company might not be able to afford to keep this very expensive IT migration project going to the end.

The PCNet Project The PCNet project was the key enabler of the whole merger, not just the IT integration. It encompassed the development of a global communications network, a standard network server infrastructure, an enterprise security and directory system, and a worldwide standard desktop environment (see Exhibit 3). The business case called for total NPV savings of $115 million, with a project budget of $149 million. The NPV figure was based on direct savings on infrastructure costs alone. In addition, the project enabled further savings, such as cutting 130 different applications in the finance area, and it later made the transition to an enterprise-wide ERP system (SAP) much faster and smoother. The lions share, both in savings and budget, came from getting the 40,000 desktops (31,000 on the original Metal Resources side and 9,000 on the RBD side) to standardize on Windows XP desktops (HP) and laptops (IBM). The corporate network, previously centered on the bottlenecks in Austin and Winnipeg, was to be consolidated around three central hubs: Austin, Johannesburg and Singapore (see Exhibit 3), with added bandwidth to the rest of the network and added internal redundancy. The servers were standardized to Windows 2000. Previously, the network had had almost 900 routers, a number that was greatly reduced by the consolidation. Ultimately the goal was to go from 10 different directories and multiple security systems and firewalls down to one each. The multiple directories caused some headaches for example, executives who had been re-assigned stopped receiving their e-mails until the IT staff could locate the directory in which they had been listed! The network integration involved reconciling outsourcing decisions that had been handled differently in the past by the two companies: Metal Resources had outsourced mainframe, telecoms and the help desk to EDS, while RBD Inc. had outsourced the server environment and the help desk to IBM. To move fast, IT management decided to shift the entire package to EDS (the provider who already had the bigger piece), and to take some server services back in house. In addition to the four integration areas, Jack Mullers project organization included his own project management office, one group for implementation and operations, and a planning group with several analysts who compiled business cases, risk analyses, and maintained the tracking tools. Embedded in the master plan for IT integration, the PCNet planning group developed and maintained its own plan and milestones (Exhibit 4). Much of the actual work (such as physically installing routers in basements and desktops in offices) was performed by local staff in the operating companies; the central project organization coordinated, standardized, oversaw time plans, and centrally sourced the standardized components. Risk Management Risk Identification Great attention was paid to risk management from the beginning. Risk plans and reviews were formally included in all project plans. (An aggregate risk list is shown in Exhibit 5). The main risk areas were seen as operating company acceptance (they had to perform and pay for a lot of the detailed implementation work and loathed the distraction from their pressing priorities); staying focused when too many activities were competing for the same scarce resources; security breaches during the transition; and any change in business climate that could threaten the availability of funds to complete the merger. Risks were estimated with potential impacts (where possible), mitigation (or countermeasures) and contingent action (a prepared fast response when risks did occur). The aggregate risk list rested on many lower-level risk identification efforts (see Exhibit 6 which focuses on HR and personnel retention risks), showing where the impact would lie (e.g., in achieving synergies, or in continuing business), whether the impact would be financial, or on the schedule, or on solution quality, and how great it would be in financial terms. The list estimated the probability of the risk and indicated the impacted parties and the owner or party responsible for responding to it. A project of this size can never be executed without encountering adverse events or hiccups. The risk planning represented a thorough homework exercise that allowed the organization to be prepared in case adverse events struck anticipating such events prevented any potential panic and the mitigation/contingent action exercise provided ready-made (rough-cut) solutions around which a team could develop a quick response. Risk Monitoring and Management Risk prioritization allowed the merger team to be proactive and responsive. First, supervision concentrated on areas of high exposure. For example, the PCNet project came out as high priority (see the classification in Exhibit 7), the desktop and server subprojects were in the upper right quadrant (high value and high risk), and the network project, while not directly of high value, was of high strategic importance and thus classified as high risk. Jack Muller could not complain about any lack of attention from upper management. In addition, the identification of the most important risk drivers by the value distribution curves (Exhibit 8) allowed the project team to manage them proactively. Two examples illustrate this. For the desktop project the dominant risk lay in the prices set by the PC vendors (HP for the desktops and IBM for the laptops), so a team of project managers visited the vendors and aggressively negotiated in order to lock in prices at a low level. Not only did this reduce the savings variance (guaranteed prices for all countries were obtained), but the centralized negotiation also achieved prices that were even lower than hoped for, garnering additional savings. The second example relates to the schedule risk of actually delivering all the desktops to all countries on time for the new system to start. As Metal Resources Co. operated in countries such as Angola, Congo and Armenia, warfare might disrupt delivery and gatekeepers, consultants, or bureaucrats could block every move until their permission had been sought. (Sometimes they merely wanted to be shown attention and respect). Generally, the schedule risk was high in such countries deployment might even be endangered entirely so for countries with significant bureaucratic restrictions a plan was devised with countermeasures, emergency procedures and appropriate buffers to allow for disruption. Deployment was not started until any remaining uncertainty had been removed and a high level of confidence installed that it could be carried out within the buffers imposed. Project Execution Monitoring and Reporting In October 2002 work started in earnest, hitting multiple fronts at the same time: telecom lines were rented and connected, network equipment exchanged, security policies and software and directories set up, and PCs switched. Control of the larger projects was paramount to keep the integration on track and produce the savings. An integration management office was set up for the merger as a whole (the Integration Management Committee Meeting, of which Max Schmeling was a member), and ITC had its own integration office, the project management office. At monthly meetings progress was tracked using metrics summarized in a deployment progress monitoring tool (Exhibit 9) which reported on the status of PC deployment (for example, in January 2003, 1,447 of the 40,000 PCs had been migrated), sites with upgraded networks, reduced Internet access points to the global network, and reduced standard applications. The dashboard also showed the current budget status and included remarks about current events in the various regions of deployment. In addition to the progress tool which focused on operational figures, budgets and, of course, financial synergies (or savings) were reported. Savings were a matter of urgency: only when they had been achieved and documented could they be incorporated into the accounting and book-keeping systems, and then reported to external financial analysts. Being able to report booked synergies is very important for a CEO after an acquisition. It soon became clear that the synergy progress reporting was causing misunderstandings and tensions. As Exhibit 10 shows, progress was not smooth but occurred in jumps. For example, a site had to be completely migrated (up to three months work) before savings really accrued, but then a large sum was saved at once. The gray bars in Exhibit 10 indicate internal progress targets, the dotted red line represents synergies captured at the day of the report (April 30), and the solid blue line the synergy forecast (top panel: all IT systems, bottom panel: ITC). As is usual practice, the forecast line had been smoothed. This caused a seeming deviation from the plan as for up to three months it looked as if synergy capture was lagging (before it caught up), although it was a reporting artifact. This required a lot of reassurance: Although nothing has been booked, you have to trust us that the site migration is really on track and the savings will accrue as planned! Reporting to and educating of the supervising committees had to go hand in hand. Unexpected Events The PCNet project had gotten off to a good start. After the huge initial effort to get things going, Jack had had the feeling that things were going well. But more recently problems had begun to arise, none of them catastrophic by itself but damaging overall, and Jack started to worry about continuing progress. For example, the IT organization had managed on day one of the merger to build connectors between the two corporate networks, but there were no standards in place across the entire merged corporation. Without rigorous change management processes in place, well-meaning people could (and did) introduce tweaks in, say, the destabilizing an entire sector of the network. As a result, e-mail files were lost and messaging capabilities corrupted. persist to this day). Moreover, some of Metal Resources Co.s partner national companies suddenly started to demand local content or brokers to be included in the channels of the hardware systems. These channel conflicts often caused delays and had to be mapped out and worked around, taking time and resources. A different kind of problem occurred in Sri Lanka: the government partner, who was paying for the migration of 2,000 seats, decided that it would need to study the proposal more thoroughly before giving its approval. This meant extra justification and a localized business case had to be submitted, again costing Joe time and resources. And problems not only came from the outside. Several times a business unit leader within Metal Resources would decide to slow the migration or postpone it from the original schedule to avoid business disruptions or to avoid the costs. One large European office threatened to delay a major deployment that had scheduling impacts on several other sub-projects. The 18 September 2003 Integration Management Meeting The overall merger progress status looked still OK. Of the six huge integration areas, none was seriously behind. IT integration had passed a major milestone in the summer and the next major one at this aggregate level was not until January. In that sense, the situation was not urgent. However, the string of unexpected events made Jack worry; hiding them was not an option. If the Integration Management Committee got the impression that progress was stalling in the linchpin PCNet project, they might panic and start breathing down his neck real hard. The economy had slipped into a severe crisis, and Metal Resources Co. (like all major industrial companies) had started a general belt-tightening and budget-cutting exercise. The IT migration project was very expensive; if top management started to doubt the benefits, they might take radical steps and stop the entire thing or major parts of it. Jack Muller gathered his slides and braced himself for a fierce discussion. How was he going to calibrate the progress hiccups to Max Schmeling and the Integration Management team? How would they react?