Tag Archives: CMMI

IT Maturity and the Changing Mix of People, Process and Technology – Part 2


I posted earlier on the way that the mix of attention to people, process and technology change as business-IT maturity increases.  I will continue that thread here.  As a reminder, below is a graphic representation of the people/process/technology mix in a low business-IT maturity organization.  Note that the technology dimension is dominant, and the people dimension is minimal.

picture21

picture31To the right is a picture of the mix typical of a mid-level business-IT maturity organization.  The relative emphasis on technology had dropped somewhat, and the emphasis on process – both business process that is the object of automation efforts, and IT process as the means to manage and improve the work of the IT organization.  Also, the emphasis on people – on the IT professional and on the people aspects of managing organizational change has increased relative to the meager attention this received at lower business-IT maturity.

Typically, in a mid-level business-IT maturity shop, the almost dominant emphasis on technology skills and issues prevalent in low maturity IT organizations has been counterbalanced with process skills and attention to process issues.  This may or may not be via a programmatic approach such as “lean” or “six sigma”, but it’s real and it’s important to the work of the IT organization – both in terms of the type of work that is done, and how it is done.  In terms of work type, there is far more attention to processes analysis and process reengineering of business processes that are being automated.  In terms of how IT work is done, there is more attention to formal, consistent, documented processes.  This is especially true in the “IT factory” processes associated with data center operations, networks and help desk support.  Sometimes this is via programmatic approaches such as ITIL, COBIT or CMMI, or via Six Sigma or other process quality methods and techniques.

In mid-level maturity shops, the people dimension gets far more attention that it does in lower maturity organizations.  This can be seen in the form of improved performance management, competency development, career planning approaches.  It can also be seen through increased attention to the human aspect of people and technology change – increased attention to the organizational change management issues.

picture4In high business-IT maturity shops, the relative balance of technology, people and process has shifted even further away from technology and more in favor of process and people.  In such companies, the IT organization may well have become the enterprise center for Six Sigma or for process and quality improvement.  It may well have become the center for Program Management and for Organizational Change Management activities.

Typically, high business-IT maturity organizations have become masters of global sourcing and inter-enterprise processes.  It is not unusual to find the CIO has now evolved to the head of global shared services, or has global responsibilities for one or more core business processes such as supply chain.

So what does all this mean to you as an IT professional or IT leader?  Think about your own organization.  Are you giving sufficient attention to people and process issues?  How has the balanced changed in the last 3 to 5 years?  How should it change in the next year or so?  How will it change?  If not as much as it should, why?  What are the barriers?  What can you do to remove those barriers?

About these ads

Forget Maturity Models?


 forget-it-forget-me-1962-roy-lichtenstein-133898.jpg

A colleague just pointed me to a ZapThink post last month entitled Forget Maturity Models−It’s time for an agility model.  It turns out the types of maturity model ZapThink would like us to forget are CMMI and any SOA maturity model.  They don’t specifically call out the Business-IT Maturity Model that has been a recurring theme of this blog since I started it in October 2007.  That’s fortunate, because for me, saying “forget the maturity model” would be tantamount to saying “forget breathing”!

ZapThink makes a valid point when they argue that, “companies flock to maturity models…  without adequately understanding what they are meant to measure.”   They further argue, “Does the measure of maturity factor in the average of all the activities in the organization, the most advanced, or the least advanced? Does the maturity model measure the company organization-wide, on a department-by-department basis, or on a per-project basis? Without understanding what the maturity model measures, it’s hard to say if it truly is any real measure of maturity.”  I believe these are all valid questions.  A useful maturity model should be able to be applied to a company, an organization, a department, or any unit of analysis.  They keys here are:

  1. Figuring out the “question behind the question.”  i.e., What maturity are we trying to assess (e.g., business demand, IT supply, solution delivery? )  If we knew the answer, what would we do about it? (e.g., are we assessing to understand?  to make a comparison? to motivate improvement?  to communicate?  to gauge progress?) 
  2. Identifying the appropriate “unit of analysis.”  i.e., For what domains? (e.g., department, business unit, business process, enterprise?) 

