Category Archives: Supply Maturity

Maturity of IT supply of IT capability

Digital Business and the Fate of the IT Organization


Social-MediaInformationWeek just published an excellent article titled “Goodbye IT, Hello Digital Business.” The article presents a compelling case for “Digital Business” as a lens into what the more information and IT-savvy companies are doing. It presents some good case studies from Digital Business leaders in the retail industry. It also presents some interesting statistics on emerging platforms for building customer ties, on the main opportunities for today’s CIOs and how IT teams are interacting directly with customers.

Are IT Organizations Asleep at the Digital Switch?

I found the statistics InformationWeek presented as both believable based on my consulting experience, and disturbing! The numbers reinforce the facts that:

  • The majority of IT organizational focus and energy continues to be consumed by legacy solutions, keeping the metaphorical “lights on and trains running on time.”
  • The IT organization typically does not play a major role in business innovation.
  • The IT organization is slow to enter the world of mobile computing.
  • Many IT staff don’t have the customer-facing skills and business knowledge to play in the emerging Digital Business space.

The statistics indicate a move in the right direction – no surprise there.  But the shift is slow – rewarding the early movers with the advantage of a differentiated experience for their customers and for their employees – especially for those IT staff that are involved in these frontier applications. The early movers, through business experimentation and studying success stories are building their digital capabilities.

Accelerating the Shift

Exploiting Digital Business is not just about innovation, agile channels, mobile computing and social media – it has profound implications for the IT organization and its context – the IT Operating Model. I’ve posted before about how IT Operating Models must change for what I called Enterprise 2.0 – aka, Digital Business.  (See here and here.)

Some companies are accelerating the shift through IT Transformation programs – reorganizing, rethinking IT processes and value streams, re-skilling the IT organization and, in some cases, radical outsourcing initiatives. Other are using ‘skunkworks’ approaches to learn and build credibility through early business experiments. Some have the most progressive and promising Digital Business initiatives happening in the shadows – outside the purview of their IT organizations. I find that to be a dreadful indictment of the IT leadership! If that is not a wake-up call for a new CIO, I don’t know what is!

Digital Business is Literally Business-IT Convergence

I’ve posted before on the concept of Business-IT Convergence. In many respects, Digital Business is all about the convergence of IT with the business – business products and services become digital, and IT capabilities – historically located in an IT organization – converge with business capabilities. Some IT professionals and leaders will see this as very threatening. Others will see it as the solution to many perennial problems associated with the ‘us’ versus ‘them’ of the business-IT relationship.

What do you think? How is Digital Business impacting your work life?

Image source courtesy of Devicix

Related articles
Enhanced by Zemanta
About these ads

How Good are your IT Capabilities and How Good do they Need to Be?


This will be the first in a series of posts about assessing the “goodness” of IT capabilities, both in terms of your current state (how good your IT capabilities are) and ‘desired’ state (how good they need to be).  We will get into the dimensions of ‘goodness’ as well as assessment methods.

I’ve been designing and facilitating IT capability assessments for over 20 years, and have conducted hundreds of them – both as part of multi-company research projects that generated a substantial base of assessment data, and through individual assessments as part of consulting engagements. Over that time, I’ve developed a number of assessment principles I’ve found to be important.

The Process Is More Important Than The Results

There are several aspects to this.

  1. People don’t like being assessed, but they love being part of an assessment process!  By and large, people like to know how they are doing, especially from an organizational perspective.  But they are mistrustful (rightly so!) of consultants or other ‘agencies’ that come in and assess them or their organizations.  So, I’ve always taken an approach where I am a facilitator of a self-assessment process.  I bring the process (which the client and I may agree to modify to accommodate specific contingencies), experience to help them through the process, and act as an impartial ‘judge‘ to resolve differences of perspective, opinion or interpretation.
  2. The process must be transparent.  If people don’t understand or buy into the process, they will never buy into the results!
  3. The process should be repeatable.  Like a meaningful scientific experiment, the process should lend itself to repetition with consistent results.  In fact, repetition over time may well be important to sustained investment in capability improvement activities.  Too many assessments are conducted, discussed and then swept under the table.  This is a travesty!  Not only is the assessment wasted effort, but it may also be that much harder, or even impossible, to get people to participate in future assessments.  “Why should I bother – the last time we did this it went nowhere!” is a fairly common refrain.

