If you’ve worked on complex projects, you’ve probably heard the recommendation to start an effort by going after short-term wins…the so-called “low hanging fruit.”
Quick wins, the reasoning goes, allow a project team to deliver some early incremental benefits, establishing momentum and setting the stage for success with more complex changes down the road. On the surface, this approach sounds reasonable. In reality, it falls flat for two important reasons.
First, many people respond negatively to incremental change. I’ve seen managers bicker for weeks over things like small changes in the size of their offices, how they report expenses, and policies about company-sponsored subscriptions. When the stakes are low, some people cling to entrenched positions until forced to change. That makes it very difficult to implement small changes.
Second, starting small is often an invitation to push issues that really matter to the back burner. It’s always easy to find reasons for postponing large-scale change–the timing isn’t right, internal politics aren’t favorable, or too many other things are going on. Once you accept such rationales for delays, you can end up bogged down indefinitely on small-scale changes.
The inevitable result of pursuing incremental change is that external events will eventually force an organization to undertake the large-scale change that it put off. But, by then, the organization will have lost the luxury of time, good planning, and proper execution for the change program it really needs. Too often, the results are disastrous.
For example, years before the company’s bankruptcy, General Motors executives knew exactly what they needed to do to save the business. They failed to make the hard choices before the market forced them to, and investors paid the price.
If you have a choice, go big with the changes you know are essential. Don’t ignore the “low hanging fruit” entirely, but don’t make those changes the focus of your project.
I disagree with this piece. The piece makes gross generalizations about large and small change that have no basis in fact. The discussion of large vs. small change ignores the concept of cost-benefit. The example of General Motors has nothing to do with the size of the change required and everything to do with “(failing) to make the hard choices.” And the same people that respond negatively to incremental change most likely respond negatively to almost all change. Quick (or quicker) change doesn’t necessarily translate into “low-value”
I’ve worked on small software projects for several years after having worked on enterprise (translation: large projects) for several decades. In my personal experience, the success rate on the smaller projects is much higher than the large projects… Simply due to large projects taking too long, costing too much and, most importantly, business priorities changing over time.
Again, this isn’t about large vs. small change, it’s more about aligning IT investment to business priorities, clarifying cost-benefit, managing execution and communicate, communicate, communicate.
Thanks for listening.