First, my apologies – this is old news!  But I was talking to a CIO last week and he made a statement I’ve heard many times over the years:  “The company views IT as ‘the piggy bank’ – it’s a place they can reliably come to when they need to cut costs!”  This reminded me that while I’ve had the good fortune over the last 5 to 10 years to work mostly with more mature IT organizations and their ‘clued in’ CIO’s, there’s a lot of CIO’s out there who should not be running enterprise IT functions – they are doing a terrible disservice to their employers!  Hence this post, intended to prompt less capable CIO’s (and maybe some CEO’s) into action!

Back to my anecdote.  I asked the CIO (knowing pretty much what his response would be), “How does the company feel about it’s IT capabilities?”  He said, “Well, no so great, actually!  They tell us we are delivering ok from a tactical perspective, but are not creating strategic value!”  I asked, (again, anticipating a predictable response) “How engaged are the members of the IT organization?”  His response, “Well, we do have an engagement problem – IT scored quite low on our latest engagement survey.”

The ‘Piggy Bank’ Trap

This CIO is caught in a familiar vicious cycle:

1. While they’ve done a decent job ‘keeping the lights on and the trains running,’ IT has not delivered strategic value.
2. As a result, when the company is looking to take out costs, IT is the first place they go.
3. Feeling vulnerable and wanting to be a ‘team player’ the CIO makes some cuts and ‘ponies up’
4. With budgets reduced, and with IT’s position as a tactical capability reinforced, the business units don’t look for strategic IT enablement, and the IT organization doesn’t have the bandwidth or capabilities to stimulate strategic demand.
5. Inevitably, more cuts are requested of IT (as a dependable source of budget money) and the cycle continues!

IT Must Be highly Cost Effective!

Make no mistake – IT has to run its operational side in the most cost effective manner – provable through benchmarks.  (And, as it turns out, IT operations and support is one of the most easily and accurately benchmarkable aspects of IT.)  Often, getting to an acceptable benchmark in operational costs means working with business units to consolidate disparate systems, retire ancient and non-viable platforms, and exploit newer technologies such as virtualization and cloud computing.  There’s good news and bad news in this:

• The bad news is, it can’t be done without business cooperation.
• The good news – it forces business cooperation!  In other words, IT is not simply acting as a piggy bank – it is working with its users to increase efficiency and effectiveness.

The good news side of this equation helps position IT beyond a ‘back office’ mystery zone of geeks and propeller-heads, and towards a valued business partner.

IT Must be Strategic

But cost effective operations is just table stakes for the real mission – enabling business growth and innovation.  Not simply helping the bottom line, but growing the top line – and even creating new top lines enabled by information and technology.  You cannot cost cut your way into this role.  If, as CIO, you find you are repeatedly getting relegated to the company piggy bank, you need to look in the mirror.  As I’ve noted before, businesses get the IT they deserve!  And the corollary to that – CIO’s get the respect they deserve.

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 54,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 20 sold-out performances for that many people to see it.

Click here to see the complete report.

Walking Ever Faster Will Not Get You Running!

If, arbitrarily, you pick 3 levels of Business-IT Maturity – say Level 1 = low, Level 2 = medium and Level 3 = high, you will typically find that the things you have to do to get from Level 1 to Level 2 not only won’t get you from Level 2 to Level 3 – they will actually prevent you from reaching Level 3!  The trick is to recognize what these things are, and that you are entering a very different learning curve.  For example, if your solutions delivery process is broken, you need a great deal of rigor and discipline – in the form of Project Management and a Systems Development Life Cycle.  That will get you from “chaotic” (Level 1 in my hypothetical 3-Level scale) to “managed” (mid-Level 2).  But over time you will find the limitations of a “managed” approach to solutions delivery – especially when you need to implement “fuzzier” solutions, such as social media, or business analytics.

One Size Does Not Fit All

With solutions delivery, one-size does not fit all, and the methodology that works well for a relatively easily pre-specified transaction processing system (order-to-cash, for example) will not work well for something that is less predictable and more emergent.  Hanging in there with the “official” methodology (for fear of reverting to the chaotic situation that persuaded you to implement the methodology in the first place!) will frustrate the developers, annoy the business client, and will probably lead to a poor or unworkable solution – which will upset everybody!  What is needed is a finer-grained way of categorizing types of business solutions, and flexibility with methodologies to fit the best approach for a given solution type.

