Tag Archives: Organizational change

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


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

His question, and the context for it was:

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

His email went on to say:

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

New Organizational Roles Disrupt the Status Quo

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

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

Implications of New Roles

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

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

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

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

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

Answering the Tough Questions

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

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

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

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

So, What To Do?

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

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

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

Image courtesy of Awakening Business Solutions

Related articles
Enhanced by Zemanta
About these ads

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

Does Your IT Shop Embody a “We Can Do That!” or a “We Can’t Do That!” Culture?


I was reminiscing with a consulting colleague recently about the two kinds of IT shops we’d worked with.  (Reminds me of an old joke that I first heard from Professor John Henderson at Boston University – “There are two kinds of people in this world – those who believe there’s two kinds of people and those who don’t!”)

The “Can Do’s”

Some IT shops fall clearly into this camp.  Suggest something innovative or new to them, and they are quick to explore the idea, see if it makes sense, and then figure out how they’d make it happen.  These clients are a delight to work with – energizing, engaging, sometimes challenging, but in a positive, constructive way.

The “Can’t Do’s”

Other IT shops fall into this unfortunate camp.  Suggest anything – innovative or not – and the immediate reaction is some variation on, “We can’t do that!” or, “That won’t work here!” or, a common variation, “That’s just not the way things work around here!”

Ask someone in a “Can’t Do” shop to help with something, and they will spend 30 minutes or more telling you why they don’t have the time to help – even if the help you are asking for would take only 15 minutes!  In other words, they will spend more time telling you why they can’t help than the time it would have taken to help.  It’s a knee jerk reaction.  The thought bubble I see in my head, floating above these naysayers is, “If I sign up for this, I might have to do something that would change the status quo.  That might be dangerous.  That might lead me to the unknown.  It’s safer to say, ‘no.’”

Prevent “Bad Change”

The “can’t do” environments spend all their energy trying to prevent change that might be harmful or counter to the established order.  Of course, there’s typically no way of knowing if it’s going to be a “bad change” or a “good change”, so by definition, any change is to be resisted at all costs!

Create “Good Change”

These are the innovators – the change agents.   Always looking to challenge the status quo and explore new possibilities.  I imagine that companies like Woolworths and Circuit City had a critical mass of “change resistors” (or at least, had enough of them in positions of power to preserve the status quo), while companies like Best Buy and Target had a critical mass of “change agents”.

I can understand why IT shops tend towards the “prevent bad change” camp.  IT operations depend upon stability and predictability, so you don’t want to mess with that.  But, unfortunately, the operational needs and culture tends to permeate everything the IT shop does!  Just when the business needs their IT specialists to be bringing them new ideas and new ways to compete, the IT specialists are beating down anything new.

From “Can’t Do” to “Disengaged”

Unfortunately, it’s an easy slide from “can’t do” to “disengaged”.  People in the organization get so beaten down whenever they try to introduce something new, that they give up.  It becomes such a painful endeavor, banging your head against a wall, that you stop trying.  It’s easier to slip into the background and go with the flow.  I have to admit that even as a consultant, there have been times where it was too painful trying to change things, and I’ve “gone native”.  Just make sure the deliverables per the Statement of Work are produced, get paid, and get out!  After a while, the extra energy it takes to break through the culture is spent.  At times like that, I empathize with the client’s employees – beaten down, disengaged, and at peace with simply going with the flow.  All that potential creative energy left at home, rather than being brought to the office as a source of new ideas.

So, What To Do About It?

I’m sorry, there’s no magic formula I’m aware of.  The first step, like the substance abuser, is to admit to the shortcoming.  Recognize that “can’t do” has permeated everything – way beyond those operational process where preventing bad change makes sense.  Then follow the familiar but tricky steps of organizational change management – establish the cost of the status quo, create a vision of the new, brighter future, build a guiding coalition, create early wins, etc.   Sometimes, it pays to stick you neck out – ask forgiveness, not permission!  If you get shot for doing so, that’s OK – you probably didn’t want to work there anyway!

Enhanced by Zemanta

Changing the Culture of an IT Organization – One Wiki Page at a Time!


I’ve been a student of IT organizational culture since I began my management consulting career some 30+ years ago.  It’s wrong, of course, to generalize too broadly, but I’ve worked with literally hundreds of large enterprise IT organizations (i.e., IT organizations of 250+ members) and have seen more commonalities than differences.  Of course, within any IT organization, there are sub-cultures – architects are not the same as operations people or as solution developers – but again, there are more common threads than sharp differences.

