3 June 2019
What Hertz v Accenture Teaches us About Failure in Systems Development Projects By Cliff Moyce
In TechRadar, Cliff Moyce, Chairman of Advisory Board at DataArt, discusses the respective roles of buyers and providers of IT systems development services, commenting on Hertz's $32 million lawsuit against Accenture.
“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.”
“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).”
“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.”
“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.”
“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.”
View original article.