Invest in your corporate brain

The brain consumes about 20% of the body’s energy, and that is why we are by far the most dominant organism the world as ever seen.

From the point of view of development, I would say that formal processes represent about half of every company’s brain – a good deal of its memory, its practical skills, its controls of perception and behaviour, quite a lot of its capacity for reasoning, balance and coordination, and most of its basic language and social skills.

On the other hand, most companies' formal processes - their lifecycles, their operational mechanisms, their ways of working - are designed more like the brain of a crocodile. (The analogy is more exact than you might imagine.) They are spread out across they organism, they barely speak to one another, they are almost never tailored to the practical needs of their users, they are seldom created with a meaningful outcome or benefit in mind and never tracked or measured to see whether they are doing their job and seldom fixed even when they plainly aren't, they have no effective direction or ownership, they are formally changed in an arbitrary and impulsive manner, they are never changed to anticipate a real problem, and so on.

Without major evolutionary leaps processes like this will never evolve into something truly intelligent.

Why is this?

It is, I think, because we don’t bother to invest in them to the extent necessary. Perhaps we just can’t believe that they need maybe 20% of all resources. Perhaps, like the brain itself, the significance of these processes is lost on people who, almost by definition, cannot see what they contribute. After all, we only need to invest so much in a corporate nervous system because most the useful things an organisation does require a span of knowledge, control and attention no individual possesses. Hence the paradox of processes – they are installed because we cannot manage such vast and complex systems, but even when they are installed and doing their job perfectly well, we seldom construct, implement or support them in a manner that really improves our view of the whole. We are still cogs in a machine that, although it may now be working better, we still cannot grasp processes as a whole.

So what needs to be done to improve our grasp? There are quite a few things that can be done:

1. Engineer processes properly in the first place!
   
   1. Make it a collective activity, don’t under-estimate how much effort it will take, or the hidden cost of getting it wrong.
   2. Start with a clear end in mind – and constantly test processes to see whether they are doing their job.
2. Make sure everyone understands what the processes are for – i.e., don’t allow people to wander blindly through their work.
   
   1. Train everyone and train in detail. The ROI on training is higher than the ROI on almost anything else in management.
   2. Not training is not only completely counter-productive but also extremely demoralising and defeats the purpose of hiring intelligent, capable people.
      
3. Do not over-engineer processes:
   
   1. Define standards and processes in terms of functional goals, not detailed technical steps, so they can be implemented and adapted locally.
   2. Conversely, explicitly Maximise local discretion and flexibility, so decisions made remotely cannot inadvertently force absurd actions locally.
4. Make sure that you can fix any problems with the process.
   
   1. Instrument the processes to make sure they tell you how well they are doing without having to ask specially.
   2. Have an intelligent waiver/exemption process so local teams can escape the worst excesses of processes not defined for their purposes.
   3. Part of every well-defined process is the possibility of changing it. It will need changing, and you need that fact into it. So make sure that all processes are owned, with clear local accountability and authority to improve. Invest in the time and re-training needed to do that.

There’s a lot more, but if you are already doing all this, you probably have other things you should be focusing on instead.

APM's mastery of metrics

A colleague kindly sends me the output from the recent APM Assurance Specific Interest Group, which focuses on assessing project quality and performance. It's quite nice, at least by the standards of the profession, though with occasional lapses into half-baked thinking. As usual with most would-be management experts, they are obsessed with turning everything into quantitative measurement. It's not a bad idea in itself, though the uniqueness of individual projects and the fact (yes fact) that metrics are only a means and never the end) do suggest that the desire to be measurable is leading them to pointless and inconsequential quantification. This in turn leads the result that the attempt to provide a solution results only in a more and more artificial definition the problem.

Take, for example, their attempt to quantify RAG ratings. I'm firmly opposed to this on principle - RAG should define a qualitative difference in consequence, not just an arbitrary definition of the 'Oh-well,-1-to-3-can-be-red-and-4-to-6-amber,-and-oh-how-can-we-say-that-10-is-really-special?-I-know,-let's-make-it-blue!' variety.

Exactly how objective and rigorous this is comes out when they find that they can't actually tell you what the difference between neighbouring scores actually is. Their scoring for 4 is 'Better than a 3, but some elements required for a 5 rating are not in place'. And for 7? 'Better than a 6, but some elements required for an 8 rating are not in place'. As a colleague immediately responded to this marvellous insight, 'No shit, Sherlock…'

I suppose there is some kind of sense in this. It lets you to deal with the all-too familiar situation where you find yourself unable to decide between alternatives. But unfortunately all that really means is that the scale you are trying to use is not defined objectively, rigorously or consistently enough (usually because, in my experience, it isn’t a single scale at all). But that is only to say that it is still too immature to be used. But here it is, being recommended as a professional standard. Which leads me to refer the refer the reader - and the APM - to my previous piece on professionalism.

The rest of the paper is riddled by the sort of inarticulacy and arbitrariness that suggests that project managers probably shouldn't be allowed to write standards or even evaluate projects. I particularly despair at the description of what needs to be in place to get a 10: 'Processes have been refined to be best practice. IT is used in an integrated way to automate the workflow, providing tools to improve quality and effectiveness. The project is demonstrating innovative techniques, thought leadership and best practice'.

No definition of best practice, so it starts with a completely meaningless idea. The assumption that the Nirvana of management is automation is also a bit scary: providing IT-based tools to manage workflow and improve quality and effectiveness, far from being best practice, is about as basic as it gets. Well, it is around here. As for 'demonstrating innovative techniques, thought leadership and best practice' (there it is again!), having led innovation management programmes and having routinely laughed/despaired at the quality of thinking that portrays itself as 'leadership' in most organisations, I am astonished at what the APM has been prepared to release under its banner.

(For what is, I think, a slightly more intelligent approach to RAG statuses - which is to say, on is focused on action, not measurement - try here.)

Agile: Guidelines or methodology?

Another discussion on LinkedIn, this time about whether Agile is a methodology or just guidelines. The consensus seems to be guidelines, which seems to reflect the spirit of Agile better.

But at the same time, this view seems only to address Agile in the abstract, not Agile (or any other delivery model) as implemented in any real organisation. Which is a pity, because it is at that point that the strains will start to be felt if Agile remains no more than guidelines. On the other hand, to convert it to a formal corporate methodology would not only defeat much of its underlying philosophy and approach but also lead to Agile being ossified in the same way that waterfall – which was never inherently rigid or bureaucratic – was ossified by immature implementations and too much top-down corporate management freakery.

And of course, there always been legitimate management reasons why Agile cannot be left to go its own way, any more than any other management tool. There will be inescapable (and entirely reasonable) reporting requirements, stakeholders will often want to know what progress is being made in non-Agile terms, and so on.

