Category Archives: Change Management

Motivation and Engagement – Why It’s Often Lacking in IT Organizations and How to Increase It!


motivation

A couple of years ago, I came across a remarkable presentation by author Daniel Pink, and featured it in my blog post, “So You Think You Understand How To Motivate People!” It’s always been a popular post (and a great example of animation as a way to present ideas.)  I recently got around to reading the book that inspired the presentation – Drive, by Daniel H. Pink.  I’ve also just read the wonderful, To Sell Is Human by the same author, so I’m clearly “in the pink” as they say, and very appreciative of his research, writing skills, and his ability to constantly challenge the conventional wisdom, with insight and clarity.

Why Are Motivation and Engagement Important to IT Organizations?

Clearly, this is a trick question – motivation and engagement are important to any organization (or endeavor) but I have worked with quite a few consulting clients over the last few years where engagement was low – it both felt low as I worked with various teams and observed behaviors, and it was measured as low in annual engagement surveys, such as those by Gallup and Towers Watson.  Often, the IT organization scored lower on engagement than any other part of the business – sorry, readers – please don’t blame the messenger!

Why is IT Organizational Engagement Low?

I’m not certain about the reasons, but I have some hypotheses based on my observations and conversations with many IT staff:

  • In tough times (yes, like we’ve had the last few years!) IT organizations take it on the chin!  They are asked to participate in cost cutting, and they do – often again and again!  I often hear comments such as, “I’m doing the work of three people – and I never feel as though I can catch up and do a good job!” These rounds of cost cutting take their toll on morale and negatively impact engagement.
  • Often the cuts impact things that are important to IT staff – education and training, for example, or office ‘socials’ where people get to network and know each other.  Even ‘perks’ that used to be taken for granted, such as free coffee and sodas, or subsidized cafeterias have been eliminated.
  • I’ve noted before that IT professionals tend to abhor ambiguity – after all, they have to reduce business problems to zeros and ones!  And yet, in times of organizational change and transition – which have become the new normal for many IT shops – ambiguity is high, leading to frustration and low engagement.
  • The nature of IT is that it is noticed most when things go wrong – less so when they go right!  I’ve observed before that the half-life of an IT snafu is 12 years, whereas the half-life of an IT success story is 12 minutes!  It’s tough to stay motivated when you are constantly defending yourself!
  • For IT to deliver great results requires that many moving parts and processes across a complex environment work together seamlessly and harmoniously.  It’s tough in such an environment to create the kind of motivation-inducing autonomy Dan Pink writes about.
  • Finally, outsourcing has created both fear of job stability, and, for some IT professionals at least, degraded the job to that of a commodity.  I don’t personally think of outsourcing as wrong or misguided, but sometimes it is handled and introduced to the IT organization in a crude and clumsy way – for example, as a threat, “You’d better knuckle down or your job will be outsourced!”

What Does Research Tell Us About Motivating Knowledge Workers?

Knowledge workers are most motivated by intrinsic rather than extrinsic factors.  This explains phenomena such as the open source movement, and, as Pink points out, the remarkable and almost unpredictable success of Wikipedia – created by volunteers over Microsoft Encarta – a product of a gigantic company with a large budget and a massive team of experts.  Pink goes on to define three elements of what he calls “Type I” motivation – fueled by intrinsic desires:

Autonomy

One of the three basic human needs, what motivation researchers Edward Deci and Richard Ryan describe this way:

Autonomous motivation involves behaving with a full sense of volition and choice.”

It can include autonomy over task, over time, over team and over technique.  I’ve posted before about the concepts of standardizing process, deliverables or skills, and how IT organizations tend to get these confused, or try to standardize everything though processes.  Autonomy has been all but stamped out in many IT shops!

Mastery

Which reminds me of Robert Pirsig‘s Zen and the Art of Motorcycle Maintenance, which I’ve posted at length about as one of the most influential books I’ve ever read.  Given sufficient engagement in an activity, rather than being forced into that activity by compliance, individuals will generally seek personal fulfillment by striving to achieve mastery.  Even though they may never get there, they find enormous personal satisfaction in the journey towards mastery – spending significant chunks of time in what some call “flow.”  My colleague at the new Business Relationship Management Institute, Dr. Aleksandr Zhuk, pointed me to this quote from Matthew E. May‘s The Shibumi Strategy: A Powerful Way to Create Meaningful Change.  Shibumi is a Japanese word that better captures the concept of flow:

