Project failure Presentation IT Project Failure Case Study

  • Slides: 26
Download presentation
Project failure Presentation

Project failure Presentation

IT Project Failure Case Study Analysis Hershey's ERP/SCM/CRM Failure Fox. Meyer ERP/Automation Failure FBI

IT Project Failure Case Study Analysis Hershey's ERP/SCM/CRM Failure Fox. Meyer ERP/Automation Failure FBI Trilogy Failure NYC City. Time Payroll System Failure Air Force Extended Combat Support System Failure CVS Pharmacy Project (Return Goods) failure

Hershey’s ERP/SCM/CRM Situation Set out to implement the following systems in 1996 SAP’s R/3

Hershey’s ERP/SCM/CRM Situation Set out to implement the following systems in 1996 SAP’s R/3 Enterprise Resource Planning (ERP) Software Manugistics Supply Chain Management (SCM) Software Siebel’s Customer Relationship Management (CRM) Software A 48 month time frame was recommended Hershey demanded a 30 month turnaround. (Y 2 K Issues) Go-Live was planned for July of 1999 When Hershey would receive the bulk of its Halloween and Christmas orders.

Hershey’s ERP/SCM/CRM Mistakes Improper Testing Proper system testing methods were completely ignored in order

Hershey’s ERP/SCM/CRM Mistakes Improper Testing Proper system testing methods were completely ignored in order to complete the project on time. High Risk Roll-Out Hershey made the mistake of rolling out all three brand new systems simultaneously using a method known as the “big bang” approach Incredibly risking even if proper system testing had been completed. Hershey cutover to these brand new systems during their busiest part of the year. Staff was unprepared and were not fully trained. Lost Earnings

Hershey’s ERP/SCM/CRM Learning Points Too Much Change Hershey’s was incredibly aggressive with their attempt

Hershey’s ERP/SCM/CRM Learning Points Too Much Change Hershey’s was incredibly aggressive with their attempt to rollout three brand new systems Separate ERP, SCM, and CRM into three different projects. Tackle each system separately. Roll-Out Schedule Hershey failed at selecting a proper time to cutover to the new systems. Analyze the business model and select a cutover time that results in the least impact to business. Proper System Testing

Fox. Meyer ERP/Automation Situation Fox. Meyer Delta Project - 1993 Purchased the SAP R/3

Fox. Meyer ERP/Automation Situation Fox. Meyer Delta Project - 1993 Purchased the SAP R/3 ERP System Purchased Warehouse-Automation software from Pinnacle Andersen Consulting was brought in to integrate the systems Fox. Meyer’s Mainframe Their Unisys mainframe was becoming inadequate for the volume and the vendor was phasing out the system. Savings and Efficiency The Delta project was expected to save $40 M annually and help increase efficiency within the warehouses by automating certain processes.

Fox. Meyer ERP/Automation Mistakes Early Adopter/Inexperience The Delta project was an early adopter to

Fox. Meyer ERP/Automation Mistakes Early Adopter/Inexperience The Delta project was an early adopter to the SAP R/3 system which was accused of being an unfinished project. Andersen Consulting was also accused of using inexperienced consultants. The new R/3 hardware could only process 10, 000 orders per night where the legacy Fox. Meyer system could process 420, 000. Warehouse Morale Fox. Meyer warehouse workers were disgruntled as the new systems were threatening their jobs. These employees eventually damaged product which lead to a huge shrinkage in inventory. Personnel Issues

Fox. Meyer ERP/Automation Learning Points Responsibility Fox. Meyer should have contractually tied some of

Fox. Meyer ERP/Automation Learning Points Responsibility Fox. Meyer should have contractually tied some of this potential risk of the project results to SAP since the R/3 system was so new. Experience Request for experienced personnel and the use of rookie personnel should have been limited or eliminated. Fox. Meyer should have also done a better job with documenting an official knowledge transfer. Fox. Meyer was left dependent on the consultant when they should have been forming in-house knowledge base on the new system. Task Management Fox. Meyer should not have placed so much stake into this one project. Fox. Meyer should have focused on one task at time. (ERP or Automation)

FBI Virtual Case File Overview Virtual Case File project started in September of 2000

FBI Virtual Case File Overview Virtual Case File project started in September of 2000 Project goal was to update legacy IT systems Reduce IT costs and redundancy Distribute critical information between organization resources 3 year project launch deadline SAIC - 3 rd party software vendor 730, 000 lines of code $100 m project cost Scott Mueller (director of FBI)

FBI Virtual Case File Mistakes Inexperienced Leaders Scott Mueller - no project planning experience

FBI Virtual Case File Mistakes Inexperienced Leaders Scott Mueller - no project planning experience Trial and Error project planning Stakeholders abandoned project Over budget ($600 m) Over schedule (2005 completion) Communication SAIC fearful of project progress $100 m project cost (SAIC) SAIC

FBI Virtual Case File Learning Points Project Overruns Early Notification Trial and Error not

FBI Virtual Case File Learning Points Project Overruns Early Notification Trial and Error not applicable Budget Schedule Communication Stakeholders keep in the loop Project Blame Leadership

NYC City. Time Situation Began in 1998 There was a change of contract mid

