Change Management is not an Implementation Issue

June 15, 2008

It’s good that we’re taking a greater interest in the relationship between enterprise architecture and change management. The interesting thing about most discussions is that they talk about enterprise architecture as the “development” phase and change management as the “implementation” phase. There’s certainly nothing wrong with this but I don’t think it goes far enough.

The reason I don’t think it goes far enough is that change management should be an input into your enterprise architecture work. It shouldn’t be a handover – we’ve built this great thing and now ‘lets do some change management’ and roll it out.

I’ve got a software background so I’ll use a software development analogy. When you’re designing software you should always take into account the deployment environment. If the application is to be deployed in a Microsoft environment then PHP and MySQL aren’t your best bet. This example is far fetched but the fact remains – deployment is a non-functional requirement, it should not be an afterthought. If you can’t deploy your finished application to the target environment then its not a ‘deployment’ issue – it’s a development issue.

What’s this got to do with enterprise architecture? Some EA teams are full of great ideas that never see the light of day purely because the change management issues are not considered up front. Typically this problem manifests itself it two ways:

  • Organisation issues – EA teams generally don’t have the clout to force large scale organisational changes – even when such changes are the right way to go. If your architecture work requires such changes in order to be of value then you’re wasting your time.
  • Technical issues – the EA team come up with a great ‘target architecture’ but don’t provide any guidance on how to get from ‘here’ to ‘there’. Enterprise architecture is a journey not a destination – so you need to provide a map.

Obviously, you don’t want your EA efforts to be hamstrung completely by organisational issues and technical issues. Enterprise architecture should be about change – and change always leads to some amount of discomfort within the organisation. They key is to find the right balance. Some organisations can handle revolution others prefer evolution. You want to push the envelope – but not to breaking point.

PS: If you’re interested in a good book about a similar topic try High Impact Consulting by Robert Schaffer. In a nutshell the book is about tailoring the work you do to what the client is ready to do. No matter how great the work is, if the organisation cannot use your advice (deploy it) it just becomes useless shelf ware.

Business Hierarchy of Needs

April 10, 2008

Anyone that has had basic exposure to the field of psychology would be familiar with Maslow’s “Heirachy of Needs”. Businesses have a similar heirachy of needs.

Maslow’s Hierarchy of Needs is often presented as a triangle :

Physiological Needs

A person’s physiological needs include air, food, water, shelter, sleep etc. Physiological needs are the difference between life and death. A business also has physiological needs : they need suppliers to provide raw materials as inputs, workers to process these raw materials and clients to buy the resulting outputs. Without all three the company will eventually die.

Safety Needs

Safety for people means things like security, morality, law and order. From a business point of view ‘safety’ means one of two things :

  • • Being profitable. A business can survive without profits by breaking even year after year but that doesn’t take into account the opportunity cost of the capital tied up in the business. Investors want a return on their investment.
  • • Fulfilling its mission. Despite not earning a profit (or in some cases even making a loss), not for profit organisations can feel ‘safe’ if they fulfil the mission their benefactors (e.g. governments, philanthropists) have entrusted them with

Belonging Needs

For people these include family, friendship, affection and relationships. The parallel in business is obvious : businesses want to build close relationships with their suppliers and customers.

Esteem Needs

Things like achievement, status, reputation are as important to people as they are to businesses. Business want to be the preferred supplier, they want to be seen as an industry leader and they want prestige. Not because they want to feel “warm and fuzzy” inside – but because all of this translates to the bottom line.


Innovation, creativity, adaptability/agility and learning are all self explanatory and relate equally well to individuals and to businesses.

Why is all of this important? Before you write a proposal or pitch an idea to the executives, the VERY LEAST you should do, is to find out where your organisation fits into the hierarchy of needs. For example, if you’re pitching the benefits of SOA don’t try and sell something at the “self-actualisation” level (like agility) if your organisation has major problems at a lower level, for example supply chain problems. If you propose something that will satisfy that physiological need you improve the odds of your proposal being approved.

Goal Question Metric (GQM) Model

April 7, 2008

I love metrics. Maybe it’s naïve to think that “numbers don’t lie” but they lie a lot less than hype, speculation and anecdotal evidence. The hard part is deciding what to measure. The “Goal Question Metric” paradigm is one tool that can help us figure that out.

