Posted: April 24th, 2025
project Risk Analysis
Assignment Overview
Quantitative risk analysis is mandatory for many private organizations and government agencies in medium- and large-scale projects. Due to its advantages recognized by both practitioners and academics, Monte Carlo simulation has become a widely applied technique in quantitative risk analysis. This assignment will introduce students to Primavera Risk Analysis (formerly known as Pertmaster and Primavera Pertmaster) and how probability theory is applied in quantitative risk analysis.
This assignment is associated with the following course learning outcomes:
- Analyze risks using quantitative methods for the purpose of risk exposure and prioritization and communicate their impact to stakeholders
- Recommend risks for risk response planning or watch list
- Devise a risk response plan based on appropriate techniques and strategies that would meet stakeholders’ expectations
- Execute the risk management plan to continuously monitor risks and risk responses
Assignment Instructions
Part 1. Follow the instructions provided in Canvas>Modules>Resources for Primavera Risk Analysis and download Primavera Risk Analysis to your computer. Primavera Risk Analysis runs on Windows operating systems. You cannot install it on a Mac OS without splitting your machine. If you are a Mac user, you can install Windows applications on your Mac by doing one of the following:
- You can install Windows 10 on your Mac with Boot Camp Assistant.
- You can install Parallels or VMware Fusion on your Mac to split your operating system.
- You can also install Primavera Risk Analysis on a virtual machine.
Part 2. Create a Word document with APA title page and answer the following questions:
1. How can Primavera Risk Analysis help project managers increase the probability of project success?
2. How does Primavera Risk Analysis work? And what are its limitations?
Hint: Answering these questions requires you to conduct some research and explore the software application. Some useful sources include the University library, Oracle website, and the Help menu of the software.
Part 3. The application of probability distributions to project schedule and cost models
1. What is your understanding of the following probability distributions? Discuss how each can impact a project schedule and/or cost.
a. BetaPert
b. Triangle
c. Normal
d. Uniform
Part 4. Performing a Monte Carlo simulation for a project case
- In this part of the assignment, you will perform a Monte Carlo simulation for the project case you selected during the first week of the class. If you did not create a performance measurement baseline for your project case, update and use the template provided in Canvas>Modules>Performance Measurement Baseline Templates. Make sure that the finish date of your project baseline is set on a future date (e.g., October 14, 2050). Based on your experience and your research so far, you can decide on the probability distribution (s) and the number of iterations for your simulation. Please explain the rational for your decisions.
- Your task is to examine, discuss, analyze, and interpret the results from the simulation.
- What information have you obtained from the results of the simulation?
- Explain how the results of the simulation may affect your commitment to the most likely completion date of the project.
- What did you learn from the Tornado graph?
Your pper should be written as an esay with topical headers; it should not be formatted in a Q&A format. These sections represent the minimal items that you would want to address. From your readings and your lectures, you will be exposed to other topics that may be relevant to this pper, and you would do well to consider those in writing the esay. As part of my evaluation process (see attached rubric), ppers which cite peer reviewed sources as opposed to general websites or articles are considered a higher quality of source.
Below are some key guidelines you will want to ensure you follow in writing the pper. Think of this list as a quality control checklist, along with the attached grading rubric.
- There is no page limit for this pper
- Include a title page and reference listing
Pper format complies with APA 6 or 7 guidelines (e.g., Time New Roman (12 points font) and with 1-inch margins on all sides). Double-space is NOT required.
If you are unfamiliar with APA 6 or 7 guidelines, please review the sample pper at the following link: https://owl.purdue.edu/owl/research_and_citation/apa_style/apa_formatting_and_style_guide/documents/20200128APA7ProfPaper (Links to an external site.)Links to an external site.
(Links to an external site.)Links to an external site.
Please be sure to review the attached rubric which will be used to grade the assignment. The rubric, along with the assignment instructions, will ensure that you have a clear understanding of the requirements of the assignment.
Watch these videos before submitting this assignment:
https://youtu.be/2gvwLZQ1vNULinks to an external site.
© HEC Montréal 2012
All rights reserved for all countries. Any translation or alteration in any form whatsoever is prohibited.
The International Journal of Case Studies in Management is published on-line (www.hec.ca/revuedecas/en), ISSN 1911-2599.
This case is intended to be used as the framework for an educational discussion and does not imply any judgement on the
administrative situation presented. Deposited under number 9 65 2012 001 with the HEC Montréal Case Centre, 3000, chemin de
la Côte-Sainte-Catherine, Montréal (Québec) Canada H3T 2A7.
Volume 10
Issue 1
February 2012
Successfully Navigating the Turbulent Skies of a Large-Scale ERP
Implementation1
Case prepared by Professor Benoit A. AUBERT,2 Simon BOURDEAU3 and Brett WALKER4
This case presents two phases of a large business transformation project involving the
implementation of an ERP system with the aim of creating an integrated company. The case
illustrates some of the challenges associated with integration. It also presents the obstacles facing
companies that undertake projects involving large information technology projects.
Bombardier and Its Environment
Joseph-Armand Bombardier was 15 years old when he built his first snowmobile by propelling a
farm sleigh across snow with the engine from a Model T Ford (CBC Archives). From these
humble beginnings, Bombardier went on to become a key player in the transportation industry. It
entered the rail transportation market in 1974, with a contract to produce 423 subway cars for the
City of Montreal. A contract to supply New York City with 825 subway cars followed eight years
later (CanadianBusiness.com). Bombardier’s desire to diversify led it to enter the aerospace
industry in 1986, when it purchased Canadair, the leading Canadian aircraft manufacturer.
Bombardier acquired Short Brothers plc, a manufacturer of civil and military aircraft based in
Northern Ireland, in 1989, and Lear Jet Corporation in 1990 (Koselka, 1992). Bombardier made
its final major acquisition in the aerospace industry in 1992, with the purchase of the de
Havilland Company from Boeing (a timeline is provided in Appendix 1).
For the year ending January 31, 2007, Bombardier Limited reported revenues of $14.8 billion.
The Aerospace and Transportation divisions contribute fairly equally to total revenues.
1 The authors would like to thank all the people at Bombardier who participated in the case study, with special thanks to Souad
El Mallem and Robert Proulx for their exceptional contribution. The authors would also like to thank Nicolas Perreault and
Alexander Schnepel for their help in conducting this study.
This research was supported by the CEFRIO.
2 Benoit A. Aubert is a Professor in Governance and Information Technologies at HEC Montréal.
3 Simon Bourdeau is a Ph.D. candidate at HEC Montréal.
4 Brett Walker is a Business Information Manager at Astellas Pharma Europe Ltd.
HEC035
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 2
Bombardier Transportation posted revenues of $6.6 billion for the period ending January 31,
2007. This represented 45% of Bombardier Limited’s revenues. Bombardier Aerospace reported
revenues of $8.2 billion for the same period, or 55% of total revenues.
Bombardier Aerospace
Bombardier Aerospace is now the third largest designer and manufacturer of commercial aircraft
in the world, after Boeing and Airbus, and the leading producer of regional aircraft. It is one of
the two largest manufacturers of business aircraft in the world (Hoovers Online), with the widest
range of business jets in the market (Canadian Business Resource).
The Montreal-headquartered Aerospace division employs more than 27,130 people across
13 facilities worldwide (Bombardier – About Us). Six facilities are located in Canada, six in the
United States, and one in Northern Ireland (Bombardier – About Us). The division’s management
and administration employees are predominantly based in Montreal, Canada. Bombardier
Aerospace’s various plants have specific roles in the completion of different aircraft. These roles
include component manufacturing, component assembly, final assembly, painting and interior
completion, and pre-flight testing and delivery.
[See Appendix 2 for a list of Bombardier’s various facilities, their locations, and roles.]
Bombardier Aerospace’s products
Bombardier Aerospace is organized into four product and service lines: business aircraft, regional
aircraft, amphibious aircraft and defence services. Within each of these lines, there are different
families of aircraft, each with several aircraft programs (an aircraft program involves the design
and production of one version of aircraft). The company has introduced 15 new aircraft programs
in 15 years, and it certified a new aircraft every year from 1992 to 2000. Additionally,
Bombardier Aerospace offers services such as aircraft charter, fractional ownership of business
jets, aircraft maintenance and pilot and maintenance training.
Bombardier Regional Aircraft consists of the CRJ Series of regional jets (which seat between 50
and 86 passengers) and the Q-Series of regional turboprops (which seat between 37 and
78 passengers). There are four aircraft programs within the CRJ Series and three aircraft
programs within the Q-Series. Based on order intake, Bombardier’s regional aircraft held 50% of
the market share for the 20-90 seat segment of the regional aircraft market in 2005.
Bombardier Aerospace firmly believes that a larger regional jet is necessary to compete with the
range of 100-seat planes that its nearest rival Embraer is introducing to the market. The C-Series
was launched during the Farnborough Air Show in July 2008. These highly fuel efficient jets will
carry between 110 and 130 passengers and will have the ability to fly transcontinental routes.
Bombardier’s competition
Bombardier’s closest competitor is Brazilian-based Embraer, the next largest aircraft
manufacturer after Bombardier. Embraer focuses on regional aircraft, but also produces military
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 3
aircraft and one corporate model. Its range of 8 regional aircraft consists of both turbo-prop and
regional aircraft. The Brazilian government owns more than 20% of Embraer (Hoovers Online).
Boeing and Airbus occupy the top tier of aerospace manufacturers. Their focus is on the
production of large commercial jets. The passenger capacity of Boeing and Airbus jets generally
ranges from 110 to 400 passengers. In addition to producing commercial aircraft, Boeing is also
one of the world’s largest defence contractors. Gulfstream is Bombardier’s main competitor in
the market for business aircraft. The American-based company had revenues of $3.4 billion in
2005. Gulfstream offers seven models of business aircraft as well as operating a fractional-
ownership program similar to the service offered by Bombardier Aerospace.
Conditions in the aerospace industry
The willingness of the public to purchase airline travel is subject to economic conditions and the
socio-political climate. This, in turn, directly impacts the performance of airline carriers and the
aerospace manufacturers that supply them with aircrafts. The terrorist attacks of September 11,
2001 had an adverse effect on the airline industry. The detrimental impact of 9/11 was worsened
by the outbreak of Severe Acute Respiratory Syndrome (SARS) and the war in Iraq (Federal
Aviation Association, 2004). The combination of these events led to reductions in passenger
numbers for large carriers.
Continuing a trend that has been ongoing for several years, regional and low-cost carriers grew
much faster than their legacy carrier counterparts. In 2005, the domestic market share for these
carriers increased 2.2 points to 45%, up from a 30% share in 2000 (Federal Aviation Association,
2006). For this reason, the focus on regional aircraft means that Bombardier is well positioned to
survive the adjustments occurring in the airline industry.
Business problems
While it now has a comprehensive range of aircraft and a global presence, the company’s strategy
of growth by acquisition has generated some challenges. A senior project manager at Bombardier
Aerospace commented that the organization has become a ‘textbook silo organization’ as a result
of its acquisition strategy. Bombardier Aerospace inherited the data, processes and systems of
each company it acquired. This created problems and inefficiencies, as systems did not
communicate with each other effectively. It was difficult to share data between manufacturing
facilities, labour mobility suffered due to the fact that the skills required to operate information
systems were not transferable between facilities, and the cost of information systems ownership
was multiplied by the number of systems maintained.
Several problems related to the operation of the Aerospace division were beginning to concern
management. These included process delays, sequential activities, low inventory turns, supplier
proliferation and price inconsistency, and multiple bills of material. Bombardier Aerospace
believed the biggest problem it faced was low visibility of inventory and lack of integration
between its legacy systems.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 4
Legacy information systems
The group of information technology applications that had been supporting Bombardier
Aerospace’s manufacturing activities since the early 1990s was known as the Bombardier
Manufacturing System (BMS). It was based on a MACPAC platform. This system had served the
company well, but it had not evolved to cope with the changes the business had undergone and
with the challenges it was now facing. Among other things, the BMS was struggling to cope with
increasing inter-site dependencies, persistent pressures on costs, the rapid introduction of new
products and a greater need for integration with business partners. According to the Vice-
President of Operations and Project Sponsor, “MACPAC was showing a great deal of ageing. It
was becoming increasingly difficult to operate, the data accuracy was appalling, and, indeed, the
future development of the Company was being impaired by the system.”
The BMS capabilities had become limited and the future development of the company would
have been constrained if manufacturing systems had not been updated. According to the Vice-
President of Operations, the production of the 90-seat CRJ900 aircraft would not have been
possible using the company’s legacy platform.
Employees had created a proliferation of stand-alone, user-developed databases throughout the
company which were being used to maintain data on operations specific to their function. This
fostered a culture where employees were unaware of the implications of data errors or omissions
on the rest of the organization. Poor data management could hinder future initiatives such as the
planned business-to-business procurement portal.
For the past 12 years, Bombardier Aerospace had been trying to align the operations of its
acquired companies by implementing common roles and responsibilities and common company
values, and by introducing Six Sigma tools for the evaluation of processes. The Vice-President of
Operations and Project Sponsor was acutely aware of the challenges and created a vision for
Bombardier Aerospace that he termed ‘One Company.’ The desired outcome of this vision was
an integrated organization in which employees would seamlessly share common data across sites
and products using a single set of unified systems and processes. However, the project was more
of a business transformation than a mere technology implementation, and it was critical that the
project be grounded in a strong business foundation. He realized from the outset that altering
decades of tradition was going to be an enormous challenge.
The BMIS Project
An Enterprise Resource Planning (ERP) system was considered by Bombardier Aerospace as the
best way to realize the strategic vision. It was well aware of the risks associated with
implementing an ERP system. A first ERP implementation at Bombardier Aerospace was
discontinued mid-project in 2000 after $130 million had been spent. Various factors were
subsequently identified by the company as having contributed to its failure. They included
focusing the implementation on inappropriate business processes, an outdated company vision, a
weak sponsorship model and insufficient involvement of internal employees.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 5
In 2001, the process of establishing the need for a new integrated manufacturing system was
headed by a group of senior managers from Bombardier Aerospace’s Irish facilities. The Senior
Project Manager authored a project charter for the Bombardier Manufacturing Information
System (BMIS) in October 2001. This document outlined the motivation for the project and a
proposed plan for realizing project goals. The detailed analysis presented in the charter was used
to secure ongoing approval and funding for the project.
A BMIS steering committee chaired by the Project Sponsor was put in place in order to focus the
project within the wider context of the business. At monthly meetings, the committee would
make decisions on the direction of the project, review the status of the implementation and
resolve issues that had been brought to its attention.
BMIS was the first project launched to realize a wider ERP strategy and a vision of an integrated
organization (One Company). This system was intended to support Bombardier Aerospace’s
operations; it would focus on the processes that support manufacturing, procurement, finance and
the engineering data required to support these processes.
The amount budgeted to implement the BMIS across all facilities was $363 million. Once
completed, it would support 9,500 users over seven sites. Its development required 400 people.
The SAP enterprise system was selected. It would have to interface with 63 other systems, some
of which were developed during the project. Bombardier Aerospace estimated that the successful
implementation would result in savings of $1.171 billion, including a one-time reduction in
material inventory of $219 million.
Creating a vision
The Project Sponsor mandated the establishment of a series of functional councils early in the
project. These councils consisted of senior employees who represented the core functions at each
of the company’s main production facilities across the world. These councils were to determine
the role and direction of their respective functions within the proposed organization, participate in
the review of processes and make rapid decisions on issues that affected their functions. Five
functional councils were established: Methods, Quality, Production, Work and Material Planning,
and Procurement. The Sponsor required the councils to formally report to him on a monthly basis
throughout the project.
Functional councils were an important means of achieving what the Project Sponsor termed
‘inclusivity.’ This entailed a large commitment by management and ample opportunity for all of
Bombardier’s facilities to express their opinions and ideas. Other opportunities for site
involvement included participation on the BMIS project team and sign-off on visioning and
process documentation. As the Vice-President Operations and Project Sponsor explains:
One of the big issues I had was inclusivity. I wanted most of the sites to be involved, because I
wanted the ability to roll it out without a “not invented here” or a “Montreal-only” solution. I talked a
lot about inclusivity to make sure all the sites were putting their views and their opinions forward and
were involved in the definition of the processes.
Once the project had received approval, the Senior Project Manager asked each of the functional
councils to undertake a visioning process in which the different functions could propose their
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 6
prospective form in an ERP environment and outline the benefits they expected from the BMIS
implementation. The output of this process was a visioning document that defined a model
organization and that identified the key performance indicators required to successfully run the
business and the skill set required for the functions to realize their proposed vision.
Visioning workshops were conducted with the functions to facilitate this visioning process. The
value management lead facilitated workshops and coached Business Project Managers (BPMs)
on how to develop business cases, what benefits to expect and how to assess those benefits.
BPMs acted as process owners and were responsible for decisions regarding processes.
A small team consisting of the champion and senior project directors reviewed the outputs of the
visioning process to ensure that it was aligned with the overall project vision. They examined
how the functional organizations proposed by the functions would interact together and
discovered that the proposed visions and key performance measures were misaligned. This
resulted in the review team challenging the nature of the organization. For example, Procurement
would practise strategic sourcing and evaluate purchasing decisions based on total acquisition
cost. Quality conformance processes would be pushed to all stages in the manufacturing process,
rather than in a final inspection. Finance would have the ability to track the cost of each aircraft
manufactured.
One of the primary objectives of the BMIS implementation was to reduce the clerical tasks
performed by Bombardier Aerospace’s employees. It was anticipated that the automation of
manual tasks would give their jobs a more analytical focus. It was also expected that an
automated and highly integrated system would dramatically reduce the amount of paper used, the
ultimate goal being a paperless workplace.
The Vice-President of Operations and Project Sponsor was considered by Senior Managers to be
an influential figure. He continued to show strong support for the project even as aerospace
manufacturers were facing an uncertain environment. According to the BMIS Project Manager:
He is a very ardent supporter of what he calls the One-Company approach. He was an ardent
supporter that we all have a pay cheque that says the word Bombardier on it and we shouldn’t forget
that. It is true in everything he did. He felt very passionately about it. How successful was he in
creating change in the business? I think as successful as any human being could be without taking a
baseball bat to everybody.
The Sponsor began to communicate the overall vision for BMIS via a number of ‘road-show’
presentations at the company’s various facilities. These presentations also explained how the
implementation of the BMIS would impact the everyday lives of employees. Even if the
information was considered high level, it was perceived to be a very effective way of informing
users. Messages promoting the One-Company vision were also included in company newsletters,
broadcast in emails and posted on the company’s Intranet.
All levels of management were responsible for passing on to their staff information regarding the
project vision and progress. The Senior Project Manager emphasized to the Business Process
Managers that communication was 80% of their job during the implementation. Managers used
different means to communicate project information to their employees. Some managers held
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 7
regular meetings with their staff, some forwarded presentations and some made no specific effort
to ensure employees were informed of progress.
The BMIS project team
A project team was established which focused on the preparation and deployment of BMIS. This
team was located in the same building as Business Transformation Services (BTS), Bombardier
Aerospace’s IS services group. Members of the BTS team made up the majority of the project
team. The remainder of the team consisted of employees from the business who were recruited as
business analysts. The BMIS project team requested that the business provide them with its most
experienced employees. They were selected to represent their function’s point of view and to
provide hands-on knowledge about the business. Employees who were recruited from the
business were relocated so they could work full-time with the BMIS project team.
Bombardier Aerospace was wary of employing too many consultants to assist in the project. The
failure of a previous large-scale ERP system implementation was partly attributed to having too
many third-party consultants employed on the project, and those consultants having a limited
knowledge of the business. The ratio of employees to consultants was reversed from 1:10 on the
previous failed implementation to 10:1 on the BMIS project.
A stand-alone team was established to handle change management activities. At its peak, this
team consisted of 50 people. Their responsibilities ranged from assisting in the preparation of
functional business cases to managing project communications and training users. An employee
from each function was transferred to the change management team for the duration of the project
to represent the function’s interests and to liaise with the business. In most cases, the members of
this team learned about change management on the job.
Creating a blueprint
The purpose of the design phase was to prepare a detailed design of the system that would meet
the business requirements stipulated in these visions. The ‘to-be’ processes were designed by the
project team and presented to the relevant functional councils for approval. It was intended that
the project would be organized according to major processes. However, this was abandoned
during the blueprint phase and the project reverted to a functional organization. The Senior
Project Manager said that the business found it too difficult to communicate in process terms:
“When we tried to do it process-wise, we practically couldn’t communicate with the business. So
you ended up having to translate it into their language all the time.”
An integration team was formed to validate the design carried out by the various functions and, as
the Senior Project Manager put it, to “cut a line through the processes horizontally.” Their role
was to identify integration points where a process crossed functional boundaries, and
independently resolve integration points that could potentially cause disagreements.
High-level decisions regarding the design of the project were made by the functional council
responsible for the area of the business affected by a particular issue. More specific design issues
were dealt with in design workshops that were held during the design phase. Managers from the
business were invited to participate in these workshops. Scheduling difficulties and pressure in
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 8
the business environment (unrelated to the project) meant that attending workshops was not
always possible for some managers. In some instances, they either did not show up or they
delegated a lower-level manager; hence making it difficult for the project team to confirm the
appropriateness of their design decisions and whether the business agreed that the proposed
processes were aligned with their functional visions. As explained by a BMIS Project Team
member in Procurement: “For example, at the start when we were sending invitations to
workshops, Directors would delegate to a Manager, and the Manager would delegate to a Buyer.
At the end, we had four or five buyers in the room.”
The BMIS team requested that the plants provide them with experienced employees to participate
in the design phase. The Mirabel Plant Manager1 said that he provided employees to work on the
design of the system, but also stated that he believed you cannot participate in the design of a
system unless you are committed 100% of the time. Mirabel sent three business analysts to
participate in the design phase; one each from Methods, Engineering and Logistics. Members of
the project team at all levels agreed that the Mirabel plant was not as involved in the project as
other plants. Some managers and users from the Mirabel plant felt that the system belonged to the
project team and was being imposed on them. On the other hand, there was a feeling on the
project team that users and managers from the Mirabel plant were waiting for the system to be
delivered by the project team. In their opinion, the business side was reluctant to take ownership
of the system. Furthermore, the project team was located approximately 50 km from the plant.
The BMIS Project Manager was concerned that there was a lack of strong business employees
involved in the design of the project. Other senior project members echoed this concern, with one
Project Manager saying:
We had a number of problems resolving design issues on the project because the people, although
empowered to make decisions and to complete the design, I think struggled with resistance both
within themselves and back with the business, because they were constantly having to go back to the
business in order to validate.
On several occasions, the business asked the BMIS team to provide it with documentation
illustrating the high-level processes that were to be included in the system. The Director of
Procurement said that they received hazy answers and were not provided with the documents that
they requested. Some people from the business suspected that the project had not always
completed the design.
The design phase ran over schedule by several months. As a result, the realization and integration
testing activities became overlapped and the time available for testing was under pressure.
Progressive implementation
Bombardier Aerospace decided not to implement such an extensive system using a ‘big bang’
approach. Full implementation of the system was to take six years. BMIS would be implemented
one plant at a time, beginning with the company’s newest facility. Assembly of the CRJ700 and
CRJ900 aircraft is done at the Mirabel plant, located near Montreal. The Project Manager said
1 Within the Bombardier Aerospace hierarchy, the general manager of a plant has the title of vice-president inside the
organization. Therefore, the terms “Vice-President, St-Laurent” and “Plant Manager” are used interchangeably.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 9
that Mirabel was selected because the CRJ700 is very much a ‘manufactured’ plane, and this
model of plane is expected to drive Bombardier Aerospace’s growth in the future. As stated in the
BMIS Project Charter, “This [phased implementation] will allow the necessary business
evaluation and also perfect the roll-out processes, techniques, and tools, prior to subsequent roll-
out activities.”
A ‘vanilla’ approach to system design was identified as a critical success factor for the project.
Bombardier Aerospace believed it was important that minimal modifications or enhancements be
made to processes in SAP.
Senior project and business management considered the first roll-out at the Mirabel plant to be a
controlled pilot implementation. Bombardier limited the scope of the first implementation in
order to get the system operational in a restricted production environment and identify lessons for
subsequent roll-outs. The Mirabel Plant Manager believed that the scope of the pilot
implementation could have been even further limited to one part of the Mirabel plant: “I would
not implement wall-to-wall. I would isolate a section, prototype the thing there, and then develop
the proper material to train the rest of the shop. I would do the proper adjustments to the system
and then I would do the entire shop.”
Inventory management was positioned at the core of BMIS. The Vice-President of ERP stressed
this was important, as at least 75% of the cost of manufacturing an aircraft can be attributed to
material spending. The first roll-out was limited to the implementation of SAP modules that were
considered essential for improving operations and inventory management. Modules that were
deemed more strategic would be brought online once a foundation of core modules had been
established. The focus on inventory management was not endorsed throughout the company.
Some managers considered this focus to be misguided.
Restructuring of the Procurement function
Bombardier Aerospace’s Procurement function has an important role in realizing the vision of the
Bombardier Manufacturing Information System. The primary goal of the system was to improve
the visibility and reduce the value of inventory held by Bombardier Aerospace. Reduced product
costs of $22 million per year and reductions in procurement overhead of $7.1 million per year
were anticipated at the outset of the project.
Inventory is the most significant cost for an aircraft manufacturer. Reductions in inventory levels
would improve liquidity and reduce cycle time. In the legacy environment, Procurement
employees were being rewarded for purchasing inventory at low prices. This encouraged bulk
purchasing. Total acquisition cost was not being considered when making purchasing decisions.
Additional objectives for the Procurement function were to move towards a policy of global
strategic sourcing, eliminate all clerical activities, automate as many processes as possible and
improve supplier compliance.
It was decided mid-project that restructuring the Procurement function would help to achieve
these objectives. Senior project management had been considering a reorganization of
Procurement for some time, but it was not announced to the rest of the organization until April
2003, during the realization phase. The restructuring was undertaken in parallel with the
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 10
implementation of the BMIS, but was completed as a separate initiative. This entailed changes to
processes and employee roles and responsibilities.
Modifications to roles and responsibilities in Procurement were confirmed a few months before
the Go Live. Prior to the reorganization of the Procurement function, employees were either
planners or buyers. Planners were responsible for determining the inventory required for a
particular aircraft based on production planning. Planners did not interact with the suppliers who
provided these parts. Buyers would coordinate purchase requisitions issued by planners, create
purchase orders based on these requisitions and send them to the relevant suppliers.
New roles and responsibilities were developed. Employees in the post-BMIS Procurement
function would become sourcing agents or logistics agents. Sourcing agents concentrated on
centralized and strategic sourcing of inventory for all internal customers. This involved
negotiating contracts that would minimize the total acquisition cost and overall procurement
costs. Several buyers were joined by planners in the role of logistics agent. This role would
oversee the acquisition process. It was necessary to bring these buyers up to speed on planning
processes, as this was not part of their previous role. The Material Resource Planning technology
implemented creates almost all of Bombardier Aerospace’s purchase requisitions for the
CRJ700/900 program when lead time criteria are met, and automatically sends them to suppliers
by fax. This effectively substitutes a lot of the work previously done by planners in the legacy
environment, creating more time for analytical activities. It was difficult to explain the changes to
users when exact details were still being defined in the final months of the project.
Management was aware of the substantial magnitude of the change that users were about to face.
A newly appointed Director of Procurement at the Mirabel plant likened it to taking 60 new
employees from outside the company and having them ready to use the system in three weeks.
Even if employees were very familiar with the business, their roles and responsibilities were
completely new. Procurement employees were confronted with a new system, new roles, new
processes, new management, new supplier files and, in some cases, new colleagues.
Data management
Data management was organized as a separate, parallel project consisting of two broad sets of
activities: data cleansing and data preparation. The Sponsor advised senior project management
that he was willing to establish a distinct organization to manage data cleansing and preparation
at any stage during the project. This was an indication of the importance he placed on data
management. Data cleansing was identified as a major risk at the outset of the project.
During project planning, it was decided that the business would be responsible for cleansing its
own data under the guidance of a data cleansing team. Data was shared amongst the business and
the BMIS team. The BMIS team was responsible for the preparation and conversion of cleansed
data. This involved the extraction, mapping, staging and consolidation of data required for the
implementation before uploading it to the target systems. The BMIS project team put in long
hours leading up to the Go Live in order to have the data ready and loaded into the system.
Users from Procurement spent the first few weeks following the Go Live cleaning data relating to
the buyers and parts they were responsible for maintaining. In the first week following Go Live,
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 11
one user had to begin cleaning data on 20 suppliers and 1,200 parts. This involved reorganizing
and cleansing data from hundreds of separate files using a system with which the sourcing agent
was not familiar. The Mirabel Plant Manager said, “Because some of the quality of the work that
was done during the data clean up was questionable, we had to redo a lot of the data clean up. We
just finished three months ago, nine months after the Go Live.”
Late decision to go with Workbench
Bombardier Aerospace made a decision late in 2002 to change the Methods and Engineering
function’s software supplier. HMS Software had been mandated from the beginning of the
project to provide its Computer-Aided Process Planning (CAPP) product, a process planning
system for managing manufacturing information and work instructions. This was one of several
systems that would interface with SAP.
SAP had been developing its Workbench module since the BMIS project had commenced. SAP
Workbench served the same purpose as the HMS CAPP product. Bombardier Aerospace thought
the improvements to the SAP Workbench product were significant enough to warrant a major
change to system architecture at that stage of the project. This decision met the company’s
criterion that called for implementing SAP unless there was an alternative solution significantly
more capable of meeting business requirements.
A third-party consulting firm working on the project was not convinced that SAP would commit
to implementing the Workbench module within such a tight schedule. Bombardier Aerospace
was aware that configuring the module within a three-month timeframe was a significant
undertaking and represented a risk to rolling out BMIS within the deadline. The decision would
send the Methods function back to the beginning of the blueprint phase and on the project’s
critical path. The project’s Business Process Manager for Methods believed that working closely
with SAP, seeking a lot of feedback from it and having an SAP representative on-site would
enable them to successfully implement SAP Workbench within the overall BMIS deadline.
Integration testing
All of the integration testing cycles were based on cross-functional business scenarios created by
analysts appointed by the business. A number of work steps were established and documented for
each scenario. The scenarios and work steps used in integration testing were derived from the
system design created in the blueprint phase. After establishing a high-level cross-functional
scenario, business analysts would work in smaller teams to create the part of the scenario and the
work steps relevant to their particular function. Cross-functional teams would then reassemble to
make sure these distinct sections of the scenario would work together.
The BMIS Project Manager used the analogy of preparing a ship for battle to describe the process
of implementation testing, which involves four cycles. The first cycle tests the activities within a
sub-area of the system, such as purchasing or preparation of the general ledger. This initial cycle
makes sure everything is working well within the functions. This is the equivalent of testing the
separate components of a ship in dry dock. During the second cycle, members of the integration
testing team went through previously created scenarios using manually created data. The ship has
now been taken out of dry dock, steered around the harbour, and parked back at the dock to
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 12
ensure that its components work together in an integrated way. The work steps established in
cycle two are tested using converted data during the third cycle of integration testing. The ship
has now participated in war games with friendly fire. The fourth cycle uses the established work
steps and converted data to carry out user acceptance testing. The ship should now be ready to go
into battle. The outcomes of all testing cycles were documented and stored in a database.
The first cycle of integration testing was carried out according to plan and on schedule. However,
problems arose during the second cycle. The integration testing team discovered that the business
people involved in writing the work steps and scenarios did not know the business as well as was
necessary. There were several cases of disagreement during the writing of the scenarios and work
steps. Resolving these disagreements caused delays in the completion of the testing phase.
The project team became frustrated when the business questioned processes that it had approved
during the design phase. A business analyst said that some directors would agree to the
propositions put to them in design and then complain that the system did not meet their needs
when it was deployed.
Tracking project status
A scorecard system was used throughout the implementation to track project status. Monthly
status report scorecards were completed by the project team and submitted to the Vice-President
of ERP and the company’s Project Review Board. These scorecards presented information on key
activities completed, key upcoming activities, project risks and high-level issues. Important
project indicators were allocated a status of green, yellow or red according to the urgency of the
problem and the attention required by management to resolve any issues. As the Go Live date
loomed closer, senior project management requested that the project team include more detail in
these reports.
Daily status meetings were held in the final months leading up to the Go Live. The Business
Project Managers would meet with the Senior Project Manager each afternoon in a project ‘war
room.’ The purpose of these meetings was to resolve issues related to integration testing,
development requests, change requests, and any other escalated issues that warranted their
attention.
The First Roll-out
Preparing the users
The use of power users was an important component of the company’s knowledge transfer
strategy. The primary role of power users is to prepare end users for use of the system on Go
Live. Power users trained end users in a classroom environment. Originally employees of the
business, they were recruited for their knowledge of business processes and the system. They
became full-time members of the BMIS project team before training commenced in order to
develop an understanding of BMIS and the knowledge required to deliver training. In preparation
for the Mirabel roll-out, 29 power users delivered 102 training sessions to approximately
1,400 users.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 13
Power users brought themselves up to speed for their courses by talking to business analysts,
looking over process models and experimenting with SAP. Several power users felt they had to
seek information about new processes and transactions themselves in order to feel competent
enough to deliver training. The availability of these resources was often limited. In some cases,
there was not enough process documentation or system functionality available to effectively
prepare themselves to deliver training. One power user commented that she did not feel
competent enough to deliver training until the day before giving her first course.
Bombardier Aerospace hired a third-party to prepare training material. Power users and
employees who received training expressed dissatisfaction with the training material produced by
the consultants. It relied on tables and descriptions instead of relying on screen shots of the
system. The training material did not reflect an understanding of the business and it was not user-
friendly. Users found the descriptions and exercises too detailed and difficult to follow. Several
power users and super users made significant efforts to adapt the training material in order to
bring it to a satisfactory standard.
Trainers often provided the first real contact between the users and the project. Users were
generally satisfied with the trainers. However, they expressed reservations about the timing,
material and focus of the training. There were a few cases of training sessions being cancelled
due to users not understanding why they were attending. Some Procurement employees were
given inadequate notice by their managers that they would be attending training. Presentations
explaining the purpose of the system and its anticipated effects had been delivered prior to
training, but many of the users who attended these meetings left more confused and bewildered
than when they arrived. As the Change Management Lead explained: “People were sent to
training at a few days notice, and it was not explained by their management that there was going
to be a change in the organization. So you’re from Procurement, you’re being sent to the training,
but you do not understand why.”
Users felt that the e-learning module gave a good overview of high-level processes, but that there
was no tool supporting a detailed view of the processes (linking the high-level view and related
transactions). There was too much focus on exceptions and details. For many users, training
provided too much information in a short period of time. They mentioned that some of the
exercises were too complicated and detailed. The training documentation was not specifically
targeted to the work users had to do on a regular basis (or on their first day of work on the new
system).
Training focused primarily on transactions, not on the roles. In some cases, roles were still being
defined as training was being delivered. A small amount of background information on the
concepts of ERP and MRP was communicated to users through e-learning tools prior to training
sessions and was reviewed briefly by some power users during the training sessions. The process
flows were not explicit and trainers were unable to explain changes to business processes to the
users. Several trainers commented that the focus of the transactional training was too broad.
Rather than focusing on the most common transactions, the training material attempted to include
all of the transactions a user would be required to complete. There were no tools supporting the
detailed view of processes (linking the high-level view and the transaction). This meant that users
were not fully aware of the impact of their tasks on those of other people.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 14
Some users felt that their new roles and responsibilities might be less prestigious than they were
previously. Some users resisted the new system because they were experts in the old system and
would become regular users in the new one. Other users thought that the new system would make
their tasks easier (or faster to complete). This was not necessarily the case. Tasks were different,
sometimes more analytical, but not necessarily easier.
Data preparation and conversion had not been completed when training began. Data used in the
training environment were not always correct and complete. Actual production data were not
always available, so manually created data were used as a substitute. Trainers found it difficult to
present a realistic experience of the system without production data. As one user in Procurement
stated: “When you have buyers who have been here for 20 years working in one way and you try
to make them change into a new culture, and you bombard them with new acronyms and new
definitions, it’s very overwhelming.”
An atmosphere of scepticism existed amongst many users concerning the system delivery and,
during the training sessions, some expressed doubts about what BMIS was intended to achieve
and the impact it would have on their everyday lives. Power users often found that it was
necessary to include explanations of the wider role and consequences of BMIS in their training
schedules. Power users were often criticised by users, and there were cases of training sessions
being delayed while users vented their frustrations about the system.
A lot of people had a hard time understanding the urgency. People were thinking “Why do we have to
do BMIS all of a sudden? Why do we have to implement SAP by the fourth of August? Why the rush
all of a sudden?” There was a lot of resistance towards it because we’ve been told for years that SAP
is coming. The same thing happened with MACPAC implementation. (Power User, Procurement)
Schedule pressures resulted in training being delivered to users in a shorter period of time than
was originally planned. The duration of training varied across functions and roles depending on
their usage of the new system. Users had to attend training while performing their everyday
activities. A Director from Mirabel felt that transmitting such a large amount of information to
users in such a short period of time had a ‘brainwashing effect.’ The pressure to meet production
deadlines resulted in some managers and supervisors instructing their employees not to attend
training sessions.
Users were given access to practice environments within SAP called ‘sandboxes’ to practise the
transactions they were learning during training. Many users did not have enough time available in
their normal working day to devote to practising outside of the training sessions.
Go Live
A calendar hanging in the cafeteria reminded the project team of the days remaining before the
deadline of August 4, 2004. Members of the BMIS project team put in long hours and worked on
weekends as the deadline loomed. They continued to work during the shutdown period while the
rest of the business was on vacation. Senior project management was adamant that the deadline
not be pushed back. As the Project Sponsor explained: “I took the decision to implement at
Mirabel knowing that they were not quite ready for that deployment. I was more interested
strategically in the lessons learnt, because I was confident that we would not lose production, and
we would make more progress by going ahead with the implementation.”
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 15
During the shutdown period preceding the Go Live, the BMIS project team executed the cutover
plan and prepared help desk facilities. Their efforts were focused on ensuring the ERP
environment was ready for the return of users and the continuance of Bombardier Aerospace’s
normal production schedule. The dedication and hard work of the BMIS project team leading up
to the Go Live date paid off. The system was online for users on the first day back from their
shutdown vacation period and production was not disturbed.
Users at Mirabel began using the system after returning from a three-week vacation period that
was necessary to carry out the cutover to the BMIS. A Go Live support pack was awaiting users
when they returned to their desks, and support staffs were present on-site to help resolve queries
from users.
Power and super users were present at the Mirabel plant to provide on-site support following the
Go Live. Power users stayed at the site temporarily to transfer their knowledge to super users in
an informal one-on-one fashion. Super users remained on-site permanently to provide ongoing
support to their peers while carrying out their everyday roles. They also acted as a liaison
between their business unit and members of the BMIS project team if problems they could not
solve had to be escalated.
The Mirabel Plant Manager noted that challenging problems tend not to be discovered in the
weeks immediately after the Go Live. Rather, they become apparent months after an
implementation. Users and management at Mirabel were disappointed at how quickly the support
staff were withdrawn from the business. As he pointed out:
There were too many people at the beginning, and then suddenly you go down to a very small amount
of people too rapidly. The problem is you don’t find problems in a new system the week after the
implementation. You usually find problems three, four, or five months later.
In some departments, questions from users in the first weeks after the Go Live were focused on
trying to understand their new roles and responsibilities rather than how to complete transactions.
This was especially true for employees in the reorganized Procurement function.
Several users agreed that there should always be at least one power user available on-site to
resolve queries from users and to act as a link between the business and technical support staff.
However, knowledge of support staff was valuable to the project team and, therefore, required for
the upcoming roll-outs.
It quickly became apparent which support employees were more knowledgeable, and the most
competent ones were soon targeted and bombarded with user queries. Some were terrified that
they would be unable to resolve users’ problems. The frustration of users increased when support
staff could not solve their problems, and frustration at being unable to complete transactions
would often lead to users placing the blame on the system. According to a super user in
Procurement:
We had twelve people on-site ready for support and everyone was terrified, because they knew if they
were asked a question on contracts and they were a supplier expert they wouldn’t be able to answer
the question. They [the users] realized very quickly within a couple of weeks who they could rely on.
The problem was that everyone was chasing the people who were reliable.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 16
Users from various functions complained that they sometimes experienced significant delays in
getting answers to their queries. The project team established a help desk and its services were
available to all users at Go Live. Users had to leave a recorded message describing their problem
and they did not always receive an immediate response to their query. Delays were problematic
when employees had to perform tasks in the system very regularly or when other employees were
waiting on them to complete a task.
Legacy systems were still accessible to users after the Go Live. Several users said that they were
still using legacy systems for some aspects of their work. Users took advantage of the availability
of legacy systems if they could not complete a task in SAP. It was possible to bypass SAP, enter
information into legacy systems and, thereby, solve a problem. Some managers gave permission,
and even encouraged users to utilize legacy systems as a workaround to problems that could
potentially cause production delays.
Problems were encountered during the roll-out, as in any new technology implementation. For
instance, SAP had a functionality to automatically fax purchase orders to suppliers. This created
problems as the MRP engine, which generates production requirements, was updated once a day.
This meant that the new system created purchase orders and suppliers received new orders every
time the MRP engine was updated. Suppliers pleaded with sourcing agents to stop sending so
many faxes. The problem was remedied by holding purchase orders in a pool and sending them
in bulk once a week, unless the order was urgent, in which case a sourcing agent could send a
purchase order separately.
On the other hand, at one stage, purchase orders were not sent to certain vendors for one month.
The functionality required to automatically fax purchase orders to suppliers was trapping
purchase orders in the system. Management told the BMIS team that they were the ones who had
to deal with the problem. BMIS team members spent three weeks printing, stapling and mailing
purchase orders to suppliers.
Procurement was not the only department that experienced problems at Go Live. A full general
ledger had not been implemented in SAP. Finance was still using legacy systems to maintain
Bombardier Aerospace’s general ledger, and it had not achieved its goal of completing the
month-end accounts in one day.
Employees in Finance were making manual corrections to the general ledger if materials were
issued incorrectly. Employees from the Finance function were used to correcting accounting
anomalies in the legacy environment. Their management had to impress upon them that SAP is
an integrated system and that they had to let mistakes show to encourage the rest of the business
to enter all the required information in the correct manner.
Prior to the BMIS, data concerning materials had been managed by Methods. After the
implementation, the material master was managed by the separate and centralized Master Data
group. Methods had to complete and send forms to the Master Data group if they needed to make
additions or modifications to a bill of materials. Methods employees were initially frustrated by
this process. Delays in entering the information in the Bill of Materials were common, and it took
some time before Methods employees understood what information the newly formed Master
Data group required from them.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 17
Managers were not using the reporting functionality available in the system. Information was
being requested in the same way it had been before the system was implemented. Several
managers were still asking their employees to print information or prepare summaries for them
that they could have retrieved from the system. This limited use of the system by managers
became very apparent to one BPM who used the new system to see which managers had logged
on. He discovered that none of the directors or managers in their functions had accessed SAP
during the previous 90 days.
Stabilization
A dedicated BMIS project team delivered the Bombardier Manufacturing Information System by
the August 4 deadline and below budget. The project’s number one critical success factor of not
disrupting production schedules was met. There was a strong sense of pride throughout the
project, as Bombardier Aerospace delivered one more plane than was scheduled during the
Mirabel implementation. There was a general consensus across the company that meeting these
constraints meant that the initial roll-out could be deemed a success.
Less than one year after the Go Live, the Mirabel implementation of BMIS had already
contributed to a reduction in inventories of $1.2 billion across Bombardier Aerospace. The
company had successfully implemented a complex ERP system without jeopardizing the
system’s operation or production. This was a significant achievement in an industry that has
experienced several ERP implementation failures.
Initial training was supplemented with additional courses and training material. One-day
refresher courses were provided for several users. The change management team developed ‘Day
in the Life’ training documents following the Go Live. These documents provide a walk-through
of a typical day for a particular role and focus on the most commonly executed transactions. They
were well received by users, who often found it difficult to retain all of the information
transmitted to them during the initial training sessions.
Increasing numbers of users were starting to see how the system made their lives easier. This, in
turn, was improving their attitude toward the system.
Several Senior Project Managers stressed the importance of the business taking ownership of the
system as early as possible. Many members of the BMIS project team felt that the business was
reluctant to assume ownership of the system, and to promote the monitoring of benefits within
the business. After the deployment of the system at Mirabel, the Plant Manager stated that he
wanted to understand the system before trying to track key performance indicators. The Business
Process Manager for Methods believed that the project had to communicate with the business in a
way that encouraged it to own the deployment and delivery date.
A team had been established within the BMIS team to develop an appropriate set of indicators for
measuring the impact of the system on business performance. This initiative was supported by
the Plant Manager, who acknowledged that the business needed to become much more
disciplined in the measurement of performance. He believed that information systems, to some
extent, had encouraged complacency in measurement because of the large volume of data that
they made available to businesses. While he thought the system had the potential to overwhelm
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 18
users with data, he agreed that it should be used to provide the data for measurement. He strongly
believed that the business had to agree on a limited set of indicators that would be applied across
the business.
Many users felt that the new system had not affected their own work as much as employees in
other areas of the business. The majority of users felt that the Procurement function experienced
the most extensive changes. Several users said that there had been little transformation of
processes and they were simply using a new system to carry out the same business processes. As
one user in Methods stated: “For Methods, there is not that much of a difference. The impact of
the implementation was not in our department. It’s pretty much all the same. It’s just the software
that has changed.”
The new system had not streamlined all processes. One sourcing agent said she had become more
restricted because of a new and exhaustive approval process. Sourcing agents could not approve a
purchase order for any part if its contract did not contain a price or if the current price was
different from that stated in the contract. She described the approval process as a nightmare, with
all parts requiring five levels of authorization, right up to the vice-president level. A purchase
order could not be generated and sent by the new system until it had been approved at every
level. To get around this problem, the sourcing agent would generate a print screen showing the
purchase order and fax it to the supplier. Prior to the introduction of the BMIS, the same sourcing
agent had the authority to approve any purchase order up to a value of $65,000.
Some system functionalities were de-scoped in order to deliver the system for the August 4
deadline. Users were disappointed when they realized that some of the functionalities that had
been promised were not delivered at the first Go Live. A lot of the finance functionalities were
de-scoped and a portal for interacting electronically with vendors was not implemented.
Functionalities that had been promised to Procurement after the Go Live were postponed twice.
Completion of new procurement functionalities was scheduled for January 2004, but was delayed
until March and then again to June.
Several users who considered themselves to be specialists in their own processes complained that
they were not involved in design, implementation or validation activities. This was especially
frustrating for users when the system was deployed and they had to face problems they believed
could have been avoided had they been consulted during the design phase. As one user in
Procurement explained:
The concern of the buyers was that the people who were giving us PowerPoint presentations, with the
nice version of what will happen, never consulted the actual soldiers. We would look at these nice
concepts and think “How will that apply to my reality?” Nobody came to ask me what my reality
was.
When considering the overall picture, business processes in Procurement had become more
efficient and integrated as a result of the implementation. In the legacy environment, planners
used charts detailing the manufacturing schedule to determine parts requirements. Once planning
was complete, the planner would enter all the necessary information to create a purchase
requisition. A purchase requisition would be assigned to a particular buyer after it had been
created. Buyers would print out all outstanding purchase requisitions in their queue and sort them
by supplier and then by manufacturing facility. A buyer would enter additional information and
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 19
assign it to a supplier to transform the requisition into a purchase order. Once completed,
purchase orders were printed and faxed to suppliers.
Purchase requisitions were now automatically generated by the system’s MRP engine when the
lead time for a part was met. All the information surrounding different materials, including lead
times, was maintained in the material master. SAP converted all outstanding purchase
requisitions into purchase orders once a day and electronically faxed them to suppliers once a
week, unless they were manually activated in the meantime.
There was a lot of buffer in the old system, and it was easy for planners to create purchase orders.
To avoid problems, planners could order more stock than was required. It was very difficult to do
this in the new system because a request had to be submitted to create a purchase requisition that
was not generated by MRP. A purchase requisition would be created this way in the case of
urgent or unplanned production requirements.
SAP ‘flags’ a user if required information is missing and guides users to enter the required
information. For example, users would be flagged if they attempted to order a part that is not
used at a particular plant. Therefore, the opportunity for human error was reduced.
Looking ahead
The Vice-President, Operations and Project Sponsor shared his assessment of the project’s
success in the following terms:
Has BMIS been a success? I have to say an absolute outstanding success in terms of the financial
performance of the Company. It’s been one of the key things in getting [Bombardier] Aerospace
through in a very, very tricky period of the business. Is it perfect? No, far from perfect.
The Project Sponsor was confident that Bombardier Aerospace could successfully roll out BMIS
to other facilities if the major lessons from the pilot implementation were applied to the next roll-
outs in a disciplined manner.
Two Years Later…
The BMIS project continued after the Mirabel implementation. In December 2005, two additional
programs were included in the scope of the project: the Challenger 300 and Global Express
Cockpit. This deployment took place at Bombardier Aerospace’s Saint-Laurent plant. This plant
does not assemble a specific model of aircraft; rather, it is responsible for assembling different
components (like cockpits) for a variety of aircraft.
Preparing the users
Significant lessons had been learned during the first phase of the project. The importance of user
preparation was well recognized. Moreover, the managers of the Saint-Laurent plant were
convinced that, in order for the project to succeed, it had to be their project, not the IT
department’s project. They organized this phase of the project accordingly.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 20
Sponsorship
The project champion for this second roll-out was the Vice-President at Saint-Laurent. He firmly
believed in the necessity of the BMIS for Bombardier’s future growth. He advocated strongly for
the system and was the one who brought senior management at Saint-Laurent on board. The
change leader was also a strong advocate of the system. He pushed the deployment and change
within the plant. In addition, the CEO of Bombardier Aerospace was leading the change from the
top level of management.
The Vice-President at Saint-Laurent made sure the message was conveyed across the
organization by holding senior management meetings, attending and playing an active role in
project kick-off and progress meetings, conducting the opening and closing of user education
sessions, participating in the management training ‘How to Accept Change,’ etc. The presence of
the Vice-President during these activities sent a very strong signal to the employees. The Vice-
President explained that the project was essential to ensure the growth of the company, as the
legacy systems were unable to support Bombardier’s development. At the same time, he insisted
that his directors and managers take the lead in the project in order to be clearly responsible for
what was happening in the plant.
This behaviour induced similar behaviour among the directors and managers. They set aside time
for training for their employees and made participation a priority. They helped review mapped
processes and they took the lead in the implementation, knowing that their participation would
have an influence on the final product Saint-Laurent would receive. Senior management at Saint-
Laurent made the project a clear priority and communicated this to their employees. Even power
and super users fulfilled change leadership roles among their peers. The vision was
communicated through different media to ensure that the message was understood by everyone.
Change leadership
A need for change was perceived among most employees throughout the Saint-Laurent plant. The
information relayed highlighted Bombardier’s position with respect to the ERP strategy in
comparison to competitors. A video by the CEO of Bombardier Aerospace sent a clear message
from top management on the rationale for the change.
The overall vision for the BMIS project was now clearly delineated and was well understood
across all levels and functions. Most directors at Saint-Laurent took visible actions to increase the
understanding of the vision within their functions, such as requesting vision presentations on the
BMIS project. These vision presentations preceded the actual training and enabled the users to
develop a good understanding of the changes introduced by the new processes.
The vision was supported by well-designed tools. Since 2003, several tools had been developed
to present an overview of the project, the processes, the roles and how all these elements were
tied together. This meant that all these tools (BMIS Roadmap, BMIS Essentials, ‘The 5 Mega
Processes,’ etc.) were provided by the project team to ensure a smooth deployment within the
business. The education tool ‘BMIS Essentials’ was especially appreciated by the users.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 21
User preparation and training
Education and training messages were tailored to the specific needs of the different hierarchical
levels. Managers and directors attended training sessions, notably the ‘BMIS Essentials’ and the
‘How to Accept Change’ sessions. Users received more extensive (and more detailed) training.
By 2005, the trainers had gained experience and their credibility with the users was good. When
surveyed, the majority of users mentioned they appreciated the quantity and quality of the
training. Users also thought that the timing of the training was appropriate. Employees were
given the time required to attend training and management made it clear that attendance was a
priority.
Changes in the various roles and responsibilities were implemented before the deployment of the
new system. Users felt that having these changes in place before the introduction of the system
facilitated the change, because they had time to adapt to the new roles before having to adapt to
the new system. This way, they were better able to cope with the changes.
A variety of channels such as meetings, presentations, posters, and newsletters were used to
communicate messages, depending on the situation and the targeted audience. In general, users
were positive about the expected outcome of the project. They thought that the project would
benefit Bombardier Aerospace and improve their own work environment at the same time.
Project management
By 2005, the project team members were able to use the valuable skills and expertise they had
acquired to ensure the project was developed according to high standards. The project team used
the SAP methodology and employed certified SAP developers. The project was still organized by
functions and not by processes. However, the project team had gotten used to the structure and
roles were clear. Any issue raised could be dealt with and technical problems were assigned clear
contact points in the help desk or the SAP Competency Centre. Nevertheless, the project structure
was not always understood by the business side and was often perceived as overly complicated.
Project team
The project team members formed a dedicated group. Most of them had participated in the first
roll-out at Mirabel. There was a positive atmosphere among the project staff. People mentioned
they liked to work on the project and enjoyed working with their colleagues. The staff were
highly motivated to make the project successful. This was seen as a personal challenge that all
employees wanted to tackle.
The dedication of the project team was manifest. On-time delivery was the highest maxim. The
project deliverables were planned with an aggressive – and perhaps even, according to some
members, unrealistic – schedule. Consequently, overtime was an intrinsic part of the schedule
and plan.
Team spirit was encouraged by the project management group. The project management people
stayed with their staff during the overtime work periods. This sent out positive signals.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 22
Employees felt it was a collective effort and that everyone was contributing to attaining the
project goals.
This pressure on delivery meant that there was very little slack in the utilization of human
resources. There were no buffers in place for potential contingency events. This created a
situation in which several key individuals had no shadows – i.e., people who could replace them
in case of emergencies or who could share some of the workload.
This was a challenging issue. The specialized knowledge was concentrated in a few individuals.
However, it was not simply a question of hiring more people. The knowledge transfer to new
team members was not simple and required the availability of key individuals who were already
working intensively on the next deliverable and who felt that the time investment required for
knowledge transfer would jeopardize the project schedule. This created a vicious circle. Since
they were in limited supply, there was strong pressure for these knowledgeable people to spend
all their time on project activities. If they stepped back to transfer their knowledge to colleagues,
they felt they were slowing down the project’s progress. However, failure to transfer this
knowledge threatened the continuity and sustainability of the project. It was acknowledged that
no project should be overly dependent on a few key resources.
Relationship between the business and the project
Top management clearly communicated the importance of the project for Bombardier and there
was a common understanding of the objectives and anticipated benefits throughout the hierarchy
on both the project and the business side.
The project’s progress was assessed through meetings, project status reports and scorecards.
These reports and scorecards were given to the management at Saint-Laurent and circulated in
the plant. The business was kept informed of the project’s progress in biweekly meetings.
If managers or directors were not able to attend any of these meetings, they sent knowledgeable
delegates with the authority to make decisions, thus avoiding any delays in the project. These
delegates would then report back to the managers and directors on the meeting results. Therefore,
management was always informed. This procedure signalled interest from the business and
indicated that the project was regarded as important.
In some instances, the business side felt that the communication with the project team could have
been a bit more transparent. There were a few times, early in the project, when scorecards were
‘embellished’ a little bit to veil some issues with which the project side was struggling. This was
done to prevent the business side from worrying about the project. As could be expected, the
information could not be hidden for long.
Go Live
The project went live on the planned date and there were no significant disruptions to normal
operations. The Challenger 300 and Global Express Cockpit deployment represented another key
step of the BMIS implementation. This particular phase of the larger project could be rightly
considered a success, both in terms of results and the deployment process.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 23
The Go Live went very well. The business had a contingency plan to keep production running in
case of problems. However, there were no real problems during the Go Live. Moreover, a very
high rate of data accuracy was achieved (97%). The stabilization phase was shorter than
expected.
There was a slightly different perception between the project team and the business about the
support during the weeks after Go Live. The project team felt that its support was not needed for
a longer period of time, because there were not many problems. However, the business perceived
the situation differently. There were some problems, but the support provided by the project team
was not completely adequate. In some cases, the business felt that a gap had emerged between the
business knowledge of the support staff on the project team (people had been transferred to the
project team years earlier) and what was really going on in the business today. In other cases, the
business perceived the procedures for receiving support to be unnecessarily complicated. In a few
cases, there were complaints about the passiveness of support staff, seen in their failure to
proactively approach the users and offer help. It was difficult to draw the line between ‘being
available without being intrusive’ and ‘being passive.’
In the end, the project team was released from support duties by the business. Power and super
users were able to deal with the majority of user questions and provided most of the user support.
It is important to note that some power and super users had been involved in SAP deployments
since Mirabel and had acquired valuable knowledge and expertise about the system and its
capabilities. If users had a question that could not be answered by their power or super users,
business analysts from the project team could be contacted. Finally, co-workers supported each
other in case of problems as well. Power and super users noticed that over time the users’
questions had become less general and more specific.
Reactions from the employees were almost all positive. Employees used various systems. The
BMIS was used in virtually all cases where the tasks were in scope. There were almost no work-
around solutions. Most users felt the new system made their job easier. Users would have liked to
have a larger portion of their job supported by SAP.
There were some complaints from the business regarding the deployment strategy. The first was
very specifically related to contract management. There was some resistance towards the system
in Supply Chain / Sourcing because SAP did not provide all the detailed contract options that
they wanted to negotiate with suppliers. Contract agents were rewarded for the cheapest contract,
not for contract compliance with SAP’s options. Therefore, contracts were negotiated with some
specific terms that were not included in the options provided in SAP. Consequently, these
contracts had to be entered manually and in different ways in Logistics, causing more work and
costs later. There was a contradiction between local savings (cheapest contract) and global
savings (having the whole process automated). It was unclear which solution was best. More
standardized contracts would have increased the costs of some contracts (although not
tremendously). On the other hand, allowing more options in the contract module increased
development costs and entering contracts manually increased processing costs.
The other complaint was of a totally different type and, in a way, it showed that the project team
was a victim of its own success. The users complained that the scope of the project was too small.
They would have liked all their activities to be supported by SAP. They wanted all the programs
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 24
to be supported by the BMIS. Most users wanted all their tasks in the new system as soon as
possible so that they would not have to deal with two or more systems.
In conclusion, after the Go Live, the majority of users considered the new system was important
for them and that it would make their job easier. They had the impression that their input was
taken into account in the various activities they participated in, such as data cleansing, meetings,
and validating and reviewing training material or processes. Among the users, there was very low
resistance and the new system was used in virtually all instances where the task was in scope.
Post-Implementation Considerations
When taking stock of the latest implementation, the Bombardier Technology Services group
noted several elements that needed to be discussed. These elements were not seen as pivotal, but
were questions raised in the course of the project. They were elements that would either facilitate
further implementations or increase the value obtained from the system.
In order to maximize value, the system had to be used and users had to take ownership of the new
technology. Users were still in the process of exploring the full capabilities of SAP. Some
managers mentioned that many of their supervisors using the new system were very enthusiastic
about its possibilities in terms of information. Some were literally ‘little geniuses’ who could
understand the system faster than anyone and pull out innovative solutions. They increased
department performance. How could these individuals be identified and how could this
appropriation process be facilitated?
Users did not have many ways to measure their contribution to the realization of the objectives.
Some key performance indicators (KPI) had been developed, but they were not used often. In
some instances, the business users were not aware of the KPIs that already existed. It seemed that
the business was waiting for the appropriate KPIs to be developed and the developers were
waiting for input, requests and requirement specifications from the business.
Training was another interesting component to assess. When reflecting on the last deployment,
some users mentioned that they would have preferred to receive less training before the Go Live
and more advanced training shortly after the Go Live to learn about some of the advanced SAP
functions once they were familiar with the tool. While this request was perfectly feasible, its net
impact had to be measured.
Other elements concerned the management of post-implementation issues. Many users made
requests for change (RFC) after the implementation of the system. Users mentioned they felt they
were not being sufficiently informed about the progress of their request or about the feasibility of
RFCs. For the project team, this issue was part of a larger dilemma. Each new implementation
generated several requests for change. Some of them were important and needed to be addressed.
Others stemmed from a desire on the part of users to re-create in the new systems the processes
they had in the old system. This was not desirable. Therefore, sorting out the RFCs that had to be
implemented from the complete list was difficult.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 25
The project personnel had to be managed with caution. While benefits were highly desirable and
depended, in part, on the pace of deployment, this pace had to be steady but sustainable for the
project staff. Peaks are an intrinsic part of major projects and could not be avoided. However,
there was a balance to maintain between the short-term and long-term objectives. The short-term
objectives concerned the next delivery (at any point in time), while the project as a whole was the
long-term objective. Activities had to be conducted in parallel, skills had to be available for each
phase and it was often difficult to retain resources for long-term objectives when short-term
deliveries were approaching.
A last issue requiring analysis concerns user expectations. As was mentioned earlier, the project
had been very well received and users wanted faster implementation, with a wider scope. This
posed a challenge. There was an inherent compromise between the allocation of efforts to
continue the deployment of the system across sites and the maintenance efforts dedicated to sites
that were already using the system. A middle ground also had to be found between the scope of
the project and the deadlines. In several instances, elements could be removed from the scope of
the project to enable an earlier delivery. Was it better to deliver a smaller portion of the scope
very quickly? Or should the team have targeted larger deliveries even if this generated longer
delays?
The project was conducted with virtuosity. The vision was translated into practical elements and
communicated efficiently across the business. Training, delivery and support were performed
flawlessly. Similarly, the business side put forward the required efforts in the project. The team
has the required tools and skills to pursue the project. From the results obtained, the BMIS team
should now move from a state of skills/expertise development to consolidation.
2012-01-25
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Su
cc
es
sf
ul
ly
N
av
ig
at
in
g
th
e
Tu
rb
ul
en
t S
ki
es
o
f a
L
ar
ge
-S
ca
le
E
R
P
I
m
pl
em
en
ta
ti
on
©
H
E
C
M
on
tr
éa
l
26
A
p
p
en
d
ix
1
B
om
b
ar
d
ie
r
A
er
os
p
ac
e’
s
H
is
to
ry
T
im
el
in
e
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 27
Appendix 2
Bombardier Aerospace’s Manufacturing Facilities
MANUFACTURING FACILITIES
Canada
Saint-Laurent, Quebec Component manufacturing for various aircraft models
including the Bombardier 415, Challenger 604, Challenger
800 and Global Express
Production of structural components for other aircraft
manufacturers such as Boeing and Airbus
Saint-Laurent, Quebec Component assembly for the Bombardier 415
Dorval, Quebec Final assembly for the Challenger 604 and CRJ200
Dorval, Quebec Interior completion of the Global Express
Mirabel, Quebec Final assembly of the CRJ700 and CRJ900
Downsview, Ontario Manufacture and final assembly of the Q-Series turboprop
family of aircraft
Manufacture of components and final assembly of the
Global series
Production of structural components for the Learjet 45
North Bay, Ontario Final assembly, pre-flight and delivery centre for the
Bombardier 415
United States
Witchita, Kansas Manufacture of the Learjet series
Manufacture of the Challenger 300
Flight test centre for various Bombardier aircraft
Tuscon, Arizona Interior completion, maintenance and refurbishment of
Bombardier business aircraft
Northern Ireland
Belfast Production of components, engine parts and spare parts for
Bombardier aircraft
Production of components for other aircraft manufacturers
including Boeing, Rolls-Royce Deutschland, General
Electric, and Pratt and Whitney
SERVICE FACILITIES
Canada
Mirabel, Québec Technical support, including support for the CF-18
military aircraft
Painting and interior completion of the CRJ series
United States
Southport, Manitoba Management of basic pilot training for the Canadian
Forces
Bridgeport, West Virginia Maintenance, modification, painting and refurbishing
service center for civil and military aircraft
Contractor Logistics Support for the C-23 aircraft fleet
with the USAF and USARNG
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 28
References
AIRBUS WEB SITE (2007). http://www.airbus.com
BOEING (2005). The Boeing Company 2005 Annual Report.
BOMBARDIER INCORPORATED (nda). About us. Retrieved June 18, 2007, from:
http://www.bombardier.com
BOMBARDIER INCORPORATED (nda). History. Retrieved April 28, 2004, from:
http://www.bombardier.com
BOMBARDIER (2006). Annual Report, year ended January 31, 2006.
BOMBARDIER (2007). Annual Report, year ended January 31, 2007.
CANADIAN BROADCASTING CORPORATION (1990). Bombardier buys Learjet Corp.
CANADIAN BROADCASTING CORPORATION (2004). Bombardier: The snowmobile legacy
Retrieved April 27, 2004, from:
http://archives.cbc.ca/IDD-1-73-362/politics_economy/bombardier/
CANADIAN BUSINESS RESOURCE (2004). Bombardier. Retrieved April 27, 2004, from:
http://www.cbr.ca/CompanyProfile.aspx?CompanyID=2559
EMBRAER WEB SITE (2007). http://www.embraer.com.
FEDERAL AVIATION ADMINISTRATION (2004). FAA Aerospace Forecasts – Fiscal Years
2004-2015.
FEDERAL AVIATION ADMINISTRATION (2005). FAA Aerospace Forecasts – Fiscal years
2006-2017.
GENERAL DYNAMICS (2005). Annual Report, 2005.
GOAD, G. Pierre (1989). “Bombardier to buy Short Brothers PLC from British government for
$50 million,” The Wall Street Journal, June 9, p. 1.
GOAD, G. Pierre (1990). “Bombardier Inc. agrees to buy assets, operation of Learjet for $75
million,” The Wall Street Journal.
KOSELKA, Rita (1992). “Let’s make a deal,” Forbes, 149, April 27, p. 62-63.
SIMONETTA, Joe (2004). Embraer-Empresa Brasileira de Aeronáutica S.A. Hoover’s Online.
Retrieved May 12, 2004, from:
http://www.hoovers.com/embraer/–ID__95436–/free-co-factsheet.xhtml
SIMONETTA, Joe (2004). The Boeing Commercial Airplanes. Hoover’s Online. Retrieved May
12, 2004, from:
http://www.hoovers.com/boeing-commercial-airplanes/–ID__107287–/free-co-
factsheet.xhtml
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Successfully Navigating the Turbulent Skies of a Large-Scale ERP Implementation
© HEC Montréal 29
SIMONETTA, Joe (2004). Airbus S.A.S. Hoover’s Online. Retrieved May 12, 2004, from:
http://www.hoovers.com/airbus/–ID__40566–/free-co-factsheet.xhtml
SIMONETTA, Joe (2004). Bombardier Inc. Hoover’s Online. Retrieved May 12, 2004, from:
http://www.hoovers.com/bombardier/–ID__42381–/free-co-factsheet.xhtml
SIMONETTA, Joe (2004). Gulfstream Aerospace Corporation. Hoover’s Online. Retrieved May
12, 2004, from:
http://www.hoovers.com/gulfstream-aerospace/–ID__40194–/free-co-factsheet.xhtml
THE DE HAVILLAND DEAL (1993). The Wednesday Report, 7, June 23.
For the exclusive use of J. ALEXIS, 2019.
This document is authorized for use only by JACQUES ALEXIS in 2019.
Expert paper writers are just a few clicks away
Place an order in 3 easy steps. Takes less than 5 mins.