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.

A generic development process

Having spent a decade or two looking at methodologies of all kinds, I note two things: that waterfall models are as prevalent as ever, and that they are generally not very clearly thought through. In particular, they tend to lack a logical model. Instead, there is a strong tendency to leap straight to a list of things for the project manager to do.

Partly in response to this and partly out of simple intellectual curiosity, I have drafted what is, I think, a completely generic model of development. Or rather, of how each stage in any waterfall method should work. I don’t worry too much about identifying the stages themselves – Requirements, Analyse, Design, Built, Test, Accept, Deploy are pretty much universal now.

Anyway, here is the generic stage model, followed by an example of how it might be made more concrete for a design stage. (As always, click to expand the images.)

How would you use this model? Just string together as many instances as you need - one for each development stage. Then add a project management and governance layer, preferably from a stage-based approach such as Prince2. Then make sure that you have something in each box - or if you haven't, that you can explain why not.

Here's a high-level implementation for a design stage:

As you can see, there is a doubling-up of tasks, and things can be defined and redefined to many more levels. but the general logic remains visible.

'It's not realistic' and 'we don't do things like that around here' are not valid reasons for rejecting an underlying logical model. Being 'realistic' means 'I have given up trying to make things work properly', and 'around here' means 'in this god-forsaken hole where nothing makes any sense' - neither a suitable reason for making an exception. If you're not persuaded, try here.

How stages work

A short presentation on how project stages work. It combines the main managerial and techical features of a stage.

First, a complete overview. (Don't worry, it's all explained as you go along.) The blue box represents a single stage. The rest is explained, step by step, in the next few images. Just click on the pictures to expand them and read the pink boxes for details. If you use any of them, please acknowledge their source.

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.

Defining capability

Another question I have spent much of my professional life pondering: What must a business capability of any kind have in order to create success?

Quite a lot of experience of service management suggests this basic model.

(Click on the picture to expand.)

Capability management cycles

I have spent a long time studying capability management - the active creation of a integrated approach to continuous improvement that goes beyond localised incremental change.

This diagram summarises my current view of this process.

(Click on the picture to expand.)

What makes a good manager?

Five minutes ago a junior project manager in the company I am currently consulting to came to me and asked me a simple question. What makes a good project manager?

I asked him why he wanted to know, and he said, ‘Because that’s what I want to be, and you’re an outsider who knows about this stuff’. So this is what I told him. I think it applies to other kinds of manager too.

Master the basics

There is no substitute for doing the basics and doing them well. Planning, risk management, dependencies, team-working, and all the rest. And make sure that you really do them well – that issues and actions are routinely tracked, that you write formal work packages rather than just assuming that what you have said is clear, and so on. Qualifications are nice because they provide a structured model for management, but just learning to do the basics properly is a matter of attention, responsibility and commitment – virtues without you will never be a good manager.

Be professional

You can acquire any number of professional qualifications and certificates. But for other people to think you a professional, you need to be worthy of the name.

For example, when I recently gave a course on delivery management and suggested that the project manager’s ultimate responsibility was to make sure that the benefits our colleagues hope for are really achieved, one very senior manager responded with ‘That’s not my job’.

Well, no, if you define your job by your formal job description, maybe it isn’t. But as Max Weber – the man who practically created the idea of professionalism – said, an employee is someone you pay so you can tell them what to do, whereas a professional is someone you pay to tell you what to do. I’m pretty sure that a good project manager is a professional, not just an employee, and I cannot imagine how a project manager could ‘tell me what to do’ without understanding what, ultimately I was trying to achieve.

So if my plan says ‘meet these requirements’ or ‘deliver this system’ then I don’t doubt that I will fail if I don’t. But I cannot see how I can really succeed unless I understand the benefits you think these requirements and deliverables will give you, and make sure that I work towards them too.

