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!

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!

Three Ways to Abuse Process Discipline

1. Forgetting that the heart and soul of process thinking is Process Improvement.
2. Process becomes a substitute for thinking, rather than an aid to it.
3. Not everything lends itself to detailed work processes.

Let’s examine these.

Come Back Deming – All Is Forgiven!

When the likes of Deming and Juran began spreading the gospel of Process Thinking, they weren’t talking about creating a process and freezing it in concrete!  The ‘Deming Cycle‘ – Plan, Do, Check, Out – was all about continuous (and sometimes, discontinuous, as in process re-engineering) process improvement.  And yet many IT organizations somehow leave this aspect behind as they institutionalize worksteps, activities, deliverables and milestones.  People are encouraged (forced”) to follow the project management methodology or systems development life cycle, and punished for violations.  For a while, things improve – some process is generally better than no process!

But then people begin to realize that the process seems to get in the way – inhibits agility.  Intelligent choices are held victim to the process, and bureaucracy reigns.  To get past this sticking point, people need to understand, believe in and be passionate about process improvement.  Be it incremental, stepwise improvement or breakthrough re-engineering, the missing ingredient of continuous improvement is essential to getting the intelligence back into the work and non-value-adding activities out of the work – especially if these inhibit speed, agility or quality.  The trick is to throw out the ‘bathwater’ of blind rigor without throwing out the ‘baby’ of process management discipline.

Three Ways to ‘Standardize’ for Repeatability and Predictability

Many years ago, my esteemed colleague Roy Youngman was co-authoring a book with me (Development Effectiveness: Strategies for IS Organizational Transition) and pointed me to this great work by Henry Mintzberg.  If a goal is to make work consistent, repeatable, predictable and of high quality, there are three ‘degrees of freedom‘ that can be tackled – the tasks, the deliverables, or the people.  The degree to which you ‘standardize’ within this mix is a function of the nature and complexity of the work you are trying to achieve.

For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.

For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.

For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below tries to capture this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, think training and performance support.

Some Process Management Questions To Ponder

• Are your IT processes holding you back – or setting you free?
• Are they an aid to thinking, or a substitute for it?
• Is it time to move past the blind discipline of mindless processes to a more context-sensitive and effective approach?
• How often to your processes improve, and where is the impetus and insight for those improvements coming from?
• How are process improvements recognized and rewarded?
• Is it clear who owns ‘improvement’ for any given process?
• Is it clear who owns the ‘services’ that are delivered by given processes?

Answers on a postcard, please!

I am very excited about an upcoming event we are holding in Chicago mid-September.  I’ve been busily collaborating with an internal team here at nGenera, and with a Professor from Emory University on creating an event designed for senior business, IT and HR executives.  The session, entitled “Unleashing the Core, Innovating the Edge” explores the thorny subject of innovation in today’s businesses. It will open with a dinner on September 17, then continue through lunch on the 19th. It will be at the magnificent The Ritz-Carlton, Chicago, Illinois.  We’re going for an innovative format and stellar presenter/facilitators including Enterprise Irregular Susan Scrupski, our own Dr. Nicholas Vitalari, Professor Gregory S. Berns, MD PhD, the Distinguished Chair of Neuroeconomics at Emory University, where he directs the Center for Neuropolicy.  Greg’s new book “Iconoclast. A Neuroscientist Reveals How to Think Differently” is actually being published September 29, but the publisher has offered to get advance copies to us for the session.  We will also have some of my friends from The Second City (improvisation and comedy) bring us lessons from the performing arts through experiential exercises.

Here’s the context. For the last decade or two, companies have been establishing and automating their operating models. Enabling all this process automation is a complex and sophisticated infrastructure comprising processes, systems, data centers, communication networks, data storage, and so on, plus a large group of technology professionals charged with building and running this infrastructure, and with defining and automating the company’s business processes. We refer to this collection of processes, systems and infrastructures that have evolved over many years as “The Core”.

While this has been going on, a technology revolution has been taking place – one that took seed in DARPA and the academic communities in the form of the Internet and World Wide Web, and that has mushroomed into what is now referred to collectively as Web 2.0. Tools such as social networks and collaboration hubs can liberate the workforce from the constraints of legacy communication and productivity tools like email. They can provide business managers with access to the right information at the right time, anywhere, through a web of inter-connected applications, services and devices. The collective “wisdom of the crowd” can now be easily tapped, with the promise of a huge competitive advantage in the form of increased innovation, productivity and agility. We refer to this emerging suite of Internet-based capabilities as “The Edge”.

The Core is the known. It is designed and managed for operational excellence. When it is improved, the business calls it business process improvement and IT calls it maintenance. The Edge is the unknown. It is where experimentation is encouraged and innovation occurs. Companies with strong Edge capabilities have an incredible knack for flourishing along the edge of the markets they serve, the products they create, the services they offer, the geographies in which they participate, or the resources from which they draw. The Apple iPod, iTunes, and iPhone are all innovations occurring along the edge of what was the Apple core market (excuse the pun!). Perhaps more than any other company, Google has learned how to detect, attract, and cultivate “edgy” people – people who creatively dream up new ways to solve problems that result in improved internal effectiveness or external service offerings. The Edge can stimulate and refresh the Core, keeping it vibrant and relevant in the marketplace.

