Can non-technical reviewers review technical products?

In many (perhaps most) of the organisations I have worked in, the question of who reviews what has been either contentious, ambiguous or been given a quite unnatural answer. The reason for this unhappy situation is that it is often difficult for a non-technical reviewer to evaluate a project, especially its technical content.

In my own specialist area – IT – this might manifest itself in a pained question such as ‘How can the business approve a change in a database design?’ But there are similar questions in all complex management situations – can techies contribute usefully to business cases, for example?

Good question – and in my experience, people only say ‘good question’ when they mean that there’s no good answer. But in this case, there is an answer, and what is more once the answer is understood it leads to a more robust approach to reviewing generally.

The basic problem is to decide what objective reviewing is trying to achieve, and so to decide whether non-technical (non-business, etc.) reviewers have any role to play in achieving it. To put it concisely, the purpose of reviewing is to decide whether the item under review is meeting its requirements. I don’t mean this in the technical sense of ‘requirement’ – i.e., something the work is supposed to achieve for it to be considered a success. I just mean does it do what it is supposed to do? This might well mean ‘does it fulfil its requirements?’, but it could also mean ‘does it comply with this specification’ or ‘if we follow this plan, will we succeed?’, or any number of other things.

From that point of view, the right reviewers are the people who can – and need to – make that call. But that still doesn’t mean that they are technically capable of understanding the item they are reviewing. Or are they? In what sense do they need a precise technical understanding of the content of the item – for example, a design document - to be able to evaluate it? To put my complete argument in a nutshell, what I am getting at is the idea that reviewing is based not on what it says so much as on what it means.

To go back to my problem about business people reviewing a change to a database design. Can they understand what the change says? Probably not, if by that you mean their grasp of namespaces, indexing and denormalisation issues, and their opinion of such things, in strictly technical terms, is probably worthless.

But that isn’t necessarily all that the review is for. For behind every such technical change, there is a pyramid of managerial and business implications that non-technical reviewers can not only understand perfectly well but are probably better judged by non-technical people.


This is illustrated in the following diagram (click to expand):

Hopefully it is clear what the diagram implies. At the lowest level, where the database change itself occurs, there is probably little benefit to be had from asking non-technical people what they think of the change from a purely technical point of view. ‘Who knows, and who cares?’ is probably the right answer. But as soon as the wider implications of the change – the non-technical elements of what the change means rather than the details of what the change documents say – start coming to the fore, both their interest and their ability to judge should start to grow rapidly.

For example, assume that the database change in question is to move from a distributed to a centralise structure. Although the technical issues will be beyond the business’ grasp, and so will most of the implementation and operational issues, not much else should be beyond them. Looking at the diagram again, what are the changes in test requirements this database change will call for? To have all your database testers in one team, located centrally, rather than separate teams all around the business? What does that entail? Much lower costs? Great, we’ll have it. And a simplified roll-out that can now happen three months earlier? Even better. But what is the downside? The changes in platform mean that we will need to recruit a whole new database team? How long will that take? What will it cost? Oh... not such a no-brainer then. And there’s a small chance that we won’t be able to meet our delivery timescales after all? But at least the total development cost will be well down? Great! But the operating cost will in fact go up? Damn...

It’s a complicated business, as anyone who has been in such a situation will testify. But perhaps it should be – and perhaps excluding the business (and other non-technical people) from reviews on the grounds that they ‘won’t understand’ what they are reviewing is not only a very narrow interpretation of what ‘understanding’ means in such a situation but positively counter-productive. After all, if you don’t ask them now, when will you? When it’s too late?

Of course, it’s not easy to make sure a review like this is successfully executed. It’s very hard to work out the real implications of as subtle a thing as a database change. But if you are the project manager and you can’t tell your customers what the consequences of your project really are, perhaps you should be finding out. After all, it’s not as though they will never find out. But the alternative to telling them in an orderly and systematic manner like the above can only be finding out through missed milestones and blown budgets.

In a way none of this should need saying – anyone who does a change request nowadays will perform an impact analysis that covers most of these issues. But as so often in project management, this simple lesson simply has not spread in the systematic manner to areas like reviewing (product or project) as one would have hoped.

How stage boundary reviews work

Stages are a basic concept in project management these days, and whole methodologies such as Prince2 and practically every other delivery method, from waterfalls to DSDM assume the same stage-based structure. But although all such methods conclude each stage with a stage boundary review, I have found little coherent thought on this topic. So here is my tuppence-worth.

This rather unhelpful diagram (click to expand it) shows the basic position reviewers finds themselves in: the orange oblong is the project, with the vertical lines marking the stages. The current review is right there in the middle – some way through, but still a way off the project’s end.