The whole point of enterprise architecture is to “make things better”. But we need to make sure that we make the RIGHT things better and be able to prove that we’ve succeeded. We need to compare the before and after. And this requires metrics. The Goal Question Metric Model is one simple way of making sure that the metrics we collect (and the proof we produce) is closely tied to the business goals.

The GQM Model is a hierarchy with 3 levels: goals, questions and metrics.

In a nutshell the process involves 3 steps:

  • Identify high level (conceptual) goals. Goals identify what we want to accomplish.
  • Operationalise the goal by generating questions that will define the goal in an unambiguous and quantifiable terms. Questions help us understand how to meet our goal.
  • Specify the metrics that need to be collected to answer the questions

From experience I can say that the distinction between ‘question’ and ‘metric’ can be rather blurred. The question seems to be the metric. The point of the exercise is to go through the process – don’t worry so much about wasting time ‘making things fit’ the model.

The first step in the process is to define the goal. A goal is conceptual not quantitative, and is made up of these components:

  • What? the product, process or resource under observation
  • What aspect?: the quality attribute of the object
  • Why?: motivation behind the goal (improve, reduce, minimise, maximise, understand, control)
  • Who?: perspective of the goal (who’s viewpoint)

Here are two examples of well defined goals.

Example 1
To improve the efficiency of customer relations staff in the call centre from the point of view of a the call centre manager.

What? Customer relations
What aspect of customer relations? Efficiency
Why? Improving
Who’s point of view? Call centre manager

Example 2
To improve the performance of the GetCustomer() web service such that service consumers are satisfied.

What? GetCustomer() web service
What aspect of the web service? Performance
Why? Improving
Who’s point of view? Service consumer

Questions help us move from the conceptual level to the operational level. Concepts such as ‘efficiency’ and ‘performance’ are abstract. Questions help people operationalise these abstract concepts.

Following on from the above examples, we could ask the following questions.

Example 1
The questions need to clarify the meaning of ‘improving efficiency’. It could mean any number of things, such as: increasing number of calls answered, reducing average call time, improving customer query resolution rates, increasing cross selling or reducing customer wait times in call queue.

Possible questions:

  • What is the maximum queue waiting time?
  • What sort of variations do we get in maximum queue times?
  • Are the peak periods? When?
  • Is the maximum queuing time increasing, decreasing or remaining the same over time?
  • What maximum queue time has the company committed to in the customer service charter?

From these questions we can see that the manager is looking to:

  • reduce customer queue times
  • reduce the maximum queue time for any one customer and not the average queue time across all customers.
  • minimise the occurrences of queue times exceeding the published wait times in the company’s customer service charter

Example 2
The questions need to clarify the meaning of ‘improving performance’. Improving performance of a web service seems pretty self-explanatory, but it still needs elaboration.

Possible questions:

  • What service level agreements (SLAs) are currently in place?
  • How often do we fail to meet SLAs?
  • What is the average response time for the web service?
  • Does the average response time vary?
  • When are the peak periods?
  • Are some customer’s details slower to retrieve than others?

From these questions we can see that:

  • We are only looking to improve performance ‘just enough’ to meet SLAs. Improving’ performance and STILL failing to meet SLAs won’t achieve the business goal. Conversely we don’t want to continually spend money to endlessly improve performance – eventually there are diminishing returns to the business.
  • We are looking to reduce the number of occurrences of SLA violations. We are not looking to improve the ‘average’ performance. In theory we could improve average performance and still have unacceptably high violation rates.

Metrics help us answer questions. They also allow us to chart our progress towards achieving the conceptual goals. Note that some metrics can be used to answer more than one question. Collecting metrics requires time, money and effort. We want to collect the minimum number of metrics that will answer the questions we are interested in.

Example 1
To answer the questions posed above, we need to collect these metrics (and no more):

  • Total time spent in queue for every call answered.
  • Total time spent in queue for every person that hung up before their call was answered.

Example 2
To answer the questions posed above, we need to collect these metrics (and no more):

  • For each invocation of the service collect: timestamp, response time and customer ID requested.

So there you have it. The GQM method is a simple way of ensuring that whatever statistics we produce to prove that we’ve made things better, are relevant to the business’s goals.