Prevent Bad Change…

For all the change that IT organizations bring about for their customers and clients, IT people are generally resistant to change.  I think this resistance is deeply rooted in a couple of factors:

  1. IT environments are full of technical complexity – layers upon layers of technology containing multitudes of interfaces and dependencies.  Change something over here and something over their is impacted – sometimes in subtle ways that may not be evident for some time, or until some other seemingly unrelated change is made.
  2. IT professionals thrive by taking complex situations and reducing them down – ultimately, to zeroes and ones.  There’s no room for ambiguity in a digital system – as such IT specialists are conditioned to abhor ambiguity.  And yet change is full of ambiguity – what ‘has been’ is no longer, and what ‘will be’ is not yet stabilized.  The natural inclination, then, is to drive out the ambiguity, and typically, the fastest, safest path to achieve that is to revert to the status quo – ending the change before damage is done (or the changed state it reached!)

Meet the Culture Where it is – Or Where You Want it to Go?

This inherent tendency to ‘prevent bad change’ creates some tough dilemma’s when introducing social networking and collaboration capabilities such as Wikis.  Wikis thrive best where a culture is open and emergent – “enabling good change,” if you will.  As you design the governance mechanisms for a Wiki, you have some interesting choices.  For example:

  • Do you allow people to create their own pages?  Or do you put controls on who creates and who edits pages?
  • Do you allow all spaces to be open to anyone in the organization?  Or do you allow for “private” spaces, where a select few (such as an IT leadership team) collaborate?
  • Do you allow people to display avatars that are humorous or ironic?  Or do you insist on “corporate photographs” from people’s security badges?
  • Do you allow people to write in their unique voices – even if a little rough around the edges?  Or do you have a Wiki Gardener monitor pages and clean up the rough edges?

To be clear, I’m not talking about allowing people to violate corporate codes of integrity – potentially offensive or inflammatory graphics or text is clearly out of bounds and violations of such codes of conduct should swiftly be managed as performance management issues.  I’m talking about an open and emergent Wiki environment – complete with the bumps and hiccups it may contain, versus a more closed and structured Wiki, protected from potential ‘voices of dissent’ or the raising of challenging or tough issues.

Governance Designed to Meet the Culture Where it is

You can take the position that Wiki governance should be designed for the current state:  “We are locked down, deeply concerned about security and privacy.  We have to have special ‘standards of conduct’ and controls to keep things structured and secure.”

Governance Designed to Help Shift the Culture

Or, do you take the position that the governance should be designed with an eye to the desired future state: “We encourage open dialog and a thriving ‘community of adults’ – keep within our corporate code of integrity and help make the Wiki a safe, valuable and fun place to grow and share our enterprise knowledge about IT.”

Given the people responsible for approving Wiki governance will probably not have significant experience with the more open model, their inclination will be to ‘play it safe’ and design for the current state.  Unfortunately, that is likely to perpetuate the current culture and probably prevent the Wiki from becoming what they want it to become.  It make take one or two strong, visionary leaders to take the leap of faith, and allow a governance model that reflects their aspirations for the culture.

Graphic courtesy of Positive Change

Enhanced by Zemanta

Changing – or Being Changed? An Important Distinction!


Elliot Ross and his always insightful blog about Strategic Technology for the Small to Medium Enterprise just posted on “ITIL, Value and Culture.” I like Elliot’s blog because of his “small to medium enterprise” perspective – I find it an interesting balance against the large companies I typically work with.

I felt the need to comment on his ITIL post because of an assertion he made about organizational change.  I then decided to turn my comment into a post of its own (get ‘em where you can, right?)

People Don’t Hate Change!

Elliot asserted “People hate change. Period!”  I think this is a common misconception – or at least, a misstatement.   People make changes all the time, and for every one person that has a cautious, conservative approach to change, there is at least one other who embraces and even seeks out change!  I’ve seen theories (though not the research to substantiate them!) that in any population, one third are highly receptive to change – may even make the change without being prodded.  One third are highly resistant to change and will fight it tooth and nail.  And one third will look to the other two-thirds and decide which path to follow.  This, of course, is overly simplistic, and probably wrong!  But I have to admit that whenever I’ve suggested the hypothesis to clients, it seems to resonate and match with their own experience, so perhaps there’s something to it?  Anyway, I’ve found it to be a useful framework to use in designing change programs.

