Monthly Archives: August 2012

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 2 of 2


This is Part 2 in a 2-Part post – please see Part 1.

Quick Recap

This post explores how a semantic wiki can support self-organizing teams, using a rock and roll band as a case study.  We developed a semantic wiki using the Symcordia™ platform to enable the band’s development and learning – both collectively (organizational learning) and for band members (individual learning).

Necessity is the Mother of Invention.

The band began as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves drowning in endless email chains, with lists of songs to cover, suggestions for band names, and so on.  I’ve always found emails to be both inefficient and frustrating as an approach to coordinating and sharing knowledge across a work group.  We were finding it tough to keep track of all the suggestions and maintain a “single source of the truth” to guide our practice and development.  We believed there was a better way, so we quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform.

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic and collective wisdom behind them – one place to keep a ‘single version of the truth.’

Initial Design and Features

Given these characteristics, we came up with our initial design.  Here’s a screen shot of the wiki sidebar – a primary navigation mechanism.  Note, we’ve not yet tried to make the site “pretty” – we will eventually create a public face into selected portions of the band wiki, and use a more fancy style sheet for that:

There’s an inevitable section about the band – each member has a page where they can post personal details, photos, videos, etc.  We’ve also worked up some “principles” or “simple rules” about how we want the band to work (e.g., We encourage band members to move from instrument to instrument.)  Having these on the wiki allows us all to collaborate on developing the principles and bringing them to life.  We struggled with naming the band, so we created a space for us to develop naming ideas, comment, vote and converge on a final name.

The most important space, in terms of developing as a band, is the Band Repertoire.  As you’ll see above, there are sections for:

  • Performance Ready Songs – songs we feel are ready for performance to an audience.
  • Songs In Development – songs that we are working on with a view to readying them for performance, at which time they get promoted to Performance Ready pages.
  • Prospective Songs – songs that we’d like to perform and within our talent and limitations, e.g., if it needs a flute, we probably can’t do it (sorry, Jethro Tull!)
  • Song Ideas – suggestions about songs we’d like to try at some time.

Typical Song Page

Here’s a partial screen shot of a typical song page:

Key here is:

  • The version of the song (some songs have multiple versions by different performers – for example the Guns ‘N Roses version of Knockin’ on Heaven’s Door is quite different from the Bob Dylan original).
  • A YouTube of the song by the performer we are trying to emulate, so we’re all aiming for a common performance outcome, or at least, a starting point to develop from.
  • Links to the tablature (music) for guitar, bass, drums, keyboards and any other learning aids.
  • The key we will play it in.  (Four band members playing a song in different keys does not sound so good!)
  • Performance Notes – clues about how to perform a song, and observations on how we are doing so far.
  • Song lyrics – lead vocals and harmony vocals singing different versions of the lyrics can really spoil a performance!

Semantic Properties

Each song page has a Semantic Properties box:

In order to protect my band mates privacy, I’ve ‘faked’ the assignment of parts to be all me!  But each part (vocal and instrument) can be assigned to different band members, and we can try different assignments at our practice sessions to see what works best (and capture this in our Performance Notes).

We can also vote on different aspects of the song.  The things on which to vote change depending upon context – e.g., whether it’s Performance Ready, Song In Development, Prospective or Song Idea.  For Performance Ready songs, a question is, “How well do we perform this song?”  For a Song In Development, it is, “Are we getting better with this song?  Are we ready to perform this song?”  And for a Prospective Song it’s, “Do we want to work on this song?”

Because these are Semantic Properties, we have pages that dynamically generate reports, such as:

  • Which parts I am playing what roles on?
  • Which songs do we most want to work on?
  • Which songs are improving the most quickly – or slowly?

Capturing Performances

We capture MP3 recordings and video clips of our performances and embed these in the song pages, track and rate how our performances are evolving over time – creating an historical record of growth and learning.

How Is It Working Out?

