Why doesn't everybody use Patterns of Business Activities?

Actually, that's probably a misleading question in the title. Most organisations use Patterns of Business Activity to some degree or other, just not formally, consistently, fully or universally. They might document some predicted usage patterns, they might have tacit understandings of what business activities result in those usage patterns but few organisations really think through the process from the business activity through to the usage demand across all services.

A Pattern of Business Activity (or PBA) is simply that, the documented explanation of the pattern to which you would expect to see a particular business activity conducted. 

EVERY business activity can or should be predictable (to a large degree) and many activities are well understood in terms of their nature.

The simplest examples are those activities which are very structured and repetitive such as monthly payroll processing:
It is know that at the beginning of the month the payroll staff will be, mainly, engaged in queries, entering new starters, updates and the like. Later in the month they'll start entering any payroll hours, adjustments, etc. and then towards the end of the month the payroll will be processed, the interfaces will be run to the financial systems and BACS is processed. In terms of staff resources this is a simple PBA as shown.

But the processing the payroll team need to undertake is just the business process (the PBA); the service provider needs to examine this and understand what services are used to accomplish each activity and what level of demand is represented throughout the cycle. Once you understand this you can make decisions about how much capacity to have available (processing, storage, bandwidth, support resources, etc.) at what time in order to support the business needs.


But, that's just taking a basic view. How about if you combined the PBAs for all of the business activities across the organisation? This would give you a clear picture of the service demands from all business units over the week or month or quarter or year. Or would it? Well, not entirely because all we've talked about so far are the regular aspects; those things which happen periodically and repetitively. It's also useful to add to this information all the business activity demands associated with all the changes predicted over the same period. This gives a complete impression of the anticipated demand for all the service providers services.

Once you've collected this information it can be used in so many ways:

• for portfolio analysis to identify what services and what elements of service need the most investment;
• during service design to determine the service architecture which will best meet the availability, capacity, continuity and security needs and determine the overall service level requirements;
• during testing to understand the baseline against which actual performance can be compared;
• during live operations to highlight points in the cycle where actual performance is not meeting expectations; and
• as part of continual service improvement to identify opportunities to better meet the business requirements in a timely and cost effective manner.

So, back to my original question: why doesn't everybody use PBAs? They're fantastically powerful ... trouble is that they take the business to understand their own business activities and the service provider has to understand the link between those business activities and the services that support them. This level of understanding is generally there but usually it's not documented and is relatively immature. But it's well worth putting it together.

If you'd like any help putting your PBAs together, get in touch with us.

Service Management, the supply chain and ISO22301

If a service is the about the service provider delivering value through outcomes without you owning the specific costs and/or risks, how come so many clients I visit concern themselves with, not just the service provider's competence and capabilities but the supply chain below their service provider? I think it's about trust and awareness.

To be honest, there are actually three types of client I visit.

