Project Management Institute

Out of the woodwork--the continuing challenges of bringing control to a troubled project

The Centre for Business Practices (2007) states that in a twelve month period, $35 million of $65million worth of projects were at risk of failing. The reasons why IT projects run into trouble are well documented. Research has revealed that the point at which ‘projects become troubled is towards the end of the project lifecycle’ (ESI, 2006, p. 6), as exemplified in Exhibit 1, leaving little time to do the ‘requisite assessment and put a recovery plan in place’ (ESI, 2006, p.6).

Crisis Point on Projects

Exhibit 1 Crisis Point on Projects

However, this may be the point at which it is recognised that there is a crisis occurring, as a project can go wrong at any point of the project lifecycle, with many projects going wrong from the on-set. The later a troubled project is realised the greater the cost and risk to the business, as illustrated in Exhibit 2.

Impact of Troubled Projects to the Business (adapted from Wideman,1992)

Exhibit 2 Impact of Troubled Projects to the Business (adapted from Wideman,1992)

Regardless of when a project goes wrong, at some point the project has to be turned around from a floundering and potentially failed project, to one that delivers. After a recovery plan has been established, execution of the plan may still face the legacy issues or reveal additional challenges for the project manager. Ultimately, the quest is to recover the project and try to manage these items as they come out of the woodwork , before they potentially derail the project.

There are many different approaches that can be taken by organisations to turn around troubled projects. This paper will illustrate, through a real business case, a successful approach taken to turn around a troubled IT project for a major UK FTSE 100 global organisation, and the issues that arose after the recovery plan was in place, and how they were overcome by the project manager.

Case Study Details

A key part of this organisation’s logistical operations was a manually operated, centralised parts distribution centre. This central warehouse distributed parts from multiple suppliers to all of its UK field work force in which to pass onto the end customer. It was a significant operation. Any problems which prevented the parts from reaching the customers caused severe inconvenience for their customers, increased customer complaints, and resulted in adverse publicity and a potential drop in share price.

The business continued growing with an increase of their customer base by more than four million. This growth spurred an increase in stock lines for the warehouse by sixty-six percent. Capacity issues began to arise which threatened the organisations ability to deliver to its customers and jeopardize any future contracts. This was a deciding factor for the organisation to invest in an automated warehouse distribution system, replacing the manual system, while providing the following benefits:

  • a reduction in operating costs,
  • an improvement in the accuracy in the selection and dispatching of the parts, resulting in improved customer satisfaction,
  • an improvement in service level agreements to the customer,
  • exploit the benefits of e-commerce in the supply chain.

The overall cost of the program was $40m. The Information System (IS) budget was $2m, including a contract price of $800k for the IS software supplier. The timeframe for transition and delivery from the current, manually based warehouse, to the new automated warehouse was two years. The program was broken down into three phases, which culminated in three key releases as shown in Exhibit 3.

Overall Phases of the three Releases for the Case Study

Exhibit 3 Overall Phases of the three Releases for the Case Study

Although the IS department had an instrumental role in delivering Release II and Release III, the entire program was governed and managed by the business. The key roles and responsibilities between the Business and IS are listed in Exhibit 4.

High Level Responsibilities between the Business and IS

Exhibit 4 High Level Responsibilities between the Business and IS

The project organisational structure follows in Exhibit 5.

High Level Project Organisational Structure

Exhibit 5 High Level Project Organisational Structure

Critically, the new warehouse could not be implemented, and the transition not complete, if the legacy software was not switched over by IS through the delivery of Release II. If the IS delivery failed, the entire project would be in jeopardy.

The Head of IS was alerted to the fact that the IS delivery might be compromised due to the lack of proper project management. Specific indicators of project distress were (i) the IS project manager submitted an unstructured red traffic light report, and (ii) the Business Program Manager was vocalising a lack of confidence in the IS project manger, who consistently failed to turn up at meetings and was receiving complaints from the team. A blame culture divided the business and IS when things went wrong. Any delay to the overall transition of the warehouses would result in $500k costs per week. The Head of IS appointed a recovery project manager to examine the critical issues within the IS work stream and develop a recovery approach in which to turn around this troubled project.

Approach to Recovery

