Project Management Institute

Not for the faint hearted

use of the rapid project development technique for starting up or turning around troubled projects

Introduction

A known phenomena of project management has been that, rarely, projects are on time, within budget, and are comprised of the original staff from start to finish (Graham, 1989, p.2). Hence it may be reasonably expected that a project manager may be called upon to rescue a troubled project, at sometime in his or her career.

The word ‘trouble’ has been defined as ‘to cause pain; inconvenience or vexation’ (Pocket Oxford Dictionary, 6th edition, p. 979). Therefore, a troubled project is not an undertaking for the faint hearted. When rescuing a project there are a number of possible outcomes: (i) the project is delivered successfully, although probably not within budget, (ii) the project is cancelled, (iii) new expectations are set and missed; (iv) a new plan is established, and new expectations are set and met by both vendor and client. (Mochal, 2005, p.1)

The point at which an organization realizes a project is out of control varies, but typically they are recognised when: (i) they exceed the planned timescale by more than 50% (excluding the time-scale impact of agreed changes in scope), (ii) they exceed the build cost by more than 35% (excluding the cost of the agreed changes in scope), (iii) there is major buyer dissatisfaction to the extent that the future of the project is called into question. (Smith, 2002, p 2), (iv) there is low team morale and motivation, which can descend into a blame culture, (v) too much change to the product begins to occur, (vi) continual re-planning and high risks/issues arise, and (vii) supplier/contractual disputes/problems occur.

The root causes of troubled projects are numerous, but the problems are frequently related to people, planning, and processes, rather than the technology.

So what does it take to turn around a project in trouble, and how do you do it? Does a project manager need a special set of skills and characteristics? What are the steps involved, and what issues are you likely to face? What techniques can be applied to successfully delivering a troubled project?

The following case study will demonstrate how a troubled European retail project was successfully turned around. It will illustrate the issues that faced the project, the application of the ‘Rapid Project Development’ (RPD) technique in assisting the turnaround of the project, and the issues faced after RPD, and the eventual outcome of the project.

Case Study Details

The organisation was a leading German global IT solutions provider (Supplier), whose UK offices were responsible for delivering four automated check out machines (ACOM) for a pilot, to an international UK retailer (Client). This was the Suppliers largest and most prestigious Client. Delivery to pilot was essential to the Supplier for revenue worth potentially £20m, reputation and as a future showcase for future orders.

The project commenced in February 2003, with a promised delivery date of January 2004. When this date did not materialise and a revised delivery date of March 2004 was agreed, to be supplanted by a promised May delivery, then a mid-August delivery date. Each failure to deliver increasingly compromised customer relations. An implementation freeze period from November until the following April had been imposed by the Client.

In July the Project Board, which comprised of both the German and UK CEO's plus senior management, became concerned that the date for delivery for mid-August would again not be met. Only a small window of opportunity was left to deliver before the freeze period. The Project Board took the decision to appoint a new Project Manager, with immediate effect.

The Product

An ACOM enables a customer to self-check out of a retail store. The customer conducts all the activities of a check out cashier (i.e. scanning the products and paying) by themselves. This reduces the processing costs for the retailer, and increases customer satisfaction, through less queuing time. Consequently, the ACOM must, as a minimum, be able to: function as a cashier; user friendly; meet the UK trading standards and disability requirements. Exhibit 1 illustrates the component architecture of the ACOM.

Component Architecture of an ACOM

Exhibit 1 Component Architecture of an ACOM

The supplier responsibilities for delivery of the product were divided between Germany and the UK teams, as illustrated in Exhibit 2:

Key Responsibilities between the parent company in Germany and the UK office

Exhibit 2 Key Responsibilities between the parent company in Germany and the UK office

Revised Approach

With the arrival of a new Project Manager there was consensus at the Project Board level to: (i) keep the project moving, (ii) conduct parallel activities to identify a strategy in which to develop a revised approach for delivery. The following stages were agreed:

  • Stage 1: Analysis of the situation: review of documentation; meet with the team (both UK and German) in Germany to observe and analyse issues; hold a joint kick -off meeting with the new Project Manager with both the team and directors present
  • Stage II: conduct a workshop using the RPD technique for half a day,
  • Stage III: report back to the Project Board with the findings and a strategy.