Moments of utter clarity. We feel wide awake and connected and balanced: everything makes sense, we know exactly who we are, what we want, and why we’re here. In that moment, be it one blink or a thousand, our effectiveness is maximal. And yet our actions seem minimal, effortless even, and the experience is consummately satisfying.”

How many IT jobs are designed to encourage Shibumi?  Many of my clients create an environment where constant context shifting takes place, as people are shuffled from design to maintenance to break-fix and so on.  Not much Shibumi takes place under such circumstances!

Purpose

Purpose provides the energy for living.  Think about the things you do outside work – and why you do them.  Coaching kids soccer.  Skiing.  Learning a musical instrument.  Volunteering for a charitable organization.  All these things have a purpose – and it’s not wealth creation.  Of course, there’s an element of wealth creation in our work, but for most of us, the need to make a living wage was satisfied early in our career.  So what is the real purpose in our work?  I remember some years back in a coaching session with a group of IT leaders from separate organizations discussing the fundamental mission of our work places.  Most of the group members were confounded by the discussion – they did not know what I was trying to uncover.  Except for one of them, who watched the others struggle with a slight grin on his face.  Eventually, this IT leader from a global pharmaceutical company said, “We save lives by inventing drugs that cure deadly diseases!  That’s why we do what we do.”

Why are you and your IT staff coming to work every day?  Is the purpose really motivating mastery?  And do you have the autonomy to engage in your work?  What could you do to improve motivation and engagement?  As a starting point, you might read some of Dan Pink’s “Drive.”

Graphic courtesy of Success Blog

Related articles

 

Enhanced by Zemanta
About these ads

Driving Business-IT Convergence – The Evolving Role of the Business Relationship Manager (Part 2 of 2)


cloudIn Part 1 of this 2-part series I defined the BRM role – with the caveat that it is by no means standardized.  In fact, as far as IT Service Management standards such as ITIL® and ISO/IEC 20000 are formalizing the existence of the Business Relationship Manager (BRM) role and corresponding process as a new best practice, they are selling the role short in terms of its potential strategic impact to business.  I went on to describe the typical BRM in terms of their purposes, goals, responsibilities and accountabilities.  To the title of this post, I introduced the shift from business-IT Alignment to Convergence and why this is so important as every aspect of business strategy and operations is increasingly dependent upon information and IT.   Today, the BRM operates at the leading edge of the convergence movement – a movement being accelerated by the ‘consumerization of IT‘, digitization of everything, and by the “Internet of Things.”

In part 2 of this 2-part series, I’d like to discuss needed BRM competencies, how the BRM role changes over time with increasing maturity (of both the BRM and her business partner) and how the way that the BRM engages with the business partner shifts the nature of the relationship from one of order taker to that of strategic partner.

Typical Competencies Required of the BRM

Drives Value Realization

This might be the most important competency for a BRM.  It includes knowing how to surface, clarify and promote the best value-delivering opportunities for IT investments and assets, and how to ensure that these actually deliver on their promised value – delivered in ways that are felt and seen.  This requires skills in Program Management (with implied Project Management skills), Portfolio Management, influence, persuasion, communication, finance and organizational change.

Understands Business Environment

Driving value realization also requires a great understanding of the business, its ecosystem and its competitive landscape.  Successful BRMs have a keen sense of the top strategic business and IT issues – both short and long term, and how these issues relate to initiatives in their industry.  In short, they understand the “business of the business.”  They are viewed by business leaders as a proactive partner in finding the right solutions to business needs and not as a mere “order takers” for IT services.

Aligns IT with the Business

First, let me say that some readers will fume at the subheading.  “IT and the Business are one and the same!” they shout.  While this may reflect a laudable perspective (and one that will gradually materialize as IT-business convergence takes place) it is rarely, if ever, the case today.  Unless your business is information technology, then “business” is where profits are generated, and IT organizations work in support of that.