What Worked for Transactional Systems Won’t Work for Innovation Solutions

Collaboration and Knowledge Management initiatives are not readily planned using traditional project management methods – they tend to follow an ‘emergent’ pattern that is typically non-linear and somewhat unpredictable.   A traditional planning style, with detailed deliverables, work steps, activities and due-by dates must give way to a more iterative and organic approach.

Social Media Projects Should be Led

You cannot mandate participation in a community – you can invite participation and create reasons to do so. You cannot schedule a date by which a given percentage of a community will be collaborating on a wiki, for example – you can only set expectations, model desired behaviors, and create good reasons for people to become active users of the wiki.  Then you must reevaluate the results and adjust the approach in the light of experience.

Recognizing the Hard-Won Battle – and the Need to Fight New Battles

It seems that sometimes the battle of getting from Level 1 to Level 2 Business-IT Maturity is so hard won, and the win so apparently fragile, that leaders hang on to the methods that got them to Level 2.  This is about being really good at solving yesterday’s problems.  It’s a different world today, and the ways that technology and information can be exploited for business advantage demand different approaches.  Don’t let the trappings of Level 2 restrict your ability to get to the next level!

Camtasia for Mac

Quite some time ago I found myself needing to produce screen video tutorials.  I’d heard good things about TechSmith and their Camtasia for Mac product.  I also loved the fact that they offered an excellent 30-day free trial, so that was my introduction to Camtasia on the Mac.  I think I was but a few days into the free trial before I decided to buy a full license.  First, the software was only $99 at the time – an easy price point for me.  Second, I was so impressed with the software experience during the trial.  Admittedly, I had done quite a lot of video editing and production (my family might say a little too much production and not enough editing, having been all but forced to watch through my vacation videos!) so I was somewhat familiar with the process, but I found Camtasia for the Mac to be a joy to use.  Very intuitive, robust and beautifully designed.  Third, I loved all the excellent tutorials and user guides they provide, and finally, I found that their Screencast.com site was a great way to share videos with colleagues and clients.

Camtasia Studio

Recently, I had the need to write, produce and edit some screen video tutorials for a client.  The wrinkle, however, was that I had to do this from within their firewall, on one of their locked down Dell laptop PC’s.   They did not have any screenncasting software I could use, so I did a little investigation and found that TechSmith had a PC product called Camtasia Studio, so that was a natural choice for me.  My first shock was the price – whereas the Mac product was $99, the PC product was $299!  At $99, given my experience with the Mac version, I’d have simply purchased the PC version, but at $299, I thought I’d take advantage of the 30 day trial.  I’m glad I did!

Chalk and Cheese!

The Mac and PC products were completely different animals!  For all the ease of use and intuitive feel of the Mac product, the PC product was a very different beast – counter-intuitive and obscure.   While it was more fully featured than the Mac version (with features that I had never needed on the Mac) there were some very basic things it could not do that the Mac version handled with ease (or, at least, I could not figure out how to do after hours upon hours of viewing tutorials, user documentation and the excellent Community forums that TechSmith hosts).

More distressingly, over months of intensive Mac use, Camtasia for Mac had never so much as hiccuped, while Camtasia Studio on the PC fell over in a heap regularly – sometimes I was able to recover my work, but sometimes my work was lost!  I quickly learned my old habit from many years ago of saving my work every time I did anything.  (This was a habit I’d lost since moving to a Mac some years back.)

I don’t know the story behind these different versions.  I can imagine a couple of scenarios.  Here’s two conversations I imagine the product managers at TechSmith saying:

1. “Hey, now we’ve got a few year’s experience under our belts with Camtasia Studio, it sure would be great to start over and really do it right!”  “Why don’t we do that with our planned Mac version?”  Or…
2. “We need a Mac version of Camtasia Studio, and I’ve just come across  a great Mac screen video editor that I think we can acquire.  It won’t look anything like our PC product, but that’s doesn’t really matter – people are either Mac freaks or PC bigots – nobody will ever use both and realize they are different products!”

Whatever the real story behind these versions, TechSmith has a product they should be really proud of in their Mac version, and one they should rebuild from the ground up for the PC.