So, for any organisation that does not want to see something as promising as Agile degenerate into either paperwork or making it up as you go along, it is necessary to be rather more specific about how either a Agile-as-methodology or Agile-as-guidelines is implemented.

So even if Agile is to be forced into the mould of a corporate methodology, any self-respecting implementation can features that prevent it from becoming a rigid, inappropriate and self-defeating. For example:

• It will be specifically tailored to the type of work that is really being done.
• It will be abstract enough to permit considerable leeway for professional judgement.
• It will be fully scalable (no, not just big, medium and small).
• It will include user-friendly mechanisms for granting exceptions and waivers.
• It will include wide-ranging but rigorous (the very opposite of rigid) ranges of meaningful options.
• It will be implemented through training and tools, techniques and templates that make explicit the team’s authority to vary, depart from or just plain ignore the ‘rules.

And so on.

I don’t see that any of this gets in the way of Agile, or how any complex organisation could safely or profitably implement it without at least a few of these quite standard methodology components.

Two Cheers for Bureaucracy

‘So, you love bureaucracy,’ said the researcher from the BBC. ‘Can you tell us why?’ She’s calling in response to my response to a BBC blog piece entitled ‘Are there too many bureaucrats in the UK?’, where I had indeed admitted to loving bureaucracy.

‘Well,’ I reply, ‘“love” would be putting it a bit strongly. But I do think bureaucracy is the most important thing humanity has ever invented.’

I see. Not content with loving these crushing administrative behemoths – he thinks these embodiments of all that is wrong with the modern corporate world are our greatest achievement. What will the funny man say next – that toothache is a much undervalued pleasure?

But it’s true. Bureaucracy is the nervous system of society, and has been for five millennia. It puts electricity in the wires, food on the supermarket shelves and controls business and government’s every move. It puts these words in front of you right now.

So what does a bureaucracy do that society finds so invaluable? It controls the flows of information and decisions an organisation needs to carry out its activity. Different bureaucracies do this more or less well, but as long as society includes lots of different individuals doing lots of different things, and they need to collaborate across wide spaces and long periods of time, then something has got to organise them, and it’s hard to imagine any alternative that won’t be bureaucracy by another name.

But why does bureaucracy have such a bad name? Why does so much of it seem to degenerate into red tape? Why are politicians constantly planning to cut it?

The full answer is complicated, but the first part is simple. Contrary to popular feelings of frustration – feelings I share whenever they break down on me – bureaucracies rarely go wrong. A past colleague of mine, Melissa, had a useful analogy: bureaucracies are the brains of society. But, she would add, like the brains that control our bodies, ‘we only notice society’s bureaucratic nervous system when it stops working. Any idea what your visual system is actually doing right now? Me neither. But we’d all find out soon enough if it stopped doing it’.

Hence the ease with which a bureaucracy gets a bad name. Most work just fine practically all the time, but who gives thanks for the good old bureaucrats when the lights go on or our salaries arrive on time? When it goes wrong, though – the wrong tax demand, the double booking, the failed delivery – who doesn’t automatically curse the idiots who made this mistake? And if it it’s only when it goes wrong that we notice bureaucracies, how can we help but have negative feelings about them?

Actually it’s astonishing that bureaucracies work as well as they do. Even to professionals, it’s quite intimidating how much information and what a complicated process you need to come to what seems a simple decision. It takes careful thought, a strong sense of purpose and a great deal of effort to design, build and manage a bureaucracy of any size, let alone having it perform note-perfectly. And as soon as its parent organisation starts to change – which can well happen unintentionally – the bureaucracy also has to change. Given that change is increasingly a way of life for organisations, it’s not a recipe for easy success.

On the other hand, the fact that bureaucracies are as imperfect as any other human creation is no argument for less bureaucracy. That would be like saying that, because cars sometimes break down, we should have fewer of them. Now, there are lots of reasons for having fewer cars, but that isn’t one of them. And just like your car, bureaucracies need occasional maintenance – which, in my professional experience, they seldom get.

Not that I’m complaining. Most of my living comes from fixing management systems that have been allowed to wither – just recently one of the biggest UK supermarkets, a major player in the City exchanges, a healthcare company. They’re all equally lax about keeping themselves sharp – which is, after all, what even they say their administrations are for. Rather worryingly, though, I haven’t had to learn much in the course of two decades advising companies – there are still plenty making the same old mistakes.

And every time I hear about some big consultancy or software company building yet another huge IT system for the government – often to the tune of hundreds of millions of pounds – I just remind myself remember that an IT system is simply an electronic bureaucracy. Given how badly we handle the paper variety, it is small wonder that so many major IT programmes – private as much as public - turn into a ‘bureaucratic’ quagmire. Years late, millions over budget, and few happy with the final result.

In fact the way these huge government projects have so often failed illustrates what is wrong with the way bureaucracies – paper and electronic - are often treated by their owners. No one is quite sure what they are for, and executives are often allowed to make endless new demands for new information, new reports, new updates, without thought for the cost and disruption this entails. They’re also often allowed to change their minds in midstream. In fact the stream of fundamental mistakes seems to be as endless as it is easily repeated.

Middle managers and staff then have little option but to turn their administrations into all things for all men: saying ‘No’ is too often a definite Career Limiting Move. And from then on, many bureaucracies face a constant demand for more and more, frequently with little budget or resource to do more than kludge together a jerry-built ‘solution’, which its ‘stakeholders’ then expect to have at their disposal forever. And if you add to this the number of reports that bureaucracies dutifully prepare and are then never read, you can perhaps imagine the disillusionment felt by many bureaucrats.

So what is the end result? Ask the people at the sharp end. Call centre staff – the modern face of faceless bureaucracy – are quite routinely the butts of public scorn. Usually paid little more than the minimum wage, they are expected to answer perhaps 60 calls a day, day in, day out. Could you do that? I’m not sure that I could. And then there’s the abuse – not least the racial abuse routinely received by Indian call centre workers.

As one anonymous call centre worker put it on The Weekly Gripe website, ‘It's shocking how badly these people are treated. First of all they are blamed for a multitude of sins by the customer about things that are completely beyond their control. As if that isn't bad enough, next they are treated like cannon fodder for the company to blame when it all goes wrong’.
Or perhaps it’s in the nature of call centres: ‘I am sure a lot of people have the kind of mind set that means if they cannot see the person they are talking to, it is somehow perfectly acceptable to be rude, abrupt and patronising’.

Do the staff deserve it? Of course not – and no doubt most abusive callers know that. But faced with delays or not being able to get what they need, who else is there to explode at but the anonymous, faceless innocent at the other end of the line?

