2British Broadcasting Corporation Project type : Digital archiveProject name : The Digital Media InitiativeDate : May Cost : £100MThe BBC’s archive of broadcast materials is unparalleled and as production continues to this day since 1922, the corporation has one of the largest archives of media materials in the world.In 2008, BBC initiated the “Digital Media Initiative” (DMI), which was intended to provide a single tool that would enable video and radio production from raw materials through to final edit.
3Lack of Clarity in Requirements No tender processWithout going through a formal tender process, the contract to develop DMI was awarded to the BBC’s existing technology provider (Siemens) in 2008.Fixed price contract source of being lack of clarity in requirementsThe fixed price contract established a plan that would see the project completed in 18 months at a cost £82M.In theory, a fixed priced contract protects the buyer from cost overruns.In practice, this is not always the case as lack of clarity in requirements, changing needs and other real world complications often leave the door open to continual changes that can impact delivery dates and costs.
4Aftermath“No-fault” termination of the contract in Jul 2009 – end of 18-month contractBecoming an in house projectNo accurate picture of the project’s true status being given to the BBC TrustResults:Failure to deliver a working systemProject being abandoned in May 2013£100M being written offReference:Why Projects Fail: British Broadcasting Corporation, Sept 2, 2013
6New Zealand Ministry of Education Project type : Payroll systemProject name : NovopayDate : Sep 2012 – May 2013 Cost : $30M NZDThe Novopay system was intended to be a tool that would streamline payments to the 110,000 teachers, administrators and staff throughout New Zealand’s educational system.2005 DecisionThe project had its origins in a 2005 decision.2010 Being Implemented, OriginallyFollowing a bid process, Australia’s Talent2 was selected to both implement the new system and then operate it on a service contract basis until 2020.Delay till Aug 2012The original project called for the system to be implemented in 2010, but following a number of delays the project only reached operationally status in Aug of 2012.
7Operational ProblemsSome school employees reported receiving incorrect payments while others were paid nothing at all.Dubbed the Novopay debacle, at one point affected staff had reported more than 18,000 payroll errors and the operational staff supporting the system appear to have been overwhelmed by the amount of manual intervention needed to correct those errors.
8Failure FactorsTracking and analysis of the errors identified after the launch, identified more than 500 distinct defects in the system.Of those 44 were deemed to be very serious.In Aug of 2012 when the system went live reports indicate that only 147 defects were known meaning that Quality Assurance testing had failed to identify several hundred problems in the system.Many of those problems were traced back to errors in the original project requirements and the design of the new system that allowed incorrect data to be entered into the system thereby leading to incorrect payroll payments and related problems.
9Aftermath Affecting daily life Result: Reference: Those problems continued to grow and the issues became headline news in New Zealand as affected employees struggled to maintain their personal finances in the face of the cash flow problems the systems failures were causing.Result:A Mar 2013 review performed by Deloitte raised serious questions about the stability of the system and outlined a 1-year remedial plan that needed to be followed to ensure the operational stability of the system and that the originally planned business benefits were realized.Reference:Why Project Fail: New Zealand Ministry of Education, May 28, 2013
11US Department of Defense – U.S. Air Force Project type : Integrated supply chain and logistics systemProject name : Expeditionary Combat Support System (ECSS)Date : Nov 2012, Cost :$1BIssues:The Air Force IT environment consisting of over 700 systemsMany being duplicative, stand-alone and ineffectiveA multitude of metrics with competing goalsNon-standardized reporting causing credibility issues and time- inefficienciesLimited visibility across the supply chain
12IT PlanUS Air Force decided to integrate their systems into a single Enterprise Resource Planning (ERP) system.Expeditionary Combat Support System (ECSS) was intended to streamline processes and bring billions of dollars in savings.Originally estimates indicated that the project would take 8 years to reach full deployment and would cost $3B.Work was to be started in 2004 and was to be completed by 2012.
13Problems By 2010, signs of major problems had surfaced. Between 2010 and early 2012, the project had been through no less than three project “resets”.No results even spending more time & moneyBy 2012, the Air Force had determined that the $1B spent to date had yielded negligible benefits and if they proceeded they would need $1.1B more to deploy just 25% of the original scope.Even with such a scaled back proposal, deployment would be pushed back to 2020 meaning that significant additional work and risk remained.Deciding to scrap itRecognizing that a partial solution negated the overall vision of an integrated system, the Air Force scrapped the Project in Nov 2012.
14Failure FactorsFailure to baseline existing practices and to establish effective measures for the desired outcomesFailure to establish an effective governance structureSelecting an Oracle based Commercial-Off-the-Shelf (COTS) based product that was a poor fit for the project requirementsLack of experience in large scale, complex integrated systems development and deploymentOrganizational silosFailure to effectively engage all affected stakeholdersLack of collaboration and a lack of understanding of “change management”
15Aftermath For the $1B spent, nothing could be saved. “$1 billion wasted on Air Force computer system,” NBC Nightly News, February 08, 2013Reference:Why Projects Fail: US Department of Defense – US Air Force
16US Census Bureau – Field Data Collection Automation (FDCA)
17US Census Bureau – Field Data Collection Automation (FDCA) Project type : Field Data CollectionProject name : Field Data Collection Automation (FDCA)Date : Apr 2008, Cost :$595MIssues:Due to concerns about escalating costs and questions about the accuracy of the data being collected, in 2001 the US Census Bureau decided to undertake a major modernization program in preparation for the 2010 census.
18IT DevelopmentHaving first attempted to do the project in-house, field testing in 2004 demonstrated that the project was more complex than anticipated.As a result the Bureau changed direction and engaged an external provider to complete the project.Taking a further year to get the Request for Proposal published time remaining before dress rehearsals in 2006 and 2008 was running short.
19Failure Factors Underestimation of complexity. The project’s problems continued even after engaging an outside supplier to complete the work.Lack of due diligence on behalf of the Bureau and failure to establish effective communications with the supplier resulted in a significant number of missing requirements.Failure to establish and stabilize requirements resulting in significant requirements volatility (at one point 400 plus change orders had been raised).Despite warnings from external auditors the problems were allowed to persist and ultimately time ran out.
20AftermathThe Bureau was left with no choice other than reverting back to using pen and paper.The failure of the project resulted in the Bureau having to request an addition $3B in funding to complete the work using the existing manual procedures.Reference:US Census – Field Data Collection Automation Case StudyWhy Project Fail: US Census Bureau – Field Data Collection Automation (FDCA) – Case Study
22eCouriereCourier are a same day 24/7 courier service based in London, UK.The company was formed in 2003 with the aim of providing a courier service that is focused on delivery transparency and automated customer interaction.Parcels are collected from any London address and taken to any final destination requested by the client.Although the company originally only delivered parcels to London addresses, they now deliver parcels to any global location requested by corporate clients.
23SystemAdvanced Information Based Allocation (AIBA), an intelligent dispatch and fleet management system is utilized to allocate a booking to the most appropriate vehicle (including bicycles, motorbikes and vans of varying sizes) and sends a message to the courier to alert them to the job through their handheld terminal.Couriers are rewarded and motivated with high pay for the service levels they provide, supported by the technology, thus rendering a courier service that is reliable, trustworthy and transparent.In addition to systems for employees, the customer has been provided with a real time tracking of their parcel on a map, utilizing GPS technology.eCourier.co.uk Demo
24eCourier’s Success Factors Building a well structured teamDefining success criteria clearly with stakeholdersUnderstanding market needsIt’s especially important for being a first-moverUnderstanding and managing technical issuesManaging the project through the proposed control cycleReference:Case Study of Successful Complex IT Projects - BCS
25What Makes Projects Succeed? How often do projects succeed?Reference:“What Makes Projects Succeed?” Synergy Professional Services,
26Common Success Factors Customer InvolvementAgreement on the goals of the projectFrequent progress checks and course correctionsA plan that shows overall path and responsibilitiesConstant and effective communication to everyoneControlled scopeManagement support
27Common Failure Causes Regarding Requirements Engineering Lack of formality in the scope definition process results in vagueness and different people having different understandings of what is in and what is out of scopeVague or open ended requirements (such as requirements that end with “etc”)Failure to address excessive scope volatility or uncontrolled scope creepFailure to fully understand the operational context in which the product being produced needs to function once the project is overRequirements are defined by an intermediary without directly consulting or involving those who will eventually use the product being produced
28Common Failure Causes Regarding Requirements Engineering (cont.) Individual requirements are never vetted against the project’s overall objectives to ensure each requirement supports the project’s objective and has a reasonable Return on Investment (ROI)The project requirements are written based on the assumption that everything will work as planned. Requirements to handle potential problems or more challenging situations that might occur are never consideredFailure to broker agreement between stakeholders with differing perspectives or requirements.Reference:Why Projects Fail: 101 Common Causes,
29Five Common Issues in Requirements Analysis Customers don't (really) know what they wantRequirements change during the course of the projectCustomers have unreasonable timelinesCommunication gaps exist between customers, engineers and project managersThe development team doesn't understand the politics of the customer's organizationReference:Five common errors in requirements analysis (and how to avoid them)
30Solving Issues about Customers Being Uncertain Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve.Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.
31Solving Issues about Changing Requirements Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.Set milestones for each development phase beyond which certain changes are not permissible -- for example, disallowing major changes once a module reaches 75 percent completion.Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan is updated accordingly.
32Solving Issues about Unreasonable Timelines Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection.Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favorable outcome for both parties.
33Solving Issues about Communication Gaps Take notes at every meeting and disseminate these throughout the project team.Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently.
34Solving Issues about Not Familiar with Politics in Customer’s Site Review your existing network and identify both the information you need and who is likely to have it.Cultivate allies, build relationships and think systematically about your social capital in the organization.Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience.Use initial points of access/leverage to move your agenda forward.