A recent lawsuit by Hertz Rental Car against Accenture has turned into a rallying cry by Agilest and No Estimates advocates. Of course, No Root Cause analysis has been performed by these advocates, but it makes good click bait for their followers.
Having done many Root Cause Analyses using the Apollo Method, let's look at the claims made in the lawsuit and see if any root causes, corrective, or preventive actions can be revealed from the court documents. This is an outside view that asks some simple questions:
- If there is an observed undesirable outcome, what might be the conditions or activities that are the root cause of this outcome?
- With the observed undesirable outcome, what corrective or preventive actions could have been taken to remove the possibility of the undesirable outcome?
This approach is guided by the processes for Root Cause Analysis on Software Intensive System of Systems project I've worked.
Root Cause Analysis is Risk Management, that asks the question what is the condition or activity that will create a risk to the success of our project? With this information, the management of the project installs corrective or preventive actions to remove or reduce as much as possible those conditions and activities. Without this approach, you only find out about the problems that will cause failure (for example Hertz and Accenture) after they have happened
Risk Management is How Adults Manage Projects - Tim Lister
As well here are some past work and resource on problems similar to this.
- Project Disappointment Starts When We Fail to recognize the 5 Immutable Principles of Project success
- Getting it Right
- Root Cause Analysis
- Bibliography of Root Cause Analysis works needed to increase the probability of project success
| Court Document | Assessment |
|
Hertz spent months planning the project. It assessed the current state of its e-commerce activities, defined goals, and strategy for its digital business, and developed a roadmap that would allow Hertz to realize its vision. |
|
|
Hertz did not have the internal expertise or resources to execute such a massive undertaking; it needed to partner with a world-class technology services firm. After considering proposals from several top-tier candidates, Hertz narrowed the field of vendors to Accenture and one other. |
|
| After Accenture put on an impressive, one-day presentation for the Hertz team that included a demonstration of the transformed Hertz experience, Hertz selected Accenture to design, build, test, and deploy Hertz's new website and mobile applications |
One day Presentations are usually not the criteria for spending double-digit millions on a software project. Funding the development of a working skeleton, some type of reference model or some other demonstration that the vendor can actually do what they say they can do is normal in our SW Intensive System of Systems world A mentor taught me a nice phrase when we were helping a large government nuclear and conventional power general agency acquire large document management and design system (about the same dollar size as this). After listening to the one-day presentation, he said I see your work here is fully buzz word compliant can you show us (our firm and the client) where you have performed similar work, what changes will be needed from that work, the cost and schedule impact of those changes. Yes, Dorthey the vendor must provide some sort of credible estimate of the work based on a model of that work - SysML is a really nice modeling language that can be used to producing cost and schedule estimates. SysML is a core requirement elicitation process used nearly everywhere we work, through tools that can produce not only the model of the system but also the basis of estimates for that system. There are lots of SysML Tools As well a Function Point Analysis can be used as well, derived from the SysML model. Google will find you all you need to know about this approach. |
| Because of Hertz's work with Accenture in the initial planning phases, Hertz trusted Accenture to lead the project and deliver website and apps that met Hertz's business requirements |
"Trust but Verify" - Henry Kissinger should always be the principle of managing any project. This axiom is the basis of all good project management. Where we work, all program management is based on Systems Engineering principles, where compliance with the needed Measures of Effectiveness and Measures of Performance of the needed business, technical, and operational Capabilities are assessed every month. A critical success factor for all projects is to ask and answer a simple question: How long are you willing to wait before you find out you are late? If both parties didn't have a status reporting process that was 0ne-half the distance between that time, they're going to lose control of the project. This is a foundational principle of program planning and controls just as it is a principle of closed-loop control systems. It's the Nyquist rate of sampling the system at a sufficiently small interval to maintain control of the system. |
| Hertz relied on Accenture’s claimed expertise in implementing such a digital transformation. Accenture served as the overall project manager. Accenture gathered Hertz’s requirements and then developed a design to implement those requirements. Accenture served as the product owner, and Accenture, not Hertz, decided whether the design met Hertz’s requirements. |
Back to trust but verify. Where was the evidence that Accenture:
Gathering Requirements is a very tricky business.
|
| Accenture committed to delivering an updated, redesigned, and re-engineered website and mobile apps that were ready to “go-live” by December 2017 |
What was the risk-adjusted date? That is what schedule margin protected that date? Without a credible schedule and cost margin, any date is suspect. To develop that schedule margin a risk model is needed. One with reducible (epistemic) uncertainties and their handling strategies placed in the Integrated Master Schedule. For the irreducible uncertainties (Aleatory) margin is needed. To develop that margin a model of the network of activities showing what work drives what other work, what the statistical distributions are for that work, what coupling between all the work is present, what the impacts are for each work activities on other work activities are present, and how all this comes together in an integrated risk management plan. This is standard practice in any mature project management process. Remember Risk Management is Project Management for Adults - Tim Lister These risk management processes are well documented, have mature tools, and standard processes. Applying them may have been the problem. |
| Accenture began working on the execution phase of the project in August 2016 and it continued to work until its services were terminated in May 2018. During that time, Hertz paid Accenture more than $32 million in fees and expenses. Accenture never delivered a functional website or mobile app. Because Accenture failed to properly manage and perform the services, the go-live date was postponed twice, first until January 2018, and then until April 2018. By that point, Hertz no longer had any confidence that Accenture was capable of completing the project, and Hertz terminated Accenture. |
What was the Physical Percent Complete on a monthly basis for this project? Better yet what was the Physical Percent Complete for the weekly progress to plan? When Accenture discovered they were falling behind schedule, did they take corrective and preventive actions to get back on schedule? Why was this a surprise? This is a fundamental principle of all project management - NO SURPRISES!!! You can be late, over budget, and have technical problems, but it can't be a surprise |
| In fact, Accenture’s work was seriously deficient in multiple respects | |
|
For instance, the contract documents required Accenture to develop a responsive website – one that automatically scales content and elements to match the screen size of the device on which the website is viewed – with breakpoints for small (phone), medium (tablet), and large (desktop) displays. Accenture ignored the specification that called for a medium-sized layout and developed the website for only small and large breakpoints and demanded hundreds of thousands of dollars in additional fees to deliver the promised medium-sized layout |
Where was the Hertz program manager? Why was Accenture allowed to proceed for a single day with noncompliant requirements? |
|
As another example, the Architecture Specifications for the Project expressly specified that a fundamental principle of the design of the website was its extensibility – that is, the use of a common core of libraries that could be extended across the websites and mobile apps for each of Hertz’s brands. Without Hertz’s knowledge or approval, Accenture deliberately disregarded the extensibility requirement and wrote the code so that it was specific to the Hertz brand in North America and could not be used for the Hertz global brand or for the Dollar and Thrifty brands. |
Extensibility requires measures of effectiveness and measures of performance be defined BEFORE any work starts. Then compliance with the MOE's and MOP's at every status review - one-month intervals at a minimum. If they're using Agile every 2 to 3 weeks. |
|
The quality of Accenture’s programming was deficient as well. Accenture’s developers wrote the code for the customer-facing e-commerce website (the “front-end development” or “FED” code) in a way that created serious security vulnerabilities and performance problems. The defects in the FED code were so pervasive that all of Accenture’s work on that component had to be scrapped. For other components of the system, substantial portions of the code were also unusable. |
Where were Hertz's Program Manager and System Acceptance and Quality Validation team? |
| In addition, Accenture failed to perform proper testing of the software that it developed. Accenture did not perform tests on many components of the system. When Accenture did perform tests, they were seriously inadequate, to the point of being misleading. |
Why? Where's the Unit Test, System Acceptance, System Integration, and System production test plans and the weekly validation and verification the deliverable software meets those specifications and continues to meet those specifications at every stage of the project through full production use? |
Summary
All projects are lost one day at a time
Without the following, the project was lost on day one
- A Capabilities based plan - what Capabilities are needed for success?
- How are these Capabilities inter-related?
- Where's the model of these interrelationships?
- What is data and process workflow is exchanged between each Capability?
- These are documented in some systems engineering tool in SysML
- What are the Measures of Effectiveness for each Capabilities to meet the business and technical goals
- What are the Measures of Performance for each Deliverable that implements a Capability
- What are the Technical Performance Measure for each of those deliverables
- Where's the Risk Management Plan?
- Reducible risks
- Irreducible risks
- Handling plans
- Risk Control plans
- Margins
- Alternative plans
- Measures of Physical Percent Complete
- It's not sufficient to simply say working software. This is naive at best
- Any measures of working requires a definition of Effectiveness and Performance
- Estimates of Cost, Schedule, and Technical Performance compliance
- These estimates adjust the cost and schedule margin
- They also adjust the needed technical performance
- Requirements Management
- RM is a Systems Engineering process
- Where were the Systems Engineers
- Where was the requirements management system? DOORs or something that
- Change Control
- Testing is more than code testing, its end to end Verification and Validation of every aspect of the delivered system
It sounds like both parties are at fault here. Accenture for not doing their job of being a good supplier and Hertz for not doing their job of being a good buyer
Any conjecture that any solution would have fixed this failed project, requires a credible root cause analysis of each of the items listed in the left column above.
Perhaps both sides should have read
- Integrating Program Management and Systems Engineering: Methods, Tools, and Organizational Systems for Improving Performance, Eric Rebentisch, John Wiley & Sons
- Engineering Complex Systems with Models and Objects, David Oliver, Timothy Kelliher, and James Keegan, McGraw Hill
- Value-Focused Thinking: A Path to Creative Decisionmaking, Ralph L. Keeney, Harvard University Press
- System Management: Planning, Enterprise Identity, and Deployment, Jeffrey O. Grady, CRC Press
- Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, KenJackson, and Stuart Arnold, Preinctivce Hall
- Systems Requirements Analysis, Jeffrey O. Grady, Academic Press
- Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John Wiley & Sons
- The Requirements Engineering Handbook, Ralph R. Young, Artech House
- The Art of Systems Architecting, 2nd Edition, Mark Maier and Eberhardt Rechtin, CRC Press
- An International Systems Engineering site with resources for Software Intensive System of Systems https://www.ppi-int.com/keydownloads/
- Some Tools for Use in Program/Project Management and Systems Engineering Integration