There are a million other things a professional manager does as a matter of routine. Many of them are not unlike being a consultant. Indeed, I don’t think there’s much difference between a good manager and a good consultant – they tend to merge in direct proportion to their maturity. Think big, take pains, even all do those clichéd things like ‘going the extra mile’. And do not think ‘outside the box’ – just recognise that there is no box unless, out of fear or ignorance, you put yourself in one.

Master the corporate management system

The third (and probably biggest) item is harder, as it is not in the individual manager’s power to do much about it. It’s the corporate project management system – that can make more difference to being a project manager than anything else. In fact I regard it as the litmus test of my own work building management systems – that managers don’t have to do anything but manage. All the rest – the petty bureaucracy and standards and elementary tools, techniques and templates – are all provided in easily used form by the policies and systems and training I create.

On the other hand, if your system isn’t quite that friendly, it is still open to the good manager to take a hand. Except in the kind (happily rare) organisation where authority is either so rigid and draconian that you would be far better off getting another job, the reason the management system doesn’t support you is usually either because you don’t understand what it is trying to do or the people who manage it aren’t telepathic and they did not know that it was causing you problems. If it’s the first (and regretfully, it often is) then once you understand the problem (hopefully) goes away, but if it is the latter, then what is stopping you getting them to change it?



Ultimately you will know when you are a really good manager – it is then that working really is more fun than fun.

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.

What we can still learn from Mao's Little Red Book

I am old enough to remember Mao’s Little Red Book. It was a collection of advice, analysis and sayings, and if you were a leftie in the Sixties there was no chance you hadn’t at least got a copy on your bookshelves. (No need to actually read it.)

I remember quite a few of the spectacularly unconvincing sloganeers that demonstrated more the chasm that separates Chinese from English ideas about language than anything specific about Maoism. My favourite was ‘Peoples of the world unite and defeat the US aggressors and all their running dogs’. I so wish I had said that.

So what has all this to do with management? At about the same time there was a story in the British media that seems to have been published primarily to ridicule Maoist revolutionism. It was about a lathe operator in a factory somewhere in China who had said that once he had read the Thoughts of Chairman Mao his lathe had turned three times as fast.

Of course everyone in the West laughed. What a fool. What a typical piece of irrational propaganda.

A little later another journalist found the man and took the trouble to ask him what he had meant. His answer was illuminating. Before he read the Little Red Book, he replied, he has simply come to work each day and followed orders. He had known all along that there were things wrong with his lathe that could easily be fixed but he did not think it was his job to do anything about t it. Just obey orders. But once he had read the Great Helmsman’s book he realised that it up to him to do something about it. So he did, and lo and behold, his lathe worked a lot better.

Not really very astonishing, of course. Yet I spend my life surrounded by staff and managers – often quite senior managers – many of whom would rather die than challenge the way things are done. And no wonder – after all what would happen if really they took the initiative and did something on their own authority?

Perhaps I can answer that slightly rhetorical question by my own recent experience. I recently attended a long offsite management meeting led by my immediate boss. He’s a good guy – I like him, and he once told me that he had chosen to work in this company precisely because he was tired of bullying corporate cultures.

So far so good. But in the course of this same meeting we happened to talk about whether the company's managers are empowered. Of course they are empowered, he insisted. I have told them they are. Of course they aren’t, I replied (over and over again – it was perhaps not the most constructive of discussions) – not until both the means and the authority are explicitly put into their hands. Which they had not been.

We came to a bit of an impasse, and started to talk about another subject. As he spoke my boss gave a little dig to one his other team members about a project that had overspent without his permission, and how the project manager had had a dressing down as a result. The amount the project manager had overspent was a small fraction of the total project costs, but this allegedly empowered project manager was in trouble. Most absurdly of all, my boss made it quite clear that, had the manager in question simply asked for permission to do what he did before he did it, he would have been authorised to do it anyway!