All in all, it’s astonishing how pleasant and polite the average call centre worker remains – but less than astonishing that the industry as a whole has staggering turnover rates. Industry figures suggest about 20% each year – which in turn suggests that the average call centre worker stays for five years. Hard to imagine. But research by George Callaghan of the Open University has challenged the official figures, concluding that the average worker stays only eighteen months.

‘Many employees expressed extreme frustration with their jobs. They were under the impression they were employed for their great people skills, but then not allowed to use those skills’, Dr Callaghan observes. ‘This is one white collar environment where employee performance is measured by the second.’

It’s a familiar accusation: bureaucracies crush the life out of professionals through their constant demands for risk assessments and reports and the constant micro-management of every aspect of their work. The public services especially seem to be prone to this – scrutiny of them is so much more intense.

Yet this is not really the result of bureaucracy as such. It is perfectly possible to design the rules that govern an organisation to include great latitude for personal discretion. They can also be built to be extremely flexible and adaptable and to be responsive to change, personal experience, unique circumstances and individual needs. It’s not bureaucracies that are at fault, any more than word processors are to blame for bad novels.

Bureaucracy as such requires only that information and decisions are designed and organised well enough to get the larger job done. In a public service organisation like a hospital, a school or a social services department, it would be perfectly possible to treat broad sweeps of professional activity as ‘black boxes’, leaving precisely what is done and how to the professionals.

The bureaucracy might also need to know a little more about how the job is carried out – who actually did the work, what resources were used (for inventory purposes only), and so on – but more than that? Only if there was a compelling reason. These people are, after all, professionals. You have employed them because they know how to do the job better than you do.

So what counts as a compelling reason for more bureaucratic control? Well, one thing shouldn’t: a media frenzy. Because even where tragedy strikes, it’s hard to imagine a better recipe for creating the wrong answer than covering your back.

After the Baby P tragedy, ‘The front-line professionals – teachers, health visitors, doctors - took fright’ recalls one healthcare worker, who prefers to remain anonymous ‘and started to make far more referrals to their local social services department. But at the same time, our own local social services department started to block direct calls between outside professionals and their staff. They even changed their telephone numbers so we couldn’t call them personally. Then we’d have to go through a long Q&A session – who we were, the child’s name and address, a lot of other details – when all we wanted was to have a quick chat, professional to professional, about whether they needed to know more about our cases. Mostly they probably wouldn’t have wanted us to refer them, but we had to go through the same rigmarole every time.’

A typical bureaucratic response to a crisis. It’s hard to see how this sort of control over professional communications made a child any safer, but it’s easy to see how it would protect the organisation.

‘Of course, when we finally got through, we just exchanged our direct phone numbers anyway, so the system was side-stepped almost as soon as it came into existence’, added my informant.
But this isn’t really the result of bureaucracy. It’s the result of managerial paranoia. Well, perhaps not paranoia – after all, a social services department’s fear of another media feeding frenzy is well founded.

So the answer is, not more bureaucracy or less, but getting bureaucracy right. But this is not something that is likely to be achieved by politicians and business executives who understand little about their own organisations’ administrations beyond the a priori assumption that it must be a bloated monster.

So the first step is to take a serious look. No, don’t hire a consultant to do it for you – go and look yourself. Martin Long, founder and ex-Managing Director of Churchill Insurance, insisted that every single Churchill employee spent regular mornings doing someone else’s job, including a turn on the call centre phones, and then suggesting three things to improve the work. Nor was he above taking a turn himself – indeed, pictures of Martin on line to customers were familiar to everyone.

I have often thought that every MD and CEO should spend some time anonymously taking a closer look at their own organisation. Like King Harry before Agincourt, a stroll past the foot-soldiers’ tents might teach them a thing or two – a very surprising thing or two – about the organisations they imagine they understand. (They just need to avoid the shameless logic chopping Shakespeare puts into Harry’s mouth.)

It’s not hard to do better than most organisations are doing right now. In fact there’s a bit of a vogue these days for so-called ‘lessons learnt’ systems that actively prompt a bureaucracy’s operators and users to feed their experience – good and bad - back to the managers who can do something about it. But it’s too early to get excited - this is only the latest of many rounds of self-improvement technique that have not quite solved the problem. Or rather, quality circles, kaizen, ‘lean’ management, Six Sigma have all helped to make bureaucracies more efficient, but whether they have made them better for their workers, customers or even the organisations that own them is a question that remains to be answered.

Still, lessons learnt systems need to be tried, if only because, unlike many other improvement tools, they ask the fundamental question of what the bureaucracy is ultimately for. It’s a bit fiddly and for many organisations deeply counter-cultural. But it’s a lot cheaper than the millions they dole out every year to consultants like me to dig their existing bureaucracies out of the pits they have created by years of poorly thought-through initiatives, weakly managed change and simple neglect.

In sum... One cheer for the general idea of bureaucracy, though it’s seldom carried out well. Another cheer for the poor bureaucrats, the butts of everyone’s scorn. But no cheers at all for the many organisations – private as well as public – who just don’t get it.

[Listen to the original BBC broadcast here.]

Implementing a methodology - do's and don'ts

An old friend sends me the outline of an IT methodology he is being expected to implement by a big client. It’s the usual bureaucratic behemoth and he asks me what can be done to make it work decently. My reply:

"Thanks for this. I read as much as I could bear and skimmed the rest. I can see why they’d hate it!

Going by this description, I had a similar problem at a large client financial services where I spent 2½ years implementing a global consultancy’s not very lovely methodology. They hated that too, but we eventually got grudging support and even commitment.

I guess that you could summarise what I would do as follows:

1. Insist on taking training very seriously – train everyone from top to bottom of the company, tailor the training to their exact needs, and as far as the delivery teams are concerned, don’t let anyone tell you can do this in less than a day for the introduction and a day for each major development stage (or discipline, perhaps). I personally trained more than 800 people in methodology at one client and they grudgingly agreed that it was money well spent. I think this which as because the training included lots of ‘whys’ as well as ‘hows’. That way people were constantly given the message that there really is a compelling reason to do this stuff, that this really is for your own good – as engineers, as professionals, and as people who don’t want to waste their own time or other people’s. The training has to be full of useful nuggets (eg, 40% of all software engineering is waste and rework, primarily for lack of decent processes), war stories, realistic exercises (ideally one big case study) and methods for finding that magic 80/20 position.

2. Encourage PMs to create tailored versions of the methodology for themselves. This is easy and reasonable and builds ownership. Given that it means cutting out waste and rework and building in the uniqueness of local areas, your client should want it too. After all, if the generic methodology includes stuff (as it always does) that doesn’t make sense in a given project context, they shouldn’t have to do it. And make sure that you build the process for tailoring the process into the main process (e.g., as a project initiation activity), make it a high priority item in training (for senior management too), and reward managers for being insightful and innovative.