Graphic courtesy of Download Spy Software

The “Can Do’s”

Some IT shops fall clearly into this camp.  Suggest something innovative or new to them, and they are quick to explore the idea, see if it makes sense, and then figure out how they’d make it happen.  These clients are a delight to work with – energizing, engaging, sometimes challenging, but in a positive, constructive way.

The “Can’t Do’s”

Other IT shops fall into this unfortunate camp.  Suggest anything – innovative or not – and the immediate reaction is some variation on, “We can’t do that!” or, “That won’t work here!” or, a common variation, “That’s just not the way things work around here!”

Ask someone in a “Can’t Do” shop to help with something, and they will spend 30 minutes or more telling you why they don’t have the time to help – even if the help you are asking for would take only 15 minutes!  In other words, they will spend more time telling you why they can’t help than the time it would have taken to help.  It’s a knee jerk reaction.  The thought bubble I see in my head, floating above these naysayers is, “If I sign up for this, I might have to do something that would change the status quo.  That might be dangerous.  That might lead me to the unknown.  It’s safer to say, ‘no.’”

Prevent “Bad Change”

The “can’t do” environments spend all their energy trying to prevent change that might be harmful or counter to the established order.  Of course, there’s typically no way of knowing if it’s going to be a “bad change” or a “good change”, so by definition, any change is to be resisted at all costs!

Create “Good Change”

These are the innovators – the change agents.   Always looking to challenge the status quo and explore new possibilities.  I imagine that companies like Woolworths and Circuit City had a critical mass of “change resistors” (or at least, had enough of them in positions of power to preserve the status quo), while companies like Best Buy and Target had a critical mass of “change agents”.

I can understand why IT shops tend towards the “prevent bad change” camp.  IT operations depend upon stability and predictability, so you don’t want to mess with that.  But, unfortunately, the operational needs and culture tends to permeate everything the IT shop does!  Just when the business needs their IT specialists to be bringing them new ideas and new ways to compete, the IT specialists are beating down anything new.

From “Can’t Do” to “Disengaged”

Unfortunately, it’s an easy slide from “can’t do” to “disengaged”.  People in the organization get so beaten down whenever they try to introduce something new, that they give up.  It becomes such a painful endeavor, banging your head against a wall, that you stop trying.  It’s easier to slip into the background and go with the flow.  I have to admit that even as a consultant, there have been times where it was too painful trying to change things, and I’ve “gone native”.  Just make sure the deliverables per the Statement of Work are produced, get paid, and get out!  After a while, the extra energy it takes to break through the culture is spent.  At times like that, I empathize with the client’s employees – beaten down, disengaged, and at peace with simply going with the flow.  All that potential creative energy left at home, rather than being brought to the office as a source of new ideas.

So, What To Do About It?

I’m sorry, there’s no magic formula I’m aware of.  The first step, like the substance abuser, is to admit to the shortcoming.  Recognize that “can’t do” has permeated everything – way beyond those operational process where preventing bad change makes sense.  Then follow the familiar but tricky steps of organizational change management – establish the cost of the status quo, create a vision of the new, brighter future, build a guiding coalition, create early wins, etc.   Sometimes, it pays to stick you neck out – ask forgiveness, not permission!  If you get shot for doing so, that’s OK – you probably didn’t want to work there anyway!

Prevent Bad Change…

For all the change that IT organizations bring about for their customers and clients, IT people are generally resistant to change.  I think this resistance is deeply rooted in a couple of factors:

1. IT environments are full of technical complexity – layers upon layers of technology containing multitudes of interfaces and dependencies.  Change something over here and something over their is impacted – sometimes in subtle ways that may not be evident for some time, or until some other seemingly unrelated change is made.
2. IT professionals thrive by taking complex situations and reducing them down – ultimately, to zeroes and ones.  There’s no room for ambiguity in a digital system – as such IT specialists are conditioned to abhor ambiguity.  And yet change is full of ambiguity – what ‘has been’ is no longer, and what ‘will be’ is not yet stabilized.  The natural inclination, then, is to drive out the ambiguity, and typically, the fastest, safest path to achieve that is to revert to the status quo – ending the change before damage is done (or the changed state it reached!)

Meet the Culture Where it is – Or Where You Want it to Go?