With that digression out of the way, alignment can be a tricky concept, and in some respects sounds inconsistent with my argument for business-IT convergence.  But alignment represents the necessary table stakes – business leaders and IT leaders need to be ‘on the same page’ in terms of mission, vision, values and goals for both IT and the business – and how these relate to each other.  Mismatches in any of these can spell disaster to the ability to build and sustain value-producing business-IT relationships, let alone converge business and IT capabilities.

Successful BRMs work closely with business leaders to predict demand for IT services and to manage that demand.  They take the lead in highlighting competing objectives.  They are effective at managing the flow of demand through negotiations and seek to iron out demand/supply disconnects between IT and business leaders.  Most important, they constantly seek ways to foster convergence – empowering business leaders – teaching them to fish, as it were, rather than always fish for them!

Manages Relationships

Any role with the word “relationship” in the title has to imply a high level of competence at creating, sustaining and developing strong relationships among stakeholders – especially between business units and the IT groups that support them.  Relationship skills do not come naturally, and are not easily developed in some people.  Effective BRMs are able to build and maintain relationships with senior IT and business leaders.  They are seen as a value-added participant in strategic business-level discussions (i.e., worthy of a “seat at the table”).  Successful BRMs are not shy in speaking up when the demand for IT services outpaces supply ability or capacity.

Manages Organizational Change

Another tough set of skills and behaviors to master!  This requires deep understanding of the organizational levers for making change (people, process, and technology) and how IT and business strategies translate into practical plans of action for change.

The successful facilitator of change engages in discussion with IT and business leaders on the intended and unintended consequences of change, and is willing to confront senior executive sponsors if they are not “walking the talk” and proactively leading the change themselves.  They understand the total cost – both technical and human – of end-to-end implementation.  They can surface the hidden costs and potential obstacles that could derail the change.

They have the ability to identify key stakeholders at the outset of a project, to assign decision-making roles, and ultimately hold leaders accountable for results.  They think and act in terms of outcomes, not deliverables.

Manages Projects and Programs

Successful BRMs typically have several years of project and, ideally, program management experience under their belts.  They have demonstrated competency in project management fundamentals and in the complexities of program management. They demonstrate the ability to get things done through others, even though they may lack ultimate authority.

Effective Communication

Successful BRMs are recognized for their ability to listen, speak, write and communicate clearly and effectively. They demonstrate the ability to negotiate win-win, or at least buy-in, in situations where there are opposing viewpoints.  They are effective at influencing those that they hold no real power over.  They have the ability to recognize and surface disconnects between IT and business leaders and are able to resolve problems through difficult confrontations.

Financial Savvy

Successful BRMs have good knowledge of finance and accounting – they know their ROIs from their NPVs and know how to build a business case that is compelling.  They understand Portfolio Management and have at least basic knowledge of Options theory.  They understand the financial drivers of the business and the drivers of the industry within which the company operates.

The BRM Maturity Journey

BRM Maturity - The Merlyn Group

The graphic above shows how the quality of the Business Partner experience grows and the BRMs maturity increases.

Ad Hoc Relationship

At the lowest maturity level, the BRM role has typically not been formalized.  As such it is being handled in an ad hoc way – the ‘squeaky wheel’ Business Partner gets the most attention.  Or, in some cases, the least demanding Business Partner, regardless of their potential to use IT for high value purposes get the most attention.

Order Taker Relationship

I see this most frequently. Typically, IT supply has been badly broken and the business-IT relationship is hostile, so the BRM role is introduced to “patch things up!”  The BRM, in her ignorance, believes the best way to improve the relationship is to say “yes” to any and all business demands.  This is nearly always a losing proposition.  IT can’t meet the demand, and if they did, there’s little to no business value to be gained.

Advisor

This is a more constructive and productive relationship, where the Business Partner sees the BRM as an advisor.  By this time, there has usually been some formalization of the BRM role and its rules of engagement.  There’s also been some level of training for the BRM – or at least some thought put into the selection of people for the role.

Strategic Partner

The ‘Holy Grail’ of BRM implementations.  This should be the clear ambition – one that is understood and shared by the BRM and her Business Partner – with the recognition that you aren’t a Strategic Partner because you say you are, or because you want to be.  You reach that elevated position because you’ve earned it – and because your Business Partner sees you that way.