3. Scale the methodology thoroughly – with a two-page checklist for truly tiny pieces of work, and a serious approach to low-risk work that really does require only a light touch. But never say that the process is optional. It is never optional. It is simply adaptable. Build in get-out clauses for compliance, take the maintenance people’s problems with project-size methodologies seriously, create massively simplified tools appropriate to very low risk situations. Make sure everything is driven by a clear sense that real risks are being managed rather than a formal procedure being complied with. But never let them do nothing – that’s just the thin end of the wedge.

4. Make the waiver/exception process as simple as possible. Quick, clear lines of authority (ideally as local as possible), 5 questions maximum, rapid response guaranteed. I would suggest simple answers to questions like:

• What do you want an exception/waiver from?
• Why do you want it?
• What will you do instead?
• Why is that better than the standard process?
• What residual risks does that create?

5. Ensure that the methodology is properly owned, so that there is someone to go to for a decision on what is really meant or needed by a specific item, or to approve an exception. This is crucial if the system is to continuously improve itself – someone has to have it as a high-priority responsibility to actually improve it.

6. Support users constantly by training a methodology expert or two (one of my clients had 6-7 for 600 engineers) providing training, internal consultancy, project management consultancy, explanations and ideas for quick wins. They also provide a powerful conduit for communicating new ideas between groups.

7. Build an decent wiki (not a fixed website) that provides high-level process flow models to remind people what to do, and which can be drilled down for more details, online forms, etc. This paper you sent me is a prime example of a format people just won’t read – even I felt ill just looking at the endless levels of heading number. On the other hand, it’s not a bad script for a training course, so it’s not wasted. Even something as simple as online PowerPoint presentations are very effective, although they tend to offend web purists! I have a couple I built for Citibank, Churchill Insurance, Amex, Accenture, etc., if you’d like the see them.

8. Build an effective lessons learnt system that completes the loop from project experience to the methodology and back (through rollouts and training) back to projects.

9. Finally, pure stick: Tie their bonuses to compliance with the methodology, as confirmed by an independent assessor. Brutal, unpopular, initially counter-cultural in many companies but amazingly effective. It provides a somewhat perverse way of dealing with the inevitable feeling on the software engineer’s part that they have little interest in complying other than simple obedience to a very dubious corporate rule – if all else fails, fine them for non-compliance. Having dealt with thousands of IT people, I can only say that it has its place in the methodology implementation toolkit.

I dare say that some or all of this could be sold to anyone who a) hated methodology enough; b) had no choice about complying; and c) could afford the likes of me to make it work!"

Don’t measure what you won’t manage

I would guess that everyone in business has been asked to fill in a timesheet with dozens of charge codes - one for this project, one for training, one for admin, one for this other activity, one for... The list is usually endless. And equally endless seems to be managers’ craving for more and more data. Right now I am working in an otherwise quite sane organisation where I am nevertheless expected to complete a timesheet in excruciating detail. Given that my time is not chargeable and I’m supposed to be the metrics and measurement guru around here, it’s all a bit galling, to say the least!

Asked what they use it for, the answer often turns out to be ‘Nothing at the moment, but it will be useful...’ Oh really? Useful for what? And when? Naturally I don’t push this too far – some things are just corporate obsessions, and it’s definitely a Career-Limiting Move to question them too harshly.

Yet there are times when this fetishisation of numbers becomes quite bonkers. Two variants are especially stupid – when the data is deliberately falsified, and when the cost of collection is wildly over the top.

Take for example a consultancy I used to work for. A timesheet was put in every week, and then our chargeability was reviewed by the board – of which I was a member. Then one day I found myself being firmly reprimanded by the Chairman himself to the effect that no one was supposed to book more 37.5 hours a week. In fact I had booked 62. So I asked him, Whose data would you like me to falsify? No answer was forthcoming, and I went on booking my real hours. But the accounts department had firm instructions to edit my timesheet so that it fell in with the Chairman’s lack of numeracy.

Of course, it’s a petty story - until you work out how much effort is put into taking, processing and reporting measurements of all kinds that are never used. Probably tens of millions of people fill in a timesheet or some other record every day/week/month, only to have it effectively ignored.

But sometimes the waste is staggering. I used to work for a big consultancy, in an internal management role. One day a bunch of consultants I had not met before rolled up and announced that they were going to ‘fix’ our project proposal process. It seemed like a good idea – we were a bit haphazard and it was not unknown for us to sign up to a real disaster we really should have seen coming.

But then they started to tell me what they were going to do, and it was essentially a process of gathering the opinion of practically every senior manager and partner in the company. I was especially surprised at the long list of data they were going to collect for me. But I don’t have any use for this information, I said. But it’s very useful, they replied. For what? I asked. It will be very useful, they insisted. For what? I reiterated (I’m not very creative when it comes to people who repeat themselves). They would not back down, and I was in no hurry to admit that there was any point in collecting data about things no one actually wanted to know about.

So I decided to investigate the matter a little more thoroughly. I went to all of the people these consultants said they we helping to evaluate proposals and asked them two questions. One, as decision-makers, which parts of the information they were being offered would they actually use. And two, as information-suppliers, how much would it cost to generate the data they were being asked for.

The answer was less than astonishing. On average, only about half of the data that was to be collected would actually be used by anyone, and the total cost of this whole process would be about £60,000 per proposal. So we would be wasting about £30,000 every time we looked at a new job.

The moral of this tale? Don’t measure what you don’t manage. And while you’re at it, don’t measure things you do manage either, unless you are perfectly sure that the measurements will really be used – ideally as the clincher, but certainly as an important source of knowledge. Not that I would expect many companies to observe such a rule – after all, how many administrations, programme offices and finance departments would survive the resulting purge?

The other moral? Don’t ask people to solve problems they don’t understand and of which they have no experience, just because they are clever people and at a bit of a loose end. But that is a subject on which I could write a book.

The real challenge

The critical problem managers face has always been to extend the range and scope of their organisation’s performance and competence. This would either allow them to expand the kinds of work it can usefully do or do what they do right now more efficiently or effectively. In the current management environment, this problem has been intensified by the demand to improve management systems dynamically, to make them self-optimising and self-improving, and even to make them generate massive and qualitative improvements capable of raising organisations to the world class level.

The radical nature of this expectation stands in stark contrast to the real nature of management systems many contemporary managers are obliged to use. Some of the more common problems managers routinely face are:

• Being asked to achieve vague, unstable or conflicting business goals, often decided without adequate analysis or assessment.
• Translating disparate, fragmented and often obsolete management processes into efficient and effective assignments.
• Making do with less than optimal technical resources, including untrained personnel, unsupported tools and incompatible techniques.
• Being blinded by a combination of, on the one hand, inadequate management information-gathering and decision-making processes and, on the other, an unmanageable mass of irrelevant data and obstructive administrative controls.
• Complying with policies, standards and procedures that add little or no value to their assignments and are of debatable value to their organisations.