The Results Must Be Actionable

The results should let you know:

  1. What needs to be done to improve capability performance.
  2. Where the greatest urgency lies for capability improvement.
  3. What it will take for a given IT capability to be improved, and to what benefit.

The Results Must Be Multi-Dimensional

This actually gets to the question of “goodness.”  I believe there are three important aspects of “goodness” as it relates to IT capability:

  1. Performance – this gets to efficiency – what resources it takes to achieve a given result.
  2. Value – this gets to the effectiveness of an IT capability – what benefits are being derived from the capability.
  3. Health – the ability to perform and deliver value over time.  We’ve all seen heroics, where, for example, a project team moves mountains in the final weeks of a project by working 20 hour days, 7 days a week.  It’s a wonderful thing to behold, and sometimes is necessary and may even promote ‘good health’ for the organization as people pull together and participate in a ‘miracle’.  But it’s not sustainable.  Expecting people to perform at a sprint when the course is a marathon is both dangerous and demotivating.

Process-based Assessments Only Go So Far!

We are all familiar with the SEI CMMI type maturity assessment.  These typically assess a capability’s maturity as somewhere along 5 levels:

  1. Initial
  2. Managed
  3. Defined
  4. Quantitatively Managed
  5. Optimizing

I believe maturity assessments such as this are appropriate for capabilities that are heavily process-dependent.  These include IT operational processes – highly predictable, repeatable processes.  But, drawing from Henry Mintzberg‘s discussion of standardization many years back, (see Mintzberg’s “Structure in Fives: Designing Effective Organizations”) not everything demands standardization of work processes.  If the goal is to make work consistent, repeatable, predictable and of high quality, there are three approaches:

  1. Standardize the work processes
  2. Standardize the outputs – i.e., the deliverables from the process
  3. Standardize the skills – i.e., focus on the people and their training

Typically, all three types of standardization apply to varying degrees – the mix being a function of the nature and complexity of the work you are doing.  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 illustrates 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, training and performance support systems are more appropriate.

For more on the different approaches to standardization, see my post, “Are Your Processes Setting You Free?  Or Holding You Back?“

Please join me for the next post in this series where we will drill further into assessment dimensions and processes.

 

Graphic courtesy of Take On Torah

Enhanced by Zemanta

Questioning the Role of the Business Relationship Manager


I’ve been deeply into understanding and developing the role of Business Relationship Manager (BRM) since the early 1990′s when, as a Partner at Ernst & Young’s Center for Business Innovation, I began researching what was then an emerging role.  Since then, I’ve continued research into this important role, led many consulting engagements helping companies implement or improve the performance of the BRM role, and have been on the faculty for several global BRM development programs.

More recently, I’ve been a co-moderator of the Professional Business Relationship Manager Group on LinkedIn.  This has been a fascinating experience for me – some very interesting dialogs surface from time to time, and the diverse opinions and approaches to the BRM role become ever more evident each day.  Also, the sheer growth of this group over the last couple of years is remarkable, and speaks to the growing importance of the BRM role.

What is a Business Relationship Manager?

First, it is important to understand that this is a role, not a job title.  In fact the job titles for people who fill this role vary enormously.  Adding to the confusion around titles, “Relationship Manager” is a common title in banking, and we get a lot of applications to join the LinkedIn group from banking officers – not the intended audience!  Also, a number of pure “sales” jobs call themselves “relationship managers.”  I don’t have a problem with that, but it’s not the focus of the BRM group.

Second, the ways that the BRM role is implemented varies significantly.  Sometimes it is a sole practitioner – other times, the BRM leads a small team (anything from 1 or 2 business analysts to a larger team, including architects and even developers.)  Sometimes the BRM reports to the IT organization – typically as a direct report to the CIO.  Other times, it reports to a business leader – perhaps with a dotted line relationship to the CIO.

No matter what the variations in organization and structure, the common thread across BRM implementations is an interface between business and IT.  The common goal (though expressed and measured in myriad ways!) is to increase the value realized from IT investments (typically, new initiatives), assets (usually current systems and infrastructure) and capabilities (the services and products offered by the IT organization.)

