Tuesday, June 30

Nobody gets fired for buying IBM

I liked this article about how some corporate IT departments are reacting to the economic downturn. "We're using smaller, lighter and cheaper technologies..." says one CIO.

Being that my employer is a small, nimble, innovative software company, I especially liked this quote from CPS Energy CIO Christopher Barron:
"With software from smaller vendors, it can take 20% to 40% less time to implement, and if it works, it could save you between three and eight times as much. The catch, of course, is that it doesn't always work. But even failing seems to be cheaper than going with the big guys."
I've always heard the adage that 'Nobody gets fired for buying IBM', meaning that even if you spend a little more, you're playing it safe by going with a trusted, well-known name. But the only projects I've ever heard becoming a colossal failure involve solutions from big name vendors with multi-million dollar price tags. And the really cool success stories you hear involve someone accomplishing something great with minimal budget.

Don't get me wrong - I know that many large businesses are run on big name solutions from IBM, SAP, Oracle and the like, but I think we need to be clear that the adage is not an axiom. That is, it's not self-evident. In fact, to some, it might even be nonsensical. Why would it make sense to spend 4x the amount of money to decrease your risk of over-expenditure?

What do you think? Does the adage hold up in today's economy? Will it hold up when we recover? Is it simply a question of finding the right solution for the job, or should it be part of a CIO's objective to put cost out in front of the decision?

4 comments:

Anonymous said...

I used to say for quite a while, "Cheaper, faster, better, pick any two.", but that isn't always true anymore either.

The fact is, lean, targeted solutions coming from vendors without a huge management overhead, and with a highly targeted product will almost *always* outperform the behemoths. Especially if the the development team listens to the customers actively and implements the features people need quickly.

The larger a software company gets, the less agile, and the less likely needed features get implemented. Scalability and overall capacity planning is usually the only downfall of a small shop, that can be handled, and is being handled by a number of them. Testing scale costs money though. Quite a bit. This is easily the first place a smaller company will, and even *has* to skimp. There simply isn't budget for it, and you can't simply test one and know it will scale linearly, it never works out that way. HA/DR is also often ignored by the small guys and typically left up to the customer. The big guys offer it all as a turnkey package.

Tim Cronin said...

I agree whole-heartedly. In my personal experience, I have seen just as many problems created by the "big guys" as the "small guys". The same goes for services. AT&T, Comcast, Verizon have outages too, it's just that Joe's ISP will get much more affected by the same outage due to the nature of having fewer customers. The same can be said for products. The Cisco(s|es?) of the world can have bugs just as much as your small vendors.

To take it one step further, A lot of this converstation usually has something to do with configuration rather than bad design. At the end of these scenarios, something along the line of "this stupid thing broke and now my project is down the tubes". Not always the case. I am a big proponent of reading... as in the manual :o)

Matt Pollicove said...

Interesting thoughts, Matt. I think there's a middle ground and that's third parties. Look to smaller nimbler, consultant who are used to thinking and acting outside the large corporation methods.

Lots of small consultancies are filled with smart people who know how to work the big systems, but want the freedom to implement without all the obstructions you cite in your article.

Matt Flynn said...

Thanks for the comments - great points!

To Matt's point, if you don't have someone who can navigate the ins and outs of a given project, it often makes sense to get consultative help from a strategic partner who can ensure that you're buying the right parts for the right reasons - and that they'll fit together in a way that meets the goal.

I also had some direct comments supporting the alternative view. The big guys are much more price-competitive in this market and even give away point solutions free as part of larger deals. And that the strategic consulting can come directly from the vendor.

At an enterprise infrastructure level, it often makes sense to form strategic partnerships with platform vendors. On a point project, though, sometimes those partnerships lead to shoe-horned solutions if the strategic platform vendor's suite doesn't provide an optimal solution.

None of these decisions are easy - it's a game of spending resources wisely to improve the business in clear ways.