It has been found that most organisations do not have a standard process for recovering projects once they are identified as troubled and 31% have no process at all (CBP, 2007).

There are a number of approaches that can be taken to turn a troubled project around. Typically, an organisation can undertake a five step approach summarised in Exhibit 6. This approach is likely to entail: extensive health checks, analysis of what has occurred (or has not), possible hiring of an external audit firm to investigate and provide solutions, continuous meetings with individual team members to uncover root causes, and/or change team members at the beginning of the process.

This approach can take time and money to create the recovery plan and commence turning around the project. For most organisations in the midst of a troubled project, neither time nor money are a luxury.

Typical Approach to Project Recovery

Exhibit 6 Typical Approach to Project Recovery

For this case study, an alternative approach was used, as there was no time for any lengthy review or money to bring in a team of consultants. A three-step rapid process to turning around a troubled project using the Rapid Project Delivery© (RPD) approach was decided upon (see Exhibit 7). RPD focuses on building collaboration with the existing team, in which to develop a recovery plan. The process elicits team members to share and create one integrated project team, strategy, and plan. This cohesive team then rapidly identifies information, activities, deliverables, milestones, dependencies, assumptions, resources, issues and risks which can be pulled together into a project strategy and recovery plan. It promotes, from the beginning, team building and members taking accountability, ownership, and responsibility through understanding their individual role as part of the project whole.

Rapid Project Delivery©: Three step process

Exhibit 7 Rapid Project Delivery©: Three step process

For the case study, the three-stage RPD timeframe was agreed as listed in Exhibit 8.

Timeframe for Case Study Recovery Plan

Exhibit 8 Timeframe for Case Study Recovery Plan

Stage I – Investigation

There are a variety of models for IT software product delivery; for example, the waterfall and spiral methodologies. Many product development models are “developments or refinements of these two” (Cadle & Yeates, 2001, p.50). Whatever the model, there are elementary principles required to deliver an IT project:

  • Design: analysis; specifying the user requirements; high level design; detailed design;
  • Build: coding; delivery of code; supplier unit and system testing;
  • Testing: user acceptance testing (UAT); performance testing
  • Deployment and realisation.

Stage I of the RPD process uses the above fundamentals, to rapidly analyse and detect the trouble spots on a failing project. Exhibit 9 depicts Stage I, which was completed within a week, and consisted of a complete project review of documentation, governance, and interviews with the team.

Typical Trouble Hotspots

Exhibit 9 Typical Trouble Hotspots

The outcome from Stage I - Investigation identified the issues in Exhibit 10 for each of the remaining scheduled project releases.

Outcome from Stage I

Exhibit 10 Outcome from Stage I

Stage II - RPD Session

The recovery project manager, by the end of the first week, had completed Stage I and moved onto Stage II of the RPD Process which was the RPD session. This one-day session brought together key project players: the technical solution specialists, the project manager, the test manager, and the program manager. It was agreed in this first session that the supplier would not be included. The objectives of this one-day session were to collaboratively build the recovery plan by establishing the status of the project, the strategy, the deliverables, and responsibilities for the way forward. Some of the key milestones that were a result of the RPD session are listed in Exhibit 11.

Stage II Outcomes of RPD session

Exhibit 11. Stage II Outcomes of RPD session

Stage III - Executing the Recovery Plan

Within forty-eight hours, a recovery plan was produced and circulated to the team for agreement. As the team became more cohesive and accountable to project delivery, issues began to come ‘out of the woodwork’. The following sections focus on four key recovery project issues which surfaced; scope, testing, and team culture and how they were successfully mitigated in order to deliver the project.

Scope

Project scope management is defined by A Guide to the Project Management Body of Knowledge (PMBOK® Guide) (1996) as “including all the processes required to ensure that the project includes all the work required, and only the work required to complete the project successfully” (p. 47). It further defines scope as referring to: “product scope, which defines the features and functions that are to be included in a product or service and project scope that must be done in order to deliver a product with the specified features and functions” (p.47). In summary, the completion of the product scope is measured against the requirements while the completion of the project scope is measured against the plan.

In any IT project, there are basic design documents that should be in place, illustrated in Exhibit 12. Although, there are exceptions, in general omission of this documentation will likely give rise to issues predominantly during testing when (i) business expectations are not met or (ii) the system does not perform.