ZapThink goes on to argue that what is needed is, “a way of measuring the state of a SOA implementation against the fundamental goal of SOA itself: agility.”  I think this is valid, although I think the goal of IT is to enable business agility and innovativeness – SOA is a means to that end.  Characteristics of mature business demand tend to be “faster, cheaper, easier, and more agile.  As such, IT supply needs to aspire to meeting this demand, and SOA, among other means such as global talent sourcing, continuous learning and development, rapid experimentation and business simulation, agile policies, are all ways to achieve this.

ZapThink raises the crucial question, “how does one measure Agility?”  They suggest seven “degrees of freedom” that are applicable to a given system.  These are a useful starting point, and are supplemented by a robust literature on dimensions and characteristics of agility.  The nature of your business strategy and competitive environment will probably suggest which agility dimensions are the most critical to your context.

So, I think ZapThink raises some good points – agility is an increasingly valued attribute, and IT can be a powerful enabler, or a restricting limiter of business agility.   And a good maturity model should help you figure out where you are in realizing the goals of agility, and what you can do to become more agile.  But “forgetting maturity models” does not seem to me to be good advice – quite the contrary!

Improve or Innovate?


My last couple of posts have been on ITIL, where I presented my argument that approaches such as this (and CMMI) are necessary but not sufficient to take Business-IT Maturity to the next level.  They are necessary because they help build a solid foundation for IT operations and services.  They are insufficient because they typically don’t lead the the kind of breakthroughs in IT performance that most enterprises need, and in turn, they don’t position most IT organizations for the kinds of business innovation that IT is capable of enabling.

I will draw upon some of the early work of the quality movement – Joseph Juran and Edwards Deming in particular.  (My apologies for not being able to provide more precise references – I just don’t have them handy at the moment.)

improveinnovategraph4in.jpg

First, at the risk of stating the obvious, continuous improvement (TQM, Six sigma, etc.) is mostly about taking a process (or product) and improving its performance.  It is a mostly incremental approach (though the increments can be quite significant if the process was way out of control).  Innovation (what Juran referred to as ‘breakthrough’) is a much more radical approach.

Today, when we innovate a process, we often call it re-engineering.  It is, by definition, not incremental, and performance gains can be orders of magnitude.  Juran proposed a cycle of improvement and breakthrough as indicated on the chart above – improve it until the marginal effort is no longer justified by the marginal performance gain, or until a new technology or method promises significant gains from a new way of doing things.   Once the innovation (innovated product or re-engineered process) has be introduced, shift back to continuous improvement methods to stabilize and incrementally improve the new product or process.

This improve/innovate cycle can be applied to products (or services) and processes.  IT organizations need to develop strong competencies in all four quadrants of the figure below – both as these apply to IT processes and products (or services) and to business processes and products (or services).

improveinnovate4in.jpg

The competencies, management styles, methods, and organizational approaches to improvement versus innovation are quite different.  As the IT industry moves from Web 1.0 to Web 2.0, from ERP to Software as a Service, from process improvement and integration to collaboration, process and product innovation, methods such as ITIL and CMMI are “table stakes” for playing in the business innovation space with significantly higher business value.

Why ITIL is “Necessary but not sufficient”


My post yesterday claimed that ITIL is necessary, but not sufficient for reaching Level 3 Business-IT Maturity.  As anticipated, this has led to a fair amount of traffic, some showing up as commentary on the blog, others showing up as email messages from various vendors of Service Management and ITIL support services.  I therefore want to expand upon and defend my position on this.

In so doing, let me be clear – intelligently implemented (i.e, without becoming an end in itself, and as part of a well-orchestrated IT transformation plan) ITIL is very useful – especially in its v3 incarnation.  As with CMMI, I’m a supporter, although I have seen both CMMI and ITIL “madness” reminiscent of the Malcolm Baldrige award and Deming Prize madness of the mid-90′s when companies drove themselves into or near bankruptcy in pursuit of a prize, while taking their metaphorical eyes of the business ball.

