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

The Process Is More Important Than The Results

There are several aspects to this.

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

The Results Must Be Actionable

The results should let you know:

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

The Results Must Be Multi-Dimensional

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

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

Process-based Assessments Only Go So Far!

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

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

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

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

Typically, all three types of standardization apply to varying degrees – the mix being a function of the nature and complexity of the work you are doing.  For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.  For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.  For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

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

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

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

Graphic courtesy of Take On Torah

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

• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)
• Exploring an IT Operating Model for Enterprise 2.0 – Part 2

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

• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The maturation of enterprise social collaboration (blogs.computerworlduk.com)

This struck me as odd – and unfortunate!  “Tactical and operational stuff” should be on auto-pilot.  IT processes and management systems should take care of most things.  When I hear that an IT leadership team is consumed by the tactical and operational, my first reaction is that it is not a leadership team – it is a management team – a very different beast.

Leadership versus Management

Much has been written about the distinctions between leadership and management, so I won’t go far into this here.  For me, leadership is about influencing people, whether you have managerial authority over them or not.  Management is about exercising authority.  This basic distinction has important ramifications.  Leaders focus on the longer term and typically are concerned with achieving higher levels of performance for an organization.  Managers are more focused on the shorter term and on achieving agreed performance goals and objectives.

So, to recognize that “our leadership team doesn’t talk about strategic issues” is to recognize that it really isn’t a leadership team, it’s a management team.  That may be ok.  I worked with the CIO and his team at a major financial services company a while back.  They had been through a multi-year transformation under a new CIO.  The CIO and his team had been very ‘hands on’ and directive.  The results had been very positive, and the business clients of IT were impressed by the gains made from the transformation.  But, like many transformations I have seen, their performance improvement efforts had plateaued.  Managers and workers in the IT organization felt dis-empowered, so there was no real culture of continuous improvement.  The results of the annual engagement survey showed significantly lower employee engagement in IT than anywhere else in the company.

I raised the subject at an IT leadership team meeting, posing the question, “Are you a leadership team?  Or a management team?”  Consensus was quickly reached that they were a management team, with this finding justified by the sorry state of IT prior to the transformation, and the need for the top people in IT to drive change.

Which Do You Need – Leadership or Management?

I think that was a valid justification in their situation.  But the follow-up question, “What do you need to be now – a management or a leadership team?’ was much more contentious – especially as we drilled into what behavioral shifts would be implied if they did shift into a true leadership role.  For example, could they really trust their IT managers to manage?  If not, would they replace them with those they did trust to manage?

Dealing with this question and it’s implications became a major theme of my work with that team for the balance of the consulting engagement.  Great managers often have a hard time transitioning to a leadership role.  Great management teams have an even harder time transitioning to leadership teams – team members mutually reinforce each other’s instinct to be directive and in the details.

Have you fallen into the management trap?  How much time do you spend leading versus managing?

Graphic courtesy of Anthem Athletic Association

Related articles

• The IT Payoff From Years of Belt Tightening – Lower Costs, and High Dysfunctionality! (vaughanmerlyn.com)
• 4 Questions You Should Ask About Your Leadership (ChrisLoCurto.com)
• Managing a Virtual Team – HBR (bjconquest.com)

Mature IT organizations rightfully resist labels that separate them from the businesses they serve.  Any discussion of “IT” as distinct from “business” is anathema – a position I wholeheartedly support.  “Us and Them” made a fine title for a progressive rock tune back in 1973 but is an unhealthy perspective when the “them” is the business where profits are generated, and the “us” is essentially a support function.

Be that as it may, while the intent to resist separating IT and the business is worthy, there is a reality that in most enterprises the business generates revenues and profits while the support functions generate costs (necessary as those costs might be).  So when times are tough (or when a senior executive comes across some anecdote about the wonders of outsourcing IT to Timbuktu) the IT organization comes under pressure to take out costs.  Sooner or later, this comes down to reducing headcount, whether by natural attrition (IT managers represent a significant population ripe for retirement, and many have taken ‘packages’ to do so early) or by downsizing.

Let the Vicious Cycle Begin

And so begins the cycle – IT steps up to the plate and costs are reduced.  Early on, many of the reductions come from increased efficiency – improved Body Mass Index, if you will.  But muscle and bone are also lost, so delivered value is reduced, services are cut back and quality suffers.  The next time cost savings are needed, IT is again a worthy target – why not – they came through last time!  This time, more bone and muscle are lost.  At the risk of pushing the analogy too far, so is the proverbial membership to the gym (e.g., training, productivity and quality improvement programs) where some level of health was being maintained.  Healthy eating gives way to fast food and cola.  Nobody has the bandwidth to deal with the ‘essentials’ of keeping the lights on and trains running on time, let alone break new ground with the consumerization of IT or the move into Enterprise 2.0. Employee engagement suffers and IT performance degrades.