The overall timeframe for reporting back to the Project Board was two weeks. Stage I and Stage II were to be accomplished in a week. Exhibit 3 illustrates the short timetable for delivery of analysis and new strategy..

Timetable for Delivery of the new Strategy

Exhibit 3 Timetable for Delivery of the new Strategy

Stage I: Outcome from the Analysis

The following issues were identified prior to the RPD workshop:

  • Weak project culture: Projects which lack proper project management tend towards disorder, which can be recognised by: (a) the schedule (if there is one) slips, (b) the project manager suddenly realises slippage and seeks culprit, (c) people from various departments involved accuse people from other departments of delaying the project, (d) project manager decides to make up time by crashing the project, (e) everyone scrambles to crash his job and become infuriated to find that they are either further behind or their part is not yet needed. (Graham, 1989, p.25)

    This project exhibited many of the above project characteristics: there was no project plan only a report, Exhibit 4. A blame culture had developed with the senior management teams blaming each others teams; the software and hardware teams and the UK Implementation team blaming the UK Project Manager; the software team blaming the hardware team and vice versa. In addition there were limited resources for developing the software.

    Project Report

    Exhibit 4 Project Report

  • Product: the product was relatively new to the company and had not been delivered to this type of client, i.e., demanding and difficult to manage; it was being developed by R&D who were not used to product delivery; the hardware design had not been finalised; functional requirements had not been signed off by the client and had been internally adapted.
  • Product methodology: the standard software product development methodology had only been partially adopted; no defect logs or configuration management were implemented; limited documentation was maintained.
  • Testing: there was no test strategy; no test scripts and sporadic testing due to the lack of co-ordination with the hardware team. During the first day of observations, when the software team was due to test the ACOM, the hardware team had taken the machine apart.
  • Scope change: there was no change control process in place. The software team was subject to constant change requests, verbal or by e-mail, from the project manager.
  • Politics: can be defined as an activity concerned with power. While it is recognised that political skill is an increasingly demanded ingredient of success and survival in organisational life, (Baddeley & James, 1987, p 1) if used improperly can cause chaos and panic. Hayes (1984) describes politically competent managers as people ‘who expect to experience resistance to their attempts to get things done, but nevertheless keep on taking initiatives in ways that eventually tend to produce the results they desire’. By contrast, he continues, ‘politically incompetent managers behave like bulls in china shops, upsetting others and creating unnecessary resistance to their proposals’.
    The former project manager, due to his relationships and influence with senior management members, and with the client, had to remain on the project. This presented both the new Project Manager and the former Project Manager with difficulties: the latter ‘face saving’ issues and belief that his direction was still the way forward; the former with political and trust issues.
  • Culture: according to Meredith and Mantel, (2000), the term culture refers to the entire way of life for a group of people. Continuing they indicate that it encompasses all aspects of living; in particular, technology, institutions, languages, and arts. The organisational culture was extremely hierarchical. At initial meeting the team expressed much concern about not being able to deliver the ACOM in a week. When the Hardware Director arrived, and asked the team if they were going to deliver the first ACOM to the UK by the end of the week, the team agreed, thus setting expectations that were unfounded, and likely to be unachievable.

Stage II: RPD Workshop

A RPD workshop was held on the fourth day of the visit. The objectives were to: (i) establish the status of the project, (ii) confirm whether or not the latest promised dates to the client could be met, (iii) identify and confirm a strategy for delivery. Given the hierarchies that existed within the company, and the blame culture that had developed it was decided that:

  • only the staff members who were conducting the actual work would be included in the workshop, not the directors, to promote free speech,
  • the Project Board would support a ‘blame free’ amnesty, i.e., no one would be penalised for past mistakes. However, individuals were expected to disclose all information and issues during the session.

RPD requires that the team members arrive at the session prepared; empowered, and if they do not have the information, be able to obtain it.

The essence of the RPD technique, illustrated in Exhibit 5 is:

  • to focus the disparate work streams into sharing and creating one integrated project team, strategy, and plan.
  • rapidity in which information, activities, deliverables, milestones, dependencies, assumptions, resources, issues and risks can be identified and pulled together into a project strategy and plan.
  • the rapidity which the team can be built and encouraged into taking ownership and responsibility.
  • a visual approach.
  • simple and transportable in its approach requiring only minimal materials; a large room, with flip chart paper sello- taped together to allow a large chart to be drawn and coloured pens.
  • the ability of the Project Manager to motivate, manage and drive its successful outcome.