People Hate Being Changed!

People don’t hate change, but they don’t like being changed! That’s a key distinction, IMHO.  So, for successful change, engage the people who must change in the change, make clear to them why it’s beneficial to them – the familiar “What’s In It For Me” (WIFM) ingredient and they will flock to it – or at least, one third of them will.  One third will fight it all the way, and the middle third will watch to see how the mythical wind is blowing.

Different Types of Change

Of course, change is a complex and multi-faceted concept, so any generalizations about it are fraught with problems.  For example, changing a simple routine – say, a new way to record your time – is quite different from moving from one boss to another.  Even more extreme is to change culture – to ‘build quality in’ for example, or become ‘customer focused’ as some change programs exhort!  These types of change require that you understand what changed behaviors are expected, believe in the need for those changes, have or can develop the required knowledge, skills and behaviors, and are willing to invest significant personal effort and take personal risk to make the change!

The Importance of Consequences!

Elliot made an excellent point about change and consequences:

If there is a lack of responsibility and consequences, people instinctively return to the old way of doing things.”

If there are no positive consequences for those who embrace the change, and/or no negative consequences for those who reject it, then the middle third in the framework introduced above will likely reject the change, the critical mass will never materialize, and the change is a lost cause.

And this lack of consequences is, from my experience, a very common problem.  I’ve had CIO‘s complain to me, “We aren’t great at implementation and follow through!”  I typically get into the “5 why‘s” routine.  “Why aren’t you good at implementation?”  And I keep asking why until they tell me, “We don’t hold people accountable.” or “There are no consequences for them following through or not.”  One more “why” from me usually gives them the mirror they need to see – they see and recognize the enemy!

Image courtesy of The Rubicon

Enhanced by Zemanta

The Accidental Project Manager


Some IT organizations invest a great deal in the processes and disciplines of Project Management.  As well they should – much of an IT Organization’s work is performed through projects.

Various approaches are deployed to bring consistency and effectiveness to Project Management disciplines – Centers of Excellence (CoE), Project (and Program and Portfolio) Management Offices (PMO), certifications (such as PMI), and so on.  But there’s a dirty little secret out there…

Many Projects Are Managed By “Amateurs”

By “amateurs,” I mean people who are operating outside the supposed disciplines, processes and standards of the PMO or CoE.  There are several reasons behind this:

  1. In some cases, it is simply a result of project work being deliberately flown ‘under the radar.’  I’ve consulted to IT shops where this is actually an effective way to get things done. It goes hand-in-hand with an “ask forgiveness, not permission” culture!
  2. Sometimes it is because the thing isn’t recognized as being a project until it is well underway – or maybe complete – or maybe never!  This is an issue that was recognized by the wonderful Jerry Weinberg in his early books on project management.
  3. In other cases, it is wanton disregard for the recommended (or even mandated) standards.  “These standards don’t apply to me.”  “They are too onerous for this particular project.”  “I don’t need them because I know what I’m doing.” And so on.
  4. In a few cases, it is sheer ignorance – not being aware that what you are doing IS project management, and would better be performed under the auspices of the rules and guidelines at play.
  5. One important driver of “Accidental Project Management” is inflexibility in the “official” Project Management methods.

Not All Projects Are Created Equal

To paraphrase Aldous Huxley, “Not all projects are created equal!”  Some deserve more rigor and discipline than others.  And some deserve different types of discipline.  For example, while many projects are most concerned with deliverables, budgets, resources and so on, planned against target dates, others deal with “softer” and more organic situations, where “emergence” is the key property and where planning by target date is unrealistic.

For example, a project that plans for, “30% of the IT organization will participate in the IT Strategy Wiki by July 31″ is not a valid planning approach.  Social activities work best through a “pull” approach – let’s identify the things that can be done to encourage and facilitate the “pull” and plan those.  The 30% participation may be a reasonable goal and outcome, but it is not a planning parameter in the sense of traditional project management.  To plan assuming that date will be reached is sheer guesswork, and anything else in the plan that depends upon this milestone is at risk.  I guess you call call the planning approach for these more emergent based needs, “Do while…” rather than the more deterministic, “Do until…”

Increasing Project Discipline Without Communism