• There are those who take it on trust that the service provider they have engaged with are suitably capable, competent and robust for their needs. They sign a contract with the service provider and assume that this will be sufficient (well there are words about consequential loss in there aren't there?).
• There are those who don't trust their service providers to the extent that they end up challenging the entire supply chain. This can end up in a hugely costly and complex exercise of ongoing assessments, audits, reviews and contracts.
• Then there are the ones who have understood that the idea is to get the service provider to prove their ability to service their needs in spite of situations which threaten the delivery capabilities. They demand that the service provider applies the same requirement on all of their sub-contractors and can demonstrate how they will continue to provide their contribution.

Historically, this has been an issue because there was no real way of proving this capability. However, ISO22301 is a new standard for Business Continuity Management against which organisations can be certified.

ISO22301 sets out the requirements for a service provider to put together a management system for understanding business risk and impact and plan their mitigation strategy appropriately. It sets out the responsibilities of senior management in  managing business continuity plans and arrangements. It follows a similar management system approach to other compatible standards such as ISO27001, ISO20000 and ISO9001 using the familiary Plan, Do, Check, Act structure for enacting continual improvement.

So, stop trying to make up for either your lack of trust of your service providers or your service provider's inadequate assurances and start insisting that they (and you) are able to demonstrate commitment to the provision of stability and continuity by looking at ISO22301.

If you want help understanding your needs around BCM or you've already made the decision to go ahead with ISO22301, give us a call, we'd be happy to help.

Unleash the power of Configuration Management

I'm a really big advocate of a good configuration management process and system but I'm always amazed at how many organisations I go in to see who either don't have a good CMS or don't see the potential or, worse still, both!

The basics of a configuration management system are really easy and even a simple CMDB can deliver huge benefits to all sorts of areas. The reason that some companies stumble is because they start complex and try to move forward from there. KISS is always the better approach. Start with a restricted scope (a single geographical location, a subset of configuration item types) and a simple structure (only the essential and easily controlled attributes and basic relationship types). This means that you can start recording the configuration information in something as simple as an Excel spreadsheet (although I've only ever seen that done successfully once and even then access to a wide audience of stakeholders didn't work well). You can certainly start with a simple set of SQL tables and a very basic Access front-end. One table containing the configuration items, one containing relationships ... easy yes?

So much for the basic version, I told you that this was about getting the power of configuration management. The true power comes from not trying to control everything yourself. It would be very useful if the CMS had a list of all users/employees wouldn't it? But, chances are, your organisation already has a database containing information about all employees ... the HR database. Connect or link to that. You'll also already have a system which records relationships between systems or applications and the users who use them ... Active Directory. Can you make use of that? Facilities Management will have information about the buildings, possibly even 'who-sits-where'. Finance have a list of all hardware and software assets bought, from whom, when, for how much. Procurement have a list of suppliers with contact information and the contracted services they deliver. Within yourselves as the service provider, chances are you'll have all sorts of small niche databases for things like telephone extensions, email distribution lists, shift rotas, etc. which can all be used as part of the whole richness.


That's the data sorted but the other major area that organisations come unstuck is managing and maintaining the information once you've captured it. I quite like the mnemonic I was taught to help remember the steps in the process: Perhaps I Can See A Vampire's Arm.

• Planning
  What am I going to record information about (what scope, what types of configuration item, what attributes of each type, what relationships, between what sort of configuration items, what statuses)?
• Identification
  How am I going to go about capturing new configuration items and the relationships between them of the type and within the scope I set in the previous step?
• Control
  During their life-cycle  each configuration item will change status as will relationships and attributes. How will I know about each of these changes? How quickly? From whom? What will I do about each?
• Status Accounting
  At various times I will need to be able to report on the information held; whether this be through a live interface for lookups and management/maintenance or through a reporting system. How will your provide the information needed for each audience or purpose?
• Verification and Audit
  Over time, there is the possibility that changes might be made to the production environment which are (shock horror) not adequately covered by a matching change control. This eventually leads to a situation where the CMS is out-of-sync with reality. To counter this effect, you need to, periodically, undertake a manual reconciliation of what there is against what you think there is and a) amend accordingly and b) seek to understand why the discrepancy occurred in the first place.

I guess that there is an argument that my interpretation of Configuration Management intersects a bit with Knowledge Management but, I don't care. I'd prefer for the service provider to have a powerful set of information/knowledge with which to make informed and accurate decisions but be unclear about which process this conforms to than stick rigidly to the ITIL process definitions and suffer reduce effectiveness.

So, hopefully you're almost as enthused now about Configuration Management as I am ... well, at least you can a) see the potential and b) see a simple way to start.

If you want to know more, please contact me and let's see how we can help you get the most out of this powerful process.

Why is value so difficult to deliver?

Service Management guidance tells us that a service is defined by the value we deliver to our customers. Such a simple concept but how many times do you feel, as a customer, that you've not received what you consider to be 'value'? Why do so many service providers fail to deliver value?

At the heart of a service provider's ability to deliver value are two factors:

- Understanding what the customer will consider as valuable; and

- Working out how to deliver that value ... consistently.

But these relatively innocuous statements hide a plethora of complicated detail.

Understanding your customers

Customer's will (somewhat annoyingly) not just base their judgement on what you deliver but on their preferences, prejudices and perceptions. Past experiences, peer reports, other options, rumours, misunderstandings; they can all affect how the customer feels about what they receive.

You could be delivering the service to the exact specification but an underlying mismatch of expectations on the part of the customer can undermine all your hard work.

