Let's Get Small

   
Doug Brockway is the founder and Managing Principal for Advance Consulting. He blogs on IT management topics at Working on Step 2.

After toiling in obscurity, learning the hard way about stand-up comedy and how to play the banjo, Steve Martin started catching on in the 1970s, hitting the big time with a comedy album titled “Let’s Get Small.”

The title and the bit by that name are nominally an absurd twist on the drug culture of the time and the phrase “Let’s get high.” As it turns out, there is a theory that Martin was actually prescribing how to manage a portfolio of IT projects. (Note: Researchers have debunked the theory that Martin was recommending that IT management parade around the office with arrows through their heads and wearing Groucho Marx glasses…)

Whether that actually was Martin’s intent, here’s good advice for businesses. Keep project sizes small. Make sure you can get benefits early in projects.

The longer each project is, the less likely that you can properly define all its goals, much less achieve them, much less ensure yourself and your colleagues that the effort was worth it. If you have a long-term goal, a roadmap, that’s fine. Get there in pieces with tangible benefits coming from each step.

The reason is that, no matter what we’re doing, from target sports to planning out a systems initiative, our aim is much better on short shots than it is on long ones. The longer the shot, or project duration, the harder it is to see, understand, explain and focus on the target. Even if you can do those, the longer the project duration, or shot, the harder it is to actually take aim at all, much less deliver what you intended.

With a little thinking, you can predict how far off your aim is likely to be and, using that information, have a sensible discussion about what should be the limits on individual project duration. To keep the example simple, let’s assume that whatever you think is the right thing to do today will, in one year’s time, be off by 20 percent. There are many reasons, among them: Technology will change, vendors will collapse, the economics of your business will change, skill sets will enhance, and new competitors will enter your market forcing new ways to compete.

If you had $3 million to spend and you embark on a large-scale, three-year project, due to compounding year-over-year change, your vision will be off by 20 percent after one year, 36 percent after two years, and nearly 50 percent after three. Few projects are managed that way, except for the “we have to replace the core systems” projects. The compound inaccuracy of vision and reality is one of the reasons so many of them result in runaway projects (I’m thinking of three that I’m familiar with right now).

If you took that same $3 million and spent it on a series of $1 million, one-year projects, the visions would miss the targets by 20 percent each year, but never more than that. Break it down again into six-month chunks and the maximum mis-alignment is 10 percent. Go “extreme” and require all projects to deliver value in three-month chunks and you’re never off by more than 5 percent:

In terms of protecting the bottom line, there is no question that making projects small is the best possible thing to do, to a point.

Just going from one-year projects to maximum six-month projects enhances the value for the dollar by 10 percent. This is big money, especially in tight money times.

This analysis must be tempered by the time, effort, and distraction you receive from repeatedly going back to the drawing board to set new goals. If you chunk up a long-term project, you frequently run the risk of losing funding from phase to phase as “higher priorities” arise or as the ROI on Step 3 is attacked as too weak to fund, even though it’s fundamental to Steps 3-6. Then there’s the ego/glory factor. Business and IT managers alike often prefer the big-budget projects with the big resume impact they carry.

This is where a plan or a roadmap comes in. Susan Cramm suggests you get the money but spend it right. What she’s on about here is something akin to the Apollo program. There was a goal set out: Get to the moon by 12/31/69. But the plan in 1961 only laid out the macro steps and the near-term efforts. On an effort like that, since it had never been done before, they couldn’t plan “beyond their headlights.” Most business projects are not that sophisticated. That said, the underlying business conditions and assumptions are constantly changing and so must project definitions.

Speaking of cramming… Do NOT use this as a license to request seven months of deliverables and their required effort in four months' time. This is an exercise in maintaining “alignment.” There are myriad ways people try to take time off a professional job. My personal favorite is “don’t do testing,” which is fine if you want to be highly productive at delivering systems that don’t work. The value of this approach lies only in keeping resources and time for tasks as they must be but re-adjusting your aim on a regular and timely basis.

If you set and execute a long-term vision, planned out up-front without downstream adjustment, you will miss the mark by a wide margin. Set long-term goals but limit your systems definitions, designs and efforts to short-as-possible projects with tangible benefits. At the end of each, take a short breath, reset your sights, and do it again. Get small. It’s the way to win.