This “interface” responsibility implies two ‘faces’ of the BRM role:

Representing the Business to IT

This is one of the BRM ‘faces’ – representing a given business unit (or units, or business process, or geography) to IT.  In this regard, the BRM’s primary role is in shaping and surfacing business demand – always with an eye to maximizing the business value of IT investments, assets and capabilities.

Representing IT to the Business

This is the other BRM ‘face’ – representing IT to the given business unit(s).  In this regard, the BRM’s primary role is in supply management – ensuring that the IT organization understands business needs and expectations, and is delivering against those expectations.

But, What is the Real Rationale for the BRM Role?

Implicit in the many debates I see in the BRM community (and behind some of the failures I see in making the BRM role successful) is the question:

What is the most important aspect for the BRM to focus on – demand management or supply management?”

There is no easy answer to this – it really is a function of both supply and demand maturity.  But, I will make some assertions based on a great deal of experience:

  1. If supply maturity is low (i.e., basic IT services are unreliable, unpredictable, unstable, unclear) the BRM role will almost certainly fail.  It cannot add real value, spends it’s time apologizing for IT and making excuses, and is quickly seen by the business partner as “overhead.”
  2. If supply maturity is moderate (i.e., basic IT services work well, but capacity is highly constrained, projects take too long to deliver and are prone to delays) the BRM role has to play a careful balancing act – stimulating and shaping demand while living within the constraints of supply.
  3. If supply maturity is high (i.e., a well regarded IT organization that delivers basic services and project work; that has ‘elastic’ supply that can flex with demand and can deliver with ‘agility’) the BRM role can and should focus almost exclusively on demand shaping and surfacing.

Of these three situations, scenario 1 is the most treacherous for the BRM.  It’s essentially a losing proposition.  My advice to clients is, “Don’t put BRM’s in place – fix the basic services first!”

Scenario 2 takes a great deal of finesse.  The temptation for the BRM is to either try to fix the problems of supply, or shield the business partner from those problems.  Fixing supply is best done with those on the supply side who are responsible and accountable for IT supply.  If you put the BRM in that role, they can’t be effective in their demand management role.  Once their business partners see them as part of the supply side, the BRM loses their credibility as valuable demand shapers.

Why would I invite you to my leadership team strategy retreat – you’re the person who’s fixing IT services!” might be the reaction of a business leader to a BRM who has asked to join the business unit’s strategy formulation retreat.

On the other hand, shielding the business partner from supply side woes is also a trap – what I refer to as “colluding with dysfunctional behavior” which is never a good idea!

Scenario 2 also takes great skill with the discipline of ‘value management’ – understanding how IT investments, assets and capabilities lead to business value – making sure that the constrained supply is working on the highest value possibilities, ensuring that low value requests do not get through the intake process and that value is actually ‘realized’ – felt and seen by the business.

Scenario 3 is the ‘holy grail’ for the BRM.  Unfortunately, by the time IT supply has reached that level of maturity, so has business demand, and the BRM role may be redundant.  But that’s a story for another post…

Enhanced by Zemanta

COBIT – Good News… Bad News!


COBIT is described by its creators, ISACA, as a “Framework for IT Governance and Control.”  Celebrating it’s 15-year anniversary, COBIT provides an excellent framework for helping bring IT under control.  In ISACA’s own words:

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!

Enhanced by Zemanta

Do You Have IT Organizational Clarity – Part 4


This picks up on Part 1, Part 2 and Part 3 in this series on IT Organizational Clarity.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.

In Part 3, I described the three different types of IT Capability – Value Chain, Aligning/Governing, and Enabling, and why the distinctions among these types is important.

In this final post in the IT Organizational Clarity series, I will discuss an IT Capability Assessment Framework.

An IT Capability Assessment Framework

There are four dimensions of IT Capability that contribute to IT performance and organizational clarity:

  1. Purpose – the degree to which the goals, values, desired business outcomes and guiding principles are defined and understood by those contributing to or benefiting from the Capability.
  2. Commitment – the degree to which organizational relationships and commitment are demonstrated in terms of sponsorship and clearly defined accountabilities.
  3. Ability – the degree to which baseline processes, structure and competency requirements, enabling technologies and measurement approaches have been established.
  4. Accountability – the degree to which criteria for success and related performance requirements have been defined and communicated.

