Tag Archives: Operating model

Is IT Organizational Confusion Exacerbated by the Role of Business Relationship Manager?


I received a question from a reader about the role of a Business Relationship Manager (BRM).  I decided to bring the question and my response to this blog.

His question, and the context for it was:

When the BRM role was introduced at our organization, the Head of IT did not convey a clear vision or direction for how the new role would fit into the existing IT organization structure.  We did not have clarity on how to deal with the issues that are brought to surface by the BRM, or how the BRM should work with Business Analysts, Project Managers and other key roles.  Please share practical examples of how a typical BRM should operate on a day-to-day basis.  What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?”

His email went on to say:

I feel that a lack of clarity and appropriate structure and governance of how a BRM is to operate within an existing IT organizational structure will result in a muddle and confusion for IT colleagues and ultimately fractured relations with the business/customers.”

New Organizational Roles Disrupt the Status Quo

My first observation is that you could substitute any major new role for the specific BRM issue above and have the same potential for organizational confusion.  I’ve seen this with the introduction of Business and IT architects, Program Managers, Service Managers, Product Managers, and so on.  Sometimes the new role gets introduced with limited clarity as to its purpose – rather it feels like “the thing to do”.  Often, the catalyst for the new role is something like:

  • Someone in an influential position has read about or came from an organization where this role reputedly worked miracles – “We should try this here!”
  • There are recurring pain points (e.g., a ‘noisy’ or dissatisfied business customer) – “Let’s put Jill into a role to face off with this customer and see if she can reduce the noise!”
  • Something doesn’t feel right about the current organization structure – “Let’s introduce a new role and see if that improves things!”  This is akin to the proverbial moving of deck chairs aboard the Titanic!

Implications of New Roles

Whatever the catalyst, there are a couple of important contextual characteristics to note here:

  1. Lack of clarity about the rationale for the new role – what problem(s) are we trying to solve and how will the new role solve them?
  2. Unclear expectations about what the outcomes of the new role should be (for example, picking up my readers question, “impact to have made in 3, 6, 12 months and who should see/feel the impact?”)
  3. Failure to fully consider changes that must be made to the IT operating model.  Presumably, the new role is taking over some Responsibility and/or Accountability from other roles, and that other roles need to be Consulted or Informed by the new role.  Note, the initials I’ve capitalized – RACI – the (hopefully) familiar tool for clarifying and assigning roles and responsibilities.

Unclear New Role + Unclear IT Operating Model = Total Confusion!

So, what we have here is a new role being introduced with a lack of clarity as to why, or how, into an organization that already has an unclear Operating Model.  In the past, we somehow managed to ‘get by’ with the unclear Operating Model because:

  1. We have bright, hard-working people who work at ‘smoothing out the bumps’ caused by lack of Operating Model clarity.
  2. They’ve been at this for a while, so unless there’s an unusual disruption to the status quo (such as a new role being introduced), we manage to limp along ok.

Answering the Tough Questions

My reader asked for “practical examples of how a typical BRM should operate on a day-to-day basis.”  With due respect to my reader, it’s the wrong question.  You can’t solve the problem by defining how a BRM operates.  The real question is, “How should the IT organization operate on a day-to-day basis with the introduction of this new role (the BRM)?” i.e., “What is our next-state IT Operating Model?”  I’ve posted many times on the components of an IT operating model, how to define one, how to implement one, and so on.  Enter IT Operating Model in the search box at the top – you’ll get about 40 posts on this topic representing 30 years of IT management consulting wisdom shared over 5 years of blogging!

My reader also asked, “What impact should a BRM expect to have made in 3, 6, 12 months and who should see/feel the impact- is it for the IT department and its behavior or how business begins to engage with BRM?”  The first part of this is totally dependent upon the organizational context – and especially on business and IT maturity.  But it is the right question, and the BRM should be working with the IT leadership team defining the hoped-for impact and how to track it.

It is also important to consider possible unintended consequences of a new role’s introduction.  For example, I worked with a global multi-billion dollar company who carefully introduced the BRM role.  They picked their “best and brightest” to fill the BRM position, and we developed a robust training program and toolkit for the BRMs.  Unfortunately, they were so effective at surfacing, stimulating and shaping business demand for IT, that they quickly exceeded supply capacity.  The BRM’s found themselves saying “no” to the same business executives they’d worked with to surface that demand.  If the expression “getting egg on your face” has any meaning, this was getting an entire chicken farm all over yourself, with lashings of excreted waste!