A while ago I posted on Business-IT Maturity and the Portfolio Lens.  In addressing the ITIL issue I want to revisit one of the core concepts from that post.  First, drawing from Professor Peter Weill’s excellent work on IT Portfolio Management, I repeat below his portfolio model showing 4 classifications of IT investment types.

weill-pfm-model_4in.jpg

In this model, we can think of Infrastructure as the underlying enabler, just as roads and railways enable us to travel, work, play, and so on.  The things we do on that infrastructure include the day-to-day necessities of processing repeated transactions – taking orders, paying vendors, managing customers and so on.  Just as with the roads and railways, we can do the daily mundane activities of getting our groceries, and getting to and from work.  We can also leverage that infrastructure for higher value endeavors such as managing information, supporting collaboration, enabling decision support, etc.  I guess the road analogy equivalent might be getting the kids to and from school, participating in social activities, be they worship or a visit to the gym.

The highest potential value in Weill’s model he calls ‘strategic’ – the things we do to drive business growth.  These are generally risky – they have a risk of failure, but when they win, they win big, and might actually become essential to business operations.  At the risk of pushing my road analogy too far, this might equate to launching a new courier service, or perhaps renting out mannequins so single people can take advantage of High Occupancy Vehicle lanes.  Yield management as first introduced by American Airlines Sabre unit gave them such a competitive advantage that now all airlines, and in fact, hotels and other businesses with similar characteristics use yield management – it’s almost become part of their infrastructure – and is certainly an integral piece of how a reservation transaction is processed.

Anyway, with some ‘poetic license’ I think there is a mapping between Weill’s IT Portfolio classifications and Business-IT Maturity, as illustrated below.

b-it-plus-weill-pfm-model_4in.jpg

Level 1 Business-IT Maturity is all about getting the IT infrastructure “right.”  Level 2 is about getting the firms transaction processing systems and core business processes “right.”  And Level 3 brings to the table business analytics, collaboration, innovation and leveraging IT to drive growth.  Bear in mind, this is a simplification of reality – some Level 3 activities do take place at Level 1 – but it’s a slim minority – not where the IT organization is primarily focused.  Also bear in mind, this is a maturity model – the Level 1 and Level 2 needs never go away.  But they become relatively ‘mastered’ and allow management attention and focus to shift to higher value activities.

Back to my hypothesis about ITIL, CMMI and other process (or service) management disciplines – they are very helpful in climbing through Level 1 and Level 2 Business-IT Maturity – but they won’t get you to Level 3!  I’ve explored elsewhere in this blog, and will continue to do so, what my research and client experience is teaching me about what will take IT organizations to the lofty heights Level 3 maturity.  There’s a trap in believing that approaches such ITIL or CMMI are going to be the “silver bullets” for driving up IT maturity and value – unfortunately, they aren’t!

When IT is Your business – Not Just a Support Function


I’ve acknowledged previously that companies where IT essentially isthe business (think Amazon, Google, et al) mature very differently than do IT organizations that are essentially supportfunctions (think most traditional businesses, even most financial services companies that are highly information intensive).  We’ve seen this in our SOA research – and this was a pattern I saw in my early days in the world of software development automation.  While “embedded IT shops” where IT was a support function were struggling with, and by and large, rejecting advanced development methods (e.g., object oriented development, programming workstations), software companies were embracing these same methods.  There’s a related theme if you look at where the real CMMI Level 5 shops are found – I’d argue that few, if any, are found in embedded IT shops.  (There’s a whole other debate about whether embedded IT shops should strive for Level 5 CMMI, but let’s leave that for another post!)

