Big Projects, Done Small
OK, all together now: Small IT projects succeed; huge IT projects fail. We all know that tune. The latest voice to join the choir is that of Roger Sessions, CTO at ObjectWatch , who has patented a methodology for breaking big projects into small pieces. There's just one problem: In the real world, big projects are big winners.
It's true. And that's a real pain, because Sessions and everyone else in the "huge projects fail" chorus is absolutely correct. We've known that ever since Fred Brooks wrote The Mythical Man-Month in 1975. Since then, the data has piled up. Sessions quotes recent research that says sub-million-dollar IT projects have a better-than-75% success rate. Once the budget passes $10 million, the chance of success drops below 10%. Ouch.
The logical conclusion: We should break up all IT projects into sub-million-dollar pieces.
The political reality: Everybody wants multimillion-dollar behemoths.
The CEO wants them. They make for great bragging points on the golf course, and they provide cover for "restructurings" of all kinds. Line-of-business executives want them because they look great on rsums. Ambitious project managers want them because in corporate politics, dollars are how you keep score -- a dozen $200k projects that succeed aren't nearly as impressive as a single $20 million Goliath, no matter how it ends up.
That means huge projects get big political support. That, in turn, makes them harder to kill. A multiyear megaproject that has the CEO's backing and millions sunk into it already is much likelier to survive at budget-cutting time than a bunch of trim, effective, quick-hit projects that could be cutting costs or selling more products within months but just don't have so many zeros at the end of the price.
If that megaproject is ever finished, it will probably be years late and tens of millions of dollars over budget. And even that weighs in its favor: It just makes the project look that much more impressive.
No matter how much we sing the praises of small projects, all the incentives that matter push for ever-bigger projects. That's why we keep doing them.
We can't change the politics. So maybe we should just decide to do big IT projects -- but do them small.
Look, what have software gurus been telling us for decades? Small succeeds. But those gurus nearly always tell us to break big projects down into small projects. That's technically sound but politically naive. It's where all those easy-to-cancel small projects come from.
Instead, we can continue to talk about big projects -- but we should plan them by breaking them down into small pieces.
There's no need for the CEO to know the implementation details. That $50 million project will still take years. The fact that it will be built of independent sub-million-dollar projects -- er, modules -- that will start doing something useful much sooner is just a nice bonus.
In fact, let's keep that IT's little secret about huge projects.
Does this sound devious and political? Of course. Hey, everyone says IT should be run like the rest of the business, right?
So propose big and build small. It's politically attractive, technically effective -- and everyone comes out ahead.
Otherwise, we can talk all we want about how small projects succeed and huge projects fail. But we'll just be preaching to the choir.
Frank Hayes has been covering the intersection of business and IT for three decades. Contact him at firstname.lastname@example.org.
Read more about management and careers in Computerworld's Management and Careers Topic Center.