This inherent tendency to ‘prevent bad change’ creates some tough dilemma’s when introducing social networking and collaboration capabilities such as Wikis.  Wikis thrive best where a culture is open and emergent – “enabling good change,” if you will.  As you design the governance mechanisms for a Wiki, you have some interesting choices.  For example:

• Do you allow people to create their own pages?  Or do you put controls on who creates and who edits pages?
• Do you allow all spaces to be open to anyone in the organization?  Or do you allow for “private” spaces, where a select few (such as an IT leadership team) collaborate?
• Do you allow people to display avatars that are humorous or ironic?  Or do you insist on “corporate photographs” from people’s security badges?
• Do you allow people to write in their unique voices – even if a little rough around the edges?  Or do you have a Wiki Gardener monitor pages and clean up the rough edges?

To be clear, I’m not talking about allowing people to violate corporate codes of integrity – potentially offensive or inflammatory graphics or text is clearly out of bounds and violations of such codes of conduct should swiftly be managed as performance management issues.  I’m talking about an open and emergent Wiki environment – complete with the bumps and hiccups it may contain, versus a more closed and structured Wiki, protected from potential ‘voices of dissent’ or the raising of challenging or tough issues.

Governance Designed to Meet the Culture Where it is

You can take the position that Wiki governance should be designed for the current state:  “We are locked down, deeply concerned about security and privacy.  We have to have special ‘standards of conduct’ and controls to keep things structured and secure.”

Governance Designed to Help Shift the Culture

Or, do you take the position that the governance should be designed with an eye to the desired future state: “We encourage open dialog and a thriving ‘community of adults’ – keep within our corporate code of integrity and help make the Wiki a safe, valuable and fun place to grow and share our enterprise knowledge about IT.”

Given the people responsible for approving Wiki governance will probably not have significant experience with the more open model, their inclination will be to ‘play it safe’ and design for the current state.  Unfortunately, that is likely to perpetuate the current culture and probably prevent the Wiki from becoming what they want it to become.  It make take one or two strong, visionary leaders to take the leap of faith, and allow a governance model that reflects their aspirations for the culture.

Graphic courtesy of Positive Change

When to Edit, When to Comment?

I guess this issue exists equally with Word documents – MS Word has its powerful Reviewing mode with its ability to add comments or to actually edit a document.  The same is true on a Wiki – you can comment on a page, or you can go in and edit the page.  The difference is, we have all been commenting on and editing Word documents for years!  But when you get to a Wiki, you typically don’t have the years of experience, nor do we have the shared but tacit understanding of when commenting makes sense compared with editing.  To the Wiki novice, not feeling sure about when to edit versus comment can freeze you into inaction!  You feel much more ‘exposed’ about making either comments or edits – but edits feel somehow more ‘in your face.’

We have found that a few supporting pages (themselves, a natural fit for a Wiki approach) can be very helpful in covering questions such as “edit or comment”.  Examples include:

• Wiki Collaboration Guidelines and Procedures
• Wiki Manual of Conduct
• Wiki Manual of Style

Additionally, we have found that the gentle guiding hand of a Collaboration Manager and/or a Wiki Gardener can both demonstrate by example and, where appropriate, make adjustments to shift comments to in-line text edits or vice versa.  And, for those who can’t wait to find out the answer by trial and error, we’ve found the general principle is – if you are certain about the change you want to make, go ahead and make it!  The Wiki will let others with an interest in the page see the changes you have made, and they can always be backed out – nothing is ever lost!  If you are less certain, post a comment, quoting the text you want to change (most Wiki tools make that easy to do) and raising the points of discussion that lead you to be tentative about making the change.

Blank Pages Are Intimidating!

I’ve run experiments, creating a new page with an important page title (such as Potential Wiki Governance Principles) and asking folk to “weigh in.”  Perhaps not surprisingly, nobody does.  Add a few threads of text, or a contentious issue (that might be addressed by a principle or two) and people start to weigh in.  As I said, this is not surprising.  People are intimidated by blank pages.  Having said that, as a consultant who has facilitated hundreds of workshops, I know that starting with a “clean sheet” is rarely a good idea.  However, there are situations (and team dynamics) where a clean sheet is exactly the best place to start.  Which is why I ran the ‘blank page’ experiment.  At least one lesson learned would be: you can make things happen in a facilitated workshop that you can’t achieve on a Wiki!