Note, that each of these dimensions comprise lower level assessment attributes.

Hierarchical Nature of Assessment Dimensions

Also note, there is a hierarchical nature to the four dimensions.  Clarity of purpose for a given capability is needed to gain management commitment to that capability and to establish the organizational relationships – for example, between the capability, its providers and its customers.  Management commitment, in turn, is needed to ensure the abilities are in place for the capability to perform.  With clarity of purpose, management commitment, and the components of ability in place (i.e., defined processes; clear roles with clear competency requirements; appropriate tools and technologies; service providers organized, ready, and able to provide service; charging and cost allocation mechanisms) then accountability (performance management and consequence management) can be meaningfully defined and assessed.

The Mechanics of Capability Assessment

I have always found the assessment process to be as important, or even more important, than the results.  Towards this end, I’ve adopted a couple of principles when helping clients with IT Capability Assessment:

  1. Follow a facilitated self-assessment approach i.e., get the right people in the room and facilitate them through the assessment process, so that the results are their results, and the insights as to what should be compared with what is are theirs to understand and ultimately, to act upon.
  2. Assess against an anticipated future state – “What is our capability to deliver against the IT vision and anticipated demand?” rather than “How are we doing today?”  Ultimately, it is the future ability to deliver that matters, and people tend to be less defensive when they are assessing their ability to handle tomorrow’s needs as opposed to how they are doing today.

The other ‘mechanical’ question is the level of granularity at which to assess.  There are two degrees of freedom, here.  One is, the scope of capability.  You can imagine, for example, assessing an entire IT capability as a single unit (not very helpful!) More realistically, assessing the 8-10 top level capabilities that comprise the entire IT capability.  Or assessing the 8-10 sub-capabilities comprising any one of the 8-10 top level capabilities.

You can also adjust the level of assessment – for example, assessing against the four dimensions (Purpose, Commitment, Ability, Accountability), or assessing against the lower level attributes, such as Service Definition, Goals and Guiding Principles.

Figuring out the scope and level of assessment is part art, part science.  In general, start at the highest reasonable level, then drill down as assessment findings indicate a need to drill deeper.  I typically start with one assessment for the IT Value Chain capabilities (discover, deliver, sustain), and one for each of the Align/Govern and Enabling Capabilities – this usually means 7 or 8 assessment sessions.  I typically allow 2 hours per assessment, and try to conduct the assessments with teams of 8 to 10 people, representing individuals from the capability being assessed and from related enabling or aligning capabilities.

Similarly, I usually start with the top level dimensions, but make sure that the assessment teams have access to descriptions and definitions of the lower level attributes.  If we are unable to come quickly to consensus at the top dimension level, we will drill down to the underlying attributes.  Experience with a relatively small number of assessments will give you a feel for appropriate scope and depth.

It’s Not About the Assessment – It’s About Identifying the Gaps to Close!

While the assessment process itself can be extremely enlightening, assessment itself is not the end – it is a means to the end.  The key to an assessment is to gain clarity on where the biggest gaps are, in order to move from assessment to improvement.

 

Enhanced by ZemantaGraphic courtesy of Asia Society

Do You Have IT Organizational Clarity – Part 2


My previous post introduced the topic of IT Organizational Clarity, discussed common symptoms arising from a lack of Organizational Clarity, and suggested two dimensions through which clarity can be assessed and improved:

  1. Bounding scope by defining “IT Capabilities” at an appropriate level of granularity. (Units of analysis).
  2. Defining meaningful and assessable characteristics for IT Capabilities. (Means of assessing and improving).

Note – the ultimate gauge of IT Organizational Clarity is in the ‘health’ of the IT Organization and the business results to which it contributes.  However, there are all sorts of demand-side complexities in assessing these things, so for now I will focus on the notion of capability maturity as a worthy proxy for and predictor of end results and the ability to continuously improve.

In this and the next couple of posts I will discuss the notion of IT Capabilities and how best to define them.  I will then address the assessable characteristics of IT Capabilities.

What Is an IT Capability?

In order to adequately define an IT Capability, we need to clarify a couple of common terms – Service and Process:

Service

