Case study i did my best but still failed

CASE STUDY: I Did My Best but still failed. What Went Wrong?

This case study is a true experience. A manufacturing company with a small head office and branches
around the country had been using the same order-entry system software for about five years. The users
were generally comfortable with the system and a decision was therefore taken to up-grade it to the
latest software version from its service provider. For reasons of anonymity, the company will be
referred to as the "Client", while the service provider (i.e. the vendor) as the "SP".
However, the Client made the decision to upgrade without looking at any alternative. The project
proceeded routinely until the Client suddenly seemed to think that the upgraded product was hardly
different from the original, and that it had made a mistake. Perhaps this was because the scope was
more complicated and perhaps difficult to understand and define.

Background to Software and Upgrades
Typically, a company buys a computer system but after a period of time it becomes out of date and the
company is then faced with a dilemma. Should it get a newer version of its current system or buy a
completely different one? A different system means a new supplier, new functionality and training for
all the users. In addition, all the information has to be taken off the old system and put onto the new
one. This introduces risks such as making sure that all the information that has been captured over the
past few years gets accurately stored in the new system.
Superficially it would seem that the better option is to stay with the current system and vendor. The
company can then carry on using the old, tried and trusted software. Not so old, however, as it is now a
newer version with problems ironed out as well as additional features. It is generally easier to upgrade
because none of the challenges of the new and unknown are encountered and this means the company
can focus on its core business instead of worrying about a new computer system.
The above thought-process was followed in the case of this particular project.

Project Management Processes
A systematic project management methodology was used derived from the Project Management
Institute's Guide to the Project management Body of Knowledge ("PMBOK")[1]. These included
attention to:
• Integration management
• Scope management
• Time & cost management
• Quality management
• Contract management
• Communications management
• Risk management
These will briefly be discussed as follows.

C/O www.maxwideman.com 10 May 2004


Integration Management
A project plan was developed, communicated to key project stakeholders and approved.

Scope Management
The SP approached the Client before the project was even thought of, and recommended that an
upgrade be done to the software. The Client asked the SP to compile a business case and feasibility
study document. This took six weeks to produce and it looked at issues with the current system, how
they would be addressed by the "new" system and additional functionality that would be provided.
The SP showed the document to the Client and was invited to present the concept at the Client's annual
planning conference. The idea was enthusiastically received. A concept document was circulated and
approved by the Client. The project was then given the go-ahead in principle. The SP then visited a
number of key user sites to discuss the impact of the upgrade on their respective parts of the business.
Comments were noted and incorporated into the project definition document.
The SP then called a session for all the key user stakeholders at which all the deliverables were
explained. The project definition document was subsequently reviewed by a group of twelve users
during a two-day workshop and the end of which the document was signed off.

Time Management
A simple high-level project schedule was developed as shown in Figure 1. Appropriate resources were
allocated to tasks.

Figure 1: High-level schedule

Cost Management
There were different categories of billing rates and this was used to calculate the overall cost of the
project.

Contract Management
It was agreed that this would be a fixed-cost project. The Client had signed a five-year license
agreement with the SP one month before and there was no "exit clause". The signing of this agreement
indicated the Client's commitment to the SP and the software. The upgrade project ensured that the
Client had the latest version of the software. Every week each project team member completed a
timesheet and this data was captured into the project schedule using MS Project. In this way the project
manager was able to track the progress of each task and produce an overall progress report.



Quality Management
The deliverables were broken down into smaller "packages". A design specification was produced for
each one and work did not continue until the users signed off on it. Once this was done, the SP
produced a technical specification for internal use. These were approved by at least two independent
reviewers. After the programmer had written and tested a program, members of a testing team tested it
to ensure that the code was sound. The system was finally put through four complete system cycle
tests.

Communications Management
A weekly project management committee meeting was held from the start of the development phase of
the project. Permanent attendees from the user side included the User Project Manager and the User
Technical Consultant (see Figure 2 below). The SP Project Manager chaired the meeting and invited
members of the project team and other personnel where appropriate. The purpose of the meetings was
to cover the status of the project to ensure that everyone knew what had been done and what was being
planned. The meetings gave the opportunity to raise issues such as unavailability of a resource or
dissatisfaction with work that had been done.