I’m going to save my richer response to this till we have a little more experience under our belts, but there are some early insights that I’ve seen many times before with my business consulting clients as they try to leverage collaborative tools like this:

  1. Email habits die hard!  For all the frustration with email overload, and the inefficiencies and inadequacies of email for collaboration, band members’ first instincts are to send an email, which begets a natural reply response.  Good thoughts are lost to the ether and invisible to the wiki!
  2. It’s tough making time to learn – even though the learning curve for a wiki is trivial.  The late Dr. Stephen Covey talked about the man struggling in the woods to saw down a tree.  An old farmer came by and observed, “That saw looks pretty dull.  Why don’t you sharpen it?”  The man replied, “I don’t have time to sharpen the saw – I’m too busy sawing!”
  3. I know from my business client experience with wikis that they gain the most traction when their use is ‘in the natural flow’ of daily work habits.  For our band members, they tend not to sit at desks with a computer screen and a browser.  They are busy executives moving from meeting to meeting and town to town.  Their dominant means of communicating beyond their meeting context is via Blackberries – phone calls and emails – so the band wiki is not ‘in the flow.’  This will change when we release a version of Symcordia optimized for smart phones and tablets.

Lessons Learned from a Reader

I’ll close this post by pulling a comment from the Part 1 post.  The comment came from Glenn Remoreras, one of my favorite bloggers (See Simple Processes.)

Based on my experience of championing the use of wiki with my team, it was a bit of a crawl, walk run process– and we are still crawling after a month. Here are our lessons learned:

  • Adoption champion is critical to success of the process. (I took this challenge myself as the manager of my area). As champion I generated initial contents and encourages to channel collaboration through the tool by suggested practices.
  • Different team members will have a different level and pace of adoption. That’s normal and acceptable. I did not force my team to use the tool, I slowly introduce it in our meetings and reporting.
  • Leader’s example is important. The leader spearheads the different ways to use the tool by doing it himself/herself. Later on the team will realize the benefits by experiencing how it changes the way they work.
  • Crawl walk run approach is necessary to not force the team adoption. Team members will adopt when they realize that it actually facilitates better flow of information and better team collaboration. Don’t rush it!
  • Subsequent and consistent use of the information in the community (wikis, blog, forum, file sharing) for information purpose to outside entities strengthens importance and drives team members to adopt.

My team is getting there collectively. Now we are managing some of our project status reporting, meetings, team locator, activity-task assignment, forum, and file sharing through the team community we have established.

Disclosure