Unfortunately, the very constructs necessary to establish a healthy Core become sticking points in creating a thriving Edge – something I’ve posted on frequently in this blog. Core’s are locked down, standardized, secured, designed to “prevent bad change.” The Edge must be open, agile, innovative, and designed to “foster good change.” How can a traditional company leverage the emerging Web 2.0 technologies? How can you unleash the Core by Innovating the Edge?

I’ll post more about the agenda, and even a link for folk to sign up for the event – please consider this an early notification.

In the context of business-IT maturity, a common sticking point is the rigorous systems development methodology.  These are just about essential to get beyond the lowest maturity levels (to reduce the chaos of systems development without rigor and discipline) but if they are obsessively and universally applied to all types of development, they tend to stifle innovation and experimentation.

I’ve felt the same way about the so-called “quality methods” such as Six Sigma.  While these are essential for bringing order to chaos, applied blindly and with quasi-religious zeal, they can limit growth and development, and, in many cases, limit innovation.  And unfortunately, the ways in which many companies introduce methods such as Six Sigma are very prone to this, with their cult-like trappings and high priests with colored belts.  Sigma Madness, or, as one of my clients said, “Death by a thousand belt-qualifying projects!” is not an uncommon malaise.

To this point, I loved the latest posts by Cognitive Edge on Putting Six Sigma back in its box … and The Context of Error.  The traps are beautifully articulated and nicely illustrate the potential tensions between the rigor and discipline needed for “preventing bad change” versus the management practices needed to “create good change” as quality guru Joseph Juran used to say.  I also admit to being tickled by the “Sick Stigma” Spoonerism!

To be clear, I don’t think there is any conflict between the notions of quality (especially as articulated by author Robert Pirsig in his classic Zen and the Art of Motorcycle Maintenance, and his lesser known Lila: An Inquiry into Morals) and innovation.  It’s the mindless, obsessive application of rigorous methods such as Six Sigma that I am questioning.

Anyway, Idris Mootee on one of my favorite blogs, Innovation Playground wrote this post on The Problem With Stage-Gate Process With Experience Innovation.  Although he’s writing about innovation more broadly than for the role of IT, I think the post applies beautifully to the IT world, and is a great example of a sticking point trap.

I’ve seen many cases where a rigorous and well-intended stage-gate process was introduced in a low maturity organization, and helped them increase maturity through a more-disciplined approach to development.  But as they tried to inject a more innovative spin to their discovery and development efforts, were stymied by the stage-gate process.

Please read Idris’s excellent post for a great perspective on why that happens.  Then consider, “Are our development processes ‘innovation friendly’.  Do they allow for the kind of program, rather than project approach, and for experimentation rather than ‘avoid risk at any cost’ mentality?”

In our multi-company research WebEx call earlier this week a participant reflected on the changing attitudes to “Shadow IT” – that term IT professionals give to non-IT professionals when they ‘step into their IT professional turf’ and do stuff that should have been ‘better left to the professionals.’

The Shadow IT phenomenon is a great example of what I’ve referred to in the past as ‘sticking points’ – things you need to do to drive Business-IT Maturity from Level 1 to 2, but that if you keep doing, will stick you at Level 2 – in fact, you almost literally have to ‘undo’ them to get to Level 3.  Let me explain.

At lower Business-IT Maturity Levels, Shadow IT is by and large, bad news.  First, it’s typically a business response to a need that the IT organization is not fulfilling – i.e., it’s symptomatic of a problem.  Second, because it is typically IT activity that happens ‘in the shadows’, it often does not have the integrity or recoverability characteristics that a ‘professionally built’ solution would have (at least, in theory!)  Third, given this, after a time, the ‘one-off’ solution created by Shadow IT evolves into a mission critical system, and gets handed to the IT organization with a plea for, “Can you please sort this out and maintain it from now on?”  This sometimes creates a problem because the solution was developed by a non-supported or non-standard technology.

So, typically in late level 1, the CIO goes Stalinist and demands that all IT budget and resources be centralized under his or her control.  This allows rationalization and consolidation, and generally helps elevate maturity into the Level 2 space.  In parallel with this, the architecture group gets empowered, principles and standards are declared, technology roadmaps produced, and IT architectures created.  Welcome to Level 2.

The paradox, however, is that to get to Level 3, the power of ‘end user computing’, for want of a better term, is critical.  That’s where most of the business knowledge lies, where the business problems are felt most intimately, and where most of the ‘arms and legs’ are.  And, given that Level 2 created all that fine IT and Enterprise Architecture with supporting infrastructure, it is now possible to safely unleash the Shadow IT monster!  Rather than see Shadow IT as an evil to be tempered, it must now be seen as a force to be harnessed and directed.

