After you have the organization following your core IT processes (more on that here), you are ready to add effective IT governance to increase productivity and alignment.  Before you do this, make sure that you squash any of these five attitudes that may exist in your teams that will implement governance – they will virtually eliminate any chances you have for success.

“We are here to govern you”

The primary goals of governance is to make sure that everyone is following the plan and and that any difficult decisions are made quickly.  Correcting deviations from the plan or to improving overall decision-making cannot be done in a heavy-handed way.  A policing attitude will not work and is often exhibited by teams or individuals who are not confident in the value they add and mask it with “attitude.”

“All you have to do is give us your documents and we will let you know if you pass or fail”

The “grading papers” mentality is also popular as IT tries to get a handle on the volumes of documents produced by the lawless business community and distributed IT organizations.  The primary flaw in this approach is that all of the work and re-work is moved to the end of the phase.  If there are any major issues, the project team needs to re-assemble and rewind their thinking, which can take significant effort (see this 1988 IEEE paper by Barry Boehm and Philip Papaccio).  Instead, the “governance” activities as such need to be woven into the core work processes.

One health insurance carrier I work with has positioned their governance team as the experts in producing key project deliverables and is often requested to help add to and review them as they are being produced.

“It is our job to determine if your project aligns with the business objectives.”

One of the benefits of good IT governance is to keep investments aligned with the business strategy.  (In fact, the technique of business blueprinting,  can explicitly make these links.)  That said, no business sponsor proposes projects they think don’t align with their own business!    Their projects are always well-intentioned but may not align with what IT thinks of as the right approach or priority.  This is yet another opportunity to build in the collaborations into the process of planning projects – business sponsors and SMEs, IT project and program managers, enterprise architects, business and IT finance managers, etc.

“IT governance takes more time, but it will be worth it.”

Adding checkpoints and meetings into an organization that lacks standards and has consistency problems will be seen as overhead.  Governance additions or changes should be done in the context of overall process improvement, not individual time savings.  IT process improvement should be implemented in small pilot areas to build belief in the improvements and outcomes that will in turn, build credibility and compliance during roll-out.

“We will make the final decisions in case of a stalemate.”

Finally, if the policing or government attitude is present, there will also be a tendency to want to force decisions.  This is the final death knell for an IT governance initiative.

The common thread through this topic is that to succeed at IT governance, you first must get the organization to follow a solid set of work processes (eg, SDLC) and then implement governance as a light-weight set of checkpoints that are designed to collaborate with those running projects.

by Chris Curran, with research by Michael Mariani

I am very passionate about coaching team sports and have been a basketball player most of my life. So, I read with great interest a recent MIT Sloan Management Review article, What Can Managers Learn From College Basketball?

There are three very interesting points:

1.  That the majority of new jobs are sourced through “weak ties,” not close relationships. (I never heard this before, but it makes sense.  Interestingly, I heard the same thing at a presentation last week by Andy McAfee on Enterprise 2.0.  The Baader-Meinhof phenomenon in action?)

2.  Between 2001 and 2007 more than 280 coaching changes were made across 341 colleges in the study.  See any parallels here to the CIO tenure situation?

3.  Many of the coaches are part of one of eight “family trees” – The John Calipari Tree or The Rick Pitino Tree, for example.  Furthermore, being part of one of these trees improves your chances of landing good jobs.

This got me thinking:  Are there family trees for the Chief Information Officer profession?

To begin exploring this question, we started with the CIO 100 and supplemented it with LinkedIn and biographical data available on the web.  For anyone who has tried to develop an easily understandable network map of customers, contacts, etc. you will know that it is a difficult task to identify links and make any sense out of them.  That said, we think there are some indications that CIO trees do exist.

After spending a few days digging through the data, a few trees seemed to emerge.  One example was around John McKinley, the CIO at GE Capital, Merrill Lynch, President/CTO at AOL and now a partner with a digital business incubator, LaunchBox.  Here is an example of some of the IT leaders who were in John’s organizations and their current firm:

Since I don’t know anyone on this chart, it only represents leaders who were working in the IT organizations during John McKinley’s tenure and went on to CIO positions later in their careers.  Given all of the IT organization variants, it’s also unclear what kind of reporting relationships existed in each organization and how much influence or opportunity for mentoring there was.  But this data can at least fuel an interesting discussion.  The idea of a CIO leadership tree seems a even a little more plausible at GE, given Jack Welch’s history of developing future corporate leaders.

The other interesting question explored in Daniel Halgen’s original study, “All in the Family: Network Ties as Determinants of Reputation and Identity in NCAA Basketball”, is if members of strong coaching trees are more resilient in the job market.  His research found this to be true and that the jobs were more prestigious for those affiliated with the trees.

I wonder if by more prominently highlighting our leadership lineage, we can land more desirable jobs?  Food for thought.

Consider the results of a question from Diamond’s most recent Digital IQ survey asking for indications of project success. Aside from the provision of a high quality computing platform, consistent project delivery has got to be one of the primary ways to measure IT’s value to the business. In this year’s survey, fewer than 50% said that projects were delivered on-time and only 16% said they delivered all of the features and capabilities initially planned. What is wrong here? Some would say that this is a governance problem – how could IT leaders constantly allow projects to continue to burn time and money without intervention?

I would argue that IT governance does not work if it is treated as separate set of overlays on top of the core day-to-day processes. In my experience, many of the performance improvements IT governance is intended to fix cannot be fixed by governance alone.

What is likely at fault in the project delivery case, is not a lack of IT governance, but rather poorly understood, poorly trained, poorly documented and poorly enforced set of work processes. In the case of IT project delivery, an organization’s use of its chosen software development lifecycle processes, or SDLC, while often talked about, is usually at the root of the problem. Symtopms of this problem that I often hear:

1. “We use the vendor’s/outsourcer’s methodology” (you need one too to drive the action)
2. “We have a standard set of templates” (that’s not enough)
3. “We use (fill in the name of a project workplanning tool)” (a tool cannot replace a well-defined and followed process)

Enterprise architecture (EA) is another area where governance is often applied. In the case of EA, lack of a solid core process is also often to blame in poor architecture adherence and adoption. Again, organizations must spend the time to enhance its project planning and SDLC processes with the proper EA tasks instead of simply adding an EA governance mechanism on top of a set of immature or broken core processes.

So, before launching a new IT governance design effort, make sure to inspect your core work processes first. They are often at the root of the problem.  IT governance does work, but only when designed along with the processes it is supposed to help.