Free, Open (and Risky?) Versus Controlled, Closed (and Safe?)

For whatever reason, my partner and I tend to find ourselves working on social media and collaboration initiatives with companies that have traditionally been somewhat “locked down” and conservative – often in highly regulated industries.  They have an inevitable (and understandable) bias towards controls and regulations – more concerned with “stopping bad things happening” than with “making good things happen!”  Unfortunately, this is not an ideal culture for open collaboration and knowledge exchange!  As much as they want to move to a more open and sharing culture, their natural instinct is to “govern and control.”

Given this, one of the issues we find ourselves coming back to as we navigate the changes inherent in becoming more open and collaborative is, ‘Do we manage the change from the current culture or from the culture we hope to change to?’  The temptation is to draw up a list of rules and create governance bodies and processes to manage the environment.  This is what people expect – but the question is, do such approaches serve to reinforce the current culture as opposed to fostering the desired culture?  Do rules and regulations send a message to people, that, “This is business as usual – be careful, think twice before you write or comment!”  And do such messages, unintended as they may be, tend to shut down otherwise valuable dialog and knowledge exchange?  Do they perpetuate the status quo?

We argue (and have demonstrated) that less rules and regulations are more effective in engaging stakeholders and fostering healthy dialog – without bringing the organization to its knees or being overrun with lawyers!  Of course, someone (the role is often called Wiki Gardener) has to monitor the site and take corrective action when needed.  They have to coach accidental transgressors.  Deliberate or malicious transgression is a performance management issue and must be handled as such – with firm and immediate action.

What have your experience been with Wikis in IT?  How have you handled “rules and regulations”?

Photo courtesy of Bionic Band: Home of Bionic Band Sports

Document Orientation – The Wikis Greatest Enemy!

My colleague and business partner Roy Youngman posted a while back on the question, “Why are Wikis in Corporate IT Rare?”  In the post he posited that most corporations, especially IT departments, are entrenched in a document-oriented approach as the means for developing, codifying, and sharing knowledge.  Roy made an important point that:

Paradoxically, ‘document-orientation’ is both the main reason why Wikis are rare in the corporate world and the main reason why Wikis are great for the corporate world.”

Wiki Benefits – A Solution to the Shackles of Document-Centricity!

Roy went on to explain that:

The Wiki approach addresses almost all the short-comings of ‘document-orientation’.  The nonlinear nature of a Wiki enables well-factored content, thereby minimizing redundancies and preventing contradictions that confuse people. It also allows people to contribute to whatever area of expertise each person happens to have so everyone is drawn in, not just the elite few.  A Wiki approach enhances the discovery of knowledge and exposes the subject matter in the greatest need of improvement. And the improvement is a constant theme – the very heart and soul of a Wiki.”

From Document to Wiki – Changing Mindsets One Page at a Time!

I’ve been using document-centric tools such as Word and PowerPoint since they first became available in the late 1970′s.  Beyond the simple accessing of Wikipedia, I’ve been actively using Wikis such a MediaWiki and Confluence since 2005.  So I have significant experience both in the traditional world of documents, and the more contemporary world of Wikis.  And I can tell you, the shift from document-centricity to Wikis is non-trivial!  I can also tell, it is HUGELY BENEFICIAL!

Here’s a sampling of the mental hurdles I’ve had to navigate in order to realize the full benefits of a Wiki approach.

When to “Polish” Versus When to “Collaboratively Evolve”?

Historically, when I’ve been creating some kind of deliverable (a Word document Project Charter, or a client project briefing PowerPoint deck for example) I’ve always felt that it has to be polished to a high degree.  Many years ago, a wise and seasoned consultant and mentor advised me to always produce quality documents – both in terms of content and look and feel.  He said, “If it looks shabby and full of typos, how can you expect the client to take it seriously?”  The latter point is not necessarily obvious based on the deliverables I see from many consultants.  As an example, I saw a key deliverable produced by a large consulting firm that was full of typos, grammatical and formatting errors.  The final insult was that a PowerPoint slide misspelled the CIO’s name – in a key presentation that was given to the CIO!