NYC City. Time Situation Began in 1998 There was a change of contract mid project from -- to SAIC Streamline and automate the timekeeping of city employees Project was 7 years late and 10 X over budget Only ⅓ of New York City agencies integrated onto the system Top consultants charged with fraud; now serving jail time SAIC was ordered to pay $500 million in restitution

NYC City. Time Mistakes Poor contractor oversight Incompetent, Unprofessional project managers Continuous waste of

NYC City. Time Mistakes Poor contractor oversight Incompetent, Unprofessional project managers Continuous waste of project funds

NYC City. Time Learning Points Use experienced project managers Thorough selection process Engineers with

NYC City. Time Learning Points Use experienced project managers Thorough selection process Engineers with real world experience Integral to project success Contractors monitored Cut fraud, waste, and abuse

Air Force ECSS Situation Between 2005 and 2012 the Air Force attempted to upgrade

Air Force ECSS Situation Between 2005 and 2012 the Air Force attempted to upgrade their logistics system New ERP software using Oracle Cost was $1 billion

Air Force ECSS Mistakes Lack of leadership High leadership turnover Leadership did not communicate

Air Force ECSS Mistakes Lack of leadership High leadership turnover Leadership did not communicate No risk mitigation strategy to start Failed to get users on board with change New ways of performing daily tasks

Air Force ECSS Learning Points Detailed requirements analysis Establish and maintain project goals Requirements

Air Force ECSS Learning Points Detailed requirements analysis Establish and maintain project goals Requirements should be clear and complete User input required, get users involved in process ● Implement change control process ○ Change Control board ○ Don’t make unnecessary, unapproved changes

Return Goods Situation ● Project overview Reconciling pharmacy return goods is a daily, enterprise-wide

Return Goods Situation ● Project overview Reconciling pharmacy return goods is a daily, enterprise-wide function performed by the Rx Merchandising Returns team. Retail, Mail, and Specialty business segments all return pharmacy product to Genco for processing. The scope of this project is to design data integration & Semantic layer to feed Purchasing, Dispensing and Returns data from the respective sources into the Integrated Data Warehouse. Also, design a business intelligence layer to do analytics on Purchase, Dispensing and Returns data using Microstrategy ● The project started in July 2013 was originally scheduled for 6 months ● The project ended up taking one and a half year to be completed and cost 2. 5 times budget

Return Goods Mistakes ● Requirement/Design creep o o The requirement/design document was not reviewed

Return Goods Mistakes ● Requirement/Design creep o o The requirement/design document was not reviewed and signed off by business users. Major Requirement/Design changes made during & after test execution ● Poor resource management o o o The project was taken over by three different project managers. Transition gap between project managers Highly turnover in data modeling team

Return Goods Mistakes ● Team internal communication issues o Business users/designers/developers had communication gap

Return Goods Mistakes ● Team internal communication issues o Business users/designers/developers had communication gap of understanding requirements. o QA team did not get in-time support from the dev team. o The top management team was not informed during implementation phase ● No risk management implemented o Lots of risks become issues during the implementation stage. o No potential solutions were in place to resolve those issues and had to do analysis from the scratch which delayed timeline also increased budget

Return Goods Learning Points ● Every minute detail in the requirement to be captured

Return Goods Learning Points ● Every minute detail in the requirement to be captured in the BRD (business requirement document). If there is any point which is not specifically mentioned in BRD and is discussed during any meeting, make a note and request business analyst update BRD and get it signed off by the business users before implementation starts. This will avoid requirement creep ● High level Design document/mapping documents should get sign off by business users before build starts. This will avoid design creep ● Test scenarios need to be reviewed with business users and ensure each every functionality mentioned in the BRD is covered in the test scenario document before test execution starts. This will make sure test coverage meets business users’ expectations ● The dedicated project manager needs to be allocated on the project since project begins. Try to avoid highly turnover in each team

Return Goods Learning Points ● Team members from different teams in the same project

Return Goods Learning Points ● Team members from different teams in the same project need to be responsible and supportive. To make sure project is progressing smoothly, effective team interaction is very important to project success ● Proper risk management has to get implemented especially for complex projects. Design team/dev team need to raise potential issues in advance after doing thorough analysis based on the requirement. All the stakeholders on the project need to be aware of these potential issues ● Good communication is vital. Keep all the stakeholders informed on the project progress as well as critical issues ● Project lessons learned is also important and should be well documented so that future project leaders can make use of the learning experience of others in order to avoid the same mistakes

Project Management Best Practices Recommendations for future project teams Communication Project overruns communicated to

Project Management Best Practices Recommendations for future project teams Communication Project overruns communicated to stakeholders Proper employee training Stakeholder neglect Company Transparency Risk Planning Risks recognized Project implementation date

Project Management Best Practices cont. Planning Vendor Selection Project Team experience Budget Project Resources

Project Management Best Practices cont. Planning Vendor Selection Project Team experience Budget Project Resources Scope Well defined Project Goals Project Requirements

Project Management Best Practices cont. Quality QA Bug tracking Code Review Security Delivery Project

Project Management Best Practices cont. Quality QA Bug tracking Code Review Security Delivery Project timeline Execution

Project Management Best Practices cont. Leadership Qualified lead Trust Ownership Project Usability End user

Project Management Best Practices cont. Leadership Qualified lead Trust Ownership Project Usability End user