So, how can you counter this? Well, by knowing your customers. Knowing their requirements (MoSCoW) is only one part of it, knowing your customer means understanding their history (where they've been, what they've done.), their current reality (what they are driven by or stressed about, what their personal and organisational objectives are) and where are they going (what their long term goals are).

Talking to them (and listening too)

Business Relationship Management seeks to understand what the customers' long term and strategic objectives and needs are but can be, mistakenly, viewed as a mechanistic process. It is not! Business relationships are just relationships whilst doing business ... people are people and do business with people. Ask lots of questions and really listen to the answers. Listen not just to what they say but also how they say it, what they don't say, verbal and visual cues, their comments and what cultural references they make. The main thing is to actually listen - it's sometimes difficult to really listen when you are full of enthusiasm and ideas.

And it's not just about capturing what they've said in such a way as allows you to regurgitate it later; you have to understand their needs. What does our service allow the customer to achieve (and, critically, what does failure to deliver all or part of our service prevent the customer from achieving)? This is what really represents value to the customer. Utility of a service comes from either supporting enhanced ability or removing constraints to the customers business processes. If your service doesn't do one of these ... no value. If you don't truly understand what the customer is trying to achieve then how do you know if you're helping them (or hindering them)? Warranty is about making sure that the service you deliver meets the living needs of the customer; is it there when they need it, to the extent that they need it? This is covered by the four factors of availability, continuity, security and capacity: When is it needed? What degree of absence can be tolerated? What assurances are needed around the areas of confidentiality and integrity? And, when it is available, what characteristics does it need to demonstrate in terms of throughput, scale, etc.?

Once you believe that you understand what will represent value to the customer, play it back to them; set a scene, paint a picture. It will help them to express to you whether you have it right whilst also consolidating it in your own mind.

Delivering that value

Hard as that first part might seem, it's just as common (if not more common over a long time period) to find service providers not following through on delivering the service in a way that addresses the customers value needs.

Having asked the right questions and really listening to the answers the service provider has to enact that into the fabric of their service delivery organisation so that everyone understands what the customer needs, how they needs it and what represents a valuable outcome to the customer. And, again, unfortunately it's lots of little things that all have to be done right not just the big things.

Here are some examples of where I think service providers have obviously got the right idea but their execution has missed the mark:

• Telephony service providers with, what I'm sure they feel are helpful, monsters of call centre menus ("Press one for support, two for sales, three if you're thinking of leaving us ..."). They know that customers want or need to call them; the customer doesn't want a series of numbers to call but it's essential for the customer to speak to the most appropriate person therefore have them call a single number and give them a menu of options.
• Web based supplier of goods who offer a 'no quibble' returns policy but you have to send the goods back via a specific network of collection points. Surely it'd be better to make sure that the goods sent were right in the first place but, on the basis that mistakes happen, if the customer has to go out of their way to return goods ...
• Live on-line chat facilities for your cloud storage provider (a good concept) ... except their live support staff are based in the US and aren't yet awake.

I realise that there is a big distinction between service providers with a known internal or known external customer base and those with an unknown external customer base. If you don't actually have a direct relationship with the customers of your services it's harder to know exactly what drivers and triggers there are but that only makes it more important that the customer is made aware of what the service will deliver and that it is delivered consistently to that specification.

What goes wrong?

Overall delivering service is at the heart of every business transaction; it's something that people have been engaging in for thousands of years but we still often get it wrong.

The problem is that delivering a service has to result in a mutually beneficial situation: I deliver these outcomes to you in return for you paying me. One of the things that I think goes wrong is that each side are out to get the most they can from the transaction:

• The service provider wants to make a profit and so greed slips in and they charge more for a service that they really should which leads the customer to expect more for their money.
• The service provider becomes lazy or apathetic about making sure that what they deliver represents true value.
• The customer has unrealistic expectations about what the service entails and so constantly feels 'cheated' by being charged for something they're not getting.
• The customer's requirements have changed but either nobody asked or nobody told. Over time the service being delivered diverged from what the customer wanted or expected.

What can we do?

The main thing keeps coming back to communications. Asking questions, listening to answers, stating expectations, confirming facts, verifying success, reassessing requirements ... a never-ending cycle of assessing what is needed and how to best deliver it in a way that shows the customer that you understand their needs (not just that you remember their needs - you understand them). That's all - dead easy right?

