Described as a “21st century gateway to Britain” (BBC News, 2008), the much heralded Terminal 5 (which primarily services British Airways) at Heathrow Airport was officially opened by the Queen of England on March 14, 2008. Shortly thereafter on its first day of operation on March 28, congratulations turned to nationwide disgrace, as the baggage system broke down, staff were unable to get into the terminal due to a lack of parking spaces, and once in the building, they did not know how to navigate through the building or the systems. The resulting chaos caused hundreds of flights to be cancelled and 15,000 bags to go missing, in a single day. The consequences for British Airways were far more than the £16m costs it incurred. The CEO later admitted that they went live without having an adequately tested the system or trained the staff.
The realization that an IT system is not fit for its purpose is usually reached on the majority of projects prior to going live. However, in some cases there may be so much pressure to go live, a decision is made to proceed.
How can project management assist a business when a project has gone live but shortly afterwards realizes that the business consequences are going to be huge? What are the challenges facing a project manager post project fallout? Are the issues any different from that faced by a project manager trying to turn around a troubled project before one has gone live? How is a recovery plan developed and instituted once the project has been implemented?
This paper will illustrate through a real case study the challenges faced by a program manager, when the logistical operation at the heart of a leading FTSE 100 organization realized two months after going live that the newly implemented, centralized automated warehouse system would not meet its commitment to customers due to an original poor implementation.
Case Study
A centralized distribution centre in the United Kingdom serviced engineers with parts and consumables in support of a four million-customer base. As the business grew, its manually operated warehouse could no longer sustain the business. Any disruption to service, particularly during the peak winter period, which prevented the parts from reaching the customers not only caused severe inconvenience for their customers but would likely result in adverse publicity and a potential drop in share price.
A decision was taken to transfer from a manually operated warehouse to a fully automated warehouse. This resulted in a two-year flagship program of delivery, for which the business, not information systems (IS) was responsible. A European logistical supplier was selected to implement and manage the system the system once it was in production, i.e., a black box implementation.
The program cost was $40 million. The design of the software deviated by 40% from the generic format and the program was implemented after a six month delay from the originally scheduled go live date. Immediately after implementation, the programme manager, who had been responsible for the delivery of the program, was made redundant while other key personnel were also released. Eight weeks after go-live, it was realised by the business that the volumes of goods required to be despatched at the end of each day to meet customer demand were not being met in the summer period and therefore the critical winter period three months away was in jeopardy.
All business as usual attempts to resolve the issues had not succeeded. It was therefore decided by senior management to establish a recovery program and appoint a new program manager.
Exhibit 1 illustrates the go-live date and the timeframe of post-implementation fallout resulting in the company hiring a post-implementation program manager to build and execute a recovery plan before the peak period.
Exhibit 1: Timeframes
Situation Analysis
With post-implementation issues rising, the new program manager faced unresolved supplier issues, insufficient staff training resulting in staff demotivation and inventory backlogs, cultural barriers, and an unstable production system all contributing to a complete lack of confidence in the system.
Supplier(s) Issues
The majority of IS projects require interaction with a supplier. The type of relationship can vary from the most basic to the very complex, such as outsourcing or black box management. When a supplier manages production systems for a client, the responsibility of risk to an operation, as in this situation, can be wrongly assumed to be that of the supplier. In this case, there were three suppliers involved in the original delivery, as illustrated in Exhibit 2.
Exhibit 2: Overview of suppliers
- A large European supplier responsible for delivery and the subsequent management of the logistical software and hardware, i.e., black box. The client and supplier had entered into a fixed price contract.
- A small organization with logistical expertise and advised the client on the design of the system, storage policies, and ensure that it was fit for purpose.
- Legacy supplier, who was responsible for the legacy systems, interfaces, and on-going maintenance (releases) of the legacy software.
An ever-increasing blame culture was developing between the European supplier and the client. It revolved around the following key issues:
- A weak, fixed price contract was executed. The focus was on production and not issue resolution, delivery, or defect turnaround, leaving no fall back for the client and creating a financial loss for the supplier.
- No mature project processes or procedures were instituted from the supplier causing production problems.
- Sporadic change requests that were received by e-mail or verbally from the client, leading to work being generated by the supplier with no result or follow through and a haphazard release.
The client had no real financial leverage post-implementation and had to address the production issues through a differentiated approach for getting the supplier to deliver adequately.
Lack of Processes and Training
Technical delivery in most projects is not sufficient to bring about success. Critical to achieving business expectations and objectives is a change program that includes the implementation of business processes and training. At the time of implementation, the business had decided that it would not institute any processes or procedures prior to implementation and develop the processes post-implementation in the warehouse.
This resulted in a vicious blame cycle between the client and supplier(s) where no one knew how to run the system with few standard procedures in place. Limited functional training was provided by the European supplier that was conducted by developers. There was no ongoing professional staff development, and there was a lack of consistency between shifts in using the warehouse systems. The outcome was an untrained and unskilled workforce, ill equipped to manage a highly precise system.
Culture
Laroche (1998) stated that differences in approaches, values and expectations between customers, suppliers and team members with different cultural backgrounds have lead to many project failures” (1998, p. 1). Increasingly, project mangers work with teams, suppliers, or clients from different countries or continents. Project managers may have key activities such as code development or testing conducted by offshore suppliers. As organizational culture becomes more complex with cross-cultural differences, project managers require additional dimensions to their skill base.
Cross cultural differences. George Bernard Shaw once quoted that “England and America are two countries separated by a common language” (Quotationspage.com, nd, ¶10) Cultural differences can be as obvious as physical gestures; homophones and assumptions made in the same situation, e.g., a black cat is considered lucky in the United Kingdom but unlucky in other countries. For project managers to be successful, it is essential to understand the varied methods that different cultures use for problem solving and communication. For example in terms of communication, North Americans tend to be upfront and proactive in alerting the client to issues, whereas German- or French-culture individuals may try to solve the problem first before alerting management. In the former case, a project manager may be alerted to a large number of risks that may not materialize, whereas in the latter example the project manager may be more susceptible to surprises.
Cross-cultural issues also arise at the organizational level because companies in different countries organize their daily business differently. For instance, relative hierarchy of departments, e.g., manufacturing departments of German-based companies have influence over their marketing and sales, whereas in North America, manufacturing departments will follow the lead of marketing and sales. Different cultural approaches will influence how a team is managed, collaborate, or communicate, even if that team is developed from the relationship of a client and supplier.
Organizational culture is potent, as
…culture resides in every fold of an enterprise—influencing the dynamics of performance, relationships, and motivation. It shapes decisions, guides its actions, and drives individual (and group) behaviour. It can block an organisations’ or projects’ strategy, or it can catalyze it. (Palentine Group Management World, 2007,p. 1).
Schneider (Palentine Group Management World, 2007, p. 4) has produced an assessment tool that has identified (Exhibit 3) four organizational cultures and shows how decision making and performance can be interpreted.
Exhibit 3: Organizational cultures
Synthesized from this, are the characteristics and implications for projects which are outlined in Exhibit 4.
Exhibit 4: Summary of Organizational Cultural Characteristics
In this case, the client culture leant towards the collaboration/cultivation culture, in contrast to the supplier who inclined towards a competence/control culture. The implications for the program were as follows:
Client:
- Lack of delivery culture and focus, resulting in constant changes in priority of scope,
- Lack of a delivery culture, resulting in resistance to project implementation structure,
- Change out of decision makers, which resulted in further prioritisation of changes,
- Lack of control over documentation and proper change control procedures, impacting delivery and finances, and
- Poor contract management of their suppliers.
Supplier:
- Hierarchical organisational structure, with exacting protocols,
- Poor communication when problems arose, as tendency to try to resolve issues without alerting the client,
- Lack of customer focus, in that their belief was that they new best and the customer did not, and
- Individual attention to client with lack of understanding about long term or lateral impacts.
Unstable Production System
A business acceptance document, which identified seven testing areas, was signed off by the previous program manager and the integration supplier with an overall statement that the system “broadly” met the functional expectations. Supporting documentation was scant to substantiate the testing and the expected volume management was never tested or designed with the current staff.
Commencing the recovery program, the new program manager was confronted with over 360 software, hardware, and process issues, with more issues burgeoning from the daily meetings. Although there were hundreds of issues, most of them were ill defined or unwarranted.
Recovery Plan
When taking over a troubled project that is prior to go-live the basic entities of project management are usually in place: a project manager, a project team, a governance structure, a plan, and a budget. Albeit, any of these items, can be the root cause to systemic project problems.
In this case, there were parallels to commencing a new project in that the scope had to be defined, teams assembled, and a budget identified. However, some of the defining factors between a project start-up and a program seeking to recover a business through include: urgency of time; intensity of post production challenges and resulting chaos, revenues tumbling daily, low morale, and remnant project people remaining potentially sabotaging any new project efforts, as defensive politics come to the surface.
Exhibit 5 illustrates a high level comparison between the key elements of delivering an IS system when a project start up phase, is in trouble prior to go live and recovery is required of the business after go live based on real case studies.
Exhibit 5: Comparison of Differences Between New Project Start-up and Recovery of Troubled Projects
To start the recovery process the following parallel activities were taken immediately by the new project manager:
Defining the Scope. One of the first steps in the creation of the recovery plan was to identify the overall scope of the new project. To rapidly baseline the overall program scope, the following basic steps were taken:
- The general manager confirmed the key objectives.
- A session was held with all key business stakeholders to identify all existing work as well as work not yet commenced that was critical to achieving the objectives. This was achieved by brainstorming, categorizing, ranking, and prioritizing, all of the work against the overall objectives. The program manager also instituted a change control process which managed any additional change requirements.
Once this was achieved, an exercise was undertaken between key business stakeholders and the European supplier to reclassify the high priority software and hardware defects and modifications.
The exercise took two weeks due to (1) insufficient detail in the logs to explain the issues fully, which required going back to the business to seek further qualification and evidence of the problem; and (2) the supplier required that defects be re-verified if they had been outstanding for more than three weeks.
The outcome of the exercise identified 60 high priority defects and 14 modifications that required implementation to stabilise the system. A road map was requested from the European supplier to detail what order the defects and modifications would be delivered, and more importantly, when they would be delivered.
Governance structure. A governance structure that included a steering committee was re-established. This structure encompassed many senior stakeholders who had played instrumental roles in the original program, as well as new members such as the chief technology officer with commercial representation.
Team. While the full scope of the project was not known, and the postproduction issues, the scale and size of the problem indicated that there was going to be a necessity to recruit key resources, such as a test manager, process leader, training manager, and another project manager. The recruitment and appointment of resources commenced immediately.
Business Process Design and Training redefined the operational processes with the current staff and then developed and trained them as a collaborative effort. This activity focused on base lining the overall comprehension of warehouse staff; production of work packages; coaching and re-evaluation an extensive program was implemented using Six Sigma to develop process compliance with the current staff.
Six sigma methodology is the implementation of a measurement-based strategy that focuses on process impact and variation reduction, through the application of Six Sigma improvement projects. It is a defect reduction methodology that seeks to transform organisations by forcing them to focus on the quality of the customer experience. (ISixSigma, 2008)
Implementing the Recovery Plan. The rapid project development technique (RPD©) was applied to bring the scope and subsequent activities into a plan and to build the new team, This technique sought to rapidly build the framework strategy, identify key milestones, deliverables and activities, as well as attaining the focus, alignment and buy- in from the team. Once the overall plan had been produced, each team leader was then required to develop their plan in line with the main program plan. A communications plan as well as an initiation of risk and issue management was created.
Subsequently, having rapidly identified the scope, resources, and timeframe, a budget of £1.5m was agreed by the investment board.
Challenges Faced during the Execution of the Recovery Program
It can be said that history ‘is something that belongs to the past” (The Free Dictionary, 2008, ¶4), and therefore, no longer is relevant. However, for a recovery program, the legacy of history will often influence the challenges faced. In this case, there were a number of underlying, inherited, issues that continually threatened to derail the execution of the recovery program:
- Supplier issues,
- Politics, and
- Legacy issues.
Supplier Issues
The key deliverable required from the European supplier in the recovery plan was a road map that detailed when the software and hardware defects and modifications would be delivered. This was promised for delivery within 10 days.
The first date for the road-map delivery failed to materialize. Another promise was made for eight days later, then another and another. One month had passed and no road map had been produced. The business fears and claims that the European supplier would not and could not deliver came to the forefront.
When a supplier is not delivering, the number of options available to the client is dependant on the circumstances, culture, on-going intention of the relationship, and the client’s dependency on the supplier. In this case, there were five strategic options available to the client to address the lack of delivery from the supplier, ranging from a more “threatening stance” to developing a relationship/partnership. These options are considered in Exhibit 6.
Exhibit 6: Client Options with the Supplier
In the recovery plan, there was a significant dependency on the supplier to turn the postproduction issues around and deliver. The steering committee was divided as to which strategy or combination to deploy. It was agreed upon to proceed with the partnership approach. Having reached a decision, the following tactics were implemented:
- Bi-monthly visits from the client program manager to the supplier, with the purpose of reviewing the road map status and an update on each issue,
- At suitable points, the client requested that the visit be extended to include other members of the team, such as the test manager to review their test quality procedures, and
- Weekly calls with senior management and monthly face-to-face visits by the program director and CTO with the supplier general director to maintain pressure.
In addition to the difficulties with obtaining a road map and the deliverables from the supplier, there were ongoing postproduction difficulties, illustrated in Exhibit 7, which needed to be addressed with the supplier to keep the business running.
Exhibit 7: On-going Production Processes
Politics
Whatever the culture of an organization, there will be politics as “organisations being made of people are essentially political” (Patching & Chatham, 2008, p. 1). Politics have been defined as “the process by which groups of people make decisions” (Wikipedia, 2008). On this level there would only seem to be positive overtures. However a further definition describes politics as “intrigue or manoeuvring within a political unit or group in order to gain control or power” (Osdir, 2001, ¶7). Organisationally it is noted that “office politics are often debilitating and counterproductive” (Little-White, 2007, p. 1).
Politics are seemingly the most intense with troubled project and post implementation recovery, due to the reactive nature of the team and stakeholders, and consequently can make a challenging position become even more stressful for the project manager.
Political situations can arise from many sources. There are no right or wrong approaches or easy answers to politics, but some that are visible and some that are beyond the control of the project manager. Exhibit 8 highlights some scenarios.
Exhibit 8: Political Scenarios
In this case, the political impacts arose from two key sources. The sponsor was changed due to personal circumstances and replaced by a former director who had been instrumental in the original program. The impact was twofold:
- The dynamics of the relationship changed with key members of the team who had formally reported to the director causing communication impacts for the project manager.
- The European supplier employee, who scheduled all development work, had been offended some time ago by a member of the client’s management. As a result, all other contracts took priority over the clients, resulting in slow or non-delivery.
The first political situation was managed by the project manager ensuring that there was complete support from the steering committee and by building a relationship with the new sponsor. The second issue was handled through escalation.
Legacy Issues and Impact to Program
As the postproduction program modifications came closer to being implemented, it was realized that there was a stock (parts) imbalance amounting to millions of pounds. In order to implement some of the key modifications, the stock had to be balanced, requiring the financial deficit to be written off.
This forced an investigation into the system, which identified that as a result of a lack of system processes, the original interface testing and implementation was flawed. So acute were these issues that the deployment of the modifications had to be delayed while the interfaces were adjusted and tested.
Outcome
With the supplier now a partner in the program and the business, the politics gravitated toward a common ground of collaboration and quality.
At the core of the production stabilization was the implementation and control of the processes and training. As the warehouse staff became more proficient, performance improved resulting in increased volumes through less production outages. This was a result of the staff working as a team, not individuals. The improved maturity of understanding of how the system worked enabled both the client and supplier to work as colleagues to address legacy issues.
As the defects were delivered and root causes addressed it became clear that some of the modifications that had been so pressing became less imperative, resulting in a decrease in the number of requests of modifications, reducing the complexity and cost of the system.
When implementing a postproduction recovery program, there are differentiating factors from both start-up projects and troubled projects prior to go live, which need to be considered before embarking on such a journey. The application of project methodology in itself will not be sufficient to turning around the business, but the real skill of the program manager, to understand the dynamics of project management when applied can successfully turn around a business.