A Service in the context of IT Capabilities is best described as the interface point between a provider and a consumer where value is exchanged.  Services should be defined from the perspective of the consumer.  They need to be ‘discoverable’ and the service interface understood by the consumer.  They need to have clarity on what they do, what they cost, how they are invoked, and how problems are reported and resolved.  The service provider should have a good understanding of the value received by the consumer, as well as the overall quality of the customer experience.  This may comprise both tangible and intangible elements, most of which are ultimately subjective.

Process

A Process is a sequence of interdependent and linked procedures which, at every stage, consume one or more resources (employee time, energy, money) to convert inputs (data, material, etc.) into outputs.  These outputs often serve as inputs for the next stage until a known goal or outcome is reached.

Capability

A Capability can be thought of as everything it takes behind the scenes that makes a service possible.  This will include:

  • One or more Processes.
  • Descriptions of the Roles needed to perform one or more of the procedures within a process (e.g., Project Manager, Business Analyst, Relationship Manager).
  • Descriptions of the Competencies needed to perform a given role (what the person performing the role needs to know, e.g., business knowledge, what skills they need, e.g., facilitation, and what behaviors they should exhibit, e.g., results orientation).
  • An adequate supply of competent human resources filling the given roles.
  • Tools and technologies needed to automate or execute necessary processes or procedures.
  • Management systems necessary to ensure the health and performance of the Capability, including funding, organizational will, personal incentives, and so on.

How Many IT Capabilities Should You Have?

This is a tricky question to answer.  First, of course it depends on the mission to be served by a given capability.  But more importantly, this is a question of granularity.  In the heady days of business process re-engineering, I learned that picking the right granularity for an end-to-end process is crucial, and perhaps as much art as science.

I think this question has more to do with the characteristics of and limitations to the workings of the human mind than anything else.  If you end up with, say, 3 IT capabilities, chances are that you are at too high a level of granularity to be really useful in terms of analytical and management discipline.  On the other hand, if you have 12 or more IT capabilities, you are at too low a level.  From my experience, between 7 and 9 is the right number of IT Capabilities to have in a ‘top-level’ IT Capability model.

How Many Levels of Decomposition Should You Go To?

Yes – you guessed it – it depends!  On the basis that you really don’t understand a Capability unless you can see a level of decomposition below it, I think the answer is at least two levels of decomposition are necessary.  Beyond that, it depends on the Capability you are trying to understand or improve.  Consider, for example, the Process aspect of an IT Capability.  Capabilities that are highly procedural, such as those found in IT Infrastructure and Operations, will typically need more levels of decomposition (i.e., more detailed process definitions).  Coincidentally, this is the domain of ITILv3, so you can effectively ‘buy’ process definitions and a process architecture off-the-shelf.

On the other hand, a Capability such as Opportunity Discovery may be more about analytical skills and the magical space between problem understanding and solution definition.  This space is much more about specially-skilled people and specific business domain knowledge rather than sequential, detailed and rigorously controlled processes (as in Statistical Process Control.)

We will pick this up in the next post and look at three different types of IT Capability  – Value Chain Capabilities, Aligning/Governing Capabilities and Enabling Capabilities – and examine the distinctions between these and why the distinctions are important.

Graphic courtesy of MassBay Organization Development Learning Blog

Enhanced by Zemanta

Do You REALLY Have Effective IT Processes?


chickenprocessFrom time to time, we conduct IT capability assessments for our clients.  These typically examine two different kinds of capabilities – those IT capabilities that are largely owned and executed by the IT organization, for example:

  • Manage the IT Infrastructure
  • Deliver Business Solutions
  • Manage the IT Organization

They also (and sometimes, of great significance) assess those IT capabilities that are jointly owned by business and IT, such as:

  • Manage the Business-IT Portfolio
  • Manage Business-IT Relationships
  • Manage Enterprise Architecture

Capability vs. Process

An important element of capability is the concept of process.  Processes tell you how work should be done, where inputs come from and outputs go to, what results should look like and how they should be measured and evaluated, how efficient and effective the process is, and how it should be evaluated and improved.  Capabilities bring in the dimensions of people and technology that use processes to get work done.