Continual Improvement - Part 1

In this first article on Continual Improvement, I'm

going to look at the considerations you need to think about when designing and introducing a systematic approach.

Most organisations are doing improvement to an extent whether because the organisation has a pervading quality improvement ethos or just because people notice that things need to be done differently and so change them. The principle of Continual Service Improvement (CSI) is not to introduce anything new, per se, but rather to improve the maturity of what is being done and how it is being done.

So, the first thing to understand is that you are not implementing something new, you are introducing an improved way of improving things. This will often get around some of the resistances that you might face from people who already believe that they're doing continual improvement and so resent the implication that they're not. It might also help with some of the funding issues which dog 'implementation initiatives' as gradual systematic improvement is what the organisation wants and needs (there may still be costs associated but they are generally easily palatable).

Since what you are trying to do is to create an easy, coordinated, common approach to improvement, enlist the support of key individuals. Create a stakeholder analysis which shows who might be able to help, who might resist, etc. and base your messages around this.

Leading on from changing the way you perceive the introduction of continual improvement and understanding who needs to be convinced, you need to craft the way you express, word or phrase any messages about the activities, actions and benefits of this (better) way of doing things. Even though you have accepted that continual improvement is already being done, perhaps in small, uncoordinated, pockets, if you tell people that there's a 'new sheriff in town' people will resist.

As Stephen Covey says "Seek first to understand, then to be understood", make sure you know what is currently being done before diving in, telling people what to do ... you never know, someone there might already be doing it in a way that you'd not thought of.

How not to do it ... Metrics

Metrics, measurements and KPIs are merely decision support tools. In order to make the correct decision you need the right information, at the right time, interpreted correctly and presented correctly. You can then make your decision based on accurate facts. Once you have acted upon the information you can then review the information collected both from the perspective of what it was but also in terms of how useful it proved.

Seems really easy doesn't it? But there seem to be innumerable ways to muck it up:

• Failure to identify
  If you don't identify the right metrics to capture then how can you possibly make a decision based on the correct facts?
• Failure to collect
  Even when you've identified the right metrics to capture, often technical limitations get in the way or an incorrect interpretation of the priority or importance is put on the metric and it's simply not collected.
• Failure to interpretI saw one brilliant explanation of this where gun crime in the US was mapped against the take-up of Internet Explorer over the past 10 years which showed that as more people began using Internet Explorer, gun crime rates went up correspondingly. Whilst I'm no fan of that browser, I think that the facts are pretty unlinked but it shows how disparate facts can, if carelessly used, 'prove' a complete fiction. Equally, if you see a correlating increase in Incidents as the number of Changes increases, this could mean there is a relationship but not necessarily.
• Failure to extrapolate
  Basing your decisions on the information as it is now fails to recognise that things change. You often need to project the information forward and make prediction. Obviously this introduces a degree of uncertainty in itself but better than using old information.
• Failure to interpolateTaking a macro view may give a good indication of the overall direction but might miss the shorter term variability of the information. The trend might be upwards over the course of 6 months but might indicate a sharp dip in the intervening months which could indicate a different option.
• Failure to connectAlmost the opposite of 'Failure to interpret' sometimes there are interconnections that we do not spot (e.g. the apparent inability of local authorities to predict the need for school places based on changes in birth-rates).

Just remember, it's not completely accurate that you can make statistics say whatever you want. You can, if you're careful, get them to tell the right story but they can, easily, be totally misconstrued or give a completely false message.

Believe that you can …

I like rock climbing. I won't say that I'm very good, I'm alright at it. But I discovered, last night, that I'm limiting myself by my own perception of my abilities.

At the indoor climbing wall I go to, there's usually a list of all the routes and the 'grade' (an indication of the complexity or difficulty) of each but, earlier this week, they changed the routes around and haven't, yet, listed the grades for each route.

Now, normally, I'd look at the list to decide which routes to attempt based on the grade I think I'm capable of but, obviously, I can't do that at the moment, so I just started picking routes … and haven't failed on one yet.

The point is that sometimes we limit what we'll have a go at based on how complex something is versus what we perceive about ourselves. Doing this means we're unlikely to fail but, it also means that we're stopping ourselves reaching our potential.

Sometimes you just need to believe you can.