Anyway, I was reminded how important this was as I was reading an excellent piece in the October Harvard Business Review, called The Institutional Yes - an interview of Jeff Bezos. (Yep, I’m behind on my reading backlog!  Blame it on blogging!)

At a first glance, especially early in their early development, Amazon could have been mistaken for an on-line book merchandising business.  Clearly today they are much more than that, and Information Technology is the business- it has enabled them to evolve rapidly, experiment broadly, adapt with agility, and, most importantly for stakeholders, grow value exponentially.  They have now moved into their “developer-facing” business, making their internally developed tools available to third parties.

Based on the interview, one can see all sorts of Next Generation Enterprise characteristics at Amazon – and can infer relatively high Business-IT Maturity.  They don’t view their IT capabilities as “support functions” or a cost center.

It’s interesting to see how different strategy development (and associated strategic change) is at Amazon compared with “traditional” businesses where IT is a support function.  I think there are many lessons to be learned here about the ultimate role IT can (should?) play in any businesses (Barnes and Noble thought they were safe until Amazon came along!)  I also think there are lessons that connect Next Generation Enterprises with Business-IT Maturity (alluded to elsewhere in this blog).

I’m going to start teasing out these lessons in some upcoming posts on “the theory of the case” in IT maturity and the Next Generation Enterprise.  The key question is, how do you get to that level of business-IT convergence?

Business-IT Maturity and the Portfolio Lens


I was with a client recently as their CIO was leading one of their regular “town hall” meetings (live meeting for those in HQ, videoconference for those elsewhere).  He was talking (eloquently!) about Next Generation Enterprises, Web 2.0 technologies and the implications for their company and for their IT / shared services organization.

A question from the floor asked if ITIL (Information Technology Infrastructure Library)was incompatible with the move towards becoming a Next Generation Enterprise (NGE).  It’s an interesting question.  It is easy to perceive NGE’s as chaotic, emergent, free-for-alls - characteristics that seem to be at odds with the rigor and process discipline inherent in approaches such as ITIL, CMMI, 6 Sigma, and so on.  There can seem to be all sorts of inconsistencies and ambiguities in the idea that, on the one hand, we are implementing all this process discipline, while on the other, we are moving to a world of rapid experiments, open networking, emergent teams, and all sorts of loose collaborations, both within the enterprise, and with customers, suppliers and the outside world.

As is often the case, I find the Business-IT Maturity lens helpful in sorting out this apparent dichotomy.  In this case, I want to add another model that I find helpful in thinking through these issues, and then combine the models.  First, as a reminder, below is a version of the basic Business-IT Maturity Model that has been central to many posts on this blog.

bus-it-small.jpg

Business-IT Maturity Model

Next, I want to consider an IT portfolio model.  The model below comes from Professor Peter Weill at the MIT Sloan School.  It is a very useful portfolio view that classifies IT spend (or investment) into infrastructure (common and shared IT capability), transactional, informational and strategic.

2075304175_6bb851c15f1.jpg

IT Portfolio Model

This model divides IT spend (or investment, depending upon how it is being used) into 4 classifications.  To a degree, Level 1 Business-IT Maturity is all about getting the right IT infrastructure capability.  Level 2 is about getting the right transaction processing capabilities in place.  And Level 3 is about the strategic and informational IT capabilities.  Again, I realize this is a crude approximation, but it helps us to realize what types of IT investments we should expect to focus on as we move through business-IT maturity, and how the shape of the IT portfolio might change with that maturity journey.  Putting the portfolio model on top of the maturity model creates the following picture.

mat-plus-pfm-small.jpg

IT Portfolio Mapped Against Business-IT Maturity

So, the IT portfolio can be something of a proxy for business-IT maturity.  Compared against ‘average’ infrastructure spend, a Level 1 organization will be higher than average.  Compared against ‘average’ transactional spend, a Level 2 organization will be higher.  And compared against ‘average’ informational and strategic spend, a Level 3 organization will be higher.  Now there are many issues that can distort this simple view.  If your transaction processing systems are a mess of dozens of different instances of disparate systems, you are probably at Level 1, but will have inordinately high transactional spend because of all the complexity in your transactional systems.  So, higher than average transaction spend may be more a symptom of lack of Level 2 attention, than a byproduct of Level 2 investment.