The cycle continues, and sooner or later top management becomes dysfunctional – not sure whether fight or flight are the best response – whether to embark on a full-blown transformation or simply to nibble at the edges with posters celebrating “Team IT” or the new “Agile” method to embrace.  Middle management is too busy to help with a fix – there’s hardly time to do annual performance reviews and budgets, let alone embark on major change programs. And the troops are, for the most part, disengaged – satisfied in accepting a reasonable wage to show up for work, but loath to give of any discretionary effort, or to put passion into their work.  Over time cynicism becomes so deep and wide, it is accepted as the ‘new normal.’  Discussion of organizational problems is all but banned by the IT leadership team – denial is best way to get through the week without the need for anti-depressant medications.

Forget Common Courtesy

In the downward spiral of belt tightening, age old protocols about responding to requests, answering emails, turning up at meetings on time or meeting commitments fall by the wayside.  As the leadership team slides into dysfunctional behavior, middle management follows by example and the troops aren’t far behind.  It’s a slippery slope, and one that’s tough to reverse!

Getting Back On Track

So, what can be done to reverse the slide – to turn the vicious cycle into one that drives increasing performance and leads to higher recognized business value from IT investments, assets and capabilities?  In practice, the catalyst for change is often a new CIO.  It’s not just that the new CIO brings in fresh ideas – it’s more about the energy and optimism they bring to the table.  If they are worthy of being hired into a turnaround position, they know they have a short ‘honeymoon’ period in which to create some visible signs that the slide is being reversed.  They probably negotiated some freedom to make change happen – reminding the executives that hired them that “businesses get the IT they deserve!”

Absent the new CIO, with the energy for change they embody and the breathing space they buy, my prognosis, I’m afraid, is not optimistic.  Einstein said, “We can’t solve problems by using the same kind of thinking we used when we created them.”  I think it’s a legitimate stretch to say, “We can’t solve problems with the same leadership that was in place when we created them!”

Image courtesy of Dysfunctional Psychology / Depression

Dion notes:

One trend has emerged with clarity from the discussions this year about the tidal wave of consumer tech moving into the enterprise: It’s profoundly reshaping the IT landscape in most organizations. Just a year ago, Bring-Your-Own-Device (BYOD) was barely on the strategic radar, yet a recent CDW survey of the federal government shows that as of last month, nearly half (44%) of federal employees now use a personal device for work purposes and that 62% of agencies now permit the use of worker provided devices.”

I’m not totally sure I believe the numbers – they seem somewhat aggressive to me given the typically conservative nature of federal government.  But Dion goes on to note:

Though data are still emerging about the trend in all industries, the early numbers in the private sector are even more dramatic, with a new report from Harris Interactive claiming that 81% of firms have already adopted some form of BYOD policy.”

Again, the numbers seem way aggressive per my conversations with IT leaders in the US, but the direction is clear.  And the movement now has its own acronym – BYOD (Bring Your Own Devices)!

A Compelling Argument…

This was the paragraph that most caught my eye:

This new mindset around IT is one where users tend to lead the IT charge. Not always, but increasingly so. They have frequently occurring technology needs on the ground. They also have the resources, time, and urgency to find the technology, or least more than the IT department does. So part of the consumerization story is a pull model of easy-to-access IT. Most of the time, it’s what they find in their browsers or app stores and on the shelf at their local mobile store or online electronics retailer.”

Bingo! The need is with the users. The funding is with the users. The resources are with the users. The urgency is felt by the users! So where is IT in all of this?

IT – The Protectors!

In spite of the rosy data Dion cites, I’m mostly seeing IT leadership either in denial (“This too shall pass!”) or anxiously assessing all possible risks and how to mitigate them.  Clearly, there are all sorts of risks – some of which we have yet to fully understand.  Infoworld’s recent BYOD: A world of pain awaits IT (subtitled: “Seasoned IT pros discuss the slings and arrows IT must endure to embrace bring-your-own-device policies”) lays out a litany of risks facing those who adopt BYOD policies.

The Real IT Choice

I believe the Consumerization of IT should be seen for what it is – a game changer for the world of corporate IT organizations.  One that will shape the future role of corporate IT and the future roles of IT professionals.  One that will unleash the creative power of IT in ways not previously seen, and that will have significant upside economic implications. This blog is titled “IT Organization Circa 2017″. That is 5 years away. I think those 5 years will see a massive shift in the center of mass of enterprise computing. Corporate IT can lead that shift – and stay relevant. Or they can study every nuance of every risk and put up barriers to change.  The change will happen anyway, and they will become all but irrelevant.