So how can you tell how well you are doing? There are basically four questions about the project itself you want answers to:

1. Did the last stage go as planned?
2. Is your project making satisfactory progress as a whole?
3. Will your project deliver as expected?
4. Based on the above, what exactly do you need to do about the next stage?

So that is exactly which the next four diagrams explain. Firstly, looking back on the most recent stage, how did it go?

For example, was product quality as required, specified and planned? Were milestones and deliverables as expected? Was the stakeholders’ involvement as agreed, and even if it was, was it enough? When coming up with a stage boundary review checklist, you could do a lot worse than start from these basics.

Next, looking back right to the project start, how has it gone so far?












In particular, what have the trends been? How has the project’s profile evolved over time – stage by stage, how have its basic features such as scope, delivery, cost, quality and risk unfolded? Are there recognisable trends? If so, what were they, what do they mean and what do you plan doing about them?

The next question involves a complete about-face, and requires you to stop looking back and start looking forward. And the basic question is now, What are your project’s prospects? Looking to the end of the project, are there any unexpected obstacles? Risks? Threats? Opportunities? If there are, again, what do you plan to do about them?











Finally – at least as far as the project itself is concerned - now that you know how you are doing and what the longer-term picture looks like, are you ready to start the next stage? For example, are the following all well defined and has provision been made for the all to be managed? Your plans and estimates? All outstanding issues and risks? Your project’s dependencies? The right team + resources? The right technology, facilities and environments? The right stakeholder awareness, commitment and involvement? If not, now is the time to do something about it.











But of course, projects do not exist in isolation. Unless you are operating in your own private universe, the project must also be evaluated from the point of view of the organisation on whose behalf it is being run. So there are four more questions that need to be answered before you can call your stage boundary review complete:

1. Does the project still fit the portfolio?
2. Is the project’s business performance acceptable?
3. Does the project comply with all relevant policies and standards?
4. Is all project information and decisions under formal control?

Hence the next four pictures, of which the first illustrates the first question. The fact is, it is perfectly possible for a project to be a roaring success and yet still be canned, for the simple reason that it no longer serves the organisation’s wider purposes. Conversely, a limping project may be kept alive because, however badly it is performing in its own right, it is indispensable to some larger programme or strategy. So it is crucial for your review to ask whether this project still makes sense, and if not, what must be done (including killing it) to make it fit the bigger picture?














Conversely, exactly how well is the project doing from the organisation’s point of view? Hence the next question, which is to evaluate the project against its business case. Costs? Benefits? Risks? Without answers to questions like these, it is hard to see how the project continues to be justified.














There is also a more practical side to a project’s ‘fit’, which is illustrated in the final two pictures. The essential question posed by the following diagram is this: Does the project comply with all relevant policies and standards? These might take many forms – regulatory requirements, quality standards, corporate policies, business roadmaps – anything that defines the broader shape into which the project must fit to be considered a success.


















Finally, the project is part of the wider organisation from an operational point of view too. It needs to fit in in the sense that it is being tracked and recorded and measured and analysed and all those other things middle management do. This naturally raises a range of essentially administrative questions about whether the project is up-to-date regarding things like records, reports, escalations, change control, lessons learned, and so on. If not, perhaps now is the moment to do something about it.


















Once you have this basic logic, the next issue is to identify specific questions (and perhaps measures) you would use to work out the answer. You will probably end up with a hundred or so. Usually people react to this number with horror – surely it will take days to review a project against more than 100 criteria? But in practice this is not a problem. After all, the stage is presumably only ending because the project manager believes that the project has met all that stage’s requirements (or if not, has obtained the necessary exemptions and waivers and re-baselined the project accordingly). That means that deliveries are complete, records and reports up to date, change requests all dealt with, all residual issues and risks under control, and so on. If that is the case – which is a logical entry condition for a stage boundary review – then the answer to every single one of your hundred questions is going to be simple and straightforward. The entire review should take literally seconds per question, and minutes for the review as a whole. Well, that may be a little optimistic, but if the review does take a lot longer than that, it should not be because there were so many questions to answer.

It is quite simple in concept. However, there are also certain things you do not want your boundary reviews to deal with. Unfortunately quite a few review systems I have worked with fell into these mistakes. Perhaps the most common is repeating tasks that should already have been put to bed – checking that the right people signed of the last stage’s deliverables, even reviewing them again, and so on. This mistake is usually indicated by the kinds of question the review checklist contains – about the content of documents, not the state of the project.