To the second part – who should see/feel the impact – I’d say that if there’s no positive impact to the business customer, then why bother with the BRM (or any new) role?  And inevitably, the IT department will feel impact – disruption initially, but over time, greater efficiency (“doing things right”) and effectiveness (“doing the right things”).

So, What To Do?

Again, this is a topic I’ve visited many times over the years on this blog – click on Organizational Change Management on the tag cloud to the right of this post for a collection of posts that more or less deal with this issue.

There’s no easy formula here – it’s about motivating change.  This is highly contingent on organizational context, relationships, and other factors specific to a given environment, but there are some common elements:

  1. Find ways to surface the pain of the status quo to those with the organizational power and authority to initiate the change – what the quality movement calls “the cost of quality”.  Use the process of surfacing this pain to build a guiding coalition of stakeholders who want and will benefit from the change.
  2. Find ways to clarify and sharpen the vision of the future state – the remedy to the pain of the status quo.  How will the introduction of a BRM role improve things?  What will this look like – after 3, 6, 12 months?  What will the implications be for our IT operating model?  Again, leverage the coalition – get their input and ensure their buy-in to the future state.  Help them understand what they must do to help the change happen and the future state become real.
  3. Find ways to clarify the transition from the status quo to the future state – what’s the transition plan?  Should we start with one BRM and conduct a pilot?  Should we pull together an “IT Operating Model Improvement Team” to do a fast cycle (no more than 60 days) analysis and provide recommendations to the IT leadership team?

Image courtesy of Awakening Business Solutions

Related articles
Enhanced by Zemanta
About these ads

Does Cloud+Consumerization Doom the Federated IT Operating Model?


The Federated IT Operating Model is Under Threat!

Today, most organizations employ some sort of Federated IT Operating Model.  Wikipedia defines a federation as:

…characterized by a union of partially self-governing states or regions united by a central (federal) government. In a federation, the self-governing status of the component states, as well as the division of power between them and the central government, are typically constitutionally entrenched and may not be altered by a unilateral decision of the latter.”

Typically, enterprise-wide or common applications, initiatives and infrastructure are a centralized (federal) responsibility, while local applications and activities are under the control of business units or functions.  This “federal rights/states rights” model has infinite variations.  Definitions of “common,” “enterprise-wide” or “infrastructure” are subject to interpretation, and these tend to change over time, with changing business conditions, leadership, technology and other forces.  There’s also inevitably a “shadow IT” phenomenon – sometimes quite large – where much IT activity happens outside the realm of IT governance.

Just as in countries with a federal governance model, the competing forces between state and federal rights pull and push over time, leading to an ebb and flow of centralization and decentralization.  This can be healthy – like an accordion, making sweet music as the parts are squeezed together or pulled apart.  It’s never static, but constantly responding to the forces of change – just as all living systems “breathe” in some way or another, and have their seasonal variations.

But every now and again, new forces surface and combine together to disrupt the gentle ebb and flow – the so-called Arab Spring comes to mind.

The New Forces of Change

IT governance is undergoing such a confluence of new forces.  These include:

  • Cloud computing – it is easier, faster and cheaper (on the face of it) to leverage the cloud to host applications and provide IT services (e.g., storage, transaction processing, data analytics) rather than have your federal IT group provide these services.  Much of this activity takes place in the “Shadow IT” realm.
  • Mobile computing – more of us are doing more via smart phones and tablets.  This exposes us to mobile applications and the many “app stores” including Apple’s and Google.  Getting an app is as simple as clicking a button – and many apps are free, or cheap enough to add to your mobile phone bill without feeling any pain.
  • The shift in the personal computing operating system – from Windows, et al, which can be controlled by the central (federal) IT department, to technologies such as Apple’s iOS and Google’s Android which are much harder (perhaps impossible?) to control centrally.  The genie is already out of the bottle, and it’s not going back any time soon!
  • Economic climate – the economic climate facing most businesses, whether in the US or just about anywhere else is in the doldrums.  This keeps people scrutinizing costs, prepared to make short term economic moves, even if at the expense of the longer term, and trying just about anything to get “unstuck”!  Such a climate tends not to favor centralization and federal power (just ask President Obama’s campaign advisers!) but empowers local forces and factions.