The RPD technique can be applied to not only troubled projects, but is also invaluable in commencing projects to position them on the right track, and verifying the status of projects during execution.

RPD technique

Exhibit 5 RPD technique

‘Only by incorporating visual thinking will the process of critical thinking be complete’ (Dunlap, 2003, p.1). At the core of its process, the RPD technique uses a visual amalgamation of mind mapping within a structured framework.

Mind mapping presents information: in a visually stimulating manner, while drawing dependencies, interdependencies, and relationships through categorization. This builds from the latent creativity of a cohesive project team. More than an outlining exercise, this process brings out additional ideas and inventive, strategic approaches, as it taps into individual creative channels, and engages team members while generating enthusiasm. (Brown & Hyer, 2001). It is a very useful technique for swiftly discovering the key requirements for project delivery.

However to commence with a mind mapping exercise, as a first step in this case, would have been viewed as further time wasting, and increase resistance from the team. This reaction can be expected in a weak project culture, where team members are inclined to view project management as a hindrance i.e., holding up their activities. Moreover, technical personnel can have a propensity to work in structured environments, and struggle with the seemingly, nebulous approach of mind mapping. Subsequently, by combining the merits of mind mapping, within a controlled framework, RPD rapidly identifies the information required to deliver the project.

Defining the scope is the one of the cornerstones of A Guide to the Project Management Body of Knowledge (PMBOK® Guide), (PMI, 1996) and is fundamental to any project. Completing a work breakdown structure (WBS) is essential to the output of the project scope definition, to ensure that the project includes all the work needed and is the primary input into core processes of activity definition; resource planning; cost estimating; cost budgeting; risk & issue management. (PMI, 2001)

While there are chapters written on the importance of a WBS, how a WBS is derived is less well defined (e.g., some project managers will use word, or start straight away with a Gantt chart). If the process of assembling a WBS is incomplete, the project could be at risk from the beginning.

Through the combination of mind mapping and working within a structured framework, RPD defines the WBS, activities, deliverables, resources, dependencies and issues, while at the same time building the team through focus, participation, and commitment.

RPD Requisites

Team building

The team is the nucleus of any project. Each person will bring his or her own set of customs, beliefs and perceptions to a project. (Graham, 1989, p.92). It is therefore essential to develop a group culture, fostering trust, cohesiveness and commonality.

RPD creates:

  • An understanding of team member challenges and dependencies
  • Provides a supportive and safe forum for cross challenging by team members
  • Forces ownership and accountability from team member to team member and to the project
  • Fosters the development of an effective group culture
  • Facilitates communication through group centeredness.

The RPD provides the environment for each person to act responsibly, as an individual within a team, and thus enables team members to see the whole project perspective, not just their own perspective through the sharing of information. The RPD outcome is the commencement of an integrated team, integrated project plan, and team commitment to an agreed way forward.

Project Manager Qualities

Central to the success of the RPD are the competencies and skills of the Project Manager. The Project Manager must have the capability to lead, manage, and focus individuals, while melding them into a collaborative team, all the while providing direction and motivation.

RPD requires the Project Manager to be able to provide, strong leadership, energy and patience, while encouraging lateral thinking; drive, and direction. This role requires confidence, independent thinking and is not for the faint hearted. It does not require the Project Manager to be a subject matter expert, but a person who truly understands the role of the project manager and the essence of true project management.

RPD Process

The starting point in the RPD workshop depends on the situation of the project and the individuals involved. During this case study workshop there was initial resistance from the individual work streams (Implementation, software and hardware steams) which was to be expected when initiating this kind of technique. This resistance dissipated as indicated through open body language, full participation, and outward enthusiasm as the session progressed. Exhibit 6 illustrates the steps that were taken during the RPD workshop:

RPD process in the workshop

Exhibit 6 RPD process in the workshop

is a high level example of the Build up of deliverables during the session

Exhibit 7 is a high level example of the Build up of deliverables during the session

Stage III: Summary of the Outcome of RPD