My company is centered around a semantic wiki platform – currently optimized for IT groups (see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using Symcordia™, our semantic wiki platform.  The platform is built on the underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

Image “Classic Rock” by C.F. Payne courtesy of Reader’s Digest

Related articles
Enhanced by Zemanta
About these ads

The Keys to IT Demand Management


Once again, I’m posting in response to a reader’s emailed question.  The reader wrote:

While trying to understand the difference between Demand management, Portfolio Management and Project management from an IT Infrastructure Service delivery perspective, I stumbled upon your blog and found some interesting reads.  Could you please share your thoughts on how to define Demand Management for a service delivery company – what is in-scope and out of scope?”

IT Leaders Tend to Focus on Supply Management

Delivering IT products and services has been challenging since businesses first became IT-dependent.  There’s lots of complexity, layers of specialization, an unnatural separation of IT producer and consumer, and significant capital investments.  Exacerbating this is the typically high ongoing maintenance and life cycle costs, rapidly changing generations of technology, with resulting technological obsolescence.  As a result, IT leaders have focused far more on supply management – figuring out their supply chains, providing security, integrity and stable services, squeezing out costs,and so on.

Meanwhile, the demand side has typically received short shrift.  Demand chains are unclear at best, and complexities such as the IT infrastructure implications of supply activities and changing technologies are opaque.  IT planners have a hard time answering fundamental questions such as, “What’s in the pipeline for the next 6 months?” or, “What is our projected resource utilization for the next 6 months?”

There are also common problems where demand meets supply – IT delivers products and services that business users don’t understand, did not really want, or did want but do not know how to extract the business value.  It is generally seen that IT’s job is to “deliver” the solution, but not to ensure it is working to full effect.

So, What is IT Demand Management?

According to Wikipedia:

Demand management is a planning methodology used to manage and forecast the demand of products and services. In business, the term is used to describe the proactive management of work initiatives (demand) with business constraints (supply).” (Bold font added for emphasis)

I like to think of IT demand management as:

A set of disciplines, tools, and governance mechanisms designed to surface, stimulate and shape business demand for IT products and services in balance with supply constraints.”

In other words, given that IT supply is always limited, how do we surface and shape demand to get optimum business value from limited IT supply?

Key Elements of IT Demand Management

Getting demand management working effectively requires an orchestration of several techniques and processes – and ultimately, a moderate to high level of Business-IT Maturity (earned through the focus on supply management mentioned above).

The key elements include:

  • Portfolio Management is an important demand management technique and tool (and, if implemented properly, a governance mechanism).  Portfolio Management can help balance IT demand across time horizons (short versus long term), across risk/reward profiles (high risk/high potential return, low risk/low potential return), across business units or business processes, and across IT investment categories, such as IT projects and programs versus IT infrastructure.  Portfolio Management can make these balancing acts explicit so that they become strategic choices (Portfolio Planning) rather than the result of natural “drift.”
  • Product and Service Life Cycle Management.  In the world of IT, creating a solution is a fraction of the cost – maintaining and evolving it, keeping up with changing business needs and shifting technologies is costly.  Traditional accounting practices add to the load as depreciation of capital expenditures creates an ongoing drag on funding sources.  So, ensuring that life cycle costs are taken into account with the initial investment, and managing product life cycles to ensure that necessary investments are made, and unnecessary products and services are retired in a timely fashion is a key Product and Service Management function.  Also, maximizing ‘reuse’ of products and services – “why bring in yet another Customer Relationship Management system when we already have three” is a common refrain that often goes unanswered.  Finally, understanding cost drivers, and influencing business behavior towards ‘responsible’ consumption of IT products and services is an important part of the demand management equation.
  • The role of the Business Relationship Manager (BRM) – the key interface between business and IT.  The BRM is an important demand management channel.
  • My reader’s question asked about what Project Management has to do with IT Demand Management.  Project Management is mostly a supply management technique.  However, poor project management can negatively impact demand.  For example, I’ve seen business behavior that essentially says, “I will ask for more than I need because I know IT will screw it up!”  Or, “I will ask for as much as I can get because I know nobody is keeping count on the results!”)
  • Though not mentioned in my reader’s question, Program Management embodies an important set of both Demand and Supply Management disciplines, tools and governance mechanisms.  Program Management is a critical linkage between Portfolio Management and Project Management.
  • Effective demand management also requires agile supply capabilities.  This is one of the best reasons for techniques such as selective outsourcing and cloud computing – being able to flex up as demand increases and scale back when it wanes.

The COBIT and ITIL Trap

I’m generally supportive of frameworks such as COBIT and ITIL – there’s no really good reason to reinvent these wheels – they embody ‘good practice’ for IT governance and service management respectively.  However, they have to be customized to fit your environment, and many companies short-change this activity and end up with processes-in-theory, but not in practice.  In other words, the processes, control objectives, and so on that they think they have are not what people actually do!

Another problem these frameworks can induce is deluding their proponents into thinking that tools and processes solve the problems of demand management.  Yes – you need clear, transparent demand (and supply) management processes, and these can certainly benefit from good frameworks and tools.

However, effective demand management hinges on strong business understanding and buy-in, highly skilled Business Relationship Mangers (or whatever you call people in that role) and robust business-IT governance.  In particular, governance must address how demand is justified, funded, and how benefits are tracked and accountability held for them.

 

Graphic courtesy of Vendeka

Related articles
Enhanced by Zemanta

Accelerating Individual and Organizational Learning – Case Study from a Rock Band: Part 1 of 2


My regular readers know that I post from time to time about how wikis can enable organization performance and increase organizational clarity.  (For example see here, here and here.)