Some capabilities (typically those whose primary value proposition is Operational Excellence) require rigorous and robust process definitions.  For example, this is the primary domain for frameworks such as ITIL and COBIT.  Other capabilities, where the value proposition is Customer Intimacy or Innovation have a far higher “human content” requiring special competencies and judgment.  In these cases, processes may be less rigorously defined, but they are still important, even if only in the form of a checklist for the major steps, entry and exit criteria, and examples of the deliverables they create or outcomes to which they are intended to lead.

The distinction between capability and process is important for many reasons.  I sometimes find myself in debates with clients along the following lines:

We have assessed that your (fill in the blank) capability is low – not in place or only partially in place.

Which garners the client response:

That’s wrong – we have processes and artifacts to do (fill in the blank) – it’s fully in place, or at least mostly in place!

To which we respond:

You might think you have a process, but the people who’s role it is to deliver the capability associated with that process either don’t know about it, or are ignoring it – the net result is, you don’t have the capability maturity you need for (fill in the blank)!

The Characteristics of Real Process

So, how do you know you really have processes that are driving (or at least, shaping) behavior?

  1. Do you have a process definition that is known by and used by impacted stakeholders?
  2. Is it defined at a level appropriate to its purpose?
  3. Does it provide “best practice’ examples of input criteria, exit criteria and deliverables for each major step?
  4. Does it clearly spell out all roles associated with each given step?
  5. Do those roles call out or point to descriptions of the competencies (knowledge, skills and behaviors) needed to satisfy a given role?
  6. Are there outcome and in-process metrics and are these used to drive continuous improvement?
  7. If a new person, once familiarized with the formal process, stepped into the work mid-flight, would they know what to expect (and would find) what work has been done so far, and what steps need to be performed next?
  8. Do you have approaches to assure that key process steps have been followed (risk management)?

Some Questions to Reflect Upon…

So, think about your major IT capabilities:

  • For which ones do you really have good processes?
  • Where are your biggest gaps?
  • What would you gain if you closed those gaps?
  • Would it help with communications – internal to the organization and with your business partners?
  • Would it help clarify roles, responsibilities and accountabilities?
  • Would it help clarify the ‘rules of engagement’?
  • Would it make work more predictable and more easily repeatable?
  • Would it help identify non-value adding steps and activities, or missing roles?
  • Would it enable process improvement and innovation initiatives?
  • Would it help bring new employees or partners up to speed more quickly – accelerate ‘time to value’?
  • What would that all be worth?
  • What’s standing in the way of doing it?

How Marketing-Savvy is Your IT Organization?


marketingI find marketing to be a tricky subject for the IT profession – there are some fine lines that can be easily crossed, and it’s not a discipline that IT organizations have typically been founded upon.  Project management, business process reengineering, infrastructure – these are more likely than marketing prowess to be among the core strengths of most IT shops.

But marketing is an important discipline in which IT should develop some competence, for several reasons:

  • The ways that the Internet and digital tools can impact a business’s marketing capabilities, and the integration of these capabilities into the entire customer acquisition process, are multiplying and changing fast. The IT organization needs to partner proactively with marketing and sales functions, and with the customer acquisition process owner.  If the company has not yet moved to a managed process approach to the demand chain, IT leaders must educate business leaders and help take them in this direction.
  • Contemporary business analytics and simulation technologies play a key role in understanding market segments and characteristics, and especially how these are changing.  Whether established as part of the IT organization or elsewhere, business analytics and business simulation Centers of Competence need to be established and encouraged, and IT has a key role to play in enabling these functions.
  • Regardless of the role of IT in business marketing efforts, the IT organization itself, in many companies, would benefit significantly by adopting selected leading practices from marketing and customer experience  – from understanding its own market segments for IT products and services, to creating an environment where those products and services are “discovered and bought” and used to great effect, to creating consistently excellent customer experiences for recipients of IT services.

In the opening paragraph above, I mentioned “fine lines” and I want to highlight one of those with an anecdote.  I recall a CIO client, who, in the interests of raising internal business partner awareness of IT accomplishments and to give them a better sense of what the IT organization was working on produced a 50 page glossy “IT Annual Report” rich with charts and graphs, and nicely illustrated.  When I interviewed business executives as part of an IT capability assessment I was involved in, this IT Annual Report surfaced frequently.  Unfortunately, the impact had been the opposite of what was intended.  “IT is clearly overstaffed and insensitive to their impact on corporate overhead if they are putting together expensive puff pieces like this!” was the common complaint I heard about the report.