Product Scope Requirements

Exhibit 12: Product Scope Requirements

The lack of required scope documentation, identified in Stage I, caused consistent testing delays in Release II as business expectations were consistently not met and change requests continuously raised.

Release II was in the latter stages of testing. To bring control to the large number of changes being raised the recovery project manager collated all agreed change requests and established a change control system. This was communicated to the team (including supplier). This (i) removed the one to one relationship between the technical specialists and the supplier, and (ii) introduced a change freeze.

For Release III, some code had already been delivered. The remainder of the code was due in three stages, requiring significant testing and release resources. The following steps were therefore agreed:

(i) to undertake a scope gap analysis, to understand the difference between the business and supplier expectations

(ii) to renegotiate the release strategy with the supplier

(iii) to address the lack of detailed technical documentation

A gap analysis can be defined as the difference between where your are and where you want to be (Web definition, 2007). It is the “process of determining, documenting, and approving the variance between business requirements and system capabilities in terms of packaged application features and technical architecture” (Web definition, 2007).

To determine the difference between what was expected by the business and what the supplier was delivering a traceability matrix (Exhibit 13) was established which compared the following information:

  • Business Requirements Specification reference to the Supplier scope documents and their internal technical documents
  • Supplier confirmation as what was in scope and out of scope
  • e-mails / meetings updates produced by the client
Sample Traceability Matrix

Exhibit 13 Sample Traceability Matrix

The traceability matrix was compiled with the business, technical team, and supplier. Once the gaps were identified they were then prioritized by the business. Functionality deemed to be in scope by the client, but out of scope by the supplier had to be supported by documented evidence.

The lack of functional specification and detailed design was addressed by the client, producing, in conjunction with the supplier, a joint hybrid technical document, which detailed how the system would work.

Finally, it was agreed with the supplier to amend the contract and have one consolidated release III, instead of three.

Testing

The purpose of testing is to increase the level of confidence that the system will successfully perform in accordance with the user requirements and design specification. If testing is not conducted thoroughly it will expose the business to operational failures and on-going costs. The V-Model (Cadel & Yeates, 2001) in Exhibit 14 illustrates the correlation between the scope and testing.

Testing V-Model ( Cadle & Yeates, 2001)

Exhibit 14Testing V-Model ( Cadle & Yeates, 2001)

When turning around a project, the duration of testing can be one of the most difficult areas to predict due to: (i) ill defined product scope resulting in scope changes (ii) poor software development (code) causing many defects, both extending the timeframe.

Exhibit 15 illustrates the common generic test phases and the associated responsibilities.

Generic Test Phases

Exhibit 15 Generic Test Phases

The Test Manager’s role is to prepare for the testing, execute it and manage it to conclusion. Preparation includes: the production of a test strategy, development of test plans for each test phase, appointment of testers and production of test scripts. The execution phase will involve the progress management of the scripts, defect meetings and progression from one test phase to the next based on the entry and exit criteria.

In this case as there was no test documentation, it was agreed that an audit would be conducted by the IS Test Program Manager. Exhibit 16 lists the findings from the testing audit. The audit centred on Release II, as no testing had commenced for Release III.

Summary of Test Audit

Exhibit 16 Summary of Test Audit

The immediate actions recommended by the audit were:

  • Test Manager to report directly into the IS project manager,
  • An IS Test manager to be temporarily appointed to work alongside the test manager,
  • Establishment of daily defect meetings and weekly reporting.

Team Culture

While project methodology, schedules, actions logs, risk logs, etc. provide a framework for project delivery, at the nucleus of any project, is the team. Project managers do not always have the luxury of selecting their team members. In the case of troubled projects, the importance of keeping the knowledge and the project moving, means that a recovery project manager will most likely inherit a team.

Each team member will not only bring a variety of key skills but also individual biases, work habits, agendas, values, and characteristics. These individuals are not normally accustomed to working with each other, nor necessarily on projects. Yet research tells us that ‘good project cultures lead to high performance and satisfaction, but bad ones to failure’ (Hoffman, 2005, p. 1)

