It’s the third time around that is difficult.
What I mean is that, as an IT pro with over 20 years’ experience helping to design, implement, and improve a very specific type of software solution, I’m usually brought in to deal with the third iteration, because that’s when opinions and passionate ideals get challenged. When money and even reputations are on the line. Why the third?
How hard is it to pick the first solution? It’s usually not even a choice the company is aware of.* It’s often cobbled together from freeware, custom-code, tribal knowledge, and bits of this-and-that.
The SECOND solution, on the other hand, is often a very conscious decision. By this point, the organization has realized that it’s not only nice to have, it’s necessary, and even business-critical. So, at the point when a company is ready to pick their second solution, there’s a lot riding on that choice. There’s a palpable sense of excitement and possibility. Out with the old, in with the new! The future lies ahead!
What’s more, a lot of management attention is focused on this second run at a solution. There’s an actual (and often not-inconsequential) budget allotted. In larger organizations, careers may be staked on the outcome of the initiative.
But it gets done. After what is usually a lengthy bidding process, a front-runner is selected, teams are gathered (or contracted, or hired), and the implementation gets under way. And then it’s installed and running in production. The solution settles into the fabric of the enterprise. “That’s the way we’ve always done it”.
The third solution. Now, there’s the monster. Why? A lot of folks will chalk it up to “can’t call their baby ugly” syndrome. Management put their reputation on the line, and now they don’t want to say they made a mistake. But that reduced everyone involved to immature and short-sighted fools, which isn’t usually true. There’s an element of it, but it’s not really the whole story.
More often than not, the third solution is hard to get done because of the “dollar auction” effect, sometimes referred to as the “sunk cost” fallacy.
To understand this particular mindset, I’ll frame it as a game. This is a simple bidding game where I’m auctioning off a dollar (hence the reason I call this the dollar auction effect). The rules are that the highest bid will win the dollar, BUT the second-highest bid will ALSO have to pay, getting nothing in return.
The bidding begins and person A (we’ll call him John) bids a nickel. Person B (Mary), eager to win that dollar, bids ten cents. John counters with 15 cents. And so this goes, all way to 95 cents (bid by John). Now Mary has a choice to make. If they counter, they are effectively bidding a dollar in order to win a dollar. But if they don’t bid, they will lose their 90 cents and have nothing to show for it. So they bid a dollar to hopefully break even.
Then John makes the extraordinary (at least if you haven’t been in this position before) move of bidding $1.05. Why? Because if they win, they will only have lost 5 cents, not 95 cents. Mary quickly catches on, and bids $1.10 in order to cut their losses to a dime. And so the bidding continues, more or less forever.
The game of “Dollar Auction” describes the difficulty people feel when walking away from something in which they’ve invested time, money, or effort with “nothing” to show for it. It crops up in many different areas of life, from relationships to purchasing a home, and it has a strong presence in IT.
Once identified, however, what are some options for a data center (DC) manager to help overcome this psychological roadblock? I have a few suggestions based on my experiences.
First and foremost, emphasize that the previous solution was not “all for nothing.” Even if you are scrapping the system entirely (software, hardware, etc.) there is a wealth of benefits that carry over:
- You (and the implementation team) have a significantly better understanding of the environment, needs of the business, processes, and workflows than you did when you went from solution #1 to #2.
- That includes a definitive list of reports, alerts, and outputs that you currently enjoy and need to be replicated. But in copying those outputs, the benefit is that the organization already knows what it wants. You aren’t inventing something out of whole cloth.
- Meanwhile, you also have a clear knowledge of what does NOT work, what the organization does NOT need.
- And of course, you’ve also got a good start on what the current solution has, but that the company needs to improve upon.
- There’s also a vast amount of pure organizational knowledge, including which departments and teams were eager for the solution, which were resistant, which implementation areas were easy, and which were challenging.
For those who express unhappiness because of a perceived “loss,” it’s important to reinforce all the benefits the previous solution continues to represent.
Next, be clear about the value the current solution represents to the business in terms of immediate needs i.e., it’s not working out. If it was working, you wouldn’t be looking at replacing it. The reason for it not working out varies from solution to solution and company to company, but you, as the DC manager, need to have those reasons handy and be able to list them in a factual and dispassionate way.
Although I’ve also had some success by bluntly pointing out that “a broken-down Lamborghini isn’t going to get you where you want to go,” a more business-friendly way to reply to, “How can we afford to walk away from everything we’ve invested?” is “We can’t afford to keep pouring resources into it and not getting the functionality we need.”
Building on that line of thinking, emphasize the benefit the new data center solution represents to the organization. As always, these benefits should be framed in business, rather than technical terms: How does the new solution increase revenue, reduce cost, or remove risk?
If, after all your efforts, the powers-that-be insist on holding on to the old solution, then you have one last gambit.
Wait for management to move on, for the changing of the guard, and then call their baby ugly.
*Unless “the solution” we’re talking about is email. In any company, there are multiple software solutions, but two religions: one is the main software the company uses to make money, the other is email.