That in turn brings up a further important point: that the purpose of the review is to check the viability of the project as a whole. It is crucial that the review process is designed to perform this task and this task only. Everything else should have been completed as an entry condition for the review itself. If it isn’t already done, most people won’t be interested or qualified to participate. After all, stage boundary reviews are governance events, and the way they work – and do not work – should reflect this fact.

Another typical error is to attempt to score the results. Although not a mistake in principle, it usually doesn't work. Recently I worked with a client whose reviews include scoring each item, and the review has to reach a pre-defined target if it is to pass. I don’t really understand this.

Firstly, it is the Project Board’s job to make that call – not some artificial calculation. Secondly, most such systems are not in fact measuring anything. In some cases, the scores are completely subjective. That is, reviews are asked to give the item a score. But by and large they do this without any objective guidelines as to how to score and in full knowledge what the ‘pass’ score is! So if they want the review to pass and they know that the pass score is, say, 3 out of 5, they give the item – at least 3! Not only are scores of this kind quite meaningless but by using numbers an illusion of objectivity is created.

In other cases, the scores stand in no real relationship to any quantified metric of success or failure. So even if you really can tell that this item is worth only 3 out of 5, there is little or no link between the criteria and the overall success of the project. So the number, interesting though it may be, is completely unconnected with the purpose of the review!

Finally, problems that arise during a stage boundary review should not usually derail or even delay the project. Again many companies take the view that ‘failing’ a review should stop the project until everything is fixed. In the first company I ever worked in that used SBRs, the whole of the previous stage had to be repeated! This is bonkers, of course.

The right approach, I think, is to treat the review as a whole as an key moment of consolidation for the project as a whole, but to treat the problems it raises as individual risks. It is possible that the outcome of the review will be the project’s cancellation or a fundamental re-structuring, but this should be rare. More usually, most work should continue as planned while the review is taking place, and only things connected with the specific issues raised by the review should be delayed as a result of the review. If there is something so fundamentally wrong with the project that it should simply cease, it should not take a stage boundary review to work this out!

What business cases are worth

Although a sceptic about many aspects of business, one thing that seems to offer real value is the business case. Being able to show that what comes out will be more than what goes in strikes me as a fairly elementary requirement for testing whether a project or operation is worthwhile, and some of the business case models I have seen are pretty sophisticated.

Pity so few businesses have any idea how to use them. A few may be using concepts like ROI for real planning, but for most this sort of calculation is used strictly after the event. Likewise for project-based organisations. For example, in the IT world a majority of projects now have a business case, but only a minority really use it to manage the project. It ought to be an invaluable means for making all sorts of decisions – prioritisation, triage, change requests, everything really. But in practice it isn’t.

My favourite business case story comes from a decade ago, when I was consulting to a credit card company. One day there landed on my desk the business case for a marketing project that said, among much else, that one of the benefits planned to accrue from the project was that the company would issues 750,000,000 more cards in Europe.

750,000,000 more cards? That was almost two for everyone in the EU! So of course I rang up the analyst who had written this and it turned out that he had meant to write 750,000 – a rather more realistic number. We had a friendly and very amusing conversation about how easy it is to make mistakes of that kind. But when he said he would correct the document and reissue it, I asked him to leave it just as it was and se who else noticed.

So we waited. And waited. The claim was repeated in every important document from that point on wards – the requirements spec, the analysis, the designs, the testing – everywhere. And not a single other individual questioned this preposterous number. Ever.

Top 10 CSFs for metrics programmes

Some preliminary thoughts about what will help make a success of a metrics programme. Most are not about metrics at all, though - which should not be too surprising, given that the main problems with metrics programmes are much the same as for any other management programme:

1. Work out what you are measuring for. More precisely, make sure that every metric is tied to a goal you are trying to achieve. More precisely still, make sure that every measurement is explicitly tied to a key performance indicator that is explicitly tied to a critical success factor that is explicitly tied to a goal you are trying to achieve.
2. Conversely, ensure that you have the sponsorship needed to force/enforce action. If your boss doesn't' want it enough to make it happen, it won't survive.
3. Measurement is not the first step in management. It assumes at least a fairly mature management environment. If you don't have that, and if the problems, data, tools and techniques you use are not at least fairly well established, then your measurements will mean practically nothing.
4. A measurement programme is not just a technical tool, it's a whole management programme. And as with every management programme, success comes from spreading awareness, commitment and involvement.
5. Things must be seen to improve following metrics-based reports. Otherwise what is it for, and why should anyone collaborate?
6. Conversely, only measure things you can really change. Discovering that you are really bad at something you have no choice about (regulations, things that are too expensive or not politically acceptable to change, and so on) is a waste of effort, creates aspirations to improve in areas you don't control and is just plain depressing.
7. The programme must serve the interests of those who collect the data. Otherwise collecting it will be hard work and the quality of the the data will be poor.
8. Don’t use metrics to single out individual culprits. They will soon start to massage the figures, and personal problems are usually only symptoms of system problems.
9. Measures must be unambiguously defined, fully understood and consistently applied.
10. This isn't trivial. Investment, training and tools must all be provided.