In the interests of full disclosure, my company is centered around a semantic wiki platform (currently optimized for IT groups – see Symcordia.com for more) so I do have a few axes to grind.  But I’m also a true believer in wikis as an enabler of collaboration and performance improvement. This is based upon my experience as a consultant and our client’s experiences using  semantic wikis.  Symcordia™ is built on an underlying Confluence wiki engine, with a variety of plug-ins that add semantic properties, sortable tables, page ratings and so on.

From IT Leadership to a Rock and Roll Band!

I’ve also posted before on lessons from the performing arts – see here.  Now, I’m adding to my business and consulting experience through my ‘non-day job’ as a member of a rock and roll band.  We are using Symcordia to enable our development and learning – both for the band (organizational learning) and its members (individual learning).

The Importance of Passion as an Ingredient for Collaboration

I was excited to get into this as it combined two of my greatest passions – wiki-enablement of growth and learning, and playing rock and roll!  In the words of the band Cheap Trick – this feels like Heaven Tonight!  (My business partner, Roy Youngman, created an excellent post on the importance of passion to collaboration.)

As you read this, think about interest groups you might be part of at work – a special project team, a six sigma team or whatever.  How could you use a wiki to enable development and learning to increase their effectiveness and ignite some passion for their work?

Here’s the Back Story

Necessity, as they say, is the mother of invention.  We started the band – a conglomeration of 4 very passionate musicians – as a vehicle to cover classic rock songs.  Over the first week or so, we found ourselves trading emails, mostly with lists of songs to cover, styles and genres to try, suggestions for band names, and potential dates to meet for practice sessions.

Having spent several years of my career successfully using wikis as a way to escape from endless email streams and knowledge lost in Windows folders, I found this both inefficient and frustrating.  I tried to keep track of all the suggestions, consolidate them and publish them as “the list” of stuff we’d work on, but it was all but impossible to do.  The list kept changing – both in content and purpose (some of the song ideas were aspirational, some were deadly serious, some were deliberately frivolous).

I had this nightmare vision of us turning up for our first practice, with no collective idea of what we were working on – we’d each prepared a different set of parts for a different set of songs!  Each band member is more or less multi-instrumental, but when 4 band members have each prepared the same lead guitar part, and nobody has worked up the bass part, keyboard part, etc., there’s a train wreck in the making!

I believed there was a better way, so I quickly (initially about 3 hours work) built a band wiki using my company’s Symcordia™ platform and got the band members onto it.

Why a Wiki for a Band?

A band has several characteristics that make a wiki a great enabler:

  1. Playing in a band is a highly collaborative endeavor.  Wikis are inherently collaboration tools.
  2. Playing in a band demands shared knowledge:  What are we going to play?  Which key should we play it in?  Who will take which parts (e.g., lead vocal, harmony vocal)?  Wikis are a fabulous way of capturing and sharing knowledge.
  3. A band must develop and grow – or it dies on the vine.  Wikis are wonderful enablers of individual and collective growth and learning – they can put at your fingertips all that you need in terms of knowledge and tools to develop and grow – things like musical scores, YouTube tutorials, song lyrics.
  4. For a developing band, history and shared experience is crucial to learning: What did we try and why?  What worked well – and not so well?  A wiki is an ideal vehicle for capturing history and creating shared learning.
  5. A band depends on all sorts of creative decisions:  What’s the best sequence of songs for a given context?  Which settings worked best for amplifiers, mixing boards and effects pedals?  A wiki is a great way of enabling and capturing those decisions and the logic behind them – one place to keep a ‘single version of the truth.’

Please join me for Part 2 of this post in the next week or so – I’ll cover the basic design for the wiki, screen shots of how we are using it – especially, how we are leveraging the semantic properties, and our early experiences.

Graphic courtesy of Cox Mpoperi Wilson Education Consultants

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

Corollary to my Post About the Value of LinkedIn Groups


Last week I posted something of a “rant,” questioning the value LinkedIn Groups.  I’ve received more email (though no comments on the blog!) about this post than any since I started blogging 5 years ago!  Many of these messages agreed with my observations, some did not.  One of the most insightful led me to post this – not as a retraction or correction, per se, but as a corollary.