IT Matures as the BRM Role Matures

At the risk of pointing out the obvious, the BRM role does not act in isolation.  It is inextricably linked to IT supply.  If IT supply is broken, the BRM role will be limited, and might not even make it to Order Taker.  This, from my experience, is a common situation.  Things are bad, so the BRM role is introduced.  Unless supply improves, the BRM is doomed to failure – and may actually make things worse.  Promises are made and expectations set that cannot be kept.  On top of lousy supply, the BRM is seen by the business partner as ‘overhead’ – yet more evidence that the IT team is clueless, always adding cost without demonstrating value!

To reach the Holy Grail of Strategic Partner, IT supply has to be excellent – both with steady state services (networks, email, help desk, etc.) and with solution delivery (projects and programs).  The “strategic” BRM needs IT supply to work flawlessly.  IT supply needs the BRM to suppress low value demand while stimulating demand that delivers real business value.  That way, everyone is happy and a virtuous cycle is sustained.

Image courtesy of TradeArabia

Related articles
Enhanced by Zemanta

ITIL and the Business Relationship Manager: Avoiding the Performance Trap!


order-taker

I have good news, and I have bad news!

The Good News…

The IT Infrastructure Library (ITIL) 2011 edition and the ISO/IEC 20000 standard for IT Service Management formalized the existence of the Business Relationship Manager (BRM) role and corresponding Business Relationship Management process as a new best practice and international IT Service Management standard requirement.  This is good – for professional BRMs around the world, for the IT profession in general, and for improving the business return on IT investments, as technology becomes ever more deeply embedded in business processes.

The Bad News…

(And I know I will get hate mail and lose readership for saying this, but…) As defined by ITIL, the BRM role comes off as somewhat tactical – not something to get business leaders salivating over their new partnership with IT, nor hungry to innovate business products and services!  Let me be clear – the ITIL vision of BRM is necessary – but from my experience, it is insufficient to drive real business value beyond a certain point.  It will help an IT organization with poor service quality get better.  But it will not help an IT organization with good service quality to excite and delight their customers with the new business capabilities that are enabled by information and information technology!

Business Relationship Manager Role

I’ve posted extensively on this role in the past – the BRM is a bridge between the IT organization and its business clients (just as a good CIO is a bridge between the IT organization and corporate leadership).  As such, it both represents the business clients to IT, and IT to the business clients.  This role has surfaced over the last 10 years or so and Gartner predicts that the fraction of IT personnel dedicated to Relationship Management and Change Leadership functions will reach as much as 15% by the end of 2013 and grow up to 20% by 2016.  LinkedIn hosts two groups dedicated to the BRM role.  One group – IT Business Relationship Management - currently boasts over 1,800 members.  The other group, Professional Business Relationship Managers currently has over 2,600 members!  (In the interests of full disclosure, I co-manage the latter group.)

I’ve conducted a significant amount of consulting, assessment and training in the BRM space, including designing and leading BRM training and development programs for global companies with over 100 BRMs (as well as for those with fewer than 5 BRMs).  From that experience, and from my ongoing activity on the LinkedIn groups, I’ve seen two distinct ‘flavors’ of BRM – “Tactical” and “Strategic.”

BRM and Business-IT Maturity