Risk Management
"Risks" was an item on the agenda of all the weekly project meetings. A risk log was continually
updated, where the risks were identified in terms of something affecting the project's "Go Live" as per
the project plan. A matrix was used to rate risks in terms of probability of occurrence and impact on the
project. Someone was assigned responsibility for each risk. Its potential affect on the project's success
was discussed and a description of the status was updated weekly. Risks that became "issues" were put
onto an issues log.

Phase 1 – Project initiation
As shown in Figure 1, the project was divided into phases commencing with "project initiation". The
project was standard and the outcome seemed to be predictable. The Client had been using the system
for about four years and was satisfied with it both in terms of functionality as well as being able to
handle the volumes. The software had been originally developed in the early nineties and it was now
time for a major upgrade.
The first step was to give presentations to key Client decision makers to advise them what benefits
would result from the upgrade. The high-level scope was approved, the delivery date was established
and, as noted earlier, it was agreed that it would be a fixed-price project. The Project Organizational
structure is shown in Figure 2. This was standard in that there was a Project Steering Committee that
met on an ad hoc basis and a Project Management Committee that met weekly.



Figure 2: Project organizational structure
The User Technical Consultant was the only person allowed to sign off the specifications. This person
did not share these business specifications with any of the users, which kept the users "away from the
new system". The reason given was that this consultant had an excellent knowledge of both the system
as well as the business application. The users were all "extremely busy" and it was therefore more
effective to have one contact person. This made the project much easier to manage since the problem of
trying to get a group of busy people into a room to sign something off was avoided. The project then
moved into the development phase.

Phase 2 – Project Development Milestones
There were twelve milestones associated with various packages of development that were signed off
during the development phase. The purpose of this was to enable the Client to understand exactly what
was being done and to give his approval. It was sometimes aniterative process but an acceptable
solution (to both sides) was always achieved. In an email seven months into the project, the Client
Managing Director (MD) assured all parties that everything was on track. See Figure 3 for an extract
from the email that was sent just over two months before the end of the development phase (in May).

"We have made personnel available for testing whenever the SP has requested them,
and a number of these sessions has taken place already. We still need to provide the SP
with detailed specifications ... None of this has impacted on the project thus far, and we
will do whatever it takes to ensure that the SP is not prevented from meeting their
commitments. In closing, I must mention that I personally believe we have an excellent
working relationship with the SP project team."

Figure 3: Client MD Email
Thus far it seemed that everything was going well, with over 80% of the project completed. But then
the situation started to go change.



Part 2: Things Start To Go Wrong
Phase 3 – User Testing
The next major step in the project plan was for the users to start testing. Word came about in a very
indirect way that the Client was not happy with what was being done. The User Technical Consultant
apparently went about telling people that there was not much difference between the old system and the
upgraded one. This got to the Client MD who immediately contacted the SP to find out what was
happening. A workshop was called for the users, including the User Technical Consultant, and a
demonstration was given of the system. No specific concerns were raised but the SP decided to do a
formal project review, conducted by a senior SP director, in order to ascertain the state of the project.
This review included all the key stakeholders from the SP as well as the Client and it took place two
weeks before the user testing was due to start. Clients interviewed included the MD, the Client Project
Manager and the User Technical Consultant. The review showed that the PMBOK processes were
being followed. The Clients interviewed expressed the opinion that the project was proceeding on
track. Reference was made to the weekly progress meetings, which they felt were constructive. No
stumbling blocks were identified. The Client did not complain about the new system, which was
strange because the reason for the review was that the User Technical Consultant had told outside
parties that he was not happy with it. The Client suggested that a team building exercise be held.

Team Building Workshop
It was agreed to hold a team-building workshop with key members of the project team as well as senior
management on both the user side as well as the SP. The SP would use the opportunity to present its
findings of the project review. The invitation to the workshop gave the following objectives:
• To discuss all current issues relating to the upgrade project
• To allocate responsibility to resolve the issues
• To agree closure dates for issues
The Client decided to use a neutral party to facilitate the afternoon. This party was a team of
consultants that had been on the Client site for the previous two months. The brief of this team of
consultants was to look at all the Client's business processes, including the Client's computer systems
and make changes where appropriate.
There was no hint of the possibility that the system was unsuitable and that the Client might be getting
cold feet. The expectation was just to talk about current issues and on this basis it promised to be quite
a routine affair.

