Retail CIOs: It’s Time To Get Off Your Dead Horse
Written by Todd L. MichaudFranchisee Columnist Todd Michaud has spent the last 16 years trying to fight IT issues, with the last six years focused on franchisee IT issues. He is currently responsible for IT at Focus Brands (Cinnabon, Carvel, Schlotzsky’s and Moe’s Southwestern Grill).
Are you dreaming of the day when your business partners provide detailed requirements before the project starts? Keep dreaming. Are you longing for a time when you get unanimous support from your franchise community for a decision? Get real. Do you anxiously await the day when the rest of the C-suite wakes up and realizes that the demand for IT greatly outstrips the supply and then bolsters your team and budget to “appropriate levels”? Not gonna happen.
It’s time for IT execs to stop trying to explain how the world works and start accepting how others think it works. I’m not saying that “If you can’t beat ’em, join ’em.” I’m saying it’s time to make your own way. The way of the Maverick CIO.
Rather than bemoaning the state of IT and how everyone else “just doesn’t get it,” CIOs everywhere should realize that that particular “horse” has been beaten to death. The gap continues to widen between how CIOs want to be seen and how they are, in fact, perceived. Now is the time to dismount and try a different approach.
Many different factors play into the current state of affairs. Here are a few of the big ones:
- As much as 70 percent of IT spending goes to supporting systems that do not work the way the users “expected” them to work in the first place.
- In trying to protect themselves from supply and demand issues and a lack of clear requirements, most IT departments have made it easier to submit a requisition for an aircraft carrier with the Pentagon than to start a new IT project. IT governance is not an answer; it is an excuse.
- By cycling through new IT leaders every three years (because of the incumbent’s lack of progress), companies doom themselves to both repeat mistakes of the past and suffer from the “not invented here” virus.
- Because most companies cannot afford to “do it right,” IT teams are left to try and string together a series of inadequate systems like a Rube-Goldberg machine straight out of a Tom and Jerry blueprint.
- To the business partners reading this column: The majority of high-value IT systems are “hard” and “expensive.” If they were easy and cheap, they wouldn’t be high value. Let me give you a hint: The answer to the question “Well, can’t you just…?” is never going to be the answer you want to hear, so stop asking. Next time you want to ask, think about the Tom and Jerry blueprint.
Whenever a group of CIOs get together, these are among the topics that typically come up. They pepper online discussion groups and come up in moderated panels at conferences and on e-mail distribution lists.
But before you start to think that I am a complete whack-job, I do believe that IT Steering Committees, Software Development Lifecycles (SDLCs), Requirements Definition and the like absolutely have important roles to play in an organization. I just think that most IT leaders try to use these things to compensate for a broken mindset and “victim” thinking. Nor am I advocating a completely unstructured environment, one devoid of any process or compensating controls. These things are also an extremely important part of the process.
-Marc
April 1st, 2010 at 4:12 pm
I think the spirit of this is generally good but I do think a few aspects are either overstated or impractical, while a few are dead-on. As you asked for feedback:
I think the most critical thing half-right, half-wrong here is re the CIO determining requirements on his/his department’s own (more or less, so to speak, etc.) and getting good at “selling” ideas, I’ve seen this fail a lot more than succeed. The simple reason is that senior business partners are often not comfortable with an idea from the CIO, if solely from the CIO, and/or the CIOs who are good at selling are not the CIOs good at understanding the rest of the business. Plus of course it really is rather unusual to see a CIO with THAT deep a grasp of the business to be successful unilaterally, nor am I sure the CIO should be that very deep – after all, managing the marriage of systems to business is its own demanding full-time skilset (but that said, yes, I DO agree the CIO should know the business well enough to be able to lead some business directions). There are exceptions, but I believe those are far and few between. That said, I don’t disagree that IT/the CIO should lead as much as possible here, and there are ways to do it. In particular, in my opinion, the path of success here is primarily via ensuring that the CIO actually does listen and does get a staff trained to be REAL business analysts, and MOREOVER the CIO should more often than not (but NOT always) ensure that another CxO or Director-level party in the business gets the credit for the innovation/project proposed. This creates a firmer partnership and most often the CIO/IT does not need the credit solely; it also assures that another sponsor is willing to follow IT’s lead to the point of putting his/her own office and reputation on the line. Otherwise too often jealous business leaders will sink the CIO’s project (even at the expense of the business, in more political environments) or will simply “leave it up to IT,” which hinders change management and sends the wrong message that “this is an IT project.”
Re the agile methodology, agreed, but remember many areas simply are not candidates for this kind of development. So also paying modifying traditional waterfall methods, getting staff invested in the RESULTS as much as (or really more than) the process is critical. Bonus employees based on BUSINESS results – including timetables – and of course ensure the business is equally committed, and there will be better results.
I agree with not presenting a bad option except there is the circumstance that most often the business is *demanding* a response to a bad option they are already aware of. This does come back to the CIO’s salesmanship and business credibility (and credibility viz-a-viz the manifestation of business process via systems) to deflect those bad options.
I hope you were exaggerating for sake of effect re “quadruple the expected effort and double the budget estimates,” as I’ve seen every CIO taking that approached fired for it before too long. Of course, I agree with the notion – but again we do have finance overseers in larger organizations who are an intimate part of the budget process and the typical CIO simply cannot get away with padding contingencies, in my experience. Here we come back to the CIO’s ability to explain those numbers in a context. From my experience though I am far more pessimistic about this one than any of your other statements. CFOs have learned over the past couple decades how to ensure they have a granular accounting of each line item, and contingencies – while well tolerated in any GOOD organization – are still rigidly challenged and scaled back to the minimum. And I do think this is actually good – it forces the business to make real choices as risks manifest, plus it ensures that not too much business flexibility is tied down with parochial IT desires for flexibility.
I definitely agree re that notion of 20% into making IT better. I have heard another way to do that, especially in organizations that will not allow it or allow something far more minimal, is to embed that 20% into project contingencies and using those moneys for related (sometimes vaguely so, admittedly) purposes that make IT more efficient or bolster sustainability, etc..
April 5th, 2010 at 9:14 am
The choice of methodology, waterfall vs agile, should be predicated on costs/benefits, the costs of agile being mostly expressed in terms of risks. A user-centric internal groupware app lends itself well to agile. A back-end system or financial algorithm where a bug would cost the organization downtime and/or loss of revenue, is better served with waterfall, however slow and inflexible. Would you want to sit on a plane whose avionics have been developed in Agile? Didn’t think so. While I am a huge proponent of agile generally, the old adage of “the right tool for the right job” does apply to methodologies. Both methodologies have a place in the organization, depending on the expected outcome and the nature and magnitude of risks.
April 5th, 2010 at 12:42 pm
Great comments.
Fabien, that is a great point. I guess in my mind I was primarily thinking about “business driven innovation” projects rather than foundational business processes. But you are right, depending on the right project, the type of development methodology would change.
Wilson,
I actually wasn’t kidding about the over-estimating work/$ amounts. However, I think that the difference is I am not talking about the guys who intentionally sand-bag well, I am talking about the guys who are always too optimistic about what it is really going to take to get a project done. (They never assume any problems will surface or that things will change). It shouldn’t be done to make yourself look good, it should be done when you find yourself typically falling short.
The problem is that most IT shops find themselves being told that they need to work like Enterprise IT shops, when they aren’t one. That is a recipe for disaster. If you are not in an Enterprise IT shop, you need to change your approach to be successful.