The causes of these problems are many and varied, and not all have to do with management systems as such. There is little a manager can do about fast-changing business environments and the regular irruption of massive new technical factors (the millennium, the Euro, electronic commerce, smart cards, identity management, electronic document, record and email management, and so on), and some of the less attractive features of the working environment such as a pervasive short-termism, disruptive cultural and political factors and the routine replacement of action and substance by glossy reports and corporate rhetoric.

Nevertheless, all organisations harbour a huge and largely untapped potential for improving their management systems, and not only managers but the organisations they work for would benefit immensely if only more attention was directed to these opportunities. For example, it is now well established that most organisations suffer from anything between 10% and 30% on waste and rework. Imagine what that means:

• Sometime between Thursday and Friday lunchtime every week, everyone stops doing anything useful and starts pouring money down the drain instead.
• If an averagely profitable company with 25% waste and rework could reduce that figure to 15%, the money they saved would double their profit – without doing anything else!
• Every year, a company with a billion dollar turnover spends between $100,0000,000 and $300,0000,000 on doing nothing.
• With $100,0000,000 extra to spend each year, your company could [enter preferred management fantasy here].

Again, this is not a solely managerial issue and managers cannot solve it on their own, but few managers would have any trouble identifying examples of poor practice and poor systems. For example, most managers could probably identify places where the following kinds of problems simply waste their time:

• Altogether too much time is spent fire-fighting problems that should never have arisen in the first place, or for which a routine solution should already be available.
• Many management systems are incapable of providing managers with the information and decisions they need to do their work properly. This often includes an effective gap between individual assignments and the organisation’s overall goals. So an inordinate amount of effort is wasted scrambling for hard data and taking ill-informed risks.
• Management systems commonly assume that all assignments are essentially the same, prescribing boiler-plate ‘solutions’ that force all work through a uniform mass production routine. Such systems actively disable managers from handling unique problems or business-critical opportunities effectively. Elementary control structures designed to adapt generic systems to individual assignments such as ‘quality plans’ are a start, but managers still find themselves bending the rules in order to get the results they need.
• Few systems provide the methods, tools and techniques needed to effectively coordinate multiple assignments into a viable programme of interconnected assignments – and increasingly important demand on contemporary management.
• Although most organisations have a nominal strategy, even the most sophisticated, for whom multi-year, multi-functional, multi-national programmes are the norm, are often incapable of industry leadership, be it at the level of values, products, processes, technology or systems. As a result their strategies are prone to vagueness, instability and even flat self-contradiction

I should emphasise that I do not take a utopian view of management: there really are times when sacrificing a manager’s time and abilities is the least evil. But all too often even perfectly routine activities are brought to a halt by an arbitrary decision, false information, the lack of the right tool, an untrained staff member or bureaucratic ossification.

Programme management - an alternative architecture

Having worked on a number of major IT progrmames, I have always been struck by the weakenss of the traditional management structure. It relies far too heavily on a single play - the programme manager. So I have been thinking about how to make it more robust.

The traditional model

The traditional programme management structure is relatively simple, and summarised in this diagram (click to expand):

In summary, it identifies:

1. A Programme Board, including representatives of major stakeholder groups such as business units and vendors, defines the programme’s strategic policy and goals.
2. The Programme Director supervises the realisation of these policies and goals.
   A Programme Manager has day-to-day responsibility for delivering the programme as a whole.
3. The Programme Manager is supported by small groups of specialists, notably a Programme Office and an Architecture team. By and large the architects are IT specialists, not functional or business architects, and the Programme Office provides administrative support, albeit very powerful and imposing it may be. It is seldom the central nervous system - making intelligent decisions as well as gathering critical inforamtion - that it should be.
4. The workstreams on which delivery depends report directly to the Programme Manager.

Complex though this may seem, considering the scope, magnitude and value of the changes any large programme is designed to deliver and the complexities of managing literally hundreds of people and millions of pounds worth of assets across multiple organisational units, it is surely far too simple. Not only is it typically a relative thin management layer compared to the hundreds of staff under its control, but it is usually functionally poorly conceived:

1. It fails to reflect the reasons why programmes succeed and fail.
2. It fails to reflect or support the flows of information and decisions on which a real programme relies.
3. It fails to define the management relationships and cycles through which a large-scale programme must be organised and controlled.
4. It fails to identify many of the very wide range of stakeholders, interests and dependencies, both within and beyond the programme’s boundaries, on which success depends.
5. It fails to create a real division of functions through which the Programme Manager can realistically manage the programme as a whole.
6. It fails to establish the roles needed to pursue and manage these critical success factors.

Below a model is presented of the critical roles through which all these shortcomings of the standard programme management model can start to be resolved. It is by no means a completely original solution – some of the roles already exist in a rudimentary form in many programmes. Nor is it a complete solution: there are many more issues that need to be resolved before programme management becomes a matter of routine. However, from the point of view of most current programmes it is perhaps the single most valuable improvement currently available.

It should be emphasised that the roles described here do not need to be assigned to individuals. As will be argued in the section entitled ‘Implementation’, there is a maturity sequence through which any programme environment should evolve, from which these roles emerge quite naturally. The crucial issue is not how they are implemented but that the necessity to conceive of programmes in such integrated, systematic and dynamic terms is recognised – and acted upon.

A good programme management environment will already be someway up this model; the purpose of this paper is to indicate new directions for development and to accelerate the pace at which progress in programme management is made. On the other hand, although the additional cost of implementing the proposed model will be obvious, it should not be forgotten that one of the largest costs of current programme management practice is the cost of delivering late, over budget and short of the full planned scope. If the model proposed here can significantly reduce these other costs, its own costs will seem quite insignificant.

An alternative model

The alternative presented here (summarised in the following diagram - click to expand) assumes that there are fundamentally four dimensions to a programme’s success, and that a closely coordinated team of senior roles is needed for them all to be kept in alignment as the programme unfolds. These roles would report directly into Programme Manager, but their functions would extend not only across the entire programme but also far into the business as a whole.

Programme Architect

The first question any Programme Manager must be able to answer at any time must be: what is its vision? In other words, what is the programme going to achieve? That is, not only should the overall goals and objectives be clear but the actual delivered solution should be fully understood. As is now extremely well established, this goes far beyond technological systems: a successful programme also invariably delivers a huge range of new and improved environments, processes, organisations, technologies, resources and facilities. Most important of all, any signfiicant programme must positively transform the very nature of the organisation - its performance, its competences, its goals, and quite possibly its ultimate purpose. The business blueprint documents far more than a collection of new systems and upgrades, and the Architect is its guardian.