The Value of Giving

One participant in one of the LinkedIn groups in which I participate – and it’s important to note that he is one of the most active participants – reminded me that there is one other aspect of the”ROI” on time and effort invested in LinkedIn groups I had ignored.  He wrote:

LinkedIn groups, like any other social medium, offer us a way to not only fully blossom into who we truly are, but they also provide an invaluable channel for others to connect with us.  …the true value of what we do is not really in what we receive, but in what we give…”

Of course, he is absolutely correct about the value of giving! I have given in terms of my time blogging and on LinkedIn (and other media) for the reason he cites – I get tremendous value from the act itself.  My blogging and my activities on social media help me think through and process how I am seeing and making sense of the world around me.  His email humbled me for ignoring this crucial aspect of the value of participation in groups such as LinkedIn.

My Lame Defense

In my defense, my rant about the value of LinkedIn groups was intended to be a message to the spammers and to all those who only want to “take” and never to “give.”  In some respects, I let my anger at them get the better of me – I probably should written the post – taken a deep breath – and then deleted it!

In the world of blogging, it is considered bad behavior to delete or change a post once published.  (And there have been a few posts over my 5 years that I wish I had not published, or wanted to rewrite!)  And, frankly, I’m not sure I would delete the rant even if it was standard practice to do so.  But my reader’s email to me was spot on – and I am glad to be able to add this corollary, saying what was left unsaid in the original post.

Related articles
Enhanced by Zemanta

To Whom Should Business Relationship Managers Report?


I recently received this question from a reader:

We are evaluating a strategy to centralize IT and implement Business Relationship Management (BRM) roles as part of the centralization. Where do you typically see the BRM’s reporting into in a centralized IT organization? Should they report directly in to the CIO, or can they be effective a level or two below the CIO?”

Rule #1 – Reporting Lines Are Weak Determinants of Success for the BRM Role

I have found reporting relationships to be a very weak determinant of success for the Business Relationship Manager (BRM) role. Far more important are the competencies (especially business knowledge and relationship skills) of the BRM and the maturity of the business executives they partner with.

Rule #2 – Heft Matters!

Notwithstanding Rule #1, the “heft” of the BRM role – the weight and implied authority it carries does matter.  There’s a couple of reasons for this:

  1. BRM’s are often on a CIO succession path (either explicitly or implicitly) – i.e., have the skills and wherewithal to be a CIO down the road, and the BRM role may be seen as a developmental step.  This has implications for who you chose to fill BRM roles, and for their career paths.
  2. The story a CIO tells the business executives when establishing the BRM role is along the lines of, “I am giving you one of my senior staff members to help surface, shape and manage IT demand so that you get the highest possible value from IT investments and assets. In return for this ‘gift’ I expect you to treat this BRM as a member of your management team.”

As a result, the most common reporting relationship for successful BRM’s is directly to the CIO.  In some cases, the BRM has a dotted line relationship to the senior business executive for the unit they represent.  In other cases, the BRM role is solid line to the senior business executive and dotted line to the CIO.

Rule #3 – Context Matters!

There are many other contextual factors to consider here, including:

  • What is the scope of the BRM role – is it primarily demand management (shaping, surfacing and managing business demand for IT)?  Or does the role include supply management, service management or other responsibilities?
  • Do the BRM’s act as Project or Program Managers for major initiatives?
  • Do the BRM’s sit on any governance bodies, such as Portfolio Management or Service Management?
  • How do BRM’s engage with the supply side?  How do they engage with Enterprise Architects?
  • How mature is IT supply?
  • Howe mature is business demand?

BRM’s Can Be ‘Game Changers’!

The BRM role is a tough one to get right, but from my experience, well worth the effort!  An effective BRM can:

  1. Elevate business maturity
  2. Ensure that IT resources are being focused on the highest potential value activities and initiatives
  3. Ensure that those initiatives capture the highest possible value

 

Graphic courtesy of Linda Galindo

Related articles
Enhanced by Zemanta