I think a couple of things were going on here.  First, the CIO misjudged the mood of his internal market.  This was an environment that had been through some significant IT challenges under prior leadership (including a major outsourcing initiative that had failed miserably and had been recently “undone”).  The general attitude was that “IT costs too much and delivers too little!”  No wonder the IT Annual Report was greeted the way it was.  To the uninitiated, this looked like a very expensive piece of marketing collateral.  (I’m sure it actually was not expensive – it was desktop published, spiral bound, with most of the charts and graphs generated out of a project and portfolio management tool.)  In my experience, these types of IT Annual Report work best in an environment with high business and IT maturity.  Even then, a more marketing-savvy IT group would better understand their audience, and would produce a document that spoke to that audience – in this case, about the business, in business terms, with simple descriptions of how IT played a role, and perhaps suggestions of how to find and pursue more opportunities for value creation enabled by information and IT.

Another common marketing mistake made by IT organizations is thinking of marketing as simply “public relations, advertising and promotion.”  Good marketers begin by understanding the markets they serve (or should be serving).  What are your primary and secondary market segments?  What do they need from IT – in terms of baseline expectations (table stakes), like to haves, and things they do not even know they need, but will “wow” them?  This type of Kano analysis can yield invaluable insight into the IT customer base – as it is today, and, more importantly, as it could be tomorrow.  Very often, the analysis will reveal that the customers we are closest to (we know each other well, have a comfortable relationship with them) are not where IT can have the greatest impact.  What are we doing to reach deep into those customer segments where we don’t have a strong relationship?

I know – the last thing most IT leaders wants to hear is about some new competency or capability they need to develop!  I hear you remind me, “Everyone is working flat out, under increased budgetary pressures, and we’re ony just keeping our heads above water.  We don’t need to be getting into new stuff!”  But, the reality is, marketing disciplines are essential to ensuring your are truly delivering the right services in the right ways to the right people – and that is surely an even more critical need today than it ever was?

IT in a Recession – What’s Different this Time?


dolphin Like most of us, I’ve been thinking about the current economic climate and its implications for IT leaders.  I posted back in early September in The Economy, Information Technology and Opportunity Creation that it is now more important than ever to find creative and constructive ways to drive growth and innovation by whatever means.  I’ve also bemoaned the fact that many CIO’s have taken an alternate approach – that now is the time to hunker down and lay low.  In my post A Tale of 2 CIO’s: Proactive Innovator vs. Reactive Operator I drew the distinction between two types of IT leader – “Cecil the Controller” and “Ivan the Innovator.”  The former essentially is inclined to hunker down and “do no harm” when the financial conditions get tough, while the latter sees the financial conditions as a challenge that is best addressed head-on – proactively looking for ways to stimulate growth and innovation.  For them it’s a time for IT to shine, not to retreat deeper into the shadows!