To help understand “tactical” and “strategic” BRMs and how they’ve come to be, I’ll use my Business-IT Maturity Model (BITMM).  I’ve posted at length about the BITMM.  In its simplest form (see graphic below) the model represents both business demand maturity (highlighted in red to the left of the learning curve) and IT supply maturity (highlighted in blue to the right of the curve. These never move completely in tandem – sometimes demand is slightly ahead of supply, other times it is slightly behind.  If demand and supply get too far out of whack, there’s usually a change of CIO (or a turnover of the IT organization to an outsourcer!)

Slide1

The number of maturity levels is arbritary, but for simplicity let’s use three – business efficiency, business effectiveness and business transformation.  Where a company is at any point in time is a function of factors such as:

  • the industry it’s in
  • current business leadership
  • competitive and regulatory forces
  • quality of IT leadership
  • quality of service delivery

For example, the financial services industry tends to be highly information-intense, so is generally demonstrated higher business demand and IT supply maturity than say, manufacturing companies, which have traditionally been less dependent on information.  All that is changing, of course, as businesses and governments everywhere become increasingly digitized.

The ITIL Connection

Improving service delivery quality is where ITIL focuses.  According to its current owners (The APM Group Limited) ITIL is “the most widely accepted approach to IT service management in the world.”  Originally developed under the auspices of the UK Office of Government Commerce (OGC), ITIL is becoming a popular approach to service management.  Often loosely, and occasionally rigorously followed, ITIL documents processes and practices for service management.  This focus on service management is crucially important in moving IT supply maturity up from low Level 1 to mid-Level 2.

The Tactical BRM

The graphic below crudely cuts the BITMM in half.  The lower half is what I refer to as the “tactical” BRM space – focused on business efficiency and effectiveness.  The conceptual dividing line between these spaces is important.  Around the mid-point of Level 2 maturity, the learning curve changes direction.  This is also a common “sticking point” (see my earlier posts on “sticking points”) where IT organizations often become trapped and their efforts at performance improvement taper off.  In some cases, they actually fall back in performance.

Slide2

So, in the pursuit of service management quality, the BRM has an important role, establishing a strong business relationship with the customer by understanding their business and customer outcomes.   But the focus is service management, as opposed to the strategic possibilities for IT capability to enable new or improved business products and services.  Service management applies most to ‘steady state’ IT services – not to transformational projects and programs on behalf of business units.

The Strategic BRM

The upper half of the BITMM is the “strategic” BRM space – focused on business effectiveness and transformation.  While an IT organization must be careful not to slip back on IT service quality and customer satisfaction, simply delivering ever-improving services will not transform IT into a respected, value-producing business partner. Sooner or later, IT service management efforts reach a point of diminishing returns. Something quite different is then needed to further improve the business return on IT assets and investments.  While the “Tactial BRM” tends to focus on IT supply management processes and activities, the “Strategic BRM” focuses on business demand management – stimulating, surfacing and shaping demand for services, activities and initiatives with the highest potential business value.  The “Strategic BRM” works closely with her business partner to ensure that IT investments and capabilities yield real business value.

Leverage the Standard Frameworks – But Don’t Get Stuck

The message here is that it’s ok to leverage standards and frameworks such as ITIL, COBIT and TOGAF – but essential to do so with intelligence!  They have their place – and a context for which they were intended – that often being UK government entities.  Nothing wrong with that, but it tends to be a context of control – not innovation.  Control can help you get from low Level 1 to mid-Level 2 – but not to Level 3.  What kind of IT capability does your business need – controlling or innovating?

Thoughts on a postcard, please!

Graphic courtesy of giffconstable.com

Related articles
Enhanced by Zemanta

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

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

Systems Thinking and Process Improvement – Pearls of Wisdom from Russ Ackoff


The late Dr. Russell Ackoff was described by Steven Brand as “the Einstein of Problem Solving”.  If you have ever brushed with the magic of Systems Thinking, you probably know who Russ Ackoff was.  He’s been described as a Renaissance Man, architect, city planner, philosopher, behavioral scientist.  He is considered the father of organizational systems theory and especially, Systems Thinking.

A nod to Alex Mathews and his excellent The Enterprise Advocate blog for coming across this excellent presentation.

 

If you are involved in any type of improvement effort, ask yourself (and your teammates) – are we approaching this with a whole systems perspective?  If not (the likely case!), what can you do about it?

Image courtesy of The Open University

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

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


This is the 3rd in a series on assessing IT Capabilities.  (See Part 1 and Part 2)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.  Part 2 defined the term IT Capability, presented a potential landscape, or normative model, if you will, for IT Capabilities, and discussed ways to determine what IT Capabilities are needed.

In this part we will examine assessment dimensions, options and ratings.

Assessment Dimensions

Figure 1 – Capability Assessment Dimensions

Figure 1 shows a capability assessment approach that uses 4 top-level dimensions – Purpose, Commitment, Ability and Accountability. Each dimension is decomposed into lower (leaf) level dimensions.  Purpose, for example, is a function of how clearly and effectively the service(s) produced by a capability are defined, and how clearly the goals for that capability and principles by which the capability operates are defined.

Note, there is a hierarchy implied among the top-level dimensions.  It is unreasonable to expect management commitment to a given capability if the purpose and goals for that capability are unclear or inappropriate.  It is unlikely that appropriate ability is in place without the necessary management commitment.  It is unreasonable to expect clarity of accountability for a given capability if ability is lacking.   In practice, I don’t usually disclose this hierarchical relationship until the assessment is underway, when I do use it as a validation mechanism.  For example, if the assessment team is scoring Accountability as fully in place, when they’ve scored Purpose or Commitment or Ability as not in place or only partially in place, then I know I need to challenge the team, and probe for the inconsistency.

Assessment Options

The multi-level assessment dimensions provide several options for the assessment method:

  1. Assess a capability at the top-level, but use the leaf levels to clarify what is meant by the top-level.  For example, I can assess the degree to which the Purpose of a given capability is in place by thinking about the effectiveness and clarity of the Service Definition for that capability, and the quality of the Goals and Guiding Principles for that capability.
  2. Assess a capability at the leaf level dimensions.
  3. Mix and match between top-level and leaf level dimension based upon the needs (purpose and goals of the assessment) and feasibility (available time, available knowledge) of the assessment situation.

Assessment Ratings

For any capability, for each dimension, a rating can be assessed as follows – the capability dimension is:

  • Fully in place – this is our universal practice and will be found to be used consistently, with few, if any, exceptions.
  • Mostly in place – this is common practice, though is not universal or not consistent, or there are frequent exceptions.  We know how to do this well – but we need to get better in practice.
  • Partially in place – this is not common practice, though we have many of the necessary characteristics, but not all of them.  We have some work to do to strengthen the capability as it exists as common practice.
  • Not in place – we have few, if any, of the necessary characteristics.  We have a great deal of work to do to develop this capability.

Note, there is clearly room for interpretation in these ratings.  This is more art than science, and for most IT capabilities, we are not dealing with highly mature processes and statistical process control!  From my experience, that is ok, and is why in Part 1 of this series that I said that my preference is to use a facilitated self-assessment approach – pull together a team of practitioners, customers and subject matter experts and facilitate them through the assessment.  It is usually the dialog this generates that has the most value, and leads to the insight and commitment from the team to initiate and sustain improvement efforts.  More on this in Part 4.

Assessment Dimension Descriptions

Below are brief descriptions for each top-level and leaf level assessment dimension.

Purpose

Are purposes and goals for the capability clearly defined and well understood?

  • Service/Product Definition
    • Is there a clear definition of the business purpose served by the capability and how this service/product integrates or links with other services and products?
    • Is there a clear definition of business outcomes for the service?
    • Have the service providers been identified? (e.g., dedicated internal service providers, external service providers, project team responsibility)
  • Goals and Guiding Principles
    • Are the appropriate opportunities to use the capability defined?
    • Are the goals established for use of the capability and/or its service providers?

Commitment

Has organizational commitment been demonstrated in terms of senior sponsorship and management responsibilities?

  • Sponsorship
    • Is there adequate understanding, support and management commitment to sustain the use of the capabilities and/or services?
    • Is there commitment by example?
  • Delivery Management
    • Is qualified management in place to provide oversight and direction for delivering the capability or service?
    • Are mechanisms in place to ensure that service delivery will improve over time?
  • Change Management
    • Is a change management strategy and plan in place to overcome issues of organizational resistance?

Ability

Have the baseline processes, role requirements, enabling technologies and deployment capabilities been established?

  • Process Definition
    • Has a documented process been implemented to guide work activities?
  • Roles and Competencies
    • Are required competencies and specific areas of specialization defined?
    • Are appropriate service providers identified and trained?
    • Are training/skill development processes defined and provided?
  • Tools and Technologies
    • Are tools and technologies in place to enable effective execution of the work processes?
  • Deployment
    • Are the service providers organized, ready, and able to provide service?
    • Are charging and cost allocation mechanisms in place?

Accountability

Have criteria for success and related consequences been defined?

  • Performance Management
    • Have measurable criteria for individual and group performance been defined?
    • Have measurable criteria for evaluating business results been defined?
    • Have necessary measurement/assessment approaches been instituted?
  • Consequence Management
    • Has a program to ensure usage been established?
    • Are the rewards for success and penalties for failure defined, communicated and implemented?
    • Have individual roles been defined including their inter-dependencies and how performance contributes to overall success?

 

Please join me for the 4th and final part in this series!  And please do weigh in with your own experiences, observations or questions!

 

Graphic courtesy of Tarun Trikha.com

Related articles
Enhanced by Zemanta

The Futility of Collaboration without Context


The term ‘collaboration’ gets thrown about as something inherently valuable and worthwhile – an end in itself, rather than a means to an end.  In reality, collaboration in of itself is:

a). Unlikely to happen
b). Unlikely to create anything of value

