Eons ago-like, in 2001-I worked for TechRepublic, which, briefly, was owned by Gartner. So for awhile, I interviewed a lot of Gartner analysts. One of their favorite maxims at the time was to "pick the low-hanging fruit."
Security? Pick the low-hanging fruit. Mobile devices? Low-hanging fruit. The Web? Low-hanging fruit. You get the idea.
After awhile, the very phrase would make me cringe. But, I have to say-all these years later, and it's the one piece of advice that still holds true for IT, CEOs and, one assumes, fruit harvesters.
What's the big deal about low-hanging fruit? As someone who's picked more than my fair share of fruit off real trees, I can tell you there are good reasons to start with low-hanging fruit:
- It's easy to get to (duh!), which means you can tell very quickly whether the apples are ready for harvesting.
- If you start at the top of the tree, you're likely to knock accidentally off the low-hanging fruit, losing some of your harvest.
- You'll need a ladder for the top fruit, so, again, the top fruit requires more investment and more experience.
(Of course, I should point out I was an amateur and about 4 feet tall at the time. Professional fruit pickers often start at the top, because the fruit ripens there first.)
But I think the point still stands, because when IT first tries a new approach or solution, it's an amateur as well. Your staff will be learning through trial and error, unless you hire consultants -- although sometimes, they're learning on the job, too. By definition, low-hanging fruit projects are quicker and easier than enterprise-wide initiatives. If it doesn't, then you haven't lost much. If it does, then you've cleared the way for harder projects by proving it's value. You've also gained experience, which in turn will help you succeed as you work your way up the ladder.
In fact, leaders who focus on delivering quick wins outperform their peers by as much as 60 percent, according to "The Quick Wins Paradox."
Picking the low-hanging fruit makes perfect sense for IT when you think it through, which makes me wonder why we keep forgetting it. I was reminded of the low-hanging fruit lesson recently during a recent interview with Judith Hurwitz, president of business consulting firm Hurwitz & Associates and co-author of the recently released second edition of "SOA for Dummies."
I asked Hurwitz what companies that succeed with SOA as a <em>business</em> initiative do differently than companies that approach it as an IT initiative. Thankfully, Hurwitz didn't use the tired low-hanging fruit expression, but that is essentially the approach she described:
"If they have been convinced that a service-oriented architecture is the way to go, they will begin by figuring out what business problems they can solve relatively quickly. They won't try to sort of boil the ocean, doing a massive project that is going to take three years to show any results. They will start with something relatively confined that they can then come back to the business and say, 'See what we were able to do? Isn't that helpful?' And the business will say, ;Wow, yeah, let's do more.'"
"Typically," she continued, "that is how emerging technologies become successful."
The problem with SOA-well, one problem with SOA-has been that IT was so focused on the "architecture" -- the big picture -- it forgot to start small. I'm not saying it was wrong to focus on the big picture. But, as Hurwitz's research shows, it's possible to both start small and build to your big picture vision.
Hurwitz isn't the only one preaching the low-hanging fruit sermon these days. A recent TechTarget article, "SOA Implementation: It's the Increments, Stupid," quotes a slew of analysts, all saying basically the same thing: Start with the low-hanging fruit.
It's good advice, not just during tough economic times, but any time -- and most especially when you're dealing with a pervasive paradigm shift such as SOA.