Metrics with no baseline

Most organisations start a metrics programme without baselining their current performance. Although quite a few people get their knickers in a twist about this ('How can you measure anything if you don't have a baseline??!!), it may not be good, but neither is it fatal …

Here are some methods for creating a perfectly credible metrics programme with no baselines:

1. Decide it doesn’t need a baseline. Sometime trends are not important to the problem you are trying to solve.
2. Estimate the baseline from indicative data. For example, financial figures are frequently good indicators, even if they are inherently indirect measures of what you are really interested in.
3. Don’t create a baseline – measure from Day 1 only. Just worry about getting better or worse.
4. Review a sample of the existing population, and treat that as your baseline. Just make sure that your sampling is meaningful, which is not as easy a thing as it sounds.
5. Adopt industry standards. They may not represent the best, but they are not a bad starting point.
6. Start from targets, not baselines. That way you'll have something to move towards rather than away from, which is lot more positive.
7. Don't even measure. Sometimes you just know what needs doing!

Documenting V-model-based methodologies

I am often involved in methodology development projects, usually based on the standard V-model. Because any serious solution delivery process now greatly exceeds this simple model, yet it is hard to diagram the extra tasks without creating a complete mess that no–one can understand, this raises the question of what functions, processes and tasks need to be shown outside the main V.

In response, the first question I would ask is what exactly your organisation’s ‘standard’ approach is. That is, what is the approach that you usually take to delivery, that occupies 80% of your people 80% of the time, and so on? That then tells you what should lie in the main V, and what not.

In any organisation whose maid delivery process is bespoke development (as opposed to, say, buying in and adapting packages), I would suggest that all else should be pushed off the main V. This would normally mean that the following are all put offline from the main diagram:

• Procurement.
• Service delivery.
• Testing.
• Project management.
• Business change management.

I would expect each of these to develop its own process (frequently its own V) and to be accessible directly from the methodology home page. Essentially, the reasons why each of these functions needs pulling out are that:

• It’s a minor variant of the major process - the main V should show only the major process (e.g., in this case, procurement).
• It is logically asynchronous with the chosen logical model of solution delivery – in most cases, stage-based development (e.g., test preparation of various kinds).
• Its logical structure is non-linear (e.g., project management).
• It may be invoked at any point (e.g., change control, defect management, risk management, and so on).
• It has a specialised audience, so most people don’t need to know how it is done (all lower-level technical processes).

So procurement should excluded from our V-model only because it is not the usual method for doing delivering a solution, and may not happen at all for many projects. If, however, you are predominantly procurement-driven, then procurement should move straight into the V and bespoke development be put off-line.

Hence also my exclusion of project management from the V, which will probably strike most people as off. But most project management activity (governance, planning, task assignment + tracking, risks and issues, reporting, etc.) is either ad hoc, repetitious or cyclical, and does not fit the linear structure of a V.

On the other hand, to make sure that everything stays aligned and everyone knows what they are supposed to be doing, the main V should ideally include not only everything in the standard delivery sequence path but also the touch-points with each of these other functions. This should indicate the points at which show not only where they provide their respective ‘services’ but also the points at which they take their ‘feed’ from the main process. This can make the main diagram physically or logically complex, but I think that that would be ideal.

For example, the main links between a bespoke development V and service planning are probably:

• During Initiation, where service planning needs to indicate the contributions it will need to make to the project.
• During Requirements, where service planning needs to identify the non-functional requirements it they need to define SLAs, shape the environmental design, and so on.
• During Design, service planning generally need to be involved in environmental + infrastructural design.
• During Build, service planning may need to be involved in unit + integration testing where these relate to infrastructure and environments, and in non-functional testing where this is will bear on SLAs.
• During system testing, service planning will be interested not only in non-functional testing but also in identifying any work-arounds + FAQs (for the Help Desk), plus starting to collect any residual defects that are likely to affect the working solution.
• Finally, during the Deployment stage, service planning will be involved in Operational Acceptance Testing and a range of deployment planning and activity.

There may be other lesser dependencies, such as where various flavours of readiness need to be checked. But by and large, the definition of all these tasks, plus any supporting techniques, tools and templates, guidelines, process maps, and so on, can all lie outside the main V. Only the touch-points need to be identified there.

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.