This is page 2 of:
Retail CIOs: It’s Time To Get Off Your Dead Horse
They say that the definition of insanity is doing the same thing over and over and expecting a different result. Why is it, then, that so many IT organizations continue to function the same way even though they produce “less than optimal results?” It’s almost as if IT is stuck in the movie Groundhog Day. We are reliving each day, trying somehow to get it right.
So what can a CIO do to break out of this vicious cycle? The first thing is to adopt the “Maverick CIO” mentality. Maverick CIOs think about problems differently than traditional CIOs. They don’t focus on the inherent challenges of their role. Rather, Maverick CIOs accept the reality of a situation and work to maximize their ability to excel in this environment.
Here are a few things that set a Maverick CIO apart from a traditional CIO:
- They build an organization that defines the business requirements for their partners and defend them vigorously. Maverick CIOs do not start with a blank sheet of paper and ask partners what they want. IT project leaders need to act like they are the CEO and offer solutions that they think will meet both business and functional needs. A Maverick CIO gets very good at selling ideas to the organization.
- Maverick CIOs implement an agile project methodology that assumes a large percentage of the requirements will change. They make sure the methodology accommodates refinements in requirements over a period of time as business partners actually see and feel the technology.
- They have a backbone. Maverick CIOs do not give their business partners bad options to choose from. Many traditional CIOs get caught in the “Well, technically it’s possible, but I wouldn’t recommend it” place. DO NOT DO IT. If it is a bad idea, a Maverick CIO doesn’t even present it as an option.
- Maverick CIOs think about delivering results more than they think about following process. They understand that a great process that delivers crappy solutions is NOT a great process. (If it was your salary being used to pay for the 18 people sitting in a worthless weekly status meeting, would it still happen?) A Maverick CIO does, however, work within industry rules and regulations as required (SARB-OX, COBIT, etc.).
- They are not optimistic, but instead realistic. Maverick CIOs quadruple the expected effort and double the budget estimates before giving them to the C-suite. They know there are always surprises in scope and timeframes, and they don’t count on a risk register to save the day. Maverick CIOs secretly long to be called a “sandbagger.”
- If given the goal of removing 10 percent of costs from the IT infrastructure, Maverick CIOs figure out how to remove 15 percent–by enabling functionality in existing applications (versus implementing new ones) and retiring systems that no longer deliver ROI (in spite of the political fall-out from the one VIP who still uses some part of the system).
- Maverick CIOs invest 20 percent of their resources into making IT better. They make it a priority to reduce the application portfolio, streamline support processes, implement better monitoring and train staff. And if, after a hard-fought struggle, that 20 percent is cut from the budget, Maverick CIOs quit and go to some place where they can be successful.
Maverick CIOs realize that traditional thinking produces traditional (read: poor) results and work hard not to get caught in the “that’s the way we’ve always done it” trap. By improving the way technology is delivered (both at a project level and through support), Maverick CIOs start to build a platform of success. Over time, this approach allows IT to be seen as a strategic asset to the organization, as an “enabler” of success.
What do you think? Love it or hate it, I’d love to gain some additional perspectives. Leave a comment, or E-mail me at Todd.Michaud@FranchiseIT.org.
-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.