Fruitful business change

Low-hanging fruit live somewhere between proofs of concept and important results in the business change hierarchy.

Your average proof of concept, far from proving the concept, does nothing more than prove a concept — a more simplistic one, applied to a problem much smaller in scale and complexity. Proofs of concept are usually little more than rigged tests.

Low-hanging fruit, unlike proofs of concept and like important results, provide real business benefit. They’re usually peared up with large-scale change efforts, and even if the big change never happens, you get to keep the business benefits they provide, kumquat may*.

They are, in a word, peachy.

Currant thinking is that the primary value of low-hanging fruit … quick wins … is to create momentum or get the company out of a jam. Achieving a small but real change helps everyone see that this time the change methodology works and change is going to happen, unlike all of those other, previous change efforts that died on the vine.

But success at small change says nothing about how well the same techniques will fare when applied to a big change, any more than aspirin’s success at alleviating a headache proves it can cure malaria.

When the subject is large-scale strategic change, employees are justifiably skeptical, usually considering the next big thing to be nothing more than this year’s passing fad. They’re probably watched more than one high-profile strategic change fail, with none brought to (ahem) fruition.

If you are preparing to lead a large scale business change, here’s something to consider before you spend too much time raisin everyone’s expectations: Maybe low-hanging fruit are the only fruit worth picking.

Software enhancements are IT’s low-hanging fruit. If there’s one certainty in IT, it’s that enhancements succeed. Large projects are where the risk lies.

That’s where Agile, Scrum, Conference Room Pilots and their iterative, incremental, adaptive relatives come into play. Boiled down to their cores, they turn large development efforts into a swarm of small enhancements. They are managed and coordinated for architectural consistency and focus on a common plan, but the coordination and focus are loose enough that the enhancement-like nature of the work is the dominant style.

So I was thinking: Since there’s no such thing as an IT project — it’s always about changing the business, or what’s the point? — maybe we should apply the same thinking to business change that Agile and its relatives bring to software development.

We need a methodology that turns large-scale strategic change into a basketful of low-hanging fruit.

What might such a methodology look like? The question is better than my answer, as you’re about to find out.

One place to start is the 3-1-3-4 formulation I introduced in “Secretive solutions,” Keep the Joint Running, 9/3/2007.

3-1-3-4, you’ll recall, stands for 3-year vision, 1-year strategy, 3-month goals, 4-week plans. The 3-year vision and 1-year strategy provide consistency and focus. The 3-month goals and 4-week plan create the collection of quick wins.

It comes down to finishing one business enhancement effort and then asking, “What can we do next?”

For what we might as well start calling the “Agile Business Change” methodology (ABC — catchy, huh?) the 3-1-3-4 approach needs some enhancement:

The 3-year vision is still a shared vision, and there’s just one.

That isn’t true of the 1-year strategy. For ABC, each member of the executive committee must have one of these, and they have to make sense together.

Now come the 3-month plans. These fan out further, to middle management. Having so many 3-month plans is what will make the enterprise agile.

It’s also where chaos can ensue, because with so many concurrent change plans going on, the need for collaboration can easily lose out to the stiff competition for shared resources.

Like the IT department.

IT, in fact, has a role to play in preventing chaos, because most business change requires new information technology or changes to what’s already in production. If different requests are in logical conflict, IT is in an excellent position to spot the problem and coordinate a resolution.

The other mechanism for preventing chaos must be a corporate culture that encourages managers to ask themselves, about their plans: Who else will be affected by this?

And, after figuring out the answer, collaborating to make sure everything will come together in the end.

As I said, I don’t have a perfect answer to the challenge, just some glimmerings.

If someone reading this column has a better way of going about this and would be kind enough to share, I’d be grapeful.

---

*Borrowed from this verse, remembered from an old Mad magazine: You’re the apple of my eye/The plum of the day/And I’ll always love you/Kumquat may.