So, what, if anything, can be done to reign in the Accidental Project Manager?

  1. First, decide if it matters.  Identify the real problems that loose project disciplines cause.  One problem may be that it’s the beginning of a slippery slope.  It sends a message that we “have standards and disciplines you should follow, but… (nod and a wink!) it’s ok if you choose not to follow them!  Another problem is that you may have bad projects – projects that suffer through not being well (or consistently) managed, or projects that should not be undertaken.  I often see a cause of waste and dysfunction in my clients in projects that should not be going on, rather than projects that are badly run.  A big problem is the implications ‘out of control’ projects have on resource management.  You just don’t really know what people are working on, and what availability they may have.
  2. Second, if you decide it does matter, determine why it is happening?  Don’t make a big deal of this – you may drive the behaviors underground.  Rather, do an informal poll – water cooler chats – ask people to ask people – try to get a sense of why people act outside the “official” practices.

Chances are you will find root causes to be:

  • Ignorance (lack of awareness and training)
  • Inflexibility in the “official” practices (‘sledgehammers to crack nuts,’ for example)
  • Lack of bandwidth in the PMO (“they just don’t have time to help me!”)
  • Poor “official” practices (“too bureaucratic, more designed for the benefit of the PMO than for those trying to manage projects!”)
Enhanced by Zemanta

The “Six Month Rule” of Organizational Change – It’s All Personal!


New Priorities AheadIt is said, “All politics is local.”  Picking up on that aphorism, I think it is equally true that all change is personal.

So Much Known – So Little Followed!

There is a substantial body of research and theory about organizational change management (OCM) dating back to the mid-50′s or even earlier.  Most OCM findings seem to resonate with people who are facing, or who have faced organizational change.  And yet, nearly all of the findings and recommendations from the body of OCM knowledge seem to be woefully lacking when it comes to increasing the success of change management initiatives.  If this were not the case, why do so many change initiatives fail to meet their objectives?

For IT professionals, even the terminology can be confusing!  I had a long, and I thought, enlightening conversation with a CIO some years back about the challenges and importance of managing change.  About an hour into the conversation, it became apparent that he was talking about technical change management – configuration management, release control, testing, and all that good stuff, while I was talking about the so-called ‘soft’ stuff (which is so hard!) of organizational change management!

How Have You Dealt With Change?

Ultimately, to effect change such as that involved in the introduction of a new work process or new tool, or increasing collaboration across silos, or improving team effectiveness, individuals must leave behind habits and behaviors ingrained over many years and adopt new ones.  Think about changes you have tried to make in your personal life – how many have truly succeeded?  Be it weight loss, increased exercise, learning a new skill, or any other change, chances are you’ve had way more more failures than successes.

A couple of years ago, after 60 years of reasonably successful brushing of my teeth (I still have most of them!), my dental hygienist suggested a slight change to my brushing regimen.  This did not require new skills, or new equipment, or any difficult physical movement.  It just required changing a habit of literally, a lifetime.  How long would it take to institutionalize this change – to make the new way of brushing my new habit?

For me, it took concentrated effort for about 6 months for the new brushing regimen to become habit – leading to my “Six Month Rule” for behavior change.  And during that period, I slipped a few times.  I did not suddenly decide to go back to my lifetime’s brushing habit, or decide to give up on the new approach suggested by the dental hygienist – no, I just lost focus in the early am when I got up, or the late pm when I went to bed, and – voila – I was back in the old routine!  It took conscious effort, as well as all sorts of reminders to help me stick with the change long enough for it to become institutionalized!  (For those facing a tooth brushing change, try a piece of string or rubber band around the handle of your toothbrush as a gentle reminder!)

The Six Month Rule – And Why Changes Fail

With business attention spans getting ever shorter, how can an organizational change that will take at least six months to shift behaviors be expected to stick?  No wonder the “this too shall pass’ response to dictated change is so common – by the time the changes may be starting to take hold, top management has moved on to the next big challenge or opportunity!

And my “Six Month Rule” applies to changed behavior demanded of someone who believes in that change.  Supposing for a moment, that my teeth brushing routine change was not something I believed in?  Or that it required I learn a new skill?  Or, as with an adjustment to a golf swing, it actually degraded my golfing abilities while I adjust to the new swing?  (Visions of me walking around with gobs of food all over my teeth, apologizing and explaining, “Sorry about the filthy teeth.  I’m learning a new way to brush – it should all be cleared up by Christmas!”)  It’s no wonder that the response to so many corporate change programs is, “This too shall pass!”

Most of what we do during a day’s work is based on deeply ingrained habit.  It’s not necessarily the ‘best’ way, or even the ‘right’ way – but it’s the way that is familiar too us and, most importantly, predictable.  And it is these deeply ingrained behaviors that are so hard to change and that often derail organizational change initiatives.