Apparently empowerment meant empowered to do things that work, but not things that don’t. Bearing in mind that empowerment is of significance only when you need to make a serious decision, this puts the project manager in an impossible position – damned if you do, and damned if you don’t.

I think I would rather have been Mao’s lathe operator.

What happened when I asked the Board to let their staff think

A few years ago I was Head of Consulting Services (and Quality Director) for a medium-sized public sector consultancy in the UK. I was a member of the Operating Board, and tasked by the MD with making the organisation's services and capabilities more dynamic. After quite a lot of thought and quite a lot of talking, I started to home in on the idea that the best people to decide how to do this were their own consultants.

After all, as I used to put it, our clients pay us £35,000 every day for advice about how to improve their organisations - so why don't we ask the people they trust to help us too?

The reaction was fascinating. Or dispiriting.

At one extreme was the HR Director, who suggested that it would simply degenerate into navel-gazing - an interesting response from the one person you would have expected to have a little faith in people. In the middle was doubt that they would come up with anything saleable. And at the other extreme was the common demand that directors be present, to make sure that they worked on whatever it was the directors (basically, as in most consultancies, a bunch of overpaid salesmen) thought important.

No, I argued, the last people you want in the room are the directors. They can get a team together to respond to market demands or their latest bright idea any time. What I wanted my innovators to work on was their own ideas. After all, they are the ones who spend their lives thinking about how we do things, they are the ones who know what the biggest problems our clients face and they are the ones who have spent their lives developing solutions for dealing with them. If they don't have any ideas we could develop, what on earth were we paying them for?

I found it very hard to get a toe-hold on their imaginations. A couple did not seem to mind, and I would swear that the chairman (who thought no-one but he understood our business) was only neutral in the pleasant expectation that I would fall flat on my face. So begrudgingly, they accepted my proposal, with a very strong undertone of scepticism.

Fortunately there was one notable exception to this symphony of indifference and cynicism: the Managing Director himself. We started innovation management the very next week. It worked too. And yes, practically the first question the teams asked themselves as soon as they had a decent idea was, Who can we sell this too?

What you think when you're not thinking

I spend a lot of my time training people in management. One thing that always surprises me is the ease with which people stop thinking about what they are doing and start to introduce key phrases that are simply shortcuts to failure.

Politicians and 'leaders' of other kinds seem to be especially prone to this, so it's much more than a peculiarity of naive managers - I can only imagine how often phrases line these came up around Bush's Cabinet table while they were 'planning' Iraq.

So, if you hear others – or yourself – using any of these words & phrases, something’s very, very wrong…

‘Pragmatic’
You only have to glance at Wikipedia to have a bad feeling about pragmatism. There it is defined as 'behavior which temporarily sets aside one ideal to pursue a lesser, more achievable ideal' - which is only to say, pragmatism decides in advance to settle for second best.

But for many in business, being pragmatic is itself the highest ideal. It's strictly an ideal for people who want their inability to think beyond their noses to look like a virtue. If they are being 'pragmatic' they are preparing for mediocrity.

‘Hopefully…’
Hope is indispensable to life, but a poor basis for delivering results.

Relying on hope alone is like driving into dense fog and assuming that there’s nothing in there you will regret smacking into head-on. As soon as you substitute the word ‘hopefully’ for specific thoughts about exactly what it is that is likely to derail your hopes, you have more or less committed yourself to failure. Regretfully, but quite hopelessly.

‘Obviously…’
For example, the Earth is obviously flat, it obviously stands still, and the Sun obviously goes around it once a day.

If you are relying on the obviousness of things to save you, then you are ignoring the fact (obvious enough) that the whole point of most useful effort is to deal with fact that what used to be obvious doesn’t make sense any more.

‘It’s only common sense…’
Common sense is what we think when we are not thinking. It was common sense that got us where we are today. If common sense were enough, we would not be trying to change things.

