Apply today for a FREE subscription to CIO Magazine!
Mon, Jul 21, 2008 10:54 EDT
|
Posted by: Laurie M. Orlov in Best Practices Topic: Enterprise ManagementBlog: Reinventing IT
Current Rating: |
Consider this. Big projects (a year or more) are unhealthy for CIOs. By the time they’re done and the business execs see the result, these snoozing sponsors discover it wasn’t what they wanted.
Example 1: A CIO of a large insurance concern is 3 years into a re-architecting of the firm’s application portfolio – at which point, frustrated with the pace and progress, the CEO fires him.
Example 2: A mid-market company completes a lengthy project in which a substantial sum is spent subscribing to external data that is then incorporated into the application. Execs get a demo – and say that this isn’t what they wanted.
Example 3: A small financial services company spends millions on outsourced project development over a three-year period. Business users refuse to use the system which they claim has bad data and doesn’t deliver functionality they requested. The CIO and IT senior managers are fired.
What do these projects have in common? All the lead participants are asleep during the project. And they are naive about who owns the effort and how to sustain ownership long enough to get a desired benefit.
Whether you believe that two-thirds of projects fail, or you believe only one-third of them fail, a lot of money gets wasted. And there are many good ways to reduce project risk And there are also guidelines on how and when to kill failing projects. No need to belabor them.
But trumping all of these, in my view, is the go-to-sleep attitude of enterprise executives (maybe even including the CIO) as these projects proceed. By going to sleep about their sponsorship and energy investment, only to wake up after prolonged elapsed time, the project became IT’s responsibility -- and perceived inadequacies clearly are IT’s fault. Now the money is spent and the result is either so inadequate as to be a total write-off, or it is cancelled before any benefit can be realized, or frustration results in intense company in-fighting and even termination of jobs.
When a project that is presumed to deliver sweeping business change and improvement – otherwise why spend so much money on it? – it is not IT’s project, nor the outsourcers’ project, nor the responsibility of a single beleaguered and perhaps junior business project sponsor or analyst. It is an enterprise effort for which IT is a small and important player, not the owner. If you wanted a custom-designed house built, wouldn’t you visit the site and monitor progress? Isn’t it your house, not the architect’s house? After all, who will live in it when it is done? You certainly wouldn't wait until the appliances are being installed to see if the kitchen was what you expected.
But when large IT investments falter, most likely that's exactly what enterprise execs have done. It's not their house, it's IT's house. And if the specifications were inadequate, the cost was over budget due to revisions, that's IT's fault.
And CIOs who let business executives off the responsibility and oversight hook, if they let them send underlings to meetings, if they provide a status and get no feedback, if the scope of deliverables is intergallactic, if ddevelopment is not iterative, that's exactly what they are aiding and abetting. Their own project failure and a waste of the enterprise's money. And that scenario, sadly, really is their own fault.
Laurie has hit on a great point: long term projects can kill anyone's career. In this day and age where so much can change in just a business quarter, who the heck would ever sign up to lead/manage/work on a multi-year project?
Forget for just a moment the challenges of keeping a team motivated for that length of time, how is anyone going to go about getting funding year after year? The one thing that Laurie didn't talk about in her posting was how to solve this problem. That's ok, the kids over at Harvard Business school have a solution that just might work.
Their suggestion is to never have a monster project that you try to completely define at project kickoff and then watch get out of control. Instead, they suggest that you do a series of much smaller projects that deliver real, immediate benefits to the company. This way nobody has a chance to fall asleep because the positive results keep rolling in.
The thoughts are novel and appear to be good. Now let's see who's career takes off once they start to do IT projects this way.
- Dr. Jim Anderson
Blue Elephant Consulting
www.blueelephantconsulting.com
CIO's should never lead major upgrades to organization's IT infrastruture nor software which support its vital business processes. This is the COO's domain of operating the business in the information age. COO's should never abdicate this role nor subjugate the CIO / IT teams to vasicillation of multi-year plans.
Hi Laurie,
Strong post...
BTW, I think we talked about this when I was looking at CIO behavior for SAP a year or so ago. My take is that too many CIOs are obsessed with becoming "strategic" (aka "Partner Players" by your taxonomy). This obsession leads to the syndrome you identified because:
1.) They're acting out according to an archetype they want to be, not what is required.
2.) They have a disinterest in building a solid foundation in core functions, so they get distracted by problems with utility functions like e-mail, voice, etc.
3.) They believe game changing initiatives have to be big, so none of them question a multi-year timeline.
As you noted in "The Three Archetypes of IT," CIOs need to realize that "[a]spiring to be an archetype is different from being one."
Best, Paul
Hi Laurie, Good post and comments.
Whether executives are asleep, distracted, or not focusing on quicker wins, they must face the same challenges as front-line project managers --- how to implement their projects well in a complex environment. If it's not on a "to-do" list or ingrained as habit, there's a chance important follow-ups will be missed. Too many distractions. So little time. Good project managers follow proven work plans even though they know what to do. It keeps them focused. I'm not an executive of a large enterprise, however, I wonder if they have best practice tasks on a check list such as checking up on the house once per week or making sure the wins come out sooner than later? Not just this house, but following the same process on all new construction, every time. Do they use some kind of project planner like MS Project, a portfolio management tool like Primavera, or a best practice governance platform like PIEmatrix. Of course, these are only tools. The real key in these tools or on a note pad is the in-your-face process content --- what do I need to do today.