Finally, back to the opening question – are ITIL and NGE approaches incompatible?  No, not all all – they are focused on very different capabilities.  ITIL will help improve Level 1 and Level 2 IT capabilities, but do little to nothing for Level 3.  If you are moving into Level 3, you need strong Level 1 and Level 2 capabilities, which leverages techniques such as ITIL and CMMI.  But these same techniques will not get you to Level 3.

More on the Sticking Point


As I get ready for a week’s vacation in Aruba (lots of Scuba diving and time with my family!) I want to explore a couple of more aspects of the “sticking point” that I see IT shops bogging down in as they mature from Level 1 business-IT maturity towards Level 3.  The sticking point is at the inflection point in the middle of Level 2.

I talked in the last post of the shift in Enterprise Architecture from an IT-out, bottom up perspective, to a business-in, top down perspective.  This is the type of shift that does not work by just “working harder at EA” or by throwing more resources at it – it takes a significant shift in approach.

Getting out of Level 1 into Level 2 is mostly about rigor and process discipline.  Process Management, CMMI and ITIL are the types of formal disciplines that bring order to the chaos of Level 1.  These all make sense – in fact, are essential (these, or similar process methods) especially given that much of the work of maturing from Level 1 is about cleaning up the IT infrastructure (“getting the trains to run on time” or “keeping the lights on” as the metaphors go) and implementing enterprise solutions (ERP, for example).

The trick in getting through Level 2 and to Level 3 is not so much to throw out the disciplines that got you out of Level 1, but to apply it in a much more selective and gentle handed way.  The types of business problems and solutions that are common in the higher reaches of Level 2 and dominate Level 3 are more about business experimentation, and less about rigorous formal specifications and requirements management.  While project management continues to be a foundation skill, program management and IT portfolio management become key in Level 2 and the Scientific method becomes an important alternative to requirements management.

The “Level 2″ Sticking Point


I believe that the major inflexion point comes at the middle of Level 2.  The things you have to do to get from Level 1 to Level 2 are quite different from the things you must do to get from Level 2 to Level 3.  The Business-IT Maturity model is a learning curve and the middle of Level 2 is the steepest part of the curve.  The good news – progress in that middle space can be fast.  The bad news – it’s literally an uphill struggle, fraught with ambiguities and elusive shifts in IT’s role and direction that IT professionals typically don’t like.

 

If getting from L1 to L2 is about bringing order to the chaos – simplifying IT infrastructure, centralizing control over IT spending and standards, establishing credibility for project results and service performance, implementing strong process disciplines – then the L2 to L3 journey is about living with complexity, fostering self-service, decentralizing control and empowering the network.  If Level 1 to 2 is internally focused, and IT-driven, then Level 2  to 3 flips to external focus and business-driven. 

The mid-point between L2 and L3 (I estimate that about 70% of businesses in North America are here today) is a point of discontinuity.  Consider learning to crawl, then to walk, and then to run.  Once you can crawl, it’s no use trying to crawl faster and hoping to walk!  It’s no good trying to learn how to run by walking faster.  The movements are different, require different skills and bring different muscles to bear.  Similarly, the good and important disciplines you’ve introduced such as consistent project management, ITIL processes and CMMI based improvement programs that helped you get to mid-L2 will not get you to L3, and may actually impede progress.  All those disciplines are optimized for traditional transactional systems solutions and applications – the stuff of Level 1 and 2, not for collaborative, web based and groupware solutions – the focus of Level 3.