What is more, the success of the programme depends not only on delivering ‘inventory’, so to speak, but also value. That is, the programme’s deliverables must be conceived in terms of their ability to produce success. That means that the architecture must be constantly modelled not only in narrowly technical terms but also in terms of fundamental business factors such as functional capability, impact on the business’s own ability to deliver, and ultimately the pure business benefits of profit, market share, ROI, and so on.

Hence the central responsibility of the Programme Architect: to maintain a single, unified conception not only of what exactly it is that the programme will deliver but also what exactly it will accomplish.

Plainly this is a more substantial role that that of current architecture teams. Indeed, at present, only some of these elements of architecture are actually under the direct control (or even substantial influence) of the programme as a whole. The role of the Programme Architect as conceived here is therefore far wider and more complex than that of the traditional architecture team that already figures in existing programmes.

There are many means for achieving this. For example, in recent years the concept of ‘Enterprise Architecture’ has emerged, which applies engineering-style concepts to the full range of business, processes, organisation and technology, thus producing an integrated vision of the organisation from the highest level of strategy down to the nuts and bolts of local systems.

Programme Strategist

If the role of Programme Architect is to define what the programme’s vision, the role of the Programme Strategist is to define its mission. That is, the Strategist defines exactly how the programme will go about its business. This includes identifying the specific benefits the programme will deliver, from which are derived the overall priorities and the top level delivery schedule. This in turn determines the financial profile of the programme, since it controls not only the internal rate of expenditure (through recruitment, support, licensing, development costs, and so on) but also how soon the planned benefits will come on stream – and, of course, how well they will realise their targets.

In short, the Programme Strategist is the key mediator between the programme and the business. Also, if the Programme Architect ultimately controls the maximum return the business can expect on its investment, the Strategist controls how fully and how quickly that maximum is reached.

The core of the Strategist’s role is their ability to manage relationship between the programme and the business. Business environments are always undergoing change, and so creating both new requirements for the programme and new opportunities to exploit (or discard) the capability the programme is designed to deliver. The Strategist’s function is to ensure that the programme is precisely geared to delivering the optimum balance of costs and benefits that can be squeezed out of a constantly shifting situation.

Hence the need for the Strategist not only to control and coordinate the plans for delivery and change but also to grasp and influence the business models and strategies through which the business as a whole operates – and to see the programme through the same dashboards and Balanced Scorecards through which the most senior management also see it.

Programme Engineer

The purpose of the Programme Engineer role is to ensure that the environment within which the programme operates is appropriate for delivering the Architect’s solutions according to the Strategist’s priorities. In other words, the Programme Engineer is responsible for the programme’s capability. This role again goes far beyond the normal technical environment that is typically under some degree of integrated management is many current programmes, and it is probably the easiest to complete according to the present model.

However, what differentiates the Programme Engineer from contemporary environment management functions is that it systematically connects the technical elements of the programme directly to its management. For example, progress management is normally achieved through more or less manual processes, which makes the real status of the programme very difficult to ascertain. In an integrated programme engineering environment, modern test tools would not only allow a far more systematic approach to verification but the results can be reported directly into management reports. This would provide a more objective and quantifiable approach to management while precluding a good deal of ‘noise’ that typically besets a large, politically sensitive programme

Within the programme, the main functions the Programme Engineer would perform would be to define, create and maintain the programme standards, infrastructure & operational processes; to set and maintain development, production and delivery environments; to propagate the results of benchmarking and internal R&D; and to ensure a common approach based on not only on comprehensive standards but also a full suite of reusable, generic delivery vehicles.

However, the Programme Engineer also ensures that the programme is connected directly to the business, operational and other external environments with which the programme needs to be connected if it is to succeed. Again, this has become considerably easier with the emergence of concepts such as Enterprise Architecture and Operational Management methods that allow more realistic analysis, tighter control of the change process and far more detailed of planning for changes to the current ‘business as usual’ environment.

Programme Controller

Finally, the Programme Controller. Again this role is largely a substantial revision to the conventional Programme Officer Manager role, but as with the other roles described here, the change is more fundamental than that would suggest.

Like any other form of management, managing a programme is essentially a matter of controlling three flows: information, decisions and materials. So it is the Programme Controller’s responsibility to ensure that these flows are in fact appropriate, effective and unimpeded by internal or external barriers, bottlenecks or biases. In other words, the Programme Controller’s job is to provide the programme with its knowledge. This naturally requires the management of traditional concerns such as the availability of resources or the traditional dissemination of management decisions and status reports.

However, in the context of a programme management structure that incorporates the new roles of Programme Architect, Strategist and Engineer, completely new classes of information and decision also need to be managed. The increased intensity of relationships within the programme and the far closer links these roles create with the external environment also demand that the role of Programme Controller is far more structured and dynamic than under traditional programme management arrangements.

ManageSpeak

One of the most wonderful things about management is its enthusiasm for the creative use of language. This entry will cumulatively record great phrases I have encountered. I will not offer any explanation - partly because meaningful language should not need more than the minimum of context, and partly because such marvelous constructions are often spoilt by the realisation that they mean anything. There is a pristine beauty about someone who is only pretending that they know the words, and this is its managerial equivalent.

"The new regime of challenge into the work package space"
"synergise our learnings"

All contributions gratefully received.

Yes, but what are processes for?

Just this morning I was talking to a colleague about scaling methodology, and how often organisations seem to lump quite diverse projects and tasks together as small/medium/large (or something like that), and force everything into what is often a quite inappropriate (not to say brainless) approach. So we end up insisting that some major document is produced or some sign-off given that is wholly irrelevant or out of proportion to the problem the work is designed to solve or the real problems it might face. But we do it anyway, apparently for want of any clearer idea of what we should be doing.

My suggestion was simple in concept, although I suspect that most organisations would have difficulty making it real. It is based on the principle that methods, processes, standards and procedures exist for just one reason – to control a risk. We don’t have standards and procedures for things that can be assumed any way. For example, shortly after the fall of the Soviet system, I was working on a group of projects for the EU (the old EC Phare programme) in Poland. While I was there I discovered that the electricity was so erratic that I would have been ill-advised to plug in my laptop, and that in most factories there was no loo paper because it was a precious commodity that was usually nicked as soon as it was put it. So my personal ‘being a consultant in Poland’ procedure included ‘leave your laptop in the hotel’ (where the current was more reliable) and ‘put some toilet paper in your briefcase’. But of course these weren’t risks here in the UK. So they are not in my ‘methodology’ here.

And so it should be for any methodology or process: if it is not controlling a risk, take it out. Likewise, if you don’t know what risk you are controlling, find out what it is and adapt the process accordingly. And in the case of the question from which we started this morning, you will only be able to make your methods truly adaptable to need if you can map the products and processes it contains to specific risks.