Beware the Unintended Consequences

So, what to do about it?  Here’s three options:

  1. Take a laissez-faire approach – a path of least resistance.
  2. Push back, hunker down and reinforce the federal model with more controls and stronger sanctions for “shadow” behavior.
  3. Adopt a “mutual adjustment” approach that navigates the stormy waters to constantly find the optimal balance.

From my perspective and experience, Option 1 has potential (likely?) unintended consequences.  We saw this when many central IT groups were slow to respond to the emergence of the Personal Computer.  When they did respond, it was generally via Option 2 – they tried to constrain them.  That drove a lot of rogue and shadow behavior and set many companies IT efforts back several years.

For most of us, Option 3 is the practical and pragmatic solution.  Let’s face it, there are all sorts of unknowns in terms of how these forces will play out over time.  We need some form of centralized coordination of infrastructure. However, the terms “coordination” and “infrastructure” must be defined clearly and re-defined from time to time as we gain experience with cloud computing and consumerization of IT.  There is not a right and wrong here – but a critical need for organizational clarity so that you are setting the bounds of infrastructure clearly and in a way that is appropriate to the times and to your business context.

Seven Steps to a Mutually Adjusting IT Operating Model

I believe IT leaders must approach this in the same way they would approach any needed change:

  1. Create and “market” a compelling end state vision.
  2. Surface and “sell” the cost of status quo or of going down the wrong path.
  3. Define a credible and palatable path to the future.
  4. Enroll key stakeholders in joining together on that path.
  5. Engage selected key stakeholders in the governance model.
  6. Surface and celebrate successes along the way.
  7. Take action to discourage deviations from the path.

Image courtesy of Charles Ayoub

Related articles
Enhanced by Zemanta

Who Owns the IT Operating Model?


I get into some great conversations with readers of my blog – often, however, they are ‘offline’ – i.e., via email or by phone, rather than through comments on posts.  I’ve been in such an exchange that I’d like to bring to the blog.  It’s around the question of, “Who owns the IT Operating Model?”

What Do We Mean By “Own”?

The specific question I initially got from my reader was:

Who owns the IT Operating Model within the organization?”

My initial response got into the issue of what we mean by “ownership” of an Operating Model.

In terms of practical implications, I like to think of the IT Operating Model as being “owned” by the IT leadership team – often with specific responsibilities allocated by domain (e.g., strategy, governance, delivery) to individual members of the IT leadership team. If it means, “who is responsible for its creation and effectiveness”, I’d say it really is the CIO.

In a subsequent email, the reader clarified his question as:

Who owns and updates “the story” – the document that explains how the organization works.

He went on to give his view that:

This owner must most definitely understand the entire organization and be a “listener” for change because if something changes how the organization operates then the model must be adjusted. This owner must be at the table with the leadership as well. I thought whoever owns strategy and planning would be the most logical home for this information.

I thought his suggestion that the owner of Strategy and Planning should own the IT Operating Model was fine, but I added the following caveat:

The IT Operating Model owner must have the respect of the organization, passion around the IT Operating Model, and some good instincts and/or experience with managing organizational change.”

The IT Operating Model Is Not Just About the IT Organization!

The reader’s comment, “if something changes how the organization operates” runs the risk of missing the fact that an IT Operating Model should be a model for all aspects of Information Technology.  Increasingly, many elements of the model will be outside of the IT organization, so there is an important element of business access to and ownership of the IT Operating Model.  For example, self-service guides and policies around “Bring Your Own Device” (BYOD) lend themselves to being part of the IT Operating Model.

The IT Operating Model Is Not a Document!

But what really struck me about the reader’s questions was his clarification that he was trying to determine “Who owns and updates ‘the story’ – the document that explains how the organization works.”  In other words, the IT Operating Model should be expressed in a document.

Documents Don’t Work As Means of Expressing Operating Models!

Documents are a lousy way to express Operating Models!

  • Documents create organizational confusion!  Where is the document?  Is this the latest version?  Why is its content inconsistent with other documents?
  • Documents reinforce organizational silos!  Who needs to know this?  Who should own it?  Who should review it?
  • Documents proliferate and deteriorate over time!  Multiple changes that are hard to track, linkages that break, definitions and terms that become lost over time.
  • People are disinclined to “read” or “use” documents – especially at the “moment of truth” when they are most relevant/mot important/most needed!

