What You Can Learn from Hertz Part II: How to Be Successful when Working with Consultants
In Part I of this blog series, What You Can Learn from Hertz Part I: Hire the Right Consultants for the Right Reasons, I discussed why good consultants do not and suck and when it makes sense to use them. Hertz hired Accenture for the right reasons – it’s right there in the lawsuit:
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.
Unfortunately it appears they did not deliver, which devolved into the lawsuit. If you want to read up on another famous epic consulting fail, look at Oracle and the State of Oregon.
An engagement needs to be structured and run to ensure fiascos are avoided. Contracts should make sense for both sides. At the same time, there are environmental, political, and budgetary aspects to why projects can get derailed and ultimately collapse. The customer/client has a lot to do with this, and they can be a big part – or even the sole reason – a project gets tanked. Competent consultants can’t compete with a customer getting in their own way. This blog post will cover what skin in the game the customer must have for successful consulting engagements.
Management must empower the team for success. Good upper management is transparent. Success, especially on large projects. usually happens because of top down support. Skunkworks projects also can succeed, but the risk – and sometimes the reward – is much higher. Both are valid approaches, and we’ve worked on many different kinds of projects over the years. When reaching out to a consulting firm, hopefully you’ll make it clear to them if you have management buy-in or not.
Make Resources Available
The consultant arrives at your office the first day of the engagement. Unfortunately, the key people he or she is supposed to work with are out at an offsite meeting for three days. Clearly that’s an issue. Now the company is going to pay for three days of paid time and the expenses of showing up with no real results. This is not the consultant’s fault. The start date should have been moved/rescheduled, but no one from the customer communicated this scheduling snafu to the consultant (or the company who sent them). Even when asked the week before if everything was fine, the company gave no indication it was not. Disconnects are expensive.
Good consultants are self sufficient, but we need information and feedback, too. This request time and input from key resources in your company to keep things moving. Projects – especially those with tight timelines – need to ensure that people are available for in person meetings or calls and answer e-mail (or IM) in a timely manner otherwise things grind to a hald.
Similarly, if a consultant needs access to systems, that process should happen sooner rather than later. That means once the ink is dry on the proverbial paperwork for the engagement, start whatever process it takes. Sometimes this takes a few days – or a few weeks – to set up if things like RSA tokens are involved. This eats time in an engagement and slows us down when we don’t have access to what we need to get the job done.
This is also a respect and common courtesy thing. We understand you have a day job and are not there to babysit us. Heck, I don’t want a babysitter! I know you have other stuff to do, but your company is also paying me to do a job and meet any scope and timeline that has been agreed upon. Respect a consultant’s time as they do yours.
Here’s a practical example: I’m writing a document as one of the deliverables on the project. In the contract, we agree on a review timeline once the document is submitted. The people who are reviewing the document need to be a) available to review when it is turned over b) able to deliver comments/revisions back to me on the agreed upon review cycle. Anything outside of that is most likely going to change the delivery date.
If you don’t have skin in the game to meet your deadlines, how can you expect us to meet them?
Establish Milestones and Timeline
Every project needs a plan, even if it is high level. A detailed one with dates and dependencies is much better for everyone. Whether the consultant/consultancy drives it or it is someone at the client, there needs to be someone making sure everything is on track. Customers are not fans of paying for project management since it seems like overhead, but good project management is fairly transparent and non-invasive. It also allows one person to be the point for any questions, and that person can get them to the right personnel (hired or in-house).
For Hertz, according to the lawsuit, they used Accenture for project management. Section 42 of the lawsuit calls out the failure of said project management. The example given is the removal of key resources from the project. Major changes like that should be communicated and the impact measured. We do not know why Accenture did that. This to me was an important phrase in the lawsuit:
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 ofcompleting the project, and Hertz terminated Accenture.
Forget the termination part – they missed the launch more than once. For a big public company like Hertz, this can be a public relations nightmare especially if you announce these things.
In the plan, key dates/events – milestones – must be set and agreed upon by both parties. If they need to be adjusted, again, everyone needs to agree to those changes. For fixed price engagements, milestones are absolutely necessary because for consultants, payments are usually tied to them. Even if payments are not tied to key dates, these should be big red flags. The nagging questions I have here are: why were tripwires were ignored and how did this not get nipped in the bud sooner?
I do not know why (or how) Hertz let $32M pass before they terminated things. There were two phases to the project, and the first obviously went well enough for Hertz to pony up for the second. Most customers I know would have cut the cord much sooner.
Ensure there is Testing, Acceptance Criteria, and Oversight
Besides milestones, most work should have a set of minimum documented criteria for success. You have carefully crafted scopes of work for a reason.
I do not know the details, but I am surprised by statements like the ones below in the lawsuit.
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.
Going rogue on a client is never acceptable. Sometimes there are honest-to-goodness technical challenges or limtations that crop up and may make something impossible to do. I’ve been there. Those are hard conversations, but you find a way around them. Deciding to go another way just because? Nope, nope, nope.
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.
I have a QA background so testing is in my blood. People should test their work. However, where was Hertz in this? Did they leave all the testing to Accenture and had no resources touching the work along way? Did Accenture just do smoke and mirrors when showing “working” versions – if they did that at all? Maybe I missed that in the lawsuit, but this goes back to skin in the game. I’m a consultant, but if you’re paying me to do something, you should check in if we’re not doing so already. Have weekly status meetings. To let it get that far down the garden path is something that should have never happened. Clearly it does (see: lawsuit), but in theory, this could have been stopped sooner. Maybe it couldn’t. I was not there so I can’t say everything that went down on either side.
Avoid Scope Creep
One of the worst things that can happen on a project is scope creep. Scope creep is at some point during the project, the requirements change for whatever reason. Sometimes that is for valid reasons (for example, deploying to Azure and something changes on the backend and code needs to be refactored). Other times people just want to add new functionality in. It is more the latter than the former that is the problem, but the end result is the same: projects slip because of scope creep. Moving the ball but not the end date is not generally a good thing. All changes to scope need to be formally agreed to by both sides. The reason you put these things in contracts is that everybody knows what success looks like at the end. You deal with the unforseen, but avoid the ones that will change end dates just because someone now wants a widget to be purple.
Stick to the Budget
Changing the budget while a project is in progress is always a tricky proposition. More money for the right reasons is good, taking away money is bad. There are two aspects of this: affecting the overall funding of the project including the consulting dollars, and then just affecting other aspects of the project but the consulting bucket is untouched. The former is concerning for obvious reasons. If we agreed to X in the contract, that is the expectation. There’s generally no re-negotiating especially if you want us to do the same amount of work. However, that is not what I am talking about; it’s the latter scenario.
Let me give you an example. Years ago, I was working on a data center migration project under a big consultancy firm. I was leading the SQL Server team. We were supposed to get our own dedicated storage unit for the SQL Server implementations, and all our plans were based on this promise. A few months into the project, after I had delivered our storage requirements and verified that what the SQL team was getting would be suitable, I was told that we were not getting said storage. We would be sharing one unit with the file server and Exchange folks. That was not good news. Doing the “simple” math, the client’s SQL capacity (forget performance for a second) was in theory cut by 2/3 in the shared storage plan.
How did I handle it? We had already rolled up our sleeves to fully understand the environment and we had enough storage for launch. Due to changes in the application, we could not measure growth until we flipped the switch. Once we did, we predicted when storage capacity would run out. I then presented the findings and let them know their options. At that point, I was set to roll off the project. I was never told how they resolved the issue.
In that example, it was purely a financial decision made much higher up the food chain that impacted everyone. I know the Exchange and file folks were not thrilled, either. I can only speak to how things played out from my point of view.
In the initial stages of trying to work with a consultancy and putting a contract in place, they may ask about your budget. Be honest and transparent because we are with you. We understand you may be pitting us against someone else to see who will be a better fit for a variety of reasons including financial. That said, reasonable consultants will put together a good scope of work that will get you what you need and come in on or under budget.
As mentioned in Part I, expertise does not grow on trees. It’s better to hire the right consultants first than land up with a costlier project because you hired a square peg for a round hole. Sometimes spending a touch more than you thought will save you much more money down the road. Budget matters, no question. Good consultants get this loud and clear – I know I always have.
Remember to work out travel things, too. If you want someone onsite, understand what that means. If you request on a Friday to have someone there on Monday, the costs involved are often much higher than planning a trip in advance. It’s up to everyone involved to control costs where possible since the consultant (or their company) is laying out the money ahead of time, but be smart about things. Having a consultant fly across the world in the back row of a plane and be dead tired to work is counterproductive.
We always hear the big consulting horror stories because they land up in the news in one way or another. The fact that way more consulting engagements are successful and do not land up splashed in the headlines is a good thing. It’s the bad ones that make many think consultants are evil, but the companies hiring us need to ensure they’re doing their part to ensure successful projects. When it all works, everyone is happy. Don’t let news articles like this scare you. Hire us! 🙂
If Accenture’s side of the lawsuit pops up, I’ll most likely do some sort of Part III since I’d be curious to see their side of the story.