I once had to manage a supplier to whom we were paying £16 million to deliver a major new system. He was useless, and perhaps the clearest sign of his uselessness was the fact that he would defend all his recommendations with the words, “It’s only common sense”. Eventually it got too much for me, and I told him that if we weren’t going to get anything better than common sense for our money, he could go. The project was a massive failure, not least because it turned out he didn’t have any ideas that weren’t common sense.

Of course, it's hard to resist common sense, since you have to dig it up by the roots and deny that a lot of things we all take for granted are worth anything. Even worse, common sense is what Antonio Gramsci called 'the practical ideology of the ruling class' (sorry to intrude politics into management) so when you attack it you will usually find that you are stepping on someone's toes - someone bigger than you. Make sure you have lots of equally big friends when you do this!

‘But in the Real World…’
But if you are starting out on any undertaking of any consequence, the ‘Real World’ is the problem! The Real World doesn’t work. I’ve been to the Real World, and I can tell you, it's six inches too small on each side, the light is bad and it has a slightly cheesy smell you would not want to live with if you didn’t have to. So don’t accept it just when you have the chance to change it!

‘That’s all very well in theory, but…’
The underlying problem with the idea of the Real World often seems to be the far more destructive idea that ideas are ‘just’ theories, and theorising is no more use than navel-gazing. Even worse, too much thought is widely believed to stifle action.

Which will come as news to what are probably the two most productive activities humanity has ever devised, namely science and mathematics. The latter is nothing but theorising, and the former is only happy when it has a good theory at its centre.

In fact, if you don’t have a ‘theory’ about what you are going to do and why, then you don’t know what you’re doing. Literally.

In summary?

• A mirage is not a vision.
• A wish is not an objective.
• A slogan is not a plan.

Unless you’re invading Iraq, of course.

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?

Principle 2: Urgent vs Important

In most organisations, the urgent will always be dealt with before the important. Urgent means pleasing someone important right now, while the important is usually only important in the long run - when we will all be found out, but it isn't today.

If you allow the urgent to overwhelm the important, everything will soon become so urgent that the most important thing left in your professional life will be keeping your head above the rising tide of bad information, bad decisions and bad products.

The only means I know of of making sure that the important has as loud a voice as the urgent is by creating an independent function staffed by respected experts who report directly to whatever level of management is accountable for both the urgency (typically project delivery) and the importance (typically product quality).

This is what a quality function should be. But usually it isn't, because:

1. They're seldom staffed by the best. The credit, the kudos and the money all go to the people who do the delivering. The people who made it possible for anyone to deliver - the people who build the processes, create the methodologies, create the training, the environment? Not a peep. Yet in an organisation with, say, thirty project managers, a 3% improvement in efficiency in the system as a whole would be the equivalent of adding another manager absolutely free of charge. Yet the people who do this (and a 3% change is about as small as a change can be and still be detectable) get no credit at all. No wonder quality management and its various adjuncts attract such undistinguished individuals, or that quality departments tend to decline into a plodding bureaucracy whose raison d'être is not professional principle but bureaucratic rule. Certainly of all the many quality management specialists I have met, few seemed to came to work in the morning relishing the prospect of raising everyone's game, not just doing a day's work.



2. The individual to whom they report is usually a lot more committed to the urgent than to the important. The reason for this is simple - the vast majority of managers grew up in an environment in which the urgent is actually more important than the important. And while someone was almost always standing over them with a whip to make sure things were done on time, few people, especially in business, have really considered the principles of their procession. As a result, in most organisations it is relatively easy to circumvent the rules in the name of some short-term goal such as appearing to deliver as promised.

Principle 1: Quality vs Risk

A basic conflict that arises again and again is that between quality and risk. It does not often show up in quite that form, though. Often it takes the form of a manager wanting to ignore some kind of established practice – a procedure, a standard, or whatever – in favour of anything from a well thought-through alternative to the gung-ho ‘Just Do It!’ sloganeering that has served Nike’s marketing department very well but is otherwise all but designed to cause you to screw up royally.