Related articles

• BYOD: Making sense of the work-personal device blur (infoworld.com)
• The essential strategy guide on the consumerization of IT (infoworld.com)
• Six Myths About the Consumerization of IT (news.dice.com)
• BYOD: A world of pain awaits IT (infoworld.com)
• Consumerization of tech: The new enterprise disruptor (zdnet.com)

1. “Ownership” is a tricky term in this context – just what does it mean to “own” a relationship?
2. There are at least two sides to any relationship – do all parties to the relationship see it in the same way?  If you “own” the relationship with me, do I recognize that and behave accordingly? Do I need to?
3. Context is everything – what works well for one company/one situation might not work at all for another!

Business-IT Relationship Issues

First, a small anecdote to frame the relationship ownership question. I recall interviewing a business executive about his needs and expectations from his IT organization. He said:

The last time I needed to talk about a possible new IT solution, I set up a meeting with my new Business Relationship Manager. Seven people from IT came to that meeting!  We had to find a conference room and move the meeting!  By the end of the meeting, most of those present had said nothing, but they had all furiously taken notes – presumably each capturing the same things.  No wonder IT costs too much and delivers too little!”

Too Many Cooks…

It’s a familiar situation – understandable but not acceptable! I imagine the seven IT folk included the BRM, a couple of Business Analysts, an Enterprise Architect, Project Manager and a couple of ‘subject matter experts‘.  They all wanted to be there so nobody would miss anything.  Perhaps they thought a “show of force” would impress the business client.  (In fact, it had the opposite effect!)

Too Many Specialists…

Yes – IT is complicated stuff, and ultimately, you have to get it right – 80% availability is not adequate for most IT solutions! This has led to an IT world that is full of specialties.  That is fine – but do all the specialties need to be represented in an initial meeting with the client?  How are the client’s needs best handled in terms of IT relationships?  How can we create an exceptional experience for our client?

The Need for a Single ‘Focus’ of Contact

The needs of both the business group and the IT organization are best served when there is a single ‘focus’ of contact – an individual who shepherds all contacts between business and IT.  This is one of the roles of the BRM.  Note, they are not a “Single Point of Contact” (SPOC), but they do “own” the business-IT relationship.  This means:

1. They are accountable for the success of the business-IT relationship.
2. As such, they need to be aware of all contacts between business and IT.  So, if I’m an Enterprise Architect, and I run into a business executive in a corridor and he mentions some specific need or IT issue, it is my responsibility to let the BRM know.
3. Similarly, as BRM, if I hear something through my business relationship that the Enterprise Architect should be aware of, it is my responsibility to let them know.

A good model to consider is the one followed by most consulting firms. They typically operate to a ‘rule of engagement’ whereby each client or prospect is ‘owned’ by a specific partner. If someone other than that partner has contact with the client or prospect (which was absolutely fine!) then they must ensure that the partner is aware of that contact.  This is seen as a common courtesy, both to the partner that owned the relationship and to the client – and a means to ensure an efficient, transparent client relationship. More importantly, it fosters strong relationships and a deep client knowledge.

Enabling the Business-IT Relationship

Business executives are not served by specific individuals – they are served by teams representing many facets of IT – operations, solutions delivery, support, training, architecture, and so on.  On the business side, there is typically not just one executive that represents a given business unit or function – there are many.

Taking the friction and noise out of these types of many-to-many business-IT relationships is crucial.  Clarity of the BRM role, their ownership of a given business-IT relationship, and an effective means of capturing and managing the myriad needs and activities are essential mechanisms for a healthy, productive business-IT relationship.

Tools such as Semantic Wikis and Customer Relationship Management solutions such as Salesforce.com can be effective enablers of many-to-many relationships such as those between business and IT, capturing all interactions and facts about the relationship.  Considering the size of IT investments and the business value that is on the line, investments in better managing business-IT relationships seem well-placed!

How clear is business-IT relationship ownership in your organization?  How well does it work?  Could better clarity around relationship ownership and rules of engagement improve the business-IT relationship?

Graphic courtesy of SmallBusinessFriends

Related articles

• Questioning the Role of the Business Relationship Manager (vaughanmerlyn.com)

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

• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 3 (vaughanmerlyn.com)

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

What is a Business Relationship Manager?

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

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

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

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

Representing the Business to IT

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

Representing IT to the Business

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

• Changing the Culture of an IT Organization – One Wiki Page at a Time! (vaughanmerlyn.com)
• More Hurdles in the Shift from Documents to Wikis (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance: Part 2 (vaughanmerlyn.com)
• The Semantic Wiki – Driving IT Organizational Clarity and Performance (vaughanmerlyn.com)