Let’s take the Example 1 and elaborate further.

Let’s say you were to build a solution (e.g. a portal) that made it easier for customer service representatives to answer customer queries. Because the call centre operator can answer questions far quicker, it will reduce ‘average call time’. This will probably have a flow on effect to queue times – if the calls are handled quicker, more people will get through, and queue times will fall. That’s all well and good but if the business is interested in ‘reducing queue times’ don’t give them metrics to prove that your solution ‘reduced average call times’. Prove you solved their problem – don’t make them connect the dots for themselves. It sounds simple – and it is. It just requires a bit of up front thought.

Change Management – Kurt Lewin

March 31, 2008

In Enterprise Architecture we often talk about models, patterns, best practices, technology and the like. Given that EA is fundamentally about change, it’s interesting that change management doesn’t get a lot of coverage in EA circles. In this post I’ll introduce a very simple model of change management that has been around for over 50years.

The term “change management” is a daunting one. Conceptually we know what it is and we know that we need it – but we often don’t know where to start. One of my favourite models of change management was devised by Kurt Lewin. I like it because it is insightful – yet extremely simple. And it shows us exactly where to start.In essence, the model proposes that “change” is a 3 step process:Change Management

Step 1: Unfreezing
This step deals with determining what needs to change and why it needs to change. It’s about overcoming organisation inertia, breaking down the status quo and changing mindsets. This step is often characterised by fear, uncertainty and anxiety. People’s doubts and concerns must be understood and managed.

Step 2: Change
Once people understand the need for change, new ideas are developed and introduced (usually through a collaborative and inclusive effort). Once the future state is agreed on, the organisation begins the transition from the old to the new. During the transition people will be out of their comfort zone so to allay their fears you need continually reinforce how the change will benefit THEM (not everyone will fall into line because something is good for the company).

Step 3: Freezing
Once the transition is complete and everyone has found their feet again you need to institutionalise the changes – make them the new status quo. Policies, procedures, reward systems and organisational values are all changed to reflect the new reality. This helps the change ‘sink in’ and provides some closure. Eventually, people’s comfort levels begin to return to previous levels.

This key insight from this model is that the process of “change management” has 3 distinct steps. To maximise chances of success you we need to start at the beginning and work your way through.

You could start at Step 3. You can attempt to freeze change by introducing new policies and procedures and then expect people to follow them. The trouble is – they won’t. At best they will obey the letter of the law but not the spirit and at worst they’ll just ignore everything and keep doing what they’ve always done. Sure, you could spend a lot of time on monitoring and enforcing compliance but this is wasted time, money and effort. If you manage change correctly people will voluntarily move with you – without any oversight or coercion.

Unfortunately you see a lot of enterprise architecture groups starting at Step 3. Endless documents, models, policies and procedures are produced and disseminated throughout the organisation. The architecture group expects people to comply. But they never do. And they never will. It is really easy for various groups to come up with arguments why they are special and why the rules shouldn’t apply to them. Typically, those arguments are hard to refute. Even if the architecture group had ‘friends in high places’ which could mandate compliance, such an adversarial spirit between the central architecture group and other groups is counter productive.

You could start at Step 2. Starting here is an improvement over starting at Step 3 because you’re at least consulting various stakeholders throughout the organisation, rather than just forcing change down their throats. This collaborative and inclusive process means you can come up with a better and more complete vision of the future and it also means that people will be less resistant to change because they’ve had a say in what the change will be. The problem with starting at this step is that ‘less resistance to change’ is not the same as ‘support for change’. And you need the latter.

Again, you see a lot of architecture groups starting at this step. Often you see a new lead architect come in and try and change things to suit their personal preference. Or a new technology comes out and the architecture group incorporates it into their vision. The problem is that various project teams are likely to be cynical of the proposed changes and dismiss them as “change for change sake”. Even if the end state is better than the status quo people won’t change, largely because change is hard work. You need to show people that the difference between the future state and the status quo is big enough to make it worthwhile moving.

But you should be starting at Step 1. By process of elimination we’ve arrived at Step 1. The logical place to start. Obviously, there’s never any guarantees when it comes to something like ‘change management’ but as with everything, if you take the time to think it through, you at least give yourself a fighting chance of success.