Documents Don’t Work As Means of Improving Operating Models!

For all the reasons above, and many more, documents are a lousy vehicle for engaging people in continuous improvement.  That’s why Wikipedia chose a wiki as the ideal platform for engaging the world in its remarkable achievement in capturing human knowledge.

From Static Documents to a Living Wiki!

That’s also why my partner and I have been helping clients with IT strategy and/or Operating Model changes implement them through wikis.  As a wiki, everyone can participate in the use and continuous improvement of the IT Operating Model.  The model becomes elevated from an abstract concept to a management tool and capability!  For more on this, please check out the video presentation on this page.

Related articles
Enhanced by Zemanta

Do You Need an IT Operating Model?


This post was inspired by some recent discussion on the IT Operating Models Group on LinkedIn.  Pär Nilsson, the Group’s moderator, posted the question:

What do you see as the cornerstone of an IT operating model?”

This question created some interesting discussion, from the insightful to the disdainful (but accurate!) observation that:

Operating Model is one of those buzz phrases that can mean different things to different people.”

Every IT Organization Has an Operating Model!

One of the noteworthy aspects of the discussion was that several participants seemed to view an IT Operating Model as something you may or may not choose to have.  I think that’s wrong – all IT organizations have an IT Operating Model.  The only questions, for me, are the degree to which the IT Operating Model is:

  1. Effective? (i.e., delivers what the business needs in the most effective ways)
  2. Efficient? (i.e., makes the best possible use of assets and resources)
  3. Clear to all those that depend upon it? (i.e., stakeholders in and members of the IT organization)
  4. Healthy (i.e., continuously improving and sustainable)

Way Beyond the Organization Chart!

In many IT organizations, the only explicit manifestation of the Operating Model is an organization chart!  This is an incredibly limited (and limiting!) way of expressing an Operating Model.  It says who reports to whom, but not what gets done or how it gets done.  It tells you nothing about decision rights, key metrics or the portfolio of services.  It tells you nothing about needed competencies or rules of engagement between functions and groups, or between the IT organization and its clients/customers/partners.

So, wherever you are, you do have an IT Operating Model.  You might not understand it.  It might be implicit rather than explicit. It might be badly broken.  But you still have one or you would not be able to ‘operate’.

The Cornerstone is Context-Dependent!

My response to the initial question was:

I think that all depends on the business context and business demand maturity against IT supply maturity. For example, for some environments, IT processes are the cornerstone; for others, it is business-IT governance; for others it is figuring out the proper balance between IT services that should be shared across business units, versus those that should be embedded in business units.  Ultimately, all these aspects (and many more!) are key – but you can’t address them all in one go, so figuring out where to start is the first trick!”

The Keys Are Organizational Clarity and Health

So, I believe that the keys to IT organizational performance are:

  1. Defining what a healthy IT Operating Model would deliver – we might call this the IT Strategy
  2. Defining how a healthy IT Operating Model would deliver that IT Strategy
  3. Ensuring that the IT Operating Model is clear and transparent to its primary stakeholders

And I further believe that very best way to achieve these is to engage those primary stakeholders in:

  1. Clarifying the IT Strategy
  2. Clarifying the IT Operating Model
  3. Continuously improving the IT Strategy and Operating Model

Web 2.0, Anybody?

And it won’t surprise any of my clients, colleagues or regular readers that I believe that the tools, technologies and sensibilities sometimes referred to as Web 2.0 can be an excellent enabler of IT Strategy and Operating Model clarification and continuous refinement.

Graphic courtesy of Kinsale

Related articles
Enhanced by Zemanta

Do You Really Need an IT Transformation?


I’ve been part of many organizational transformations over 30 years of management consulting.  Most were with IT organizations, many were with HR organizations and some were transformations to global shared services.

I used to be excited by the idea of an organizational transformation.  When a client or prospective client used the word “transformation” I would salivate!  “Them’s fighting words!”

But nowadays, I generally shy away from the “t” word. Here’s why.

The Trouble With Transformation

