The point of presenting this graphically is to establish two fundamental principles: firstly, the goal is change (not pretty documents); secondly, the elements of activity which you undertake to achieve that change are interwoven, cross-over, confuse and interrupt each other, but are fundamentally one of the same thing and that is, achieving change. Different types of people like to focus on different parts of the process, but if they are allowed to become completely separated or sequential, the project will probably fail. They need to be managed together.

So how do you do that?

Having issued that dire warning, I have no choice but to look at the individual elements and talk about what to do. But don’t forget: they’re not entirely separate!!

Defining the impact that you want to achieve.

Steven Covey says, “Start with the end in mind”. This is the ‘Why?’ question. Why do you want a management standard? Are you getting too many project overruns? Is your internal control inadequate?  Is staff turnover too high? (What is the ‘right’ level of turnover?)  Are you not getting to market quick enough?  Do you want more innovation or more reliability?  Do you want more autonomy or more compliance?  A word of warning; people can give very vague answers to these questions and it is very easy to collude. “We want more teamwork” or “We want more consistency” are examples. Why? What would more teamwork look like? What would it add to the bottom line? What would you need to sacrifice in order to get it?

It’s important to ask these questions. As you can see, you may well be wanting things that are essentially in conflict. And here’s trick number one: you don’t have to resolve these conflicts. Of course modern organisations are complex and roles are diverse. Sometimes you want both hard and soft, blue and green etc. If they have equal weight, acknowledge that and move on. The risk here is that you go too far in one direction and end up undermining management behaviours that actually hold your organisation together. Beware particularly of discouraging the less glamorous, but valuable contributions. Too many stars and you’ll overheat.

This is the element where you need the most buy-in because buy-in here gets you commitment later. It leaves you freer to design the solution. Think about everyone affected: directors, general managers, managers, technicians, support staff, customers, even people who haven’t yet joined the organisation. How you get buy-in and who from is going to be different for different organisations, so I’m not going to go into it here. The point is that if the key stakeholders believe the job needs to be done and that you’re working towards the right outcomes, you’ve saved yourself a lot of grief later on.

Where you want to get to with this part of the process is to have a clear idea of what is going to be different, and how that impacts your business. Although this is an up-front activity, you’ll need to cycle round, revisit and revise as the project progresses.

Expressing the standard in a meaningful way

This is where many people start. Of course, you haven’t. You know that knowing where you’re going is the foundation and without it, you’re building on sand. So what do you need to do here?

The first thing is a design question. How comprehensive and how rigorous?

At one end of the spectrum, you’ve got the very simple and very accessible statements of intent: a kind of charter or commitment that is so simple that everybody can pretty much hold it in their heads. It’s the kind of thing that can squeeze onto a credit card sized fold-out. This is the “Remember the Force” style of thing. Maxims that can be called to mind in a crisis. For example, “If in doubt, trust the customer”; “The great manager’s door is always open”; “Who have you helped today?” (It might be a worthwhile exercise thinking through what these could be for your organisation.)

These can actually have enormous power. As generalisations they’re never completely wrong. They can enter rapidly into the culture and become a way of life in the organisation. The downside is that they can be somewhat pat and appear trivial to the cynical. They are not comprehensive or sophisticated enough to guide people’s development.

The other end of the spectrum is the comprehensive capability framework with specific behavioural indicators. Typically developed by gathering desirable and undesirable behaviours, prioritising, sorting and resolving down into a hierarchical structure of headings, sub-headings and specific examples. You might end up with a heading of “Teamwork” (many companies do), which is further broken down into things like “working cross-functionally”, “helping colleagues’ development”, and “championing the wider business perspective”.  Each of these will have indicators like “actively seeking opportunities to participate in cross-functional projects”; “ensuring the needs of different departments are integrated”; “demonstrating a proper understanding of business issues outside own area”.  Sometimes these are expressed as “Do’s” and “Don’ts”.

These frameworks have the following key strengths: they are explicit (so people know what it means), and they are comprehensive. This means that they can be used more easily across all people processes: development, reward, selection, and recruitment. This could become a critical influence on the success of your implementation.