For example, I was recently involved in a simple project that required a standard rate table to be updated from time to time. The table fed the public website, so its potential impact was enormous, and in many organisations this alone would be enough to trigger the full-blown development lifecycle. Yet the risk was extremely tightly focused, and there as a single simple and quite fool-proof method of mitigating it – conduct a proper acceptance test before any change is allowed to go live. There was no merit in insisting on business or functional analysis, on a detailed design or a formal build process, and technical testing was completely trivial.

So triggering the full lifecycle would be stupid. Yet for many organisations it is the only option. No wonder so many developers and managers are so irritated by processes and methodologies!

The solution is simple. Most organisations have some kind of work classification tool or procedure for deciding how the standard processes should be applied. Many are based on pointlessly trivial issues, like the sheer size of the work involved, but even where there is a proper evaluation of the risks involved (e.g., novelty, organisational complexity, regulatory impact, and so on), there is no direct link to the specific products, procedures, verification methods, approvals and other things the work will have to include.

I have already given one simple example of what this might mean that most organisations could implement today. But our processes are seldom so little defined by the risks they control that it would take a considerable effort to unbundle all the different components ended to control specific threats. In other cases a single item effectively controls multiple risks and vice versa. Yet I am quite sure that a great deal of flexibility could be built into our methods, tools and standards that would make work much more risk-driven – and so much more intelligent and intelligible – than it is now.

Even if you can measure, maybe you still can’t manage

It has always been assumed that the use of metrics is one of the more convincing indicators that business management is approaching maturity. There is an alternative view, however, which is that measurement is used because there is some mileage in it, and it is easier than being serious about understanding management.

This is all encapsulated in the famous consultant’s dictum that if you can’t measure you can’t manage. This in turn seems to derive from a remark by Lord Kelvin:

When you can measure what you are talking about and can express it in numbers,
you know something about it; but when you cannot measure it, when you cannot
express it in numbers, your knowledge is of a meagre and unsatisfactory
kind.

Now Lord Kelvin was one of the truly giant figures of science, so he probably shouldn’t be contradicted without good reason. But there is another figure, altogether more relevant to management and business in general and, unusually for that field, of equal standing even to Kelvin. This is John Maynard Keynes, who not only invented large chunks of twentieth century economics and shaped how the world worked for half a century but was also a great authority on statistical methods. So his opinion is certainly worth considering. And while his opinion does not contradict Kelvin’s, it certainly undermines quite a lot of modern business measurement programmes.

Am I right in thinking that ... the statistical method ... essentially
depends on ... having furnished, not merely a list of the significant causes,
which is correct so far as it goes, but a complete list? For example, suppose
three factors are taken into account, it is not enough that these should be in
fact verae causae [true causes]; there must be no other significant factor. If there
is a further factor, not taken account of, then the method is not able to
discover the relative quantitative importance of the first three. If so, this
means that the method is only applicable where [one] is able to
provide beforehand a correct and indubitably complete analysis of the
significant factors. The method is neither one of discovery nor of
criticism.

In other words, measurement is only valid where the underlying model of what you’re measuring is:

• Coherent.
• Consistent.
• Complete.
• Correct.
• Current.

… and probably a lot of other things beginning with ‘C’.

Now, I’d like to think that modern management and business systems were based on a clear conceptual framework, but my sense of humour is not quite so surreal. It is true that areas like manufacturing, logistics and mass commodities measurement is alive and very healthy, but I suspect that that is mostly because these areas are closer to technology than business. But as far as the day-to-day management of less mechanical things – such as people and projects - is concerned, it is simply contrary to the management culture of most companies to manage in the objective terms that measurement either assumes or supports.

I think I can honestly say that every people- or project-based company I have ever worked in was racked with opportunism, pragmatism (no, not a good thing, especially in this context) and the horizons of a whelk. In fact the entire history of management often seems to consist of one insight/revolution/fad after another.

This is completely anathema to the entire ethos of measurement, and the persistence of this attitude strongly implies that:

• We don’t really know how business and management work - otherwise we would not let consultants sell us a new toy every ten minutes.
• We don’t really care how business and management work - otherwise we have recognised how pointless much of what management does really is decades ago, anda come up with more intelligent models.
• The widespread introduction of measurement and metrics isn’t noticeably improving our understanding of either.

Certainly we are nowhere near the point where Kelvin’s advice (which was pretty weak on a few other things) can be sensibly applied.

But does it matter? Not much, as it happens. You only have to go back to the source of the ‘if you can’t measure you can’t manage’ philosophy to see why. Lord Kelvin was a physicist. He studied atoms. In particular he studied how things move and use energy when you bash them about. As I have argued elsewhere, as a model for anything except physics, physics fluctuates between the unhelpful and the disastrous, and other people who have taken Lord Kelvin’s a bit too seriously whilst he was banging on about non-physical matters seem to have come unstuck. Even Charles Darwin was seriously disturbed by Lord Kelvin’s ignorant but highly effective assault on evolutionary theory, which was based solely on a model of matter that left out radioactivity and which I have written about in more detail elsewhere. But this was a perfect example of perfectly accurate numbers leading to completely spurious conclusions because the underlying model was wrong.

But metrics are a limited (though not useless) basis for managing business for a different reason. As far as intelligent beings are concerned, metrics make sense only if you can assume that the basis on which they act is not changed by the fact of being measured. But we know from a dozen different sources that this is exactly what is not true about human beings. Indeed, it cannot be, for the simple reason that human beings are not atoms. Rather, as conscious beings, if they become aware that they are being watched, this fact alone is enough to create a new ‘factor’ in the ‘system’, and so to undermine the very assumption that the observers know what they are looking at!

Take, for example, the well-known Hawthorne Effect. Between 1924 and 1932, experiments observed workers’ performance as they changed various conditions – lighting, group incentives, and so on. They found that it was not the changes themselves that caused increases in performance so much as the workers’ consciousness that they were being watched (as demonstrated by the constantly changing conditions). In other words, measuring their performance changed their performance.

Hence another well-known phenomenon in business and management, which also tends to undermine measurement, namely the fact that people tend to manage so as to optimise what they are being measured on. Again, the Keynes effect – the system is changed by the fact of being measured.

Is this a problem for management? Yes – if you think that human beings are simply assets you buy and sell and will do as they are told in a completely mechanical manner. And in some businesses, perhaps what the organisation needs really are such drones. It must be a very crude, basic industry if it is.

Yet we should still celebrate the fact that human beings are never so lifeless that they can be expected to behave like things instead of people. For this simply ignores where the real ‘value’ in employing intelligent beings comes from – from their insight, their creativity, their enthusiasm, their combination of love of doing great things with the uniquely human quality of responsibility to do it properly.

When we can reduce that to numbers, we will be either gods or in big, big trouble.

Taking quality back from the bureaucrats