It is important to remind ourselves that as a maturity model, this is cumulative – the Level 1 and 2 demand never goes away, so the processes and disciplines needed to be effective in managing and satisfying those types of demand are important to sustain.  However, in order to stimulate demand for Level 3 capabilities, and to satisfy that demand, new disciplines must be learned, and some older disciplines must be applied with a careful hand.  An example – the Level 1 to Level 2 shift typically requires a far more rigorous approach to business cases, often achieved through sophisticated templates and NPV analyses.  Now, imagine this Level 3 scenario:  A business executive comes into work one morning bubbling with an idea she had in the shower about a novel way to incorporate RFID into the companies supply chain.  She calls her friendly IT relationship manager and explains the idea.  He says, “That’s great!  Now, here’s the business case template.  You have to figure out the lifecycle costs and value, and complete these 12 pages of project definition.  Let’s meet in a couple of weeks, and we can go through this.”  Two weeks later, the executive, with no idea how to estimate the value of an innovative business capability, and daunted by the 12 page template, decides maybe the idea was not that great after all, and drops it!

The problem here is that getting from Level 1 to 2 requires a more disciplined and consistent approach to framing, prioritizing, and driving transactional solutions.  If those same methods are applied to the more innovative possibilities that are the focus for Level 3, they will die on the vine.  The Level 2 to 3 journey requires more of a “portfolio” based approach – portfolio management for all IT investments, and a portfolio of project and program prioritization and approval methods, each suited to the types of investment being considered – infrastructure, transactional, information, and innovative, for example.

Business-IT Maturity – a helpful lens for the future?


The Next Generation Enterprise (NGE) is highly (totally?) dependent upon IT.  A rich and robust infrastructure, user friendly tools, on demand web services, on demand processing capacity and storage space are merely table stakes for tapping the next generation of collaborative, social networking, and marketing capabilities.  IT organizations need to partner with business units and functions in new ways.  Business and IT need to have the skills to collaborate and converge in news ways – finding opportunities for product, service and process innovation.  The massive burden and resource drain from legacy systems and technologies, which often consume 80% or more of the IT budget, must be reigned in so as to free up funds and resources for the new sources of business value that are available to NGE’s.  And yet, this is proving elusive for most businesses – especially those with a long history and the associated “legacy” environment, including infrastructures, systems, skillsets and, above all, mental models about the role of IT.  Why is this proving so challenging?

Business-IT Maturity Model

Maturity models can be very useful.  I think Richard Nolan was one of the first to propose a Stage theory for IT management back in the 60′s.  The Software Engineering Institute has contributed much to comtemporary best practice with a Capability Maturity approach, and its current manisfestion CMMI.  Maturity can be a great lens or perspective through which to understand the journey to 2017.  The highly simplified Business-IT Maturity Model above separates business demand (the business’s “appetite” for IT) and IT supply (the enterprise’s ability to satisfy that demand) and explores how they mature over time, and how they are mutually dependent.  Business demand at any point in time is a complex function of industry characteristics, market forces, business vision and leadership, and many other variables.  Capital Markets (e.g., investment banking and brokerage houses) and high technology companies tend to have high demand maturity – in the financial services case, information and IT are at the very heart of the business, while in the high tech case, rapidly evolving business models (think Dell and Google, for example) are highly dependent upon agile IT infrastructures.

Business demand is also a function of IT supply – low supply maturity will constrain business demand.  For example, an IT infrastructure that is unreliable and hard to use will tend to dampen the business appetite to leverage IT for business innovation and for collaboration with customers and partners.  Typically, if business demand gets too far ahead of IT supply, there will be a change of IT leadership.  On the other hand, if IT supply gets too far ahead of business demand, IT will be seen to be overspending, resulting in a change of IT leadership.  The most common patterns are that at Level 1, business demand leads IT supply; in Level 2, IT supply tends to ‘catch up’ with and overtake demand, and in Level 3, demand and supply are closely aligned. From the perspective of late 2007, we see the majority of companies at mid-Level 2, some at high Level 2, and a minority at either low Level 3 or high Level 1.  Why are so many at mid-level 2, and seem to be struggling to get to the next level?