From the completion of the first RPD session, and throughout project execution, there were a number of people issues that the recovery project manager had to resolve and manage:

  • The IS project manager: The starting point for a good project culture is the project leader, whose leadership will &‘ shape the communications, behaviour, rituals, values and day to day performance on a project. It is the attitude of the leader that engenders the support of the team members’ (Hoffman, 2005, p. 1) Little leadership was exhibited by the IS project manager, who was demonstrably erratic and unreliable. This led to a distraction from the real project issues and led to disrespect from the team.
  • The project co-ordinator: the role of a project co-ordinator is often merely seen as an assistant. A good project coordinator can significantly contribute to the overall success of the project as the backbone to project delivery. They ensure the documentation is up-to-date, accessible, version controlled, and track follow up action items. Additionally, a good co-ordinator will assist the project manager through communication and be proactive on managing risks and support project reporting, including financial management. In this case, the documentation was chaotic and uncontrolled and activities were undertaken grudgingly and communications remained poor.
  • The test manager: the immediate reaction of the Test Manager after the recovery project plan was produced was to advise the recovery project manager that the dates for testing could not be met and testing was going to slip again. Recommendations resulting from the test audit and continued lack of structure and poor communication demonstrated that this person was not in the appropriate post

“If you are not sure whether or not an employee should stay, then they should probably go” (Cohen, 2006, p.1) Nonetheless “letting people go is painful, but the alternative is more painful” (Cohen, 2006, p.1). In this case all three of the above individuals were removed from the project within the first four weeks of assignment of the recovery project manager.

In addition, to the team members who have to be removed, within a team there are many characteristics that need to be watched and managed for encroaching and possible detrimental impacts. These can range from blockers (someone who finds reason for not moving the project forward), to the grenade (person who holds onto information and reveals it at the last minute which frustrates colleagues and raises issues) and to person who makes isolated decisions based on their own expertise.

In this case study, two of the team members exhibited at least one of the above characteristics. These characteristics were managed through the recovery project manager understanding how they worked, thus preempting any additional impacts.

Summary

The production of a recovery plan is a critical step for getting a project back on track. However, this is not sufficient in ensuring a trouble project stays out of trouble and ultimately gets delivered. Many out of the woodwork issues will be caused from legacy issues, such as continued project and product scope issues which can still threaten to turn a recovery project into a doomed project. By understanding and managing the areas of weaknesses, a strategy can be developed to successfully mitigate these kinds of post recovery plan challenges. This case study has highlighted the typical issues, mitigation and solutions as they arise from developing the recovery plan to delivering the project.

References

Cadle, J. & Yeates, D. (2001). Project management for information systems (3rd ed.). England: Pearson Education Limited.

Center for Business Practices (2006). Troubled projects: project failure or project recovery: A benchmark of current business practices. Retrieved from http://www.cbponline.com/ProductDetails.asp?ProductCode=Research%2DTroubledProjects

Cohen, A. (2006). Letting People Go retrieved from http://www.alcohen.com/LettingPeopleGo.

Definition of gap analysis (2007) retrieved fromhttp://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html#G

Electric Power Research Institute (EPRI), (2007). Design documents retrieved from www.epri.com/eprisoftware/processguide/ddd.html

Hoffman, E. (2005). High performance projects and the @culture thing. National Aeronautics and Space Administration Academy Sharing Knowledge, 18. Retrieved from http://appel.nasa.gov/ask/pdf/pdf18/105470main_18_resources_directors_desk.pdf

Integrated Manage Chief Toolkit (IMCT). (2007). High level design documents retrieved from http://www.managechange.co.uk/

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Newtown Square, PA: Project Management Institute

Saving troubled projects: Five steps to rapid recovery. (2007, January). ESI Horizons Newsletter, 8,(1), 1.

Spolsky, J. (2000). Painless functional specifications – part 2 what’s a spec? Retrieved from http://www.joelonsoftware.com/articles/fog0000000035.html

Wideman, M. (1992). Project & program risk management: A guide to managing project risks & opportunities. Newtown Square, PA: Project Management Institute.

2007 Elizabeth Goodman & Patricia Henry
Originally published as part of Proceedings PMI Global Congress 2007 – Atlanta, GA

Advertisement

Advertisement

Related Content

Advertisement