And I have lost count of the number of manager’s who heroically declared that they were willing to ‘take the risk’ of proceeding without the right review, with half a dozen fatal flaws outstanding, and so on. As if it were they that was taking the risk at all! Surely it is their employer who is taking the risk – after all it’s not likely that the manager will have to cough up for the mistakes they make.

But there is an important principle here. There is a real issue that, because most of us work in environments we don’t really understand, there is a marked tendency for work to drift to one of two extremes. Either rules are followed slavishly or they are simply disregarded. The latter is especially common where there are no mechanisms for actually tracking and enforcing compliance with the rules – which seems to be the norm for most organisations, outside truly hallowed ground such as filling in timesheets. In both cases –and in most of the intermediate cases, such as simply pretending to comply – is a huge amount of squandered effort. It serves no one, and we all hate and despise it.

So what is the underlying principle that allows us to extricate ourselves from this dilemma? It is simply to acknowledge that quality (and with it all those tiresome policies, rules, standards and procedures) exist solely for the sake of risk management. If a standard exists it is because it cannot be assumed that achieving that standard will happen as a matter of course. Conversely, if I can demonstrate that the risk a management control is designed to control either does not exist in my case or is better managed by other means, exactly why should I comply? If the keepers of your rules – the quality department, the accountants, and so on – cannot tell you the answer, then they aren’t doing their job.

An example may explain this better. Some years ago I was involved in a handful of EU quality management projects in Poland. This was just after the fall of the Soviet Union so the place was in a pretty bad state – so much so that I was warned that the local electricity supply was so flaky that it would damage my laptop. At the same time I was warned to take my own loo roll, because toilet paper was such a precious commodity that it was invariably stolen from offices. Neither of these are issues I would expect to have to deal with in a project in western Europe, North American or on most of the Pacific rim. But if I was to assure the ‘quality’ of my work to Poland in the early 90s, then the rule was simple – no laptop but lots of loo roll.

On the other hand, by the time I had (regretfully) stopped working in Poland, neither was a problem any more. So this particular quality management procedure was now obsolete. But in how many companies, I wonder, would it have continued to be enforced for years afterwards?

So, a question. Can you actually say you know what risk each of your management controls is designed to control? Do you really know? And if an exemption is asked for, is the answer ‘Certainly – if you can explain how your proposed alternative will manage this risk better than the standard approach’?

If the answer to any of these questions is No, then you don’t have a management system. You have a bureaucracy, in the worst sense of the word.

And how many of them have long since ceased to solve any significant problem? Many years ago I worked for a major global consultancy. Part of my job was to manage the engagement reviews conducted by partners on one another. After building the basic administrative database, I started to look at the checklist the reviews were expected to complete. They had lots of strong points, but also quite a few of major defects.

1. One was that there were four different checklists, even though they did not seem to serve different purposes. But no one ever complained.
2. A second was that many of the question were simply repeated – in one case the same question was asked three times. But again, no one ever complained.
3. Finally, it soon became clear that the answer to quite a few of the questions was always Yes. The checklists were worded in such a way that the ‘right’ answer was always Yes, so what this told me was that we were constantly harking on about things that simply weren’t problems.

So I revised them very thoroughly. In fact I got 7 pages of questionnaire down to 1½ pages and one diagram. And no one complained about that either. Because the result was perfect? No, because they didn’t know what the new version was for either – they just did as they were told. And this was, as I say, a vast global consultancy whose principal service is being more clever than other people. But not as clever as all that, it would seem.

Inhuman capital management

I work for a living. I like the work I do quite a lot, though like many (most?) people I suspect I would prefer to be professionally rich. However, some things about working for a living annoy me more than others. One of them is the language of business. Or rather, the attitudes that language signifies. Apparently I am ‘human capital’. So are you. Bad enough to be reduced to a statistic, as ‘personnel’, and still worse to be a ‘human resource’. But 'human capital'? Exactly which chunk of machinery were they thinking of comparing me to?