Lessons Learned, Questions to Ponder

We can all learn lessons about organizational change management – whether we are leading them or simply participating – by looking into ourselves and identifying what we need to be doing differently, and how are we going to accomplish that.  Achieving change at the personal level is crucial for most corporate change programs.  While it is easy to depersonalize change at work as “something that’s going on around me”, the reality is that if we don’t change ourselves at some deep, personal level, the desired change will not take hold.

So, first ask yourself, “Do I want this change to succeed?  What might be in it for me?  What if it fails – how might I be impacted?  Then, assuming you decide the change is positive, ask yourself, “What do I need to be doing differently?  What will that look like and feel like?  How will I go about making the personal changes happen?  How will I recognize success or failure, and what consequences will I hold over myself?”

Enhanced by Zemanta

Crowdsourcing Organizational Change: A Collaborative Approach to Leading Change


In the first post in this series, I provided some brief context for ‘change leadership’ (a term I find more apt than ‘change management.’)  I also introduced a caveat about linear, sequential, ‘programmatic’ change methodologies and briefly discussed the emergence over the last 15 years or so, of a more organic and emergent view of organizational change.

I observed that these emergent models are less alternatives to the more mechanistic models than they are refinements that help us interpret and apply them – i.e, organizational change can be planned and led, but the plans must be continuously revised in the light of emergent behaviors. And sometimes the emergent behaviors actually precede the recognition of the need for organizational change – i.e., you are not starting from scratch – you often recognize a good change that is happening (perhaps in one part of a company) and want to accelerate and broaden that change.

From “Push” Change Leadership…

Traditional organizational change methods are generally based on a ‘push’ model of change – we (company leadership) want you (employees) to work differently (e.g., reengineered processes, new incentive/reward systems, new tools/technologies, new organization structures, mergers/de-mergers, and so on).  For example, John Kotter’s 8-Step Change Process suggests we should:

  1. Establish a sense of urgency
  2. Create a guiding coalition
  3. Develop a vision and strategy
  4. Communicate the change vision
  5. Empower broad based action
  6. Generate short term wins
  7. Consolidate gains and produce more change
  8. Anchor change in the new culture

There is something both ‘Taylorist’ (the leaders are smart and know what to do, the workers are dumb and must be told what to do) and inherently manipulative about this approach.  I believe that the types of changes many companies are attempting to engage in today require that both ‘hearts and minds’ must be engaged in the change.  It’s not enough for them to simply to follow a new process – they must truly understand and wholeheartedly embrace the values and ideals behind the process.  They must want to follow the new process (or whatever the change being implemented is), not do so just because they’ve been told to.  Ensuring an exceptional customer experience, for example, does not simply happen because your customer-facing employees follow new procedures.

As such, change that requires “hearts and minds”, while it might be accomplished through a ‘push’ model of change leadership, is far more likely to take hold with more of a ‘pull’ approach.  In fact, I’d argue that most of the changes around Enterprise 2.0 (corporate and organizational adoption of Web 2.0 technologies, social networking, and so on) very much lend themselves to a ‘pull’ approach, or at least to more of a balance between ‘push’ and ‘pull’ change models.

… to “Pull” Change Leadership

So, adopting Enterprise 2.0 really requires more of a ‘pull’ approach to organizational change management.  And the good (great!) news is that Web 2.0 lends itself to enabling this kind of change.  Of course, there’s a ‘catch 22′ here – if people aren’t using Web 2.0 (or even worse in some companies – are not allowed to use these tools!), then how can they be used to facilitate change?

We will dig deeper into this in a subsequent post, where I will take a fictitious (but realistic) change situation and see how Web 2.0 ‘pull’ can be leveraged as a great counterbalance to traditional ‘push’ methods of change.

Image courtesy of Transforming Visions

Reblog this post [with Zemanta]

Influcencing Change In Your IT Operating Model


My last post, “Business-IT alignment – The Relationship Dimension” drew some interesting and even passionate commentary.  In particular, one frustrated commenter (someone in a Relationship Management role) pleaded, “What should I do? How can I influence to bring the necessary changes?”

I’ve posted numerous times on aspects of Organizational Change Management (see link for examples) but perhaps it’s time to revisit this perennial puzzle.

Change Management – The Quintessential Misnomer!