We’ve been in recessions before, and the innovator versus controller behaviors – ever present – do tend to stand out during such times.  I guess the appropriate variation on the old cliche is “When the going gets tough, tough CIO’s innovate!”  Anyway, the question I’ve been pondering lately is, “Is there anything different with this recession that should influence IT leadership behaviors?”  The familiar knee jerk reaction of “take out costs” – stop discretionary spending and be the responsible corporate citizen by cutting IT costs might deserve a second look.  Here’s what I’ve come up with so far.  What’s different this time?

  • If you have been a responsible IT leader, you’ve already done the reasonable cost cutting and cost take-out measures, and run an efficient IT operation.  Cutting any further is likely to cut into bone and muscle rather than fat.  Is the best thing we can say about IT that when money is tight, we should do less of it?  My problem with the knee jerk reaction is it reinforces the perennial perspective that IT is only a cost to be contained, rather than an investment to be leveraged.  This time, and under current global economic climate, it seems to me that finding growth and business innovation (be it process, product or service innovation) is a better strategy – a more constructive IT response.
  • But, you’d better be able to prove the investments are going to pay back in a time frame that is consistent with business needs.  Therefore, robust business cases, a clear business-driven IT portfolio strategy and ongoing portfolio management are essential.  Similarly, superb program management and a real focus on value realization become key.  As is rapid business experimentation and analytics.
  • This time you might be able to get into or accelerate the use of SaaS and Cloud Computing – these approaches are inherently less capital-intensive, and, arguably, lead to lower operating costs.
  • For those that have not already done so, you might need to get more serious about global sourcing – not just as in outsourcing, but as in leveraging temporary and contract workers, retirees, and the growing body of unemployed who will be happy to work for lower rates than might have been the case 6 months ago.  Unlike in other recessions where the IT ranks felt almost immune, this time around there are many well qualified people out there in the unemployment lines – and with life saving perhaps seriously depleted, they are hungry for work.
  • This is a great time to take advantage of the “air cover” that the economic climate provides and get really aggressive and focused on ‘weeding and pruning’ – rationalizing and consolidating the legacy environment.
  • This time most companies have the basic infrastructure (broad band web access, desktop videoconferencing, services such as WebEx and LiveMeeting to support virtual work arrangements.  Given that much of the IT operating cost base is people, it might be worth getting creative about not only facilitating, but proactively encouraging alternate work arrangements (e.g., work from home, work part time).  People may be willing to give up some base pay to take advantage (including cost savings plus green benefits) of work-at-home arrangements.
  • Some IT expense is depreciation – with many companies coming off several years of capital investments, you might need to get creative about moving assets off the books. This was one of the forces driving outsourcing 15 years (or so) ago, and it may be worth exploring some creative (though legitimate) financial schemes.
  • Some organizations have been improving IT service levels year over year, and are now in a situation where service levels are higher than is truly needed.  You may therefore need to reassess and re-balance service levels/demand constraints. (e.g., take help desk response times from 15 min guarantee to 1 hour.
  • Lastly, Web 2.0 and all that it means (cloud computing, SaaS, etc.) promise a relatively quick and easy way to find and conduct experiments in business innovation and collaboration, without the investment and effort of building all the infrastructure and developing a whole bunch of code.  For many companies there is a potential gold mine in the application of social networking to business growth and innovation.  Now is a great time to look hard and identify opportunities to connect with employees, customers and the company ecosystem in new and productive ways.

IT Pros – What Will Become of Them?


Ben Worthen had a great post last week in the WSJ Business Technology blog entitled “Tech Pros: The Next Dinosaurs?”  Ben cites Nucleus Research’s Rebecca Wettemann:

It’s the logical consequence of two interrelated trends: the average worker becoming more tech savvy, and tech companies realizing that appealing directly to workers is as – if not more – important than appealing to IT management… There was a time when IT departments could get away with forcing employees to use complicated and hard-to-use software. The average worker didn’t know that better alternatives were out there. But as workers gain experience with consumer-focused software – either in their personal lives or at the office – they’re starting to realize that software can be easy to use and quick to get started on. It started with productivity boosters like instant messaging and collaboration software, but it’s crept into the realm of software that’s traditionally the realm of IT departments, such as sales automation.

In the language of Business-IT maturity often cited on this blog, I find that business demand in general is maturing quickly, and IT supply, as defined in terms of the collective supply (hardware, software, services) is maturing alongside demand (perhaps just slightly ahead of demand).  However, if we consider IT supply through the lens of any particular IT organization as opposed to collectively, then to Ben Worthen’s and Rebecca Wettermann’s point, progress is not so rapid or so obvious at many IT organizations.  I’ve referenced before that some IT shops seem to be stuck in time warp – in an age of mainframe programming and big ERP application packages, of taking orders from business partners and delivering against those orders, no matter what the potential business value.  Innovation and collaboration are not seriously visible on their agendas, and notions of measuring business value of IT investments are as foreign as notions of flying saucers and apparitions.

It is the IT pros in these low maturity shops – especially those without a real ambition to drive up both business demand and IT supply maturity that I fear for.  They are becoming the dinosaurs.  They evolved in a time when you could get by with a fairly weak set of IT capabilities, and lay the blame on the business for “not getting it!”  I come across many such IT pros who are cruising along with an ‘entitlement’ mentality.  I have never been more convinced that their time is limited.  They will be the ones that will be outsourced, off-shored and ultimately, will have a hard time staying actively employed.