By contrast, when I start to create a Wiki page, I feel almost obliged (and grateful!) to start with a much rougher “draft” and look forward to the ensuing “collaborative polishing” that will emerge.  Sounds obvious, but getting comfortable with a “rough draft” as a starting point did not come easily to me until I began to notice that people were less inclined to collaborate on a document if it looked highly polished and “print ready”.  Learning when to “polish” and when to release “draft” material is not always obvious and is very situationally dependent – demanding a keen sensitivity to the specific context for the document.

Structure, Linking, Tagging and Factoring in a Wiki World

I’ve always paid attention to document structure.  I believe I understand the basic principles of good structure, and learned a lot about logical structure from the powerful Minto Pyramid Principle back in the late 1980′s.  But when you get to a Wiki, things change!  The ability to hot-link across “documents” and to external sources in ways that just don’t work in a document-based world (who knows where any given document will be located?) changes the way you think about structure.

Tagging and Folksonomies create another layer of possibilities (and another layer to think about!) that is rarely used effectively in a traditional document environment.  The concept of factoring, well understood (if not always followed!) by programmers, involves structuring content for maximum reusability, minimum redundancy, and ease of search.  These are typically not considerations in a traditional document approach.

One of the many benefits of a Wiki is that it enables an entire collection of ideas and information to be placed into a single, hyper-linked space.  But if that space is a messy structure, the benefits may quickly erode.  If you aren’t a programmer (or, at least, not a good programmer!) you may need access to a Wiki expert for help in thinking through the structuring of a given space – especially if you are using a Wiki that allows for a hierarchical structure among pages.

Does eMail Traffic Really Reduce?

A client I was working with recently was (appropriately!) paranoid about anything that drove up eMail traffic.  When they learned that the Wiki could send eMail notifications about changes, they were immediately hesitant to utilize this feature.  While it’s natural to want to find ways to reduce eMail traffic, we’ve found that there’s an important distinction between “normal” eMails, that come from people and automatic notifications.  The former typically demands time and activity – responding to the email.  The latter is purely and helpfully informational.  Also, if you aren’t finding the information helpful, then turn off the automatic alerts!

The great news for this client, in addition to discovering that automatic informational eMails in the form of Wiki alerts were far less intrusive and demanding than real eMails from people, was that the transition to a Wiki approach dramatically reduced the person-to-person eMail traffic, as the endless cycle of passing documents around was replaced by collaborative editing of a Wiki.

I’ll look at more of these “mindset changes” associated with the shift to Wikis in upcoming posts.

Image courtesy of Westwood K-8 Technology

My New Venture

The venture is a partnership with my dear friend and long-time colleague, Roy Youngman.  (See Roy’s blog).  Roy and I have been on a fascinating journey over the last 20 years – learning about the levers that impact IT performance and business value.  Back in the 1990′s, I was a Partner at Ernst & Young‘s Center for Business Innovation while Roy led a team at the Center for Information Systems Planning and Delivery, taking what the Innovation Center discovered and developing tools and methods for use by E&Y’s consultants and clients.   Since then, Roy and I worked together at The Concours Group (and nGenera, when they absorbed Concours) and as independent consultants.

Social Tools Shape a Vision…

For the last 5 years, we have focused on driving IT improvement using social media and, though I hesitate to use the term, leveraging Web 2.0 and 3.0 capabilities.  We have worked together on client engagements and multi-company research.  We have worked to improve how management consulting works – a process that has always struck us as a “leaky” and inefficient!

We’ve focused on three questions:

1. How can the business value of IT be increased using the kinds of social tools that are transforming they ways friends and communities interact, share and collaborate?
2. How can social networking and collaboration capabilities be used to increase organizational clarity and drive higher engagement among IT professionals?
3. How can the knowledge transfer process be improved to, within and between our clients?

We’ve worked with various tools (e.g., SharePoint, MediaWiki, Confluence) and with a variety of plug-ins and extensions in support of IT organizations who are trying to improve their performance and the value they deliver to their business clients and customers. We’ve created a meta-model of IT Capabilities.  We’ve created an architecture for a Semantic Wiki, based on this meta-model and populated from our combined 60 years of IT experience.

The ‘learning journey’ has been rewarding, and from it a vision has emerged – one where IT professionals and their customers deliver services through a Web-based social context.  I will use this blog to post about what we have learned and are learning.