Workshop Outcome
The workshop proved to be far from a routine affair! All participants were asked what they thought
should be the objectives of the meeting. The following, an extract from the minutes, showed that there
was a very hidden agenda.
1. To find alignment between [the Client's] expectations and the SP's offering



2. To agree on a common way forward
3. To determine if the system is able to satisfy [the Client's] needs
4. To remove barriers and ensure open communication and mutual support going forward
5. To clarify issues perceived by all parties and agree how to resolve them
All the emails, meetings, workshops, demonstrations and even the project review had not managed to
uncover what the Client was thinking but had never actually expressed. The "hidden agenda" was that
the Client felt that its expectations were not being addressed (point 1). Doubt was expressed if the
system was able to satisfy the Client's needs (point 3). It was felt that there were barriers that were
preventing open communication (point 4). None of these issues had been expressed until then.
The Client project manager said that it was possible that the upgraded version of the software would
not suit their business needs. The facilitator then said that the project should be put on hold and a
"package evaluation and selection" project be done. The SP representatives objected and said that this
had never been within the scope of the project. Possibly the setting provided a forum for the Client to
express nagging doubts that it had in its mind. The following extract from the minutes shows the
actions documented.
1. The SP needs to perform an industry analysis and benchmark to determine if the System
compares with industry standards with regard to overall functionality and cost effective
performance
2. Industry standards should be assessed against the base functionality in the system. A gap
analysis should be performed and presented to the Steering Committee for a decision
3. [The Client] needs to make a strategic decision to continue with the implementation of the
project provided the product offers reasonable ability to deploy changes quickly and cost
effectively. This decision will be based on a functionality comparison between the current
system and the upgraded version of the System. The anticipated outcome is an appreciation by
[the Client] that the system does, in fact, offer more functionality/features than the current
system

Next Steps
The matter was referred to the steering committee, which recommended that the SP put together a
presentation giving the reasons for the upgrade. This was done and the Client decided not to proceed
with the project. The relationship between the Client and the SP remained cordial. Since there was no
"exit clause" the Client remained with the older version of the software for the duration of the contract.
It did, however, buy a competitor product and slowly moved its business onto it. But what did the
Client actually think of the project?

Client Perspective
Time was spent with the Client to find out what the thinking had been and where things had gone
wrong. The most obvious question was: "Why did you wait so long before saying you were not happy
with the upgrade".
The Client Project Manager used the analogy that he had been promised a car and that is what was
delivered. He said that the only difference was that he was expecting a Ferrari and instead he got a Fiat



UNO. He had been one of the signatories on the project definition but probably had not understood all
the detail. See Figure 4 for comments from the Client Project Manager and the User Technical
Consultant.

Client Project Manager: "... the project was delivered according to specification;
overall all went well"

User Technical Consultant: "I agree. The project deliverables are not in dispute, and we
have always had the assurance that we will get what we have paid for. The problem is
not with the delivery, it is with the potential cost and benefit of implementing the
upgrade.""

Figure 4: The Client's post-project perspective
They seem to be saying that the project was fine but the product was not. This may have been their
opinion but the fact is they stopped the project because they were not happy with what was to be
produced.



CASE QUESTIONS: Five (5) Questions Q1 to Q5
Please follow Directions. Your answer will not be checked if you are not following the answer
format.

Start Time: 10:30 am
End Time: 12:30 pm

Q1: Which 2 Knowledge Area(s) contributed to the failure of the project?
If your answer is Procurement and Risk, Send to : 09996290556
Answer Format → Q1 Area , Procurement
→ Q1 Area, Risk

Q2: How was each knowledge areas handled? Send to : 09996290556
Answer Format → Q2 Communication, <your answer>
→ Q2 Risk, <your answer>
→ Q2 Human Resource, <your answer>
→ Q2 Procurement, <your answer>
→ Q2 Scope, <your answer>
→ Q2 Time, <your answer>

Q3: Give suggestions to avoid Similar Situations. Send to : 09996290556
Answer Format → Q3 Suggestions, <your answer>

Q4: If you were given a chance to arrange the knowledge areas by order of priority (highest to least),
which would be the top priority? Send to : 09996290556
Given: Procurement, Human Resource, Risk, Cost, Scope, Time, Quality

Answer Format → Q4 Priority, <your answer>

Q5: If you will be given a chance to be a Project Manager, which among the Nine knowledge Areas
would be the deadliest of all if not given an attention? Send to : 09996290556

Answer Format → Q3 Deadliest, <your answer>


Case study i did my best but still failed

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Case study i did my best but still failed