Postimplementation blues: techniques and challenges of recovering a business after go-live, through the application of project management
Described as a “21st century gateway to Britain” (BBC News, 2008), the much-heralded Terminal 5 at Heathrow Airport, primarily servicing British Airways, was officially opened by the Queen of England on 14 March 2008. Shortly afterwards, on its first day of operation on 28 March, 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 when they did get in, they did not know how to navigate the building or the systems. The resultant chaos caused hundreds of flights to be cancelled and fifteen thousand bags to go missing, in a single day. The consequences for British Airways were far-reaching, going beyond the £16 million costs that were incurred. The CEO later admitted that they went live without having adequately tested the system or trained the staff.
The realization that an IT system is not fit for purpose is usually reached on the majority of projects prior to go-live. However, in some cases, there may be so much pressure to go live that the 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 fall-out? Are the issues any different from those 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 6 weeks after going live that the newly implemented, centralized automated warehouse system would not meet its commitment to customers due to an original poor implementation.
A centralized distribution center in the United Kingdom serviced engineers with parts and consumables in support of a 4 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, that 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 made to transfer from a manually operated warehouse to a fully automated warehouse. This resulted in a 2-year flagship program of delivery, for which the business, not IS (Information Systems), was responsible. A European logistical supplier was selected to implement the system, and to manage and support the system once it was in production (i.e., a black box implementation).
The program cost was £21 million. The design of the software deviated by 40% from the generic format and the program was implemented after a 6-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. Six weeks after go-live, it was realized by the business that the volumes of goods required to be dispatched at the end of each day to meet customer demand were not being met in the summer period and therefore the critical winter period that was 3 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 time frame of postimplementation fall-out. resulting in the company hiring a postimplementation programme manager to build and execute a recovery plan before the peak period.
Exhibit 1: Time frames.
With postimplementation 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.
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 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 that had logistical expertise, whose role was to advise the client on the design of the system and storage policies and ensure that it was fit for purpose.
- A legacy supplier, who was responsible for the legacy systems, interfaces, and ongoing maintenance (releases) of the legacy software.
An ever-increasing blame culture was developing between the European supplier and client, revolving 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 or support processes or procedures were instituted from the supplier causing production problems.
- Sporadic change requests that were 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 postimplementation 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 that it would instead develop the processes postimplementation 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, which 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.
Laroche indicates “differences in approaches, values, and expectations between customers, suppliers, and team members with different cultural backgrounds have led to many project failures” (Laroche, 1998, p.1). Increasingly, project managers work with teams, suppliers, or clients from different countries or continents, and 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.
George Bernard Shaw once quipped that “England and America are two countries separated by a common language” (Shaw, G.B., n.d.). Cultural differences can be as obvious as differing physical gestures, homophones, and differing assumptions made in the same situation (e.g., a black cat is considered lucky in the UK but unlucky in other countries). For project managers to be successful, it is essential to understand the how different cultures operate, in particular with regard to problem solving and communication. For example, in terms of communication, Americans tend to be up front and proactive in alerting the client to issues, whereas in the 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, this may be seen with the relative hierarchy of departments; for example, 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, collaborates, or communicates 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” (Palatine Group/ Management World, 2007, p.1).
Schneider has produced an assessment tool that has identified (Exhibit 3) four organizational cultures, and how decision making and performance can be interpreted (Palatine Group/Management World, 2007, p. 4).
Exhibit 3: Organizational cultures.
Synthesized from this are the characteristics and implications for projects, which are outlined in Table 1.
Exhibit 4: Summary of organizational cultural characteristics.
In this case, the client culture leaned towards the collaboration/cultivation culture, in contrast to the supplier who inclined towards a competence/control culture. The implications for the program were therefore:
- 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
- Constant change out of decision makers, which resulted in further prioritization of changes.
- Lack of control over documentation and proper change control procedures, impacting delivery and finances
- Poor contract management of their suppliers
- Hierarchical organizational structure, with exacting protocols
- Poor communication when problems arose, resulting from a tendency to try to resolve issues without alerting the client
- Lack of customer focus, in that their belief was that they knew best and the customer did not
- Individual attention to the client with a 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 programme 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.
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. However, 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 include: urgency of time, intensity of postproduction challenges and resulting chaos, revenues tumbling daily, low morale, and remnant project people remaining and potentially sabotaging any new project efforts as defensive politics come to the surface.
Table 2 illustrates a high-level comparison between the key elements of delivering an IS system when a project is in 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.
|Key Elements||Project/Program Start-Up||Recovering a Project/Program Prior To Go-Live||Postimplementation Recovery|
|Planning||No recovery plan, starting from a ‘blank sheet.” |
Time may be of the essence but can be planned.
|Plan of sorts may exist but is only likely to be of value in terms of providing information; recovery plan will need to be put in place. |
Time will be of the essence, and activities may have to be crashed unless stakeholders agree to extended time frame, or agree that it is simply impossible to deliver in the time frame.
|Recovery plan will need to be implemented in addition to commencing a plan from a “blank sheet.” |
Time is of the essence, and scope may have to accommodate this constraint.
|Scope||Scope to be defined.||Scope already defined, but may be of poor quality and subject to constant scope change.||Scope to be defined.|
|Build||Code to be built||Code may be delivered that is of poor quality, or it may be delayed to due to many code changes.||Code to be built or revisited.|
|Testing||To be conducted as part of the life cycle, and test strategy, test plans, etc., to be defined and produced.||Frequently part of the problem as to why the project is not going live.||Test strategy and plans will need to be defined. Legacy of poor testing may affect recovery.|
|Processes||To be defined.||May not have been defined and part of the problem.||May be essential part of why the business is not operating.|
|Deployment||Training plan and roll-out strategy to be defined.||May not have been defined and part of the problem.||To be defined.|
|Team||New team to be appointed.||Team in existence; team likely to be de-motivated, blame culture. Recovery will almost certainly let some team members go, will require team building and remotivation.||New team to be appointed but previous team members likely to be involved.|
|Suppliers||Commercials to be agreed, commencement of a new relationship.||Supplier may be the part of the issue. Blame culture may have commenced. Leverage over the supplier in terms of finance may be good.||Supplier relationship potentially at the blame level; commercials may be invoked; minimal financial leverage if not a good contract.|
|Project/Program Management||New project/program manager appointed.||Project manager in place likely to be removed from the project as he or she is often part of the problem.||New project/program manager appointed.|
|Budget||To be identified or finalized.||Usually in existence, although may be overspent.||To be identified.|
|Risk Management||Assumptions and risks to be identified.||Relevant risks may not have been identified, and those that have are now issues.||Risks will be related to legacy as well as new implementation.|
|Business||Expectation high.||Possible blame culture with supplier or IS.||Possible blame culture with supplier.|
Table 2: 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:
- General Manager (sponsor) confirmed the key objectives.
- A session was held with all key business and technical 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 that managed any additional change requirements.
Once this was achieved, an exercise was undertaken between key business stakeholders and the European supplier to reclassify which were the high-priority software and hardware defects and modifications.
The exercise took 2 weeks due to:
- Insufficient detail in the logs to fully explain the issues, which required going back to the business to seek further qualification and evidence of the problem
- Supplier required that defects be re-verified if they had been outstanding for more than 3 weeks
The outcome of the exercise identified 60 high-priority defects and 14 modifications that required implementation to stabilize the system. A roadmap was requested from the European supplier, to detail in what order the defects and modifications would be delivered, and more importantly, when they would be delivered.
Governance structure: This involved reestablishment of a governance structure, which included a steering committee, and 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 and the post production issues were not known, the scale and size of the problem indicated that it would be necessary 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: This involved redefining the operational processes with the current staff, and then developing and training them as a collaborative effort. This activity focused on baselining the overall comprehension of warehouse staff; production of work packages; coaching and reevaluation of an extensive program 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 organizations by forcing them to focus on the quality of the customer experience”(Six Sigma, 2008, ¶3)
Implementing the recovery plan: to bring the scope and subsequent activities into a plan and to build the new team, the rapid project development technique (RPD) was applied. This technique sought to rapidly build the framework strategy, identify key milestones, deliverables, and activities, as well as to attain the focus, alignment, and buy-in from the team. Once the overall plan had been produced, each team leader was then required to develop his or her own plan in line with the main program plan. A communications plan was created, along with the initiation of risk and issue management.
After the scope, resources, and timeframe were subsequently rapidly identified, a budget of £1.5 million was agreed on 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) 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
- Legacy issues
The first key deliverable required from the European supplier in the recovery plan was a roadmap which 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 roadmap delivery failed to materialize. Another promise was made for 8 days later, then another and another. One month had passed and no roadmap had been produced. The business fears and claims that the European supplier would not and could not deliver came to the fore.
When a supplier is not delivering, the number of options available to the client is dependant on the circumstances, culture, ongoing intention of the relationship, and the dependency of the client 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 Table 3.
|Option 1||Commercial||Litigation is a last resort on most contracts as it will inevitably bring the relationship to a new low, if not extinguish it and available working options. Litigation is never an easy option as it requires a strong audit trail and detailed evidence of the supplier’s negligence.||A commercial stream was established to go through all of the documentation, but it was soon discovered that there were no audit trails, and in some cases critical documents had been lost. It was considered that to engage in a commercial dispute would result in further deterioration of the relationship, and likely result in no delivery from the European supplier.|
|Option 2||Customer references||All suppliers need references. In logistics it usually requires on-site customer visits. |
However, much as the supplier is to blame for client woes, to malign a supplier can potentially bring litigation for a client. Refusal of a reference is a very powerful message to both the supplier and potential new customer bases. It is also unlikely to bring limitative procedures.
|In the contract, the client had agreed to support these onsite visits to new potential customers for the supplier.|
|Option 3||Publicity stoppages||Many suppliers wish to do press releases or case studies on the web. Refusal by the client to permit or participate can send a negative message.||No press releases had taken place since go-live.|
|Option 4||Financial||To withhold payment to a supplier is a common course of action. Finance does not always have to be a threat, in some cases it can be an incentive.||Unfortunately, in this case, the majority of the money had already been paid, and only £1 million remained unpaid. However as the supplier had lost profit on this contract, they were keen to secure the remaining £1 million.|
|Option 5||Partnership||Ultimately building a partnership with the supplier at all levels can assist in influencing delivery. Building a partnership requires a sizeable effort from the client. This effort may entail frequent visits from the client to the supplier to maintain a degree of prominence.||Very few visits had been conducted by the client to the supplier site, particularly at senior level.|
Table 3: 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 to proceed with the partnership approach. Having reached a decision, the following tactics were implemented:
- Bimonthly visits from the client programme manager to the supplier, with the purpose of reviewing the roadmap 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.
- Weekly calls with senior management and monthly face-to-face visits by the programme director and CTO with the supplier general director to maintain pressure.
In addition to the difficulties with obtaining a roadmap and the deliverables from the supplier, there were ongoing postproduction difficulties, illustrated in Table 4, that needed to be addressed with the supplier to keep the business running:
|Release of the code updates (drops)||There was no structure or notification as to when a code drop would be made, what it would do, and why it was being implemented. As a result, the operation would often be unexpectedly destabilized.||A release management process was implemented, which implemented basic release management processes.|
|Configuration management||Uncontrolled configuration changes by the client team (any member of the staff could make a change without having to record it or without realizing what impact it was having elsewhere) or by the supplier, who could do the changes remotely.||Both the client and supplier were required to restrict change to a few individuals, and notify and record changes.|
|Lack of process of modification requests||There was no formal request process for changes. As a result, the supplier would submit details and a quote based on a short e-mail from the client. This frequently resulted in rework and disillusionment on both sides.||Formal change process implemented.|
Table 4: Ongoing production processes.
Whatever the culture of an organization, there will be politics as “organizations being made of people are essentially political” (Patching, K., & Chatham, R., 2000, 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). Organizationally, 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 postimplementation 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, nor any easy answers to politics, but only some that are visible and some that are beyond the control of the project manager. Table 5 highlights some scenarios.
|Probable Political Areas||Description||Project Impact|
|Sponsors||Too many sponsors can cause political conflict as each one fights for the direction of the project.||Frequent changes in the direction of the project and frustration for the team. |
Slow decision-making process.
|Sponsor change out.||Change in management style and direction on a project, which can be positive or negative. |
Possible appointment of new resources.
|Hidden agendas: some sponsors may have their own agenda or their own career interests for taking a certain strategic direction.||Lack of support for the project manager. |
Re-work if the decisions do not meet their objectives.
|Suppliers||Low internal sponsorship for the project manager.||Difficulty in securing good resources. |
Project timescales slip as other contracts take priority.
|Internal fighting, weak matrix management structures, history of the company formation, and disgruntled employees; turnover of staff.||Schedule slips as deliverables do not materializes.|
|Team||Politics from direct team members can arise for many reasons: ||Time spent by the project manager fighting for resources. Lack of trust on the team.|
Table 5: Political scenarios.
In the case study described above, the political impacts arose from two key sources:
The sponsor was changed out due to personal circumstances and was 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 him, causing communication impacts for the project manager.
- The European supplier employee, who scheduled all development work and who had power through historic reasons within the organization, had been offended some time ago by a member of the client’s management. As a result, all other contracts took priority over that of the client, resulting in slow or nondelivery.
The first political situation was managed by the project manager by building a relationship with the new sponsor, ensuring that there was complete support from the steering committee. The second issue was handled through escalation, at the regular meetings.
Legacy Issues and Impact to the 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 GBP (£). 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 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.
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 stabilization of production 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 as 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 one embarks on such a journey. The application of project methodology in itself will not be sufficient to turn 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.
BBC News Channel. (2008, 14 March).Retrieved from www.bbc.co.uk/1/hi/uk7294618.stm
Free Dictionary (2008). Retrieved from http://www.thefreeddictionary.com/history
Laroche, L. (1998). Managing cross-cultural differences in international projects. Retrieved from http://www.itapintl.com/mngdifintproj.htm
Little-White, H. (2007). Politics and relationships, Jamaican gleaner. Retrieved from hhht://www.jamican-gleaner.com/gleaner/20070902/out/out5.html
Osdir mail archive. (2001). Retrieved from http://osdir.com/ml/science.physics.hydrino/2001-05/msg00079.html
Patching, K., & Chatham, R. (2000). Corporate politics for IT managers: How to get streetwise. Newton, MA: Butterworth-Heinemann. Retrieved from http://books.google.co.uk/books
Palatine Group/Management World. (2007). Linking strategy, leadership and organization culture for project success. Retrieved from http://www.pm.pmforum.org/library/papers/2007/dallas/sudastrategy_leadership_culture
Shaw, G.B., n.d. Quotations by author. Retrieved from http://www.quotationspage.com/quotes/george_bernard_shaw
Six Sigma.(2008) What is Six Sigma? Retrieved from http://www.isixsigma.com/sixsigma/six_sigma.asp
Wikipedia. (2008). Politics. Retrieved from http://en.wikipedia.orglwiki/politics
©2009 Elizabeth Goodman
Originally published as part of proceedings PMI Global Congress 2009 – Amsterdam, Netherlands
Organizations must invest in building a culture - and project teams - that can turn cutting-edge ideas into reality, according to new PMI research.