Case Study - Rescuing a Troubled Project C.A. McCall-Peat Liberty Life, Johannesburg, South Africa P.O. Box 10499, Johannesburg, 2000, South Africa, telephone +27 11 408-3687, fax +27 11 408-3650, email: c..t@liberty.co.za Summary This case study outlines a troubled project and the issues faced by the project. The case study attendees are asked to analyze the project information provided and to recommend courses of action to bring the project back on track. Attendees are also asked to suggest actions that could be taken on future similar projects to mitigate encountering similar problems. The key lessons learnt could be applied by other organizations to avoid common pitfalls which result in projects going off track, as well as knowing the telltale signs of troubled projects and actions to take to bring them back on track. This is an interactive session, which utilizes group discussion to facilitate the adult learning experience. Background A leading financial services company embarked on a new product development project. The nature of the company's business is that it operates in an extremely competitive environment that necessitates fast delivery to market so as to prevent competitor companies from gaining dominant market share with similar competitive products. The key success factors of the project were, therefore, time to market and quality. Cost of delivery was not a major concern. Scope The scope of the project was to make a new investment product, including the systems changes, the policy documents, marketing launch material, and the administrative user training. The project was divided into sub-projects consisting of: Systems, Marketing, Training, and Legal. A project manager was appointed, as well as sub-project co- coordinators. Time Scales The launch date was set as 1 June 2002. The product had to be ready for launch on this date, as all the marketing material would reflect this date and the launch had to precede the launch of similar products from competitors. The project start date was 3 December 2001. The tasks that had been completed prior to 3 December were the Business Case compilation and approval and the project team establishment. Technology The systems development was to be done using the Java programming language and environment, which was new to the development team. The developers were sent on Java programming training 2 weeks prior to the project start. The developers were used to working in a COBOL programming environment and had not worked with any object-oriented languages before. Case Study Summary of Events Business Case Development The Product Development Department developed the Business Case for the proposed new product, including projected cost/benefit analysis based on previous similar products and current market share. The Business Case was reviewed by Executive Management and approved. Requirements Definition The Product Development Department developed the requirements specification for the new product. .

1. Case Study - Rescuing a Troubled Project C.A. McCall-Peat Liberty Life, Johannesburg, South
Africa P.O. Box 10499, Johannesburg, 2000, South Africa, telephone +27 11 408-3687, fax +27
11 408-3650, email: c..t@liberty.co.za Summary This case study outlines a troubled project and
the issues faced by the project. The case study attendees are asked to analyze the project
information provided and to recommend courses of action to bring the project back on track.
Attendees are also asked to suggest actions that could be taken on future similar projects to
mitigate encountering similar problems. The key lessons learnt could be applied by other
organizations to avoid common pitfalls which result in projects going off track, as well as
knowing the telltale signs of troubled projects and actions to take to bring them back on track.
This is an interactive session, which utilizes group discussion to facilitate the adult learning
experience. Background A leading financial services company embarked on a new product
development project. The nature of the company's business is that it operates in an extremely
competitive environment that necessitates fast delivery to market so as to prevent competitor
companies from gaining dominant market share with similar competitive products. The key
success factors of the project were, therefore, time to market and quality. Cost of delivery was
not a major concern. Scope The scope of the project was to make a new investment product,
including the systems changes, the policy documents, marketing launch material, and the
administrative user training. The project was divided into sub-projects consisting of: Systems,
Marketing, Training, and Legal. A project manager was appointed, as well as sub-project co-
coordinators. Time Scales The launch date was set as 1 June 2002. The product had to be ready
for launch on this date, as all the marketing material would reflect this date and the launch had to
precede the launch of similar products from competitors. The project start date was 3 December
2001. The tasks that had been completed prior to 3 December were the Business Case
compilation and approval and the project team establishment. Technology The systems
development was to be done using the Java programming language and environment, which was
new to the development team. The developers were sent on Java programming training 2 weeks
prior to the project start. The developers were used to working in a COBOL programming
environment and had not worked with any object-oriented languages before. Case Study
Summary of Events Business Case Development The Product Development Department
developed the Business Case for the proposed new product, including projected cost/benefit
analysis based on previous similar products and current market share. The Business Case was
reviewed by Executive Management and approved. Requirements Definition The Product
Development Department developed the requirements specification for the new product. These
requirements were specified based on the understanding level of the project team, which had
many years of experience in the company and an extremely good understanding of the systems.