I have spent a good deal of my career around quality management. Be it pure ISO 9000- and TQM-style quality management, more tangential activities such as methodology and process architecture or innovation and research management, I think I have done pretty much everything in this field.

One persistent theme in all this experience – and in most organisations this seems to be as true today as it has ever been - is the tendency of quality to degenerate into bureaucracy. For serious professionals quality should be the sexiest thing on earth, but in fact most people find that quality management is a tiresome chore of jumping hurdles, filling in forms, being subjected to irksome and apparently pointless audits, and being admonished to do better by tiers of senior management who plainly haven’t a clue about what your working environment is really like.

Hence the collapse into bureaucracy. If I can’t/won’t join up all the dots, then some of them will have to remain mysteries and I can only get you to do what I want by simply ordering you to do it. It doesn’t have to be a direct order – I can just create a system of bureaucratic controls and reports and you will do as you re told anyway.

Well, that’s the theory. But as every real manager knows, it just doesn’t work like that. In fact, if I wanted to design a system for stifling commitment, creativity, and passion, that’s how I’d do it – replace a real understanding of quality with a bureaucracy.

So how to take back quality from the bureaucrats? Not easy. Perhaps, ultimately, not possible. But here are three steps that should take you some way towards that goal.

Step One – Define quality as excellence

If you want passion, commitment and creativity, then your quality management system absolutely must nurture professional, managerial and operational excellence. If you want to create a culture in which everyone wants to do their job and then some­ - the basis of every truly triumphant organisation – then there is no alternative.

But is this not already the norm? Although there are many preliminary definitions of quality (e.g., as compliance with specification, as fitness for purpose, as customer satisfaction, and so on) surely everyone in quality management would probably like to define quality as ultimately about excellence?

True so far as it goes, but as so often, it’s not far enough. The problem is that these definitions tend to stay on the rhetorical level. In the absence of a genuine culture of quality, it is extremely difficult to move quality on any further. So what is needed to make that move? What is needed is a practical definition of what excellence is. I would suggest the following key elements that, if accepted, provide a basis for practical change. In a sense this is quite simple and already very familiar.

For example:

• Excellence must be the explicit, overriding goal. Not conformity or standards or even customer satisfaction.
• Your organisation can only excel as a whole. Privileging supposedly ‘key’ functions is self-defeating.
• Excellence can only be known through practical results. These results must be defined in terms of achievements, not activity.
• Excellence must be driven. Leadership should be the goal at every level – corporate, functional, individual. To achieve this, innovation must be actively pursued and external research, benchmarks and resources vigorously exploited.
• Excellence is suffocated by ignorance, distraction, trivia and noise. Excellent people need excellent leadership, processes, systems, skills, tools, information, and support.
• Excellence is founded on a personal desire to excel, not a bureaucratic procedure. Translating a corporate plan for excellence into a personal desire for demand recognition and reward, for contribution to every level.

All quite familiar, really. But how many of these are embedded in management systems that facilitate accomplishment, development and leadership? In my experience, very few. And they are almost invariably confounded by the presence of countervailing forces, such as the standard ‘Not in this financial year’. ‘Not in my backyard’ and ‘Not invented here’ syndromes. There is seldom any investment in standing back and looking at the organisation as a whole or in looking to what other have achieved, and little reward for creating change.

Step Two – Mapping your management system onto your definition of excellence

Hence step two – creating the management system that will actually communicate, support and track this translation of corporate goals into local objectives. Here are some basic elements of such a system:

• Quality is defined and measured by intrinsic values – delivery, satisfaction, ROI, etc., not formally correct ‘quality metrics’.
• Quality management is recognised as a key investment, not just an overhead or cost.
• Quality is a cultural value. Not only does everyone routinely ask ‘How can we do this better?’ but there are regularly meetings and improvement systems for making sure that they really do get better.
• Your management systems are intrinsically adaptable – and regularly adapted. That is to say, they are rigorous but not rigid, and driven by explicit objectives that are traceable to real corporate goals.
• The Quality System itself is driven exclusively by identifiable risks, not by formal models or methodologies. If you can’t say what risk your management system is responding to when it makes me follow some formal routine, then what is the point in my doing so?

The management system is owned by its users and stakeholders, and no one else. The ultimate test of this is that your management systems are valued by its users, not imposed from without.

Again, not exactly startling. At least, I hope not, after a couple of decades of consultants like me ranting on about this sort of thing.

But again, how much of this is real in your organisation? Have you ever looked? Have your ever gone about your organisation, in disguise like a medieval prince, to see what life is really like for the teeming masses? You don’t believe your own subordinates’ and HR department’s protestations that all is well, do you? You don’t read Dilbert? Ye gods…

Step Three – Make it happen

Finally, some basic mechanics of a management system that will deliver all this. There are endless things that could be done, but I always feel that these are the most directly useful.

• Insist on black-box management – it's the ideal way to combine empowerment with responsibility. But make sure that you define all four 'outside' sides of a black box - the expected output, the standard inputs, the underlying infrastructure and information sources and the overarching context information that tells your team what they are contributing to - but also the 'inside' side - the basic standards, frameworks and tools for doing the job. Otherwise you will end up with everyone making it up as they go along.
• Promote your best to managing the management system itself. Respected individuals with vision and imagination who really get things done.
• Make a stint in some form of quality management a precondition of promotion. You might be astonished how must there is to learn from a simple exercise like conducting a quality audit or building processes.
• Build systems that explicitly connect your strategic goals and tactical activities together. And make sure that they work both ways - top-down and bottom-up.

Bureaucracy is wonderful

Why do people hate bureaucracy so? I love it.

Bureaucracy is humanity's greatest invention. It's what holds the building up. It's what put the building up in the first place. It put the lights in and keeps them lit.

So what is a bureaucracy? It is an organised and controlled flow of explicit information and decisions of demostrable quality and value, designed to manage the flow of resources, materials and results. What could possibly be more important to any society? Nothing.

Bureaucracy is far more important than writing or even fire. Or at least, it is around here. After all, the Incas managed to have a perfectly good bureaucracy without writing, but I doubt that any great society has ever existed without bureaucracy. And in an industrial society, the vast majority of people only have fire because they first have access to bureaucracy. We get it through vast gas and electricity supply systems, none of which would be thinkable without the organised flow of information and decisions, which is all that bureaucracy is.

Most paradoxical of all - and I make my living out of this paradox - is the idea that we can get rid of bureaucracy by replacing it with computers. But what else is a computer but an electronic bureaucracy? And why else do computers fail in supplanting bureaucracy than for the same reasons that bureaucracy itself fails, namely because we fail to adapt it to its users' needs? Just think, if only bureaucrats had learned to find out what their users needed and then adjusted their systems to that, there would have been no management consultants.

Who could possibly object to that?