Actually, I think that the term “Organizational Change Management” is a terrible misnomer – change can’t be “managed” in the ways that people and projects can.  It can be “inspired”, “led”, “facilitated”, or it can “subverted” and “rejected,” but it can’t be managed.  Also, for IT folk, the term is too close to “change management” – that technical stuff associated with ensuring that changes to a system are implemented in a controlled manner.

I prefer the term “Change Leadership” – with the important caveat that we are all leaders when it comes to changes we’d like to see.  If it’s a change we don’t know is needed, or we would like to see it not happen, then it is down to others to “lead us into the light” and get us on board with the change.  Either way, it’s a leadership issue.  That’s why I loved my most recent commenter’s plea – “What should I do? How can I influence to bring the necessary changes?”  This is one relationship manager who recognizes his role in leading change!  (And who is not afraid to ask for help in filling that role!)

So Much Known, So Little Applied!

The big irony for me is that so much is known about and written about Organizational Change, and that we all have many years of first-hand experience trying to change our own behaviors or those of friends or family members, and yet most organizations are so completely inept at it!  There are books on change dating back to the early 1940′s (see, for example Kurt Lewin’s work), and a current search on Amazon.com yields 11,860 titles!  And, according to Google, there are currently 191,000 Blogs on the topic!  Clearly, the domain is fraught with subtleties and complexities.

Why Are IT Professionals So Inept at Organizational Change?

OK, so that’s a deliberately inflammatory question and a massively sweeping generalization – but from my personal experience in a 40-year IT career, it’s generally true.  I think it has to do with the characteristics of the IT profession that draw people to it – tangible, finite, project oriented.  IT professionals take highly ambiguous situations and ultimately reduce them to zeros and ones!  I’m not sure which is ‘chicken’ and which is ‘egg’ (i.e., do people good at driving out ambiguity gravitate to IT, or is it a learned behavior by IT professionals?) but I find that IT folk don’t like ambiguity.  And yet leading change means living with ambiguity.  IT professionals like plans, with beginnings, middles and ends – with defined deliverables and clear milestones.  Organizational change has none of these characteristics.  It is about people, not systems or bits and bytes.  It is about politics and influence, not routines and processes.

So, with such a plethora of research and written wisdom, what can I hope add to this body of work?  My goal (in a short series of posts) is to highlight the most useful Organization Change Leadership Model I have come across, and try to simplify and illustrate it with real examples from the world of IT management.  I’ll also point you to the excellent Change Management Blog.

Kotter’s Change Model – And It’s Potential Flaws

Harvard Business School Professor John Kotter has researched and written extensively on organizational change and has articulated an 8-Step Change Model.   (See his excellent HBR article “Why Transformation Efforts Fail.”  Also, the invaluable MindTools web site has this excellent summary of the Kotter Change Model.)

First, an important caveat.  To my point about the misnomer of “Change Management”, the Kotter model  implies linearity and assumes predictability and manageability of the change processes.  I don’t believe it should be interpreted or used this way.  In the immortal wisdom of Jerry Weinberg, “The project actually started long before it was officially declared ‘a project’.”  So has the organizational change typically ‘started’ before anyone gets too involved in planning how to drive it or, at least, to steer it!

In the last 15 years or so, a more organic and emergent view of organizational change has surfaced, leveraging chaos and complexity theory.  See, for example, Wanda J. Orlikowski and J. Debra Hofman’s “An Improvisational Model of Change Management: The Case of Groupware Technologies.”

I don’t see these emergent models as alternatives to the more mechanistic models, but as refinements that help to interpret and apply them – i.e, organizational change should be planned, but the plans continuously revised in the light of emergent behaviors.  And sometimes the emergent behaviors actually precede the recognition of the need for organizational change.  For example, many IT organizations today are trying (and failing!) to leverage social networking (typically around Microsoft‘s SharePoint).  At the same time, many members of the IT organization are participating in a number of social networks – both within their company and with external communities (e.g., FaceBook, LinkedIn, Plaxo).  So, while IT leaders are trying to “manage” a social network initiative (i.e., planned, formally managed), the reality is that social networking is already happening, but in an unplanned and emergent way.  If the planned efforts could understand and leverage the emergent activities, there is a better chance that social networking could be “steered” towards improved outcomes for the IT community and for the company.

My next post will pick up on the Kotter Change Model and begin to illustrate it with real world war stories and examples.

Image Courtesy of Management Excellence

Reblog this post [with Zemanta]