As mentioned in the introduction, these can be developed top-down (starting with strategic planning at the top of the organisation), or bottom-up (starting with the “coal-face” issues at the bottom of the organisation), or a combination of the two. Top-down is supposed to drive development more strategically. It is more future facing. It is inherently more speculative. Bottom-up is more remedial. It is inherently more conservative and can be criticised for “freezing” the current organisational culture. My personal belief is that different competency frameworks come out more similar than the above would suggest. Most companies approach the development task as a pragmatic combination of top-down and bottom-up and come up with a fairly generic result that’s pretty interchangeable among similar organisations.

Does this mean how you go about it doesn’t matter? Well actually it does matter. It matters because this drafting stage is part and parcel of implementation. So here’s the second question to consider: what form of representation will the stakeholders best respond to? I don’t think there is any generic answer to this. Generally speaking I favour relative simplicity, strong integration with other people processes and face validity. The content should be concrete, practical and flexible. But all this is a negotiation. A dance. A pas de deux with the current organisational norms.

Finally on the question of drafting, a couple of warnings:

Firstly, don’t believe you can get it “right”. There is no single right answer and it’s incredibly important to remember that. One person will tell you it should be a certain way and someone else will surely tell you the opposite (usually after you’ve changed it). It can drive you to distraction. This is why it’s important to know where you’re heading. You know what you’ve got to achieve and you’ve got to make the decisions that mean you get there. You are going to have to say “no” to some people some of the time. (If you know you’re going to hit a “no”, you can always try slipping a “yes” in earlier on.)

Secondly, don’t fall prey to the God of inclusion. It’s like sorting out priorities. The more there are, the less priority there is. I had a conversation once with a manager about the inclusion of foreign language ability in a competency framework. They were running a team where speaking a foreign language was a ‘must’ and they wanted that contribution overtly valued by its inclusion in the framework. There was no way I was going to do this. The rationale was that it was not a significant element of the generality of roles across the organisation. I’ve seen frameworks where to get buy-in, the development team have taken an inclusive approach, pulling in near enough anything and everything that was suggested. The outcome is a lumbering beast of a document that runs into the sand, taking the worthy efforts of conscientious managers with it. Don’t go there.

Implementation

Finally we come to implementation. If you’ve been following my argument, of course, you’ll see that we’ve been talking about implementation all along. Without going into a treatise on change management, I want to highlight just three issues:

Firstly, there is an obvious choice between a “big-bang” and “drip-feed” approach to implementation. If you’re implementing gradually, you might go for a pilot business area, or you might go for one people processes at a time (say, development first, iron out some of the problems, then selection and so on). The pros and cons of each are well rehearsed elsewhere. The only note I make here is that either way there needs to be an ongoing commitment to updating and refreshing the standard. It needs to be kept stable enough for people to stick with it, but not so fixed that it cannot be improved.

A second choice is around how non-conformance will be dealt with. It would seem ill advised, both from a popularity and possibly a legal perspective, to bring down the guillotine on managers who do not meet the new requirement. On the other hand, you do want people to sit up and take notice. How will the standard integrate with your current performance and reward systems, and when? One approach would be to implement it immediately on selection. This creates a “pull” effect on development.

This leads us onto the subject of integration. I believe that the more integrated your people processes, the more effective they become. It’s like a fleet of tugs all pulling a great tanker in the same direction. Obviously this introduces a level of complexity, and in particular many people raise the question of the conflict between development and performance/ reward aspects of standards. How do you have an open and trusting conversation with a manager about where they need to develop, and then on the basis of that, decide how much they should be paid? This is a topic in itself. Very briefly, the most elegant solutions I’ve seen avoid rewarding competence per se. They reward results and competence development. So in the annual review, the manager is set both job-related targets and development targets. This both sidesteps the conflict and clearly signals development as a legitimate investment.

These points on implementation only serve to underline the most important consideration: that this is a change project and you can’t afford to forget it. You need to win the hearts and minds. Talk, write, and shake hands with people. Silence will be taken as exclusion. Quiet progress will be taken as plotting. Don’t think that there’s no point communicating because you’ve got nothing new to say. It’s not much fun, but if you have to, stand up and say that you’ve got nothing new to say.