There are several reasons why I don’t like the word “transformation”:

  • For most of the organization, it can feel demeaning, effectively sending the message, “You aren’t any good and you have to transform!”  That can be a bitter pill to swallow (and is almost always untrue – at least in part.)  Not the best way to enroll people in change!
  • From the perspective of 2012, most people have been part of at least one organizational “transformation,” – it was painful and ultimately failed to deliver on its promises.  Announcing yet another transformation typically elicits the response, “Here we go again!” Organizational transformations tend to promise too much and deliver too little.
  • Transformation implies a journey from current state to a future state by going through some kind of radical (transformational?) change.  Increasingly, organizations that are healthy, effective and growing in capability are in a state of constant change and adaption.  The current state → transformation → future state model no longer applies, so why delude ourselves and confuse everybody about having a transformation?
  • Transformations are highly disruptive. They are disruptive because they assume that someone (or group) knows what the future state will look like – “all we have to do is to transform into that future state from our current state!”

To this last point, the reality is that organizational behavior is way too complex for anyone to “know” what the future state will look like.  Perhaps, way back when, in the days of hierarchical, authoritarian organizations in the early industrial revolution, a determinist approach to operating model design was feasible – especially if you thought you were transforming into a future state that would then be ‘frozen.’  We may well know the characteristics we would like to see in the future state, and the kinds of behaviors we’d like to experience, but exactly how we will get there, and what our Operating Model (processes, roles, rules of engagement, governance, services, metrics, etc.) will look like is far less certain.

I think organizational and operating model design nowadays is more about emergence – point people in the right direction, then get out of their way!  To that end, we need to define that direction:

  1. Outcomes we’d like to see
  2. Capabilities we need to achieve those outcomes
  3. Processes, roles, competencies (i.e., knowledge, skills and behaviors) we need for those capabilities
  4. Management and governance systems

Then we need to:

  1. Over-communicate items 1 through 4 above – engage people in really understanding, co-developing and creating organizational clarity.
  2. Empower them to do what is necessary, make sure they have the right tools and infrastructure and get out of their way.
  3. Enable them with a meaningful way to participate in shaping their future – we have found that a semantic wiki can be a great vehicle to achieve this (see this post and the earlier posts (here and here) in the series).

Image courtesy of Wikipedia

Related articles
Enhanced by Zemanta

The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3


Example of Semantic Structure for an IT Operating Model

This is the 3rd and final part of a 3-part post.  (See Part 1 here and Part 2 here.)  This short series represents the culmination of 5+ years of work for my business partner, Roy Youngman, and me.

A Quick Recap

In Part 1, I discussed the frustration Roy and I felt with the state of management consulting, where the artifacts we’d leave behind (PowerPoint slides, Word documents, etc.) rarely became part of our client’s organizational fabric.  Also, the middle managers and the ‘troops’ who had to bring to life the strategies and operating models we were developing often did not get exposure to the work until relatively late in the day.  Because they had not been part of the work, they were slow to understand and embrace it.

I explained that we quickly recognized that the technologies and sensibilities of Web 2.0 and social media promised a better way to help our clients – a way that would engage broader and deeper participation by client staff at all levels, and would leave behind a ‘living, breathing’ IT strategy and/or IT operating model, captured as a set of wiki pages.  These pages were developed collaboratively with our clients, so the act of development and deployment essentially became concurrent – defining the IT operating model was part of deploying it, and vice versa.  We determined that a Semantic Wiki would be an ideal technology to support our consulting work – and more importantly, to provide a platform we could leave behind with our clients to empower their organizational collaboration and ongoing refinement and use of the IT strategy and operating model.

In Part 2, I went on to provide historical context for the wikis first introduction in 1995, and enumerated its strengths and weakness that were limiting IT organizations ability to collaborate effectively using traditional wikis. I went on to explain the concepts behind the Semantic Wiki and how these provided an ideal platform for enabling complex organizations such as IT, where multiple, different value propositions have to be supported.

Balancing Order and Chaos

IT organizations are surprisingly complex, supporting two fundamentally different value propositions:

  • Core capabilities comprising the critical processes, assets and structures that help run the day-to-day business
  • Edge capabilities where innovation, growth and change are cultivated

These distinct value propositions have Operating Model implications, requiring distinct forms of semantic wiki-enablement, as highlighted in Table 1 below.

Value Proposition

Example Capabilities

Needed Wiki Characteristics

Wiki Governance Model
Core
  • Operations
  • Service Management
  • Enterprise Solutions
  • Coherent integrated structure
  • Stable space
  • High integrity
  • Globally governed
  • Workflow controlled
  • Process Owner as key control point
