Case study i did my best but still failed


Published on

Published in: Business, Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Case study i did my best but still failed

  1. 1. 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 branchesaround the country had been using the same order-entry system software for about five years. The userswere generally comfortable with the system and a decision was therefore taken to up-grade it to thelatest software version from its service provider. For reasons of anonymity, the company will bereferred 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 projectproceeded routinely until the Client suddenly seemed to think that the upgraded product was hardlydifferent from the original, and that it had made a mistake. Perhaps this was because the scope wasmore complicated and perhaps difficult to understand and define.Background to Software and UpgradesTypically, a company buys a computer system but after a period of time it becomes out of date and thecompany is then faced with a dilemma. Should it get a newer version of its current system or buy acompletely different one? A different system means a new supplier, new functionality and training forall the users. In addition, all the information has to be taken off the old system and put onto the newone. This introduces risks such as making sure that all the information that has been captured over thepast 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. Thecompany can then carry on using the old, tried and trusted software. Not so old, however, as it is now anewer version with problems ironed out as well as additional features. It is generally easier to upgradebecause none of the challenges of the new and unknown are encountered and this means the companycan 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 ProcessesA systematic project management methodology was used derived from the Project ManagementInstitutes Guide to the Project management Body of Knowledge ("PMBOK")[1]. These includedattention to: • Integration management • Scope management • Time & cost management • Quality management • Contract management • Communications management • Risk managementThese will briefly be discussed as follows. C/O 10 May 2004
  2. 2. CASE STUDY: I Did My Best but still failed. What Went Wrong?Integration ManagementA project plan was developed, communicated to key project stakeholders and approved.Scope ManagementThe SP approached the Client before the project was even thought of, and recommended that anupgrade be done to the software. The Client asked the SP to compile a business case and feasibilitystudy document. This took six weeks to produce and it looked at issues with the current system, howthey 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 Clients annualplanning conference. The idea was enthusiastically received. A concept document was circulated andapproved by the Client. The project was then given the go-ahead in principle. The SP then visited anumber 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 wereexplained. The project definition document was subsequently reviewed by a group of twelve usersduring a two-day workshop and the end of which the document was signed off.Time ManagementA simple high-level project schedule was developed as shown in Figure 1. Appropriate resources wereallocated to tasks.Figure 1: High-level scheduleCost ManagementThere were different categories of billing rates and this was used to calculate the overall cost of theproject.Contract ManagementIt was agreed that this would be a fixed-cost project. The Client had signed a five-year licenseagreement with the SP one month before and there was no "exit clause". The signing of this agreementindicated the Clients commitment to the SP and the software. The upgrade project ensured that theClient had the latest version of the software. Every week each project team member completed atimesheet and this data was captured into the project schedule using MS Project. In this way the projectmanager was able to track the progress of each task and produce an overall progress report. C/O 10 May 2004
  3. 3. CASE STUDY: I Did My Best but still failed. What Went Wrong?Quality ManagementThe deliverables were broken down into smaller "packages". A design specification was produced foreach one and work did not continue until the users signed off on it. Once this was done, the SPproduced a technical specification for internal use. These were approved by at least two independentreviewers. After the programmer had written and tested a program, members of a testing team tested itto ensure that the code was sound. The system was finally put through four complete system cycletests.Communications ManagementA weekly project management committee meeting was held from the start of the development phase ofthe project. Permanent attendees from the user side included the User Project Manager and the UserTechnical Consultant (see Figure 2 below). The SP Project Manager chaired the meeting and invitedmembers of the project team and other personnel where appropriate. The purpose of the meetings wasto cover the status of the project to ensure that everyone knew what had been done and what was beingplanned. The meetings gave the opportunity to raise issues such as unavailability of a resource ordissatisfaction 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 continuallyupdated, where the risks were identified in terms of something affecting the projects "Go Live" as perthe project plan. A matrix was used to rate risks in terms of probability of occurrence and impact on theproject. Someone was assigned responsibility for each risk. Its potential affect on the projects successwas discussed and a description of the status was updated weekly. Risks that became "issues" were putonto an issues log.Phase 1 – Project initiationAs shown in Figure 1, the project was divided into phases commencing with "project initiation". Theproject was standard and the outcome seemed to be predictable. The Client had been using the systemfor about four years and was satisfied with it both in terms of functionality as well as being able tohandle the volumes. The software had been originally developed in the early nineties and it was nowtime for a major upgrade.The first step was to give presentations to key Client decision makers to advise them what benefitswould result from the upgrade. The high-level scope was approved, the delivery date was establishedand, as noted earlier, it was agreed that it would be a fixed-price project. The Project Organizationalstructure is shown in Figure 2. This was standard in that there was a Project Steering Committee thatmet on an ad hoc basis and a Project Management Committee that met weekly. C/O 10 May 2004
  4. 4. CASE STUDY: I Did My Best but still failed. What Went Wrong?Figure 2: Project organizational structureThe User Technical Consultant was the only person allowed to sign off the specifications. This persondid not share these business specifications with any of the users, which kept the users "away from thenew system". The reason given was that this consultant had an excellent knowledge of both the systemas well as the business application. The users were all "extremely busy" and it was therefore moreeffective to have one contact person. This made the project much easier to manage since the problem oftrying to get a group of busy people into a room to sign something off was avoided. The project thenmoved into the development phase.Phase 2 – Project Development MilestonesThere were twelve milestones associated with various packages of development that were signed offduring the development phase. The purpose of this was to enable the Client to understand exactly whatwas being done and to give his approval. It was sometimes aniterative process but an acceptablesolution (to both sides) was always achieved. In an email seven months into the project, the ClientManaging Director (MD) assured all parties that everything was on track. See Figure 3 for an extractfrom 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 EmailThus far it seemed that everything was going well, with over 80% of the project completed. But thenthe situation started to go change. C/O 10 May 2004
  5. 5. CASE STUDY: I Did My Best but still failed. What Went Wrong?Part 2: Things Start To Go WrongPhase 3 – User TestingThe next major step in the project plan was for the users to start testing. Word came about in a veryindirect way that the Client was not happy with what was being done. The User Technical Consultantapparently went about telling people that there was not much difference between the old system and theupgraded one. This got to the Client MD who immediately contacted the SP to find out what washappening. A workshop was called for the users, including the User Technical Consultant, and ademonstration was given of the system. No specific concerns were raised but the SP decided to do aformal 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 twoweeks before the user testing was due to start. Clients interviewed included the MD, the Client ProjectManager and the User Technical Consultant. The review showed that the PMBOK processes werebeing followed. The Clients interviewed expressed the opinion that the project was proceeding ontrack. Reference was made to the weekly progress meetings, which they felt were constructive. Nostumbling blocks were identified. The Client did not complain about the new system, which wasstrange because the reason for the review was that the User Technical Consultant had told outsideparties that he was not happy with it. The Client suggested that a team building exercise be held.Team Building WorkshopIt was agreed to hold a team-building workshop with key members of the project team as well as seniormanagement on both the user side as well as the SP. The SP would use the opportunity to present itsfindings 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 issuesThe Client decided to use a neutral party to facilitate the afternoon. This party was a team ofconsultants that had been on the Client site for the previous two months. The brief of this team ofconsultants was to look at all the Clients business processes, including the Clients computer systemsand make changes where appropriate.There was no hint of the possibility that the system was unsuitable and that the Client might be gettingcold feet. The expectation was just to talk about current issues and on this basis it promised to be quitea routine affair.Workshop OutcomeThe workshop proved to be far from a routine affair! All participants were asked what they thoughtshould be the objectives of the meeting. The following, an extract from the minutes, showed that therewas a very hidden agenda. 1. To find alignment between [the Clients] expectations and the SPs offering C/O 10 May 2004
  6. 6. CASE STUDY: I Did My Best but still failed. What Went Wrong? 2. To agree on a common way forward 3. To determine if the system is able to satisfy [the Clients] 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 themAll the emails, meetings, workshops, demonstrations and even the project review had not managed touncover what the Client was thinking but had never actually expressed. The "hidden agenda" was thatthe Client felt that its expectations were not being addressed (point 1). Doubt was expressed if thesystem was able to satisfy the Clients needs (point 3). It was felt that there were barriers that werepreventing 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 wouldnot 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 thishad never been within the scope of the project. Possibly the setting provided a forum for the Client toexpress nagging doubts that it had in its mind. The following extract from the minutes shows theactions 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 systemNext StepsThe matter was referred to the steering committee, which recommended that the SP put together apresentation giving the reasons for the upgrade. This was done and the Client decided not to proceedwith 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 theClient actually think of the project?Client PerspectiveTime was spent with the Client to find out what the thinking had been and where things had gonewrong. The most obvious question was: "Why did you wait so long before saying you were not happywith the upgrade".The Client Project Manager used the analogy that he had been promised a car and that is what wasdelivered. He said that the only difference was that he was expecting a Ferrari and instead he got a Fiat C/O 10 May 2004
  7. 7. CASE STUDY: I Did My Best but still failed. What Went Wrong?UNO. He had been one of the signatories on the project definition but probably had not understood allthe detail. See Figure 4 for comments from the Client Project Manager and the User TechnicalConsultant. 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 Clients post-project perspectiveThey seem to be saying that the project was fine but the product was not. This may have been theiropinion but the fact is they stopped the project because they were not happy with what was to beproduced. C/O 10 May 2004
  8. 8. CASE STUDY: I Did My Best but still failed. What Went Wrong?CASE QUESTIONS: Five (5) Questions Q1 to Q5Please follow Directions. Your answer will not be checked if you are not following the answerformat.Start Time: 10:30 amEnd Time: 12:30 pmQ1: 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, RiskQ2: 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> C/O 10 May 2004