Recently, we saw the filing of a lawsuit between two of the best-known companies in the world, The Hertz Corporation and Accenture LLP, for the claimed failure of one to meet the expectations of the other when building and delivering a new IT system. Though widely reported in the media as a ‘new website’, the new IT system that had been commissioned was actually a new digital platform with e-commerce and other business processing functionality on which Hertz would operate all of its customer facing businesses and brands worldwide.
At face value the project was a timely response to the enhanced expectations of corporate and retail customers who are now using ‘omni-channel’ (eg mobile) digital solutions in many areas of their work and personal lives. It was also a sensible way to realise the huge efficiencies available from digitalisation. Though the dispute is a sad thing to happen for both parties, it can serve to remind us of the pitfalls of systems development projects generally, and outsource systems development projects in particular.
- Will AI replace the project manager?
- Do spreadsheets have a role in project management?
- 5 dangers that comprise project management
At face value the claims suggest that lessons from high-profile project failures that should have been learned by companies a long time ago just don’t seem to be getting learned. Even if the lawsuit is defended successfully, many organisations around the world will recognise the issues cited in the case. In 2012, McKinsey reported that “17% of IT projects go so bad that they can threaten the very existence of the company”. So what is going wrong?
Becoming a good buyer
Being a good buyer of outsource systems development services and working well with suppliers during projects are crucial skills for organisations. Yet, the absence of those skills explains more project failures in third-party projects than any other factor. Some may argue that suppliers should have all the skills required to make their projects a success, but any company relying completely on the skills of a supplier is making themselves a hostage to fortune. If you are not a ‘good buyer’ then you risk not spotting when the supplier and/or the project is failing.
A good buyer of third-party systems development will have excellent knowledge, understanding and experience in what should be done, when, why and how when defining, planning, directing, tracking, controlling and reporting systems development projects. It does not mean that they will be doing all of those things – in many projects the supplier should be running those processes as part of helping a client achieve their target business outcome (after all, the supplier is expected to have done a great many projects of this type) – but it does mean that the client should know themselves what needs to be done.
In most large IT projects, it is excellence in programme and project management that is the crucial factor in determining success – not knowledge of technology. Examples of the context in which this can be true includes when a project is being carried out across an enterprise (especially a global enterprise); across a group of companies in collaboration; or, on behalf of a central marketplace and its participants (such as a stock exchange).
In large business-critical projects neither the supplier nor the client should be doing any aspect of the project in isolation, as to do so will increase the risk of failure. This isn’t just a need for transparency, it is a need for active communication plus active confirmation and verification that messages have been received and understood (think military communication protocols).
In the High Court of Total Project Failure there are three defences that don’t work: (1) I was drunk, (2) I thought the client or supplier knew what they were doing, and (3) I thought the client or supplier was doing it, not me. If you are the client and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as they don’t happen very often in most companies), then you must hire a very experienced interim executive to act of your behalf, even if the supplier will still do the majority of project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.
Responsibility for the project – including responsibility for it failing – always rests ultimately with you, the client. Your highly experienced interim executive can assume delegated responsibility on your behalf but that means that he or she becomes you and therefore you can never blame that person for anything (eg in the way you might blame the supplier). The supplier will thank you for this clarity of thinking around responsibility and authority as there is nothing worse for a supplier than a client unable or unwilling to fulfil their responsibilities during an important engagement.
Hertz vs Accenture
That is one of the more surprising aspects of the Hertz v Accenture case – a client appearing to be passing responsibility for failure to their supplier. Taking a just few examples from the points from the case:
“Hertz eventually selected Accenture, relying on Accenture’s claimed world-class expertise in website and mobile application development.”
Caveat emptor my dear boy, caveat emptor. It is the responsibility of the client to validate the claims of any supplier.
“Hertz spent months planning the project… defined the goals and strategy for its digital business, and developed a roadmap..”
Not good practice if true (though statements in the Factual Allegations section of the lawsuit suggest that it was Accenture that actually did this work). Don’t hire a major professional services firm then plan the project for them. They will know a lot more about defining, planning and delivering this type of project than any client. Instead, work with them to identify and validate the problems that you want to solve for yourself and your customers with this project; assess options for solutions and report on possible candidates; test ideas and prototypes for those options; get customer feedback at every point; select a solution; and, actively change your ideas and designs for that solution based on customer feedback during the course of the project. If you end up delivering the idea you had on day one, then you did it wrong. All ideas should evolve.
“Hertz trusted Accenture to lead the project and deliver website and apps that met Hertz’s business requirements.”
Clients cannot delegate responsibility for project success, but they can delegate authority for leading a project. However, that delegated authority means the client retains responsibility for the project – and that means they must be able to validate that it is going the way they need it to go, every step of the way (not just at the end). If I seem to blame clients, then remember that a good supplier should spot any misunderstandings on the part of the client, point them out, and coach the client to be able to protect their own interest (which is also of benefit to the supplier).
“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.”
The educated reader will know that the third rule of systems development is that for every requirement there must be a valid test - a test that the client must sign-off on; results that should prove the case; and, results that the client can understand and agree (or not). If, using the agreed test, the client cannot determine at the earliest possible stage whether its requirement has been met or not, then another test should be derived. If no tests existed for this requirement, then both sides have to take responsibility: the client for not fulfilling its responsibility to validate everything being done on the project, and the supplier for not putting the client in a position where it could validate all requirements.
“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.”
There is an increasing trend for suppliers to be testing their own stuff. Even doing user-acceptance testing on behalf of the client - ie not involving users in their own testing and sign-off. This is crazy. Objectivity in testing is everything. Clients – and other sub-contractors and suppliers of the client – should be testing new software and systems, not the people doing the build. And those testers should enjoy breaking software, not feel under pressure to validate the work of their colleagues.
Failure to communicate
Unfortunately, none of the perceived or claimed failures in this case are new or unique. In the end, project failure is always down to failures of people, specifically failures of people to communicate. Those communication failures are rarely or never due to a base-measure such as low intelligence. Instead they are usually down to a lack of experience, knowledge and skills. Too many people involved in systems development project don’t know how to define and run systems development projects. It’s as simple as that. Commonly, they know how to do one task out of all the tasks required. Most importantly – they don’t know how to operate within such projects; they don’t know how it all fits together.
If a large number of people on a global project cannot talk coherently and correctly on the subject of defining, planning, directing, tracking, controlling and reporting third-party systems development projects, then you are at serious risk of failure. Even things like failing to code for security come from gaps in these areas of project and programme management (because project and programme management done well would not have allowed the coding failure to happen).
If you spot one theme in this sad story, then spot the fact that in all third-party project failures it is both the client and the supplier that have been deficient. Never deliberately, often carelessly, sometimes unknowingly, but always both. Also spot that every mistake could have been avoided with more knowledge and or better advice.
Cliff Moyce, Chairman of the Advisory Board at DataArt
- We've also highlighted the best project management software