Edge
  • Enterprise Architecture
  • Product Management
  • Departmental Solutions
  • Project & Team Spaces
  • Business Relationship Management
  • Idea Generation
  • Consistent modular structure
  • Agile
  • Support divergent discussion & brainstorming
  • Content can migrate to Globally governed
  • Domain governed
  • Workflow optional
  • Domain Owner as key control point

Table 1 – Types of Wiki Space

Globally Governed Space for ‘Core’ Capabilities

Core capabilities such as data center operations, service management and enterprise solutions (e.g., ERP systems) depend upon processes that are standardized, tightly controlled and centrally planned.  Management systems for these types of capability must focus on integrated, reliable, efficient processes and compliance to norms.

A wiki that supports core capabilities must be highly ordered and globally governed.  For example, each process should have a ‘Process Owner,’ with clearly defined accountabilities for maintaining and continuously improving their processes.  They need defined workflow mechanisms, for example, to control the promotion of a material change to a process page from ‘draft’ to ‘pending approval’ to ‘approved’ to ‘operational.’

Domain Governed Space for ‘Edge’ Capabilities

Edge capabilities, on the other hand, depend upon structures that are loosely knit, with agile processes that can rapidly adjust to entrepreneurial initiatives and fast-shifting technologies.   Management systems and organizational culture must foster new product success and the experimentation needed to get there.  Whereas core capabilities epitomize highly ordered environments, the edge represents the place where chaos and order meet and creativity blossoms.

A wiki that facilitates edge capabilities works best with limited structure and control, where, to paraphrase China’s Chairman Mao Zedong, “one thousand flowers bloom”.  Here the underlying semantic model will be centered on problem areas and the process of ideation, with Business Relationship Managers, Product Managers and Architects as the natural choice for the wiki’s points of control.

Today’s wiki platforms are helpful here, but we expect them to evolve to better support techniques such as brainstorming, innovation jams, mind mapping, and provide integration with tools for simulation and modeling, prediction markets, sentiment analysis and ‘light weight’ collaborative project management.

One Space – Two Wiki Models

IT organizational needs can be comfortably addressed in a single Semantic Wiki, with each value proposition having its own underlying semantic model and associated governance structure.   Having both ‘core’ and ‘edge’ capabilities supported in the same wiki space affords important benefits.  For example, everything is discoverable and linkable across the models.  These characteristics are all but impossible to achieve in a traditional document-centric collaboration approach.

If the primary goal of the core is to ‘prevent bad change’, a tightly structured semantic wiki with a robust governance model is a powerful way to support this goal and the organizations that must deliver against it.  If the primary goal of the edge is to ‘create good change’, a loosely governed semantic wiki with ‘sandboxes’ to generate and test ideas is a great way to support this goal.  Today’s leading wiki platforms, with their semantic extensions offer a single, integrated solution that can help drive IT organizational clarity and improve performance.

An Empowered, Continuously Improving IT Organization

Roy and I have found that encapsulating IT strategies and operating models in a semantic wiki has tremendous benefits that are simply not available in the more traditional approach some call, “death by PowerPoint!”  For example:

  • A far broader group (and ultimately, the entire IT organization and their clients and partners) can be engaged in the process of strategy and IT operating model development and deployment.
  • All the artifacts of strategy and IT operating models (strategy on a a page, key themes, business outcomes, major programs, metrics, processes, and so on) are immediately available to the organization and its stakeholders – this enables continuous improvement and evolution.
  • Significant productivity increases result from having these artifacts available as shared wiki pages.  While the term “knowledge management” (KM) has fallen out of favor, the goals of KM continue to be highly relevant, and the end result of building a semantic wiki for the IT organization creates a very robust and powerful KM platform.
  • A semantic wiki dramatically decreases email traffic and, more importantly, decreases the time taken to find information and increases the confidence that the information found is the ‘single source of truth’
  • Adoption and organizational change management issues can be largely addressed by ensuring that use of the wiki is “in the natural flow of work.”  I will did further into this important concept in a future post!
Related articles
Enhanced by Zemanta

Exploring an IT Operating Model for Enterprise 2.0 – Part 4: IT Governance


