When I was a child I learned a funny nonsense rhyme:
I eat my peas with honey.
I’ve done so all my life.
It makes the peas taste funny
But it keeps them on the knife.
The logic of the rhyme argues that:
- I eat peas with a knife.
- But when I try to eat peas with a knife, they fall off.
- So I should eat the peas with honey so they’ll stick to the knife and not fall off.
I coined the phrase “Honey Project” based on the rhyme; a Honey Project is one that makes a bad solution easier to tolerate. When faced with a Honey Project, you should seriously consider whether the project is worthwhile. After all, wouldn’t it make more sense to replace the bad solution with a better one instead of compounding the problem by dressing up the bad solution?
Here are some examples of Honey Projects:
An Attempted Central Customer Service System
A friend of mine told me about a customer service system that his company tried to put together. They wanted a single system that a customer service rep (CSR) could use to tap into the data of his company’s twenty or thirty different business divisions. The IT people working on the project made the incorrect assumption that a copy of the data had to reside in a central database (eating peas with a knife), so they spent tons of time and money trying to work out the systems and processes required to take daily copies of the data from all over the world. Ultimately the project collapsed due to the number of data translations required, the politics of moving data across multiple IT organizations, and the realization by the users that the data provided in the CSR system wouldn’t be real-time anyway.
In hindsight, the project team should have considered a layered approach, with a single CSR system providing a common interface that goes out to other existing customer service systems under the covers to retrieve data as it is needed. And they should have solved the problem in phases, adding a few business divisions at a time in order to build political support for the central solution. But the project failed because the project team jumped to a bad solution before fully understanding the problem.
Inappropriate Product Acquisitions
I did some work with a corporation that has a history of inappropriate acquisitions. Although it’s a technology corporation, the non-technology-savvy marketing executives have repeatedly discovered small companies with supposedly complementary products (eating peas with a knife). Then the corporation spends big bucks on “integrating” (Honey Projects) the small companies with the corporate products, in most cases spending more than it would have cost to develop an equivalent product internally, and in many cases abandoning the new products after the unsuccessful integration effort.
Doing the right technology due diligence should have prevented some of these small companies from ever being acquired. In this case the corporation asked the right questions during technology due diligence, but the corporate executives didn’t like the answers so they ignored the due diligence results and acquired the companies anyway. Ultimately the due diligence proved correct, and the Honey Projects failed to make up for the shortcomings found in the due diligence. It’s hard to dress up a bad investment.
Microsoft Virus Protection
Microsoft Windows has long been criticized for its susceptibility to computer viruses (eating peas with a knife). Microsoft’s answer to the problem is to introduce its own virus protection product, Microsoft Windows OneCare Live, rather than to fix the vulnerabilities in the Windows product. Thus OneCare Live will become the “honey” that helps to cover up the problem that Microsoft itself created.
Virus vulnerability is a difficult problem for Microsoft to solve. Historically Microsoft has had mediocre initial releases for each of its products, but it has invested large amounts of money on product improvements for later product versions. The computer virus susceptibility in Microsoft Windows dates back to the initial versions of Windows, is embedded deep in the architecture of the product itself, and will require huge amounts of effort to correct. It’s likely that Windows users will live with the Honey Project approach from Microsoft for some time to come, probably until a solid competitor to Windows is available.
The “Peas with Honey” rhyme is about an attempt to salvage a bad decision, and the lesson from the rhyme is to be very careful of your decisions before you start building on them. Too often we make this mistake in IT: we don’t fully understand what’s needed, we put a lot of effort into building an inappropriate or incomplete solution, and then we waste effort on Honey Projects to make the bad solution more palatable.
Take a long hard look at the projects you’ve got going on now. How many of them are Honey Projects? What can be done to solve the real problems and put your resources to better use? How can you change your processes to prevent this kind of problem in the future?
Honey Projects happen to all IT groups, but if you’re going to do a Honey Project, then make sure you’re going into it with your eyes wide open. Try to minimize wasted effort on Honey Projects by taking the time to make the right decisions in the first place. But if that doesn’t work, then try making the right decisions the second time around.