In time, we will create a separate web site and provide the means for others to collaborate with us on this journey, but for now we are strictly focused on our client work (and our respective blogs!)

Some Early “Lessons Learned”

Create a baseline quickly

Set the quality bar high, and make rapid, incremental improvements thereafter.  The name of the game is “emergence” – you need sufficient structure to help people have some sense of the destination, but not so much that they can’t participate in shaping the journey.

The most effective way to instill change is through “Pathfinder Projects”

Pathfinder Projects are ones that have to be undertaken anyway (their primary purpose) but that have an explicit secondary purpose of leveraging one or more social capabilities, such as a Wiki (e.g., adding quality content) as an outcome of the project.

Be “in the flow”

The social tools need to be incorporated into the natural work flow.

Take a ‘cascading’ approach to deployment

Deploy in “waves”, starting with IT leadership and Pathfinder Projects, continuing with Process Owners, natural Communities of Practice, and grow from there based upon how the collaborative/social energy flows.  But also be sensitive to naturally emerging opportunities – go to where the puck is going!

Pride in workmanship trumps controls!

It is far more important to instill a pride-in-workmanship than to install a complex review and control process.

Expect a Power-Law distribution

A Power-Law Distribution is expected and good; a few will contribute a lot and some will contribute little, but everyone has something worth contributing.

Leaders demonstrate commitment by example

Leaders must demonstrate their commitment ‘by example’ while avoiding the temptation to criticize (which will be initially easy).

Are you working with Social Tools to improve IT work?  What are you doing and how is it working?

Image courtesy of pcms consulting

COBIT

COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks. COBIT enables clear policy development and good practice for IT control throughout organizations. COBIT emphasizes regulatory compliance, helps organizations to increase the value attained from IT, enables alignment and simplifies implementation of the COBIT framework.”

With Version 5 being released this year, COBIT 5 will consolidate and integrate IT value delivery and IT risk management into the COBIT 4.1 framework.

So, You Want to Increase IT Maturity?

For IT shops of relatively low maturity, COBIT provides an effective framework and body of intellectual capital for implementing or improving IT processes and controls.  It can help avoid a great deal of ‘reinventing the wheel’ that so many IT shops get into, developing IT processes from scratch, or living with processes that do not integrate properly and propagate IT organizational silos.  The danger here, though, is that simply licensing a set of process descriptions is by no means equivalent to adopting them.  If people don’t really understand the processes they are supposed to be following, or if they aren’t completely bought into the need for and value of those processes, then having scads of process descriptions and related documents is not going to ensure a controlled IT environment.

Oh, You Want to Reach High IT Maturity?

I have blogged at length about Business-IT Maturity and have described a simple 3-stage model of both Business Demand Maturity – the business ‘appetite’ for IT, if you will, and IT Supply Maturity – the necessary IT capabilities to satisfy business demand (at lower maturity) and to shape and stimulate business demand (to reach higher maturity).  I’ve also written several posts on what I refer to as ‘sticking points‘ or traps that IT organizations fall into when they are in the middle levels of business-IT maturity. (I’m reminded of the proverbial ‘gumption traps‘ that Robert Pirsig so eloquently describes in his exploration of the metaphysics of quality, Zen and the Art of Motorcycle Maintenance.)

Unfortunately, I’ve found that COBIT can easily create one such trap.  While it can be an effective way to get from Level 1 to Level 2 maturity (on the 3-stage model), it will not take you from Level 2 to Level 3, and can, in fact, inhibit movement towards high business-IT maturity.

Let me try an analogy.  Imagine a car driver who is taught how to drive around a city and diligently follow all the rules and regulations of the road, including speed limits.  Then put that driver into a racing car and expect them to keep up with other racing car drivers on a race track.  Not only will they be unable to keep up, they will likely wreck the car and hurt themselves, unaccustomed as they are to the finer points of fast driving, and unskilled in high speed steering techniques.  Note, the racing car driver is still perfectly able to drive in the city and be compliant with the rules of the road, she has learned additional skills to win races and avoid high speed crashes.  Our novice, city-trained driver has not learned these skills.

This is the COBIT trap – it will take you so far, but, absent further skills and enhanced processes, will not take you further.

I’m expecting this post to be controversial, and the COBIT bigots to attack my heresy, so please, bring it on!