Let's Get Small

(this post is expanded, in content and images from an article published at IT Business Edge)
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 1970’s 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. Researches 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…

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.

This 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%. 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 3 year project, due to compounding year-over-year change your vision will be off by 20% after one year, 36% after two years, and nearly 50% after 3. 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 dollar, 1 year projects the visions would miss the targets by 20% each year, but never more than that. Break it down again into 6 month chunks and the maximum mis-alignment is 10%. Go “extreme” and require all projects to deliver value in 3 month chunks and you’re never off by more than 5%:




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 6 month projects enhances the value for the dollar by 10%. 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 one frequently runs 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 7 months of deliverables and their required effort in 4 months time. This is an exercise in maintaining “alignment.” There are myriad ways people try and 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 is 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 down-stream 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.