2. Some of the finer details of the requirements, such as the reporting requirements and the final
policy document wording, were not defined at this initial stage. The outstanding requirements
would be agreed during the project, once the users had decided exactly what they wanted in this
regard. Project Team Appointment John was appointed as the overall Project Manager. John had
been with the company for 23 years and been involved in numerous projects for new product
developments in the past. He knows the existing systems intimately and has good working
relationships with all the various departments involved in product development and launch. The
project team appointed consisted of people from various departments, all of whom had been
involved in previous product development projects. Their knowledge of the systems and
applications is extensive. Project Kick-off The Product Development Executive, the Sponsor of
the project, chaired the project kick-off meeting, held on 3 December 2001. She emphasized the
importance of the project to the company, as it would ensure good returns by getting the new
product to the market before the competitors. She stressed that the delivery date must not be
compromised in any way, as this would open the doors for competitive products and the
opportunity would be missed. The Project Manager and the sub-project co-coordinators were
asked to get busy immediately with their planning, and a follow-up meeting was set for 17
December to review the project plans. Project Plan Development The project team had been
involved in many similar projects in the past, and thus knew exactly what the project entailed.
For this reason the plans were based on previous historical information of past projects. The
project plans included only the systems related work. The interfacing to other areas, such as
Legal Department, Marketing and Operations would be handled by the Project Manager at the
specific time required for their input. Project plans were drawn up using a scheduling tool. The
phases and tasks were detailed, but resources were not allocated to the tasks, since each resource
knew exactly what their role was on the project and which tasks related to them. Task
dependencies were not put into the plan, as this made the plan too complex. Dependencies were
handled by each team member and by the Project Manager. Project Plan Management
Management of the project plan consisted of updating tasks with their percentage complete on a
weekly basis. Record of actual hours spent on specific tasks was not deemed necessary. Each
resource gave an estimate of the percentage complete for each task, which was used to update the
plan. Resource availability was handled in an informal manner whereby each resource gave
feedback on a weekly basis regarding their workload on the project and other non-project work
responsibilities, such as systems maintenance. Progress Reporting Progress reports were
produced every 2 weeks. These consisted of a progress summary, deliverables attained, %
complete, risks, issues and cost information. (See attached most recent progress report). Minutes
were kept of all meetings. See attached most recent meeting minutes. Progress for Period 3
December 2001 to 31 January 2002 Initial progress was good, with all team members working

3. well together. Programming started almost immediately, since the team knew the systems so well
that they were able to make some of the required changes immediately. Some issues were
identified with the user requirements, since not enough detail was in the requirements document.
These issues were resolved between the programmers and the users. Some of the programmers
experienced problems when they discovered they were working on the wrong version of the user
requirements. This was resolved when the users printed out the current version of the
requirements for all the team members to make sure they were all working on the current
version. Progress was not as fast as desired, due mainly to the users changing their minds about
the requirements. The programmers were very accommodating with such changes and tried their
utmost to keep the users satisfied. Unfortunately, the number of changes and additional
requirements requested by the users caused the work to fall behind schedule. When some of the
programmers complained to the Project Manager, he said that it was essential that the users
received what they wanted, so their changes must be accommodated, even if it meant having to
work extra hours to catch up. The programming was also delayed from time to time due to
technical problems experienced with the new development environment. The company did not
have anyone experienced in the new development software, thus having to rely on vendor
support, which was a bit lacking due to their commitments at other companies. Progress for
Period 1 February 2002 to 1 April 2002 (2 months before live date) The Sponsor became
concerned with the project progress, since she felt there was a risk of not meeting the required
delivery date. The programmers were working long hours to try catch up on the project work, as
well as doing their required maintenance and problem fixing of the live systems. The Legal
Department said that they might not be able to provide the Policy Document wording in time for
the live date, due to other priorities. They said they might have been able to if they had known
about it sooner. The user department said they might have a problem getting the test packs ready
for user testing, as some staff was going on leave over the Easter period. Initial testing revealed
that the performance of some of the modules was very slow. This was resolved to some extent
when it was found that some of the programmers had used inefficient coding, as they were new
to the programming language being used.
According to the above case study, Explain how each team members (Project manager, Budget
Analyst, HR representative, and excecute sponsor) address the following questions: What are the
key issues surrounding this case? What is the nature of the problems that exist? Identify
opportunities that may be involved. In what ways were problems resolved or leveraged?
Recommend and justify additional courses of action that are most likely to be effective.