Strangely enough, I have heard people suggest that referring to people as capital is better than calling them personnel or human resources, as it ensures that ‘the business’ appreciates their real value. Really? More likely it tells you exactly how mistaken we are to regard business as being part of society in any positive sense. They really do think we are just another resource to exploit for their profit.

So when it comes to the crunch – and speaking as someone who has been made redundant three times, I know just how appropriate that word is – it is quite clear what the priority is. It’s the money. That’s all. It makes you wonder about all that rhetoric about profit being a reward for risk-taking. Well, that’s what they used to tell me when I was studying economics. Since economists don’t seem to have much of a handle on how businesses really operate (and in my experience most business people have little grasp of economics), it’s as good a guess as any.

But when the risks explode in their faces, who exactly shoulders the burden? Who loses their job? Which comes first, profits or wages? Can you remember the last time obviously incompetent board members were sacked before a fair few workers and managers had been deprived of their livelihoods? Human capital indeed: maintain it well (enough) when it’s making you money; scrap it when it’s not.

But even in the good times I can’t say I’m impressed with the idea of ‘human capital’. If the phrase encourages business people to see the people the employ as valuable, it also encourages them to see them as things. Just look at any book or website about ‘human capital management’. In the new human capital management regime, people have been promoted from ‘costs’ to ‘assets’, but one has to ask, what is the new relationship to business this suggests? Costs are measured, controlled, minimised. Not a nice way to talk about human beings, I would have thought, but it’s still pretty tame compared with what you do to assets. Assets you exploit.

Yet it is such a stupid way to treat people. Because if there is one thing human beings are not, it’s capital. Which is just as well, because if they were capital, they would not have the kinds of ability every human being on Earth has, and no machine. Imagination. Creativity. Commitment. The ability to learn. Willingness to take on responsibility.

But is that how the human capital management movement regards human beings? Absolutely not. It’s all about binding your staff to business goals, designing the perfect process for them to fit into, evaluating their performance, measuring the ‘contribution’ to the bottom line. It’s about designing the perfect treadmill.

Which completely misses the point of human beings. In an advanced industrial society, can we really claim that we still need to treat human beings as ‘appendages to a machine’? At the same time, are businesses really so good at what practically every ‘business leader’ now says are the critical functions in business – innovation, creativity, agility, and so on – that they can afford to ignore the only ‘asset’ they have that is capable of any such thing – namely their own staff? What ‘process’ ever had a good idea? What computer ever thought up a better way to do things?

And what human being did not? It’s true that human beings are seldom at their best when at work. But then how many workplaces encourage (or even permit) the vast majority of workers (or even managers) to have any ideas of their own, let alone think outside the box? But look at the most ordinary individual outside of work, and an astonishing number of them are busy doing exactly what most their employers despair of them doing in the factory or at the office. Having ideas. Taking responsibility. Making sure things get done. The world is awash with evidence that practically every single human being on the planet is capable of intelligence, insight, innovation. So why is there so little evidence of them in the workplace?

Perhaps the answer is that, when they get to the office or start up that machine, it is the very nature of business that makes it impossible. Outside they are people. Inside they are assets.

Is this the necessary price of basing an economic system on profit? Not really. Maximising profitability requires businesses to get out the most their staff. But that does not mean that they have to believe that this is best done by treating people like machines.

And the first thing that needs to change is that ‘human capital management’ label. I don’t know a better one, but perhaps that’s because people don’t need a label. Maybe we should just call them people. Maybe we should actively encourage those little eccentricities that make people so different from any kind of capital. Like their capacity to look at what they are doing and work out how to do it better. Like wanting to do it better, just because it is better. Like lateral thinking - or thinking of any kind! But of course, they are never asked. Just do your job.

People really are our greatest asset. But they won’t reveal their greatness until we recognise that they aren’t ‘assets’ at all.