In Part 1 of this series, I suggested that the implications of Enterprise 2.0 for the IT organization are dramatic.  I also suggested that the ways of designing and executing an IT Operating Model in a Web 2.0 context are quite different from traditional approaches.  In Part 2, I outlined the major elements of an IT Operating Model as being:

  • Processes – how we perform activities that deliver predictable and repeatable business results through competent people using the right tools.
  • Governance – how we make and sustain important decisions about IT.
  • Sourcing – how we select and manage the sourcing of our IT products and services.
  • Services – our portfolio of IT products and services.
  • Measurement – how we measure and monitor our performance.
  • Organization – how we structure and organize our IT capabilities.

In Part 3 we looked at how Web 2.0 approaches could transform the way IT processes are defined and managed.  I now want to look at IT governance, and the implications of Web 2.0 for this ever important aspect of IT operating models.  Due to the depth of this topic, I will discuss the facets and domains of IT governance in this post, then deal with the Web 2.0 implications in a subsequent post.

Facets of IT Governance

There are many definitions and descriptions of IT Governance, and frameworks such as COBIT that attempt to bring ‘best practices and processes’ to the domain.   The two definitions I have landed on in my years of research and consulting in this space, are:

  1. A framework of decision rights and accountabilities to encourage desired behavior to realize maximum value from information technology.
  2. Aligning IT decision-making with enterprise governance and business unit objectives through an interrelated set of processes, policies and decision-making structures with clear goals, roles and functions, sponsored by the CEO, with clear consequences for compliance or lack thereof.

I like the first definition for its simplicity, getting to the heart of both ‘decision rights’ and ‘accountabilities’ through the lens of ‘behaviors’ all focused on maximizing the value realized through IT.  This is pragmatic – you can define the types of behaviors you would like to see (e.g., business takes ownership for the business outcomes to be enabled by IT initiatives), or behaviors you are seeing but would like to eliminate (e.g., people see IT as a ‘free’ resource, and therefore use it with little or no regard as to its cost or value.)

I like the second definition in contrast for its recognition that IT governance is an extension of enterprise governance, and for its reference to ‘processes’, ‘policies’, and ‘decision-making structures.’  I also like the emphasis on CEO sponsorship and consequence management – i.e., governance with ‘teeth’.

I’ve come to view IT governance as a means to achieve balance between the competing forces of innovation versus standardization and business unit autonomy versus collaboration.  I also see IT governance as a way to manage IT investments and assets as a  resource that is shared by the enterprise.  Finally, good IT governance provides a “transmission chain” for the highest level enterprise strategy, from senior executives on down through the organization. As such, IT governance is a critical alignment mechanism.

IT Governance Domains

Peter Weill and Jeanne W. Ross, in their excellent book, IT Governance: How Top Performers Manage IT Decision Rights for Superior Results, call out five decision domains of IT governance:

  • IT Principles (strategic choices between competing perspectives.  For example, ‘We will optimize IT investments for the enterprise rather than for individual business units.’)
  • IT Architecture (“the organizing logic for data, applications, and infrastructure captured in a set of policies, relationships and technical choices.”)
  • IT Infrastructure (“Centrally coordinated, shared IT services that provide the foundation for the enterprise’s IT capability.”)
  • IT Investments and Prioritization (“How much and where to invest in IT, including project approvals and justification techniques.”)
  • Business Application Needs (“Specifying the business need for purchased or internally developed IT applications.”)

While these domains may each be handled by different processes, policies and decision-making structures, all of these domains must be covered in ways that support a coherent strategy and set of beliefs about IT.

IT Governance, In Other Words…

IT governance deals with how the business makes decisions about the deployment and delivery of IT.  When sound IT Governance is in place, senior executives not only know their organization’s IT plans and policies, they also know how they are made.  IT governance is about the specification of decision rights and responsibilities required to ensure effective and efficient use of IT.  As such, it deals with organizational power and influence, and therefore  must be approached with care!

IT Governance 2.0

The implications of Web 2.0 on IT Governance are dramatic and far reaching!  On the one hand, with ‘transparency’ a watchword of good governance, 2.0 capabilities offer several important mechanisms to bring transparency both to the design of effective IT governance processes and structures, and to their ongoing execution and management.  On the other hand, dealing with decision rights and accountabilities in the types of highly diverse, distributed and fluid information environment enabled by social networking tools can become quite complex.  We will dig deeper into the implications of Web 2.0 for IT governance in a subsequent post.

Image courtesy of The ERM Current

Reblog this post [with Zemanta]