So Many Collaboration Platforms, So Little Collaboration!

Collaboration platforms are everywhere!  Most IT shops have at least one collaboration platform (usually SharePoint) and often several others.  And some people do participate.  The question is, with what result?  The answer often is little that is really worthwhile, and even less that can truly be called “collaboration.”

I used to wonder if there was something in our human nature that inherently resisted collaboration.  Of course, the opposite is true – human beings are both inherently gregarious and naturally collaborative – it’s in our instinct for survival.  The reason I was seeing so little collaboration on collaboration platforms was not that people did not want to collaborate – it’s that they did not understand (or believe in, or want) the purpose for collaboration.

The Collaboration Context

Alan Kay is credited with one of my favorite quotes, “Context is worth 80 IQ points!” In the case of collaboration, context not just the extra IQ points – it’s the whole enchilada of collaboration!

Several years ago, while I was an Executive Vice President at the The Concours Group – a management consulting, research and executive education firm, we were acquired by a company that had developed a collaboration platform.  Our new management was very keen for us to “eat our own dog food” and encouraged everyone in the company to get on the platform and ‘collaborate.’

I found this to be an interesting and enlightening experiment.  Most of us did indeed get on the platform.  Thoughts were posted and commented upon.  Interest groups popped up.  We had a ‘social reputation’ system, and I was proud the day my avatar suddenly listed me as a “Docent”, though I could not find out what that actually meant in this context!  After an early spike, usage dropped.

