There’s a story circulating, which will no doubt get more coverage and about which we will no doubt get more detail: how Hertz is suing Accenture for failing to deliver a functioning site for which they paid a staggering amount of money.
The high points:
- Hertz hired Accenture in Aug-2016 for a launch in December 2017 (~15 month project)
- Accenture pushed the launch to Jan 2018, then April 2018
- Details are murky after that, but whatever was launched in April was said to be inadequate, buggy, and without responsive design requirements being met
- Hertz paid $32 million over that 19 month period, and they claim that Accenture wants additional fee to make things right
There are many, many details we are missing at this point, and there’s a good chance that a settlement will prevent us from having more details emerge. Still, there is enough detail to make some statements.
- how on earth did a project go for 19 months without anyone foreseeing a problem?
- How did big checks, totaling $32 million, get written during this process? What kind of schedule of milestones allows that kind of money to flow only to miss launch dates and be surprised at the result when the launch finally happens?
- what did the meetings, approvals, and check-ins sound like?
Now, agencies always bear a large chunk of responsibility for disastrous outcomes like the ones alleged. But, agencies are also paid to hide “how the sausage is made” and “keep clients happy” and not “keep them up at night.” Some of the bad communication – ie, the hiding of problems, the exaggerations of progress, the big presentations that make key stakeholders feel good – has to have been done by the agency team.
But what about the client? Surely, some people on the team had to sense that there were problems. Somebody’s spidey sense must have tingled that something was off. My guess, and it’s just a guess, is that most of the client team wanted to believe things were OK and wanted to rely on having throats to choke if their worst fears were realized. There’s a line from Hemingway that disasters happen “gradually, then suddenly.” This is common to software projects – people can convince themselves that everything is fine, that the house isn’t getting warmer, that there isn’t that much smoke, until the house is suddenly ablaze and you have a very different set of problems.
In my experience with projects that go awry (of which I have some, but at a lower rate than most! ;-)), is that people lapse into believing things are OK during the gradually phase for a couple reasons:
- they don’t want to be the negative voice in a room where everyone else has a vested interest in being positive – when a group wants to believe things are going well, when their bonuses and weekends, and professional relationships depend on things going well, nobody wants to hear “that person” saying “we have a problem.” Anyone who’s read Bad Blood, the account of Theranos’s 9 year journey of naivete, false optimism, and eventually fraud, saw a pattern of punishment of negative assessments – firing, high school style ostracization, or exclusion from meeting. Most of these people were raising fairly obvious issues – the prototype takes a long time, they’re not showing us the data they promised, things are happening off-site that we should be seeing – but the overall culture with partners and investors and backers was to reject that negative energy out of hand. In addition to being a great read, part of the book’s popularity must be because many of us have been that lone, scorned, voice in the room.
- managers insist on solutions not problems – this is a handy catchphrase of managers: “don’t bring me problems, bring me solutions.” For work tasks where an individual is solely responsible for their contribution, or the work is well understood by everyone on the team, it’s a fair demand to make. But with large, multi-disciplinary, multi-location teams – ie, software teams – that’s too high a bar to set. Spotting a problem that you don’t know how to solve shouldn’t prevent you from reporting it to the people who collectively can solve it. And fears of hearing about problems you might not be able to solve shouldn’t be baked into your job review as a manager.
- most firms don’t reward people catching problems early, they punish them – if you’re running a project on a 19 month project and you worry in month 5 that you’re on a bad path, there’s a high likelihood that the management response will be defensive, punitive, or dubious of your assessment. Senior management will likely poll other people – who have that vested interest in avoiding conflict – and they will say “we’re doing fine”, and make the problem-catcher the odd person out and probably the stupid one. Being willing to say “I think my project has a problem” should be rewarded as brave behavior that it protecting the interests of the company.
- scheduling was based more on calendar availability and visual designs than functional milestones – if you’ve ever worked on a software project schedule, you know that logistics of executives’ time and “having something to show at x or y meeting” gets as much time as proof of concept, systems integration checks, working features, and tracking project risks.
- team members may not have the requisite skills or knowledge to interrogate the project and see the problems – and they like it that way. To see a problem in a large software project 14, 9, or even 3 months out requires a knowledge of software building that can’t be absorbed in a single book or some HBR articles. To see, and eventually prove, that a problem exists requires some deeper knowledge of how software is made, what is easy and what is difficult, and an understanding of the tasks that are being done by a big multi-disciplinary team. You have to have more than your classic management skills to see the problem, and you need more than your classic skills to listen correctly to the people who have spotted it.
As I mentioned above, there are still way too many details that we don’t know to fully understand how this costly disaster happened. But we should conclude and learn that clients need to have a set of skills, and a culture, that can hear and interrogate problems during the “gradually” phase of a calamity. Agencies will have to learn to live with stronger, tougher, more curious and demanding clients. This is for the good of everyone, but especially companies that are trying to catch up