You can see the challenge – in a relatively short period, perhaps 18 months or 2 years, something that was treated as a pariah must now be cherished and nurtured.  This creates a kind of mental whiplash that most people can’t easily absorb.  But I believe that you have to manage through this see-saw to get to Level 3 and the business value that is unleashed at Level 3.  Recognizing this phenomenon, and being able to dialog about it is half way to solving it.

Yesterday I suggested a refinement to the single, continuous “S” curve Business-IT Maturity model, to one comprised of a series of “S” curves, with discontinuities between them.  I think the refinement is more than trivial, and certainly not simply cosmetic.  I’ve blogged before on the notion of Level 2 “sticking points.”   These are behaviors and characteristics I’ve noticed in my research and consulting work where things done in order to raise business-IT maturity from one level eventually become inhibitors or limiters to reaching the next level.  The fact that the shifts in maturity level are in reality shifts from one computing paradigm to another, and are therefore discontinuities, helps explain why practices and behaviors that might be necessary to climb through one level of maturity might not be appropriate to climbing through the next.

I wrote yesterday about the old mainframe computing paradigm of the 1950′s through the 1980′s was largely associated with custom applications programming.  Yes, there were application packages, but they were not widely used (certainly, not the ‘norm’ and were typically so heavily customized as to behave more like custom programs than like vendor packages.)  From the early 80′s through today, mainframe computing gave way to the client-server paradigm, and while custom application development is still commonplace, the majority of companies today use vendor application packages for many of their core business processes.  Early in this paradigm shift, IT shops struggled.  The methods they had evolved over years of trial and error no longer worked.  Think of requirements gathering and waterfall development methods.  Applied to implementation of the major ERP packages such as SAP and Oracle, these methods just did not work – often leading to heavy package modifications and customizations, with their resulting software maintenance challenges.  Also, companies who modified packages to fit their processes failed to take advantage of ‘leading business practices’ – they got the software implemented, but did not get the benefits of efficient, effective business processes.

Today, companies are starting to move from the client-server paradigm, where vendor application packages are commonplace, into an Internet-based ‘cloud computing’ with On Demand computing, Service Oriented Architecture (SOA), Software as a Service (SaaS), Open Source and the rise of Web 2.0.  My bet is that these companies are going to experience similar types of discontinuity as they figure out what from the old paradigm (client-server, vendor application packages) is transferable to the new (cloud computing, SaaS), and what new practices are needed for the new paradigm.  Recognizing that we are entering a paradigm shift, and figuring out all that that entails is going to be a critical aspect of ‘crossing the chasm’ from Level 2 to Level 3 business-IT maturity.

In later posts, I will explore some of the characteristics of the client-server to cloud computing discontinuity.

[Note on the graphic - I was looking for an interesting image for this post, and came across the prism graphic above, thanks to Google Images and a search for 'discontinuities'.  Given my penchant for rock 'n' roll, and love of Pink Floyd, I could not resist the resemblance to the "Dark Side of the Moon" album cover.  If we're all too busy to stop and listen to the music, at least we can reminisce on one of the more iconic pieces of cover art!] 

Mark Runta posted recently on the question Are You Chasing Perfection?  He asks an important question, and makes a powerful point.

I see many IT organizations that, in the interests in getting from Business-IT Maturity Level 1 to Level 2, try for perfection, and elimination of any possible risk.  This becomes one of the sticking points I’ve referred to in the past - the drive for perfection becomes a trap that will (a) get you from Level 1 to Level 2, but (b) keep you at Level 2!  You have to recognize and act on the difference between preventing bad change and fostering good change.  This is parallel to the dynamic between continuous process improvement (six sigma, et al) and process re-engineering.

To get to Level 3, IT organizations need to get comfortable with “good enough”, with rapid iteration, with experimentation and with risk management as opposed to risk avoidance.  With many IT professionals inherently uncomfortable with ambiguity, this is a mindset shift they are going to have to work at!

From time to time I’d like to raise questions on this blog that I think are fundamental to improving IT capability in general, but also more specifically to accelerating the journey through the business-IT maturity curve.  I’m especially interested in the “sticking points” people experience on the journey – many of them found at the the middle of Level 2.

This blog is not intended in any way to represent the BSG Alliance Research Team, Project Participating Companies or the Research Program – it represents my personal views, and hopefully, will generate some interesting heat and perhaps a little light on how to keep enterprise IT capability up with or even ahead of demand.

Question for today:

Let’s consider supply maturity – what are you finding as “sticking points” where it feels like you are bogged down in Level 1 or Level 2 IT supply maturity? 

I’m going to be taking the research participants through a member roundtable on this question on Friday, so any thoughts prior to then will be input to the process.

We’ll look at demand-side maturity questions tomorrow.