After a while, someone introduced Yammer into the firm.  A new groundswell of so-called “collaboration” surfaced, but after a while, that too dropped.  I observed that in spite of putting time and energy into “collaboration”, in reality, people were engaging in conversations that, while they may have been interesting, never went anywhere.  Conclusions were never drawn, deliverables were never created, insights never extracted, lessons never learned and applied.

The problem was not the tool – it was a lack of context.  There was no clear purpose or intent to the collaboration.

So, What’s Your Collaborative Intent?

  • Are you trying to engage people in problem solving?  For example, stakeholders and/or subject matter experts might be invited to review and expand upon a cause-effect analysis.
  • Are you trying to create a deliverable, such as a project proposal?  People might work together on creating the proposal, perhaps each working on their own section, but reviewing and commenting on others sections such that the whole is coherently structured and internally consistent.  Or you might wish to get everyone’s input to the whole proposal, rather than have people focus on their section.
  • Do you want a community of practice or interest to capture and evolve a body of knowledge – best practices, templates, examples of how to do something, such as charter a project?
  • Are you creating an ‘operating manual’ for an organization, with processes, roles, competencies, rules of engagement, and so on?  Perhaps people will be encouraged to not only create and/or refine the knowledge content, but will also rate the content based upon usability, clarity or how well the organization handles a given situation.
  • Are you encouraging people to share across organizational silos – looking for points of leverage or redundancy?

Each of these ‘collaborative intents’ implies a specific goal or set of goals.  And each goal, in turn, might lend itself to a different type of collaboration mechanism.  While content or document management systems might be great for managing ‘documents of record’, they might not be so effective at encouraging multiple authorship.  In fact, document-centric tools tend to deepen and strengthen the traditional document mindset, where a document is something you email around to people to get their input.

It’s all a question of context – what are you hoping to gain through collaboration?  Is the goal clear?  Do those that must participate understand and believe in the goal?

Graphic courtesy of diagoal

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