The RPD workshop achieved the following, which provided the basis for the report and recommendation back to the Project Board:

  • Scope Definition: the scope for the hardware was confirmed. The original ACOM estimate was incorrect, due to the omission of the ACOM for testing and quality assurance certification. It was realised that the functional specification had not been signed off with the Client, and consequently there was a risk of potentially missing key functionality.
  • Project Strategy: the key components for delivering the ACOM's were rapidly identified. Exhibit 8 illustrates some of the detail produced for the Work Breakdown Structure. The strategy for how the activities and deliverables would be deployed (e.g. five ACOM's were to be delivered by the end of the first week of September and assembled and tested by the end of the second week of September) and timeframes were developed into an agreed project charter, which was later approved by the Project Board.
    Elements Identified for the delivery of ACOM's

    Exhibit 8 Elements Identified for the delivery of ACOM's

  • Resources: a project organisational structure was identified, established, and agreed by the team. It was also agreed that a Test Manager was required, to oversee the testing between the UK and German teams; supplier and client.
  • Team: the RPD workshop verified to the team what was required to deliver the ACOM's. It also provided the basis for the beginning of a strong team and project culture.

After RPD

The RPD provided the foundation for moving forwards. Nonetheless it took a further ten weeks to bring the project under control. During this time, the key issues revolved around (i) the functional scope and managing the client expectations, (ii) the matrix management of the team, (iii) uncontrolled change requests (iv) other project priority conflicts (v) continued politics from the former Project Manager and isolated decisions from the hardware director. Each of the issues as they arose, were addressed and overcome, in a timely manner, through the help of having a project plan and an acculturated team.

After the first few milestones were achieved, a strong mutual trust developed between the team and the Project Manager, increasing confidence with the Project Board. Gradually a weak project culture transformed into a stronger culture, as the team began to realise their efforts, make headway, and deliver on schedule. Isolated decisions diminished as the team became cohesive. The main key on-going issue that remained was the number of defects found with the software.

Ultimately four ACOM's were delivered, of the highest quality and standard, to the Client in January 2005, in the opening that the Client had agreed to delivery.

Conclusion

The RPD technique provided the needed catalyst for the commencement of turning the project from potential failure into success. Investment of a little time, and a significant amount of trust in a capable project manager, the RPD technique can successfully provide the foundation for creating an integrated project team and plan, for delivering projects, even those gone awry.

Baddeley, S & James, K Owl (1987). Fox, donkey or sheep: Political skills for managers. Management Education and Development, 18(1), 3-19.

Brown, K, & Hyer N. (2001). Mind mapping as a WBS development tool. Proceedings of the project Management Institute Annual Seminars & Symposium, Nashville, Tenn, USA, November 1-10

Dunlap, N. (2003) Visual Learning and Media Usage. Retrieved on 16th July 2006 from URL www.csafari.com/articles/visuallearing.html

Graham, R. (1989). Project Management as if People Mattered. Bala Cynwyd, PA: Primavera press.

Hayes, J. (1984). The politically competent manager. Journal of General Management, 10(1), 24-33.

Meredith, J. R. & Mantel, S. J. (2000). Project Management: A Managerial Approach, 4th Edition. New York: John Wiley & Sons

Mochal, T. (2006). Start a recovery project to rescue a troubled project 2005. Retrieved on 18 June 2006 from URL (www.techrepublic.com.com/5100-10878_11-5727633.html.

Dunlap N., Director of Educational Services, February 2003 /2004. Safari Technologies Inc Retrieved on 4th June 2006 from URL (www.csafari.com/aricles/visuallearning.html).

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

PMI (2001). Practice Standard for Work Breakdown Structures. Newtown Square, PA: Project Management Institute

Smith, J. (2002). The 40 root causes of troubled IT projects. The Computer Forum. Retrieved on 18 June 2006 from URL (www.ice.org/onComms/sector/Computing/Article_Display)

The Pocket Oxford Dictionary of Current English, 6th Edition edited by J.B Sykes, Oxford at the Clarendon press.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

©2006, Elizabeth C. Goodman
Originally published as part of 2006 PMI Global Congress Proceedings Seattle, Washington

Advertisement

Advertisement

Related Content

Advertisement