Recruiting square pegs for round holes

Currently looking for a new client, and as usual most advertisements include the idea that the would-be employer will only consider consultants with a strong background in [insert name of business sector/activity/system here]. Looking at a potential client with a requirement to build IT management systems and processes in the London financial sector, they say that they will only consider candidates with a strong risk system background.

I have worked in lots of sectors – software development, credit cards, insurance, defence, manufacturing, insurance – and I can’ t say that knowing about how the business worked made any substantial difference to how they needed to build their IT development management systems – methods, tools, reporting, etc. Basically, this is one case where the nature of the solution that is being built has far more in common with other solutions of that technical nature (i.e., other IT systems) than it has with other kinds of solution in that sector. So all development methodologies tend to look the same, all project management tools, all reporting systems... And why not? 80% of the time, the code for a word process is indistinguishable from the code for a bank system or a helicopter command-and-control systems.

But of course the business knows best. So they ask someone who knows all about helicopters – or insurance policies, or whatever – to build their processes, and they get ... a lump of dead, mechanical ‘process’ that looks like it was written by Franz Kafka and goes down like a lead balloon with developers.

A related mistake is to recruit someone who is good at a job to build management systems that will help other people do that job just as well. Seems sensible until you ask yourself whether you recruit a racing driver – even a very good one – to design your car. I wouldn’t. I wouldn’t even care if they had a driving license, so long as they had a long track record in designing race-winning cars.

The value of validation

I just attended a workshop on testing procedures. It was a bit worrying – not that anything was wrong with the procedures themselves (in fact they were well thought through) , but it was a bit shocking that testers still need telling.

One topic the workshop didn’t address was the distinction between verification and validation. These terms are used in different ways in different environments, so I should start by saying what I mean by each. Verification is making sure that a production meets its spec. Validation is checking that, even if it does, it will also fulfil the original requirement it is intended, to meet. Not at all the same thing, not only in the obvious sense but also in the sense that step-by-step verification from the requirements to (say) the code you are reviewing would not be equivalent to validating the code against the original requirement. There is just no substitute for asking which requirement a piece of code contributes to – and how each requirement is realised in the code.

There are lots of reasons for this, of which the fallibility of previous checking it one. But there is (a mathematician friend tells me) a much more compelling one that should convince even the most hardened reviewer and tester. This is that it is (apparently) possible to prove mathematically that no two languages can be translated into one another such that the semantics is exactly correct.

This may seem an abstruse point, so here is a practical example I have used in training courses. There is a well known saying in English that, if you translate it correctly into Russian (again, I am told) and then re-translate it back into a possible but correct English phrase. One of the possible outcomes is the following:

The vodka is acceptable but the meat is off.

So what was the original English phrase? Give yourself a few seconds before you look at the answer, which is at the foot of this post.

Now look. Not quite the same, is it? Now it is essential to recognise that both the translations, from English to Russian and from Russian to English, were both 100% correct. Just like a model may correctly represent a requirement, a design a model and code a design. And yet it is clear that if you came up with the second English phrase (the code, as it were) rather than the first (the requirement), it would leave something to be desired. The problem is, requirements, models, design and code are all in different languages (in every sense) and not two languages (let alone four) are exactly equivalent.

Hence the critical value of validation as well verification. Your just have to do it, not because your verification (reviews, testing, static analysis, etc.) isn’t good enough but because it does a different job.

Not that you should validate everything. It’s expensive, and like verification itself, not always the most productive thing you could be doing with your resources. Like everything else in good management, what you look at should be determined by the risk it represents. So only validate the items that represent a real threat if they are wrong. By and large, focus on the critical, the complex (at any level), the novel (to you). After that, either an error won’t matter much or you should be able to fix it relatively easily.

Answer: The spirit is willing but the flesh is weak. Or, more completely, ‘Watch and pray, that ye enter not into temptation: the spirit indeed is willing, but the flesh is weak’ (St Matthew 26:41).

Implementing a methodology - do's and don'ts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Don’t measure what you won’t manage

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

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

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

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

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

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

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

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

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

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

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

Management quotes

Well, everyone else seems to have a list of favourites, so here, in no particular order, are mine...

• Good management systems are like good brakes: they help you go faster.
• The way to secure success is to be more anxious about obtaining than about deserving it. William Hazlitt.
• 99% correct is wrong.
• Some things that don't count are counted, many things that count aren't counted.
• You can't rise unless you set goals that make you stretch.
• The greatest pleasure in life is achieving things that people say can't be done.
• It is not enough to aim. You must hit. Italian proverb.
• 90% of your problems have already happened the moment the ink is dry on teh contract.
• Activity is not achievement.
• Nothing great was achieved without enthusiasm. Ralph Waldo Emerson.
• Who begins too much accomplishes little.
• Quality is free, but it is not a gift. Philip Crosby, quality guru
• The best is the enemy of the good.
• Either dance well or leave the ballroom. Greek proverb.
• At the heart of every large project is a small project trying to get out.
• Good project managers know when not to manage a project.
• Failing to plan is planning to fail.
• An individual without information cannot take responsibility; an individual with information cannot help but take responsibility. Jan Carlzon, CEO SAS Airlines.
• A little risk management saves a lot of fan cleaning.
• Do your duty in all things. You cannot do more. You should never wish to do less. Robert E Lee.
• All successful men are men of purpose. They hold fast to an idea, a project, a plan, and will not let go.
• 'Begin at the beginning', the King said, very gravely, 'and go on till you come to the end: then stop'. Lewis Carroll.
• No plan survives contact with the enemy.
• Plans are nothing; planning is everything. Dwight D. Eisenhower.
• Knowledge is no more to be found in data than a house can be found in a pile of bricks. RJ Robinson.
• A good workman is known by his tools.
• Nothing is impossible for the person who doesn't have to do it.
• You can plan too much, but no one has ever been caught doing it.
• A project without a critical path is like a ship without a rudder.
• In NASA, we never punish error. We only punish the concealment of error.
• You can only elevate individual performance by elevating that of the entire system. W. Edwards Deming, quality guru.
• A badly planned project will take three times longer than expected - a well planned project only twice as long as expected.
• Pareto’s Other Principle: The first 80% of the project will take the first 80% of the budget, and the remaining 20% of the project will take the remaining 80% of the budget. RJ Robinson.
• Project management is like juggling three balls - time, cost and quality. Programme management is like a troupe of circus performers standing in a circle, each juggling-three balls and swapping balls from time to time.
• Of all the things I've done, the most vital is coordinating the talents of those who work for us and pointing them towards a certain goal. Walt Disney.
• Either dance well or leave the ballroom.
• An individual without information cannot take responsibility; an individual with information cannot help but take responsibility.
• Good estimators aren't modest: if it's huge they say so.
• The sooner you begin coding the later you finish.
• A verbal contract isn't worth the paper it's written on. Sam Goldwyn.
• What is not on paper has not been said.
• If you don’t know where you’re going, any road will take you there.
• If you don't attack the risks, the risks will attack you.
• The sooner you get behind schedule, the more time you have to make it up.
• The more you plan the luckier you get.
• A project is one small step for the project sponsor, one giant leap for the project manager.
• Quantitative project management is for predicting cost and schedule overruns well in advance.
• The philosophers have only interpreted the world in various ways; the point is to change it. Karl Marx.
• Good project managers know when not to manage a project.
• Metrics are learned men's excuses.
• Good project managers admit mistakes: that's why you so rarely meet a good project manager.
• Fast - cheap - good: you can have any two.
• The more ridiculous the deadline the more money will be wasted trying to meet it.
• The project would not have been started if the truth had been told about the cost and timescale.
• The most successful project managers have perfected the skill of being comfortable being uncomfortable.
• If it wasn't for the 'last minute', nothing would get done.
• Warning: dates in the calendar are closer than you think.
• There is no such thing as scope creep, only scope gallop.
• If project content is allowed to change freely the rate of change will exceed the rate of progress.
• If you can interpret project status data in several different ways, only the most painful interpretation will be correct.
• A project gets a year late one day at a time.
• The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man. George Bernard Shaw.
• When you describe your approach as ‘pragmatic’, do you mean ‘I’m devoid of principle’, ‘I’m completely lacking in insight’, ‘I would settle for second-best’ or ‘I’m making it up as I go along’? RJ Robinson.
• Metrics are learned men's excuses.
• I know that you believe that you understand what you think I said but I am not sure you realise that what you heard is not what I meant.
• It must be considered that there is nothing more difficult to carry out nor more doubtful of success nor more dangerous to handle than to initiate a new order of things. Machiavelli.
• I love deadlines, I especially like the swooshing sound they make as they fly past. Scott Adams (Dilbert).
• Work expands to fill the time available for its completion. Northcote Parkinson.
• Brevity is the soul of wit. Shakespeare (Hamlet).
• Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. Sun Tzu.
• Vision without acting is daydreaming, acting without vision is only pastime.
• What you don’t know will hurt you.

Creating an open project management wiki

I've been thinking about building a wiki that would contain a standard project management methodology. Initially it would just be the formal standards, processes, procedures, roles, etc. Eventually it might be connected to an open management toolset. I had in mind basing it on Prince2, but with including as much as possible (adapted as necessary) from other project management processes. The idea would not be to build an encyclopaedia of management so much as a hands-on, directly usable methodology online.

Anyone interested?

I also thought it might be something that might be supported by the industry. Any thoughts on getting something like this funded?

Stakeholder management links

I have recently started to look at stakeholder management. As usual, I began by cruising the internet for useful sites. One helpful one I have found is the Project Stakeholder Management blog at http://www.projectstakeholder.com/. Its case studies and brief articles are especially helpful, as they include many substantial ideas and interesting examples, generally from outside management. I have certainly plagiarised it shamelessly (and I hope they will return the compliment).

Thoughts on thought leadership

If you go to http://thoughtsonthoughts.net/, you'll find Cole Sandau's interesting blog about thought leadership. Reading it started me thinking about why it is so hard to get companies engaged with the idea of thought leadership. I suspect that the issue relates very closely to other issues I am personally interested in, such as maturity management.

Here is the comment I added to Cole's latest post:

I have often thought about - and despaired over - how so many companies are content to just go along with short-term actions. But if they are going to achieve a genuinely strategic approach then they absolutely need thought leadership, even if they have to buy the damn stuff from people like you ad me. Because without a clearly and explicitly articulated conception of past, present and future, all linked together by clear analytics and an implementable proposition at every level, they literally don't know what they are doing.

Which is, I think, more than a little mysterious - who would even go on holiday or down to the shops without knowing exactly what they were about? Perhaps the routines (and sheer inertia) of business makes it a little too easy to just get on with stuff. Which suggests a strategy - to put managers and execs into a situation that radically disrupts their myopic situation and forces them into innovation.

Don't know how that can be done realistically, short of threatening to fire them all is they don't come up with the goods! But my experience certainly suggests that even C-level management is neither equipped nor inclined to think at all deeply about their situation.

The reason for this is I think a little too close to home for most organisations to accept. According to some research I read a while back, the managers who are most likely to be promoted are not the one who are best at getting their job done. In fact there is almost no correlation between execution and promotion.

So of course, the higher many successful managers rise, the less they are relying on substantive knowledge and the more they rely on networking ,salesmanship and so on.

Doesn't bode well for people who care about thought leadership.

Management methods, models + theories

If, like me, you find management methods, models + theories a lot more interesting than actually managing, you could do worse than look here. It's an index of such things.

Successful managers vs effective managers

Trying to think a bit more clearly about the difference between effective managers (i.e., ones who solve problems) and successful managers (i.e., ones who get promoted), I find myself reading a 1988 paper by Professor Fred Luthans, who was/is George Holmes Distinguished Professor of Management at the University of Nebraska at Lincoln.

Professor Luthans 'found that communication and human resource management activities made by far the largest relative contribution to real managers' effectiveness and that traditional management and - especially - networking made by far the least relative contribution'.

By contrast, 'networking activity had by far the strongest relative relationship to success'.

And in summary, less than a tenth of managers made the top third of both 'successful' and 'effective' groups - which is what you would expect if there were no connection between the two.

Scary? Anyone have any ideas about how valid this finding is? Or how it is possible?

[Update - a quick email exchange with Professor Luthans confirms that, in his view, this is still the position.]

[Further update - I show this to various colleagues. They laugh. Basically, our bosses are blagging their way to the top (for non-London readers, that means getting to the top by less than legitimate means.) And no one is even faintly surprised.]

How many maturity models are there, dammit?

Looking through my files on maturity management this morning, I came across the following list - and I don't think it's even nearly complete!

• Agile Maturity Model
• Architecture Maturity Models
• Assessment Maturity Model
• Automated Software Testing Maturity Model
• Brand Maturity Model
• Business Archive Management (thanks to Cole Sandau)
• Business Continuity Maturity Model
• Business Intelligence Maturity Model
• Capability Assessment Tool (CAT)
• Capability Maturity Model for Software (retired)
• Capability Maturity Model Integration (CMMI)
• Change Management Maturity Model
• Change Proficiency Maturity Model
• Configuration Management Maturity Model
• Customer Experience Maturity Model
• Data Center Infrastructure Maturity Model
• Data Governance Maturity Model
• DITA Maturity Model
• Earned Value Management Maturity Model
• E-Government Maturity Model
• e-Learning Maturity Model
• Enterprise Architecture Maturity Model
• Extended Enterprise Architecture Maturity Model (E2AMM) v2.0
• Green Enterprise Maturity Model
• Information lifecycle management maturity model
• Information Maturity Model
• Information Process Maturity Model
• Information Security Management Maturity Model
• Gartners' Infrastructure Maturity Model
• Integrated Product Development Capability Maturity Model
• Internet Maturity Model
• IT Architecture Maturity Model
• IT Maturity Model
• IT Service Capability Maturity Model
• Knowledge Management Maturity Model
• Leadership Maturity Model (LMM)
• Learning Management Maturity Model
• Localization Maturity Model
• Managed Care Maturity Model
• Medicaid Information Technology Architecture
• Gartner's Network Maturity Model
• Open Source Maturity Model
• Operations Maturity Model
• Organisational Capability Maturity Assessment (CMA)
• Organizational Project Management Maturity Model
• Organisational Project Management Maturity Model (OPM3)
• Outsourcing Maturity Model
• People Capability Maturity Model
• Performance Engineering Maturity Model
• PM2 Maturity Model
• Portfolio, Programme and Project Management Maturity Model
• PRINCE2 Maturity Model (P2MM)
• Process Maturity Model (PMM)
• Product Development Capability Maturity Model
• Programme Management Maturity Model (PMMM)
• Project Management Maturity Model
• Property Asset Management Maturity Model
• R+D Maturity Model
• Resource-Oriented Architecture Maturity Model
• Reuse Maturity Model
• Risk Maturity Model
• SaaS Architecture Maturity Model
• SaaS Simple Maturity Model
• Security Maturity Model
• Service Desk aturity Model
• Service Integration Maturity Model
• Services Maturity Model, Self-Assessment Maturity Model
• SOA Maturity Model
• Software Acquisition Capability Maturity Model
• Software Engineering Capability Maturity Model
• Software Maintenance Maturity Model
• Software Reliability Engineering Maturity Model
• Stakeholder Relationship Management Maturity
• Systems Security Engineering Capability Maturity Model
• Talent Management Maturity Model
• Testing Maturity Model
• Threading Maturity Model (ThMM)
• Training Management Maturity Model
• Usability Maturity Model
• Web 2.0 Maturity Model
• Web Services Maturity Model
• Website Maturity Model

... and so on. And on. And on.

I also found a rather nice 'Maturity Maturity Model' and even a splendid Capability Im-Maturity Model!

Given that maturity models are basically a good idea - at least they get us away from the silly idea that radical change can be accomplished in a single step - it's a pity that so many of them are based on the chronically immature SEI CMM model. This, I have always thought, is more like a list of things the DoD finds it hard to do, in approximate order of difficulty.

I have had quite a few goes at maturity models (not to mention basing a complete book on the large-scale structure of human history on an analogous idea), including my 'Lattice Methodology', which is designed to direct strategic transformation programmes by maturity management methods, and a methodology maturity model. I may post either or both here, though I wouldn't get your hopes up just yet.

Anyone got any more? And if someone can find the URLs, I'd be happy to put them in.

Best Practice - yuk!

Am I alone in finding the phrase 'Best Practice' at best irritating and at worst deeply pretentious? How many companies have I worked in where the local Best Practice (and yes, it is always capitalised) would embarrass a mentally challenged nine-year old child? What is it about organisations that, although not yet capable even of good practice, makes them emblazon their half-baked bureaucratic nightmares with such an utterly inappropriate title?

The objectives of maturity management

The purpose of maturity management achieve the following major objectives:

• To define a strategy for creating revolutionary change by means of evolutionary steps.
• To free leaders from the limitations of corporate management systems by creating management systems that enable leadership rather than constraining it.
• To define a truly manageable management system capable of supporting fundamental, strategic change.

Surprisingly, these are not stated objectives of other management models such as the Software Engineering Institute’s well known Capability Maturity Model or the Project Management Institute’s standards. Nor are they made any easier to achieve by the approach those standards adopt, which is basically pragmatic, eclectic and bound by convention.

These objectives are described in more detail below.

Objective 1: Revolution by evolution

The primary objective of maturity management is to deliver radical, even revolutionary change. That means not merely re-invigorating moribund management systems and staunching the haemorrhages caused by poor management practice, but creating genuinely world-class organisations.

But how is that objective to be achieved? Most approaches to organisational change share at least one assumption: that radical results could be delivered in a single heroic step. Maturity management is based on a quite different assumption: that realistically, radical change can only take place in well-defined, incremental steps, quite probably extending over many years and certainly requiring many discrete developmental steps.

Hence its first objective: to define a sequence of discrete, manageable stages through which radical change can be brought about. Revolution by evolution, in fact.

Objective 2: Freeing leadership from management

One way of conceptualising how maturity management works is in terms of the distinction many authors have drawn between management and leadership. To quote Stephen Covey's Seven Habits of Highly Effective People:

Management is efficiency in climbing the ladder of success; leadership determines whether the ladder is leaning against the right wall.

Other commentators have expressed similar sentiments in different ways, but it is striking that they all insist on this difference and on the importance of leading organisations rather than merely managing them. Leaders bring vision, inspiration and direction, and without it an organisation loses its impetus, its cultural integrity and its ability to take decisive action.

Yet many organisations seem determined to encumber their leaders with unnecessary or subordinate management tasks, even actively disabling them by failing to provide the basic information and decisions real leadership demands.

Of course, no organisation could succeed by completely replacing management by leadership. Conversely, where leadership is not supported by robust management, the ‘leadership’ and ‘empowerment’ routinely degenerates into senior management abdicating responsibility for the actions, accomplishments and performance of their subordinates, backed up by the usual blame and recrimination when things go wrong.

So a balance must be struck – but only the right balance:

• The ability to manage is quite commonplace, whereas leadership is notoriously rare.
• The ability of leaders to delivery results depends on the presence of management systems (including competent and empowered managers) capable of implementing their vision.
• Unbridled, universal ‘leadership’, if not backed up with clear control of the whole, will soon degenerate into chaos, and the whole becomes a great deal less than the sum of its parts.
• Once they have been applied to a range of assignments, many leadership skills can be translated into reliable methods, tools and techniques that can be taught to less inspired individuals.

Hence another aspect of maturity management: by continually upgrading management systems, activities that previously required that rare combination of inspiration and perspiration that defines genius can be done almost as effectively by any modestly capable individual who has been trained to use the appropriate methods, tools and techniques and is supported by the necessary flow of information and decisions. Indeed, the whole history of management consists very largely of the creation of management systems to do things that were previously done only by great leaders. That is one of the main reasons why great organisations – nations, teams, businesses and so on – can exist at all.

On the other hand, where will future leaders acquire the vision on which leadership so crucially depends? Where will they get that spark of insight leavened by sound practical experience? Surely the answer is, yet again, from the management systems in and through which they work. If these systems are bad, then any manager’s experience will be less than illuminating. If, on the other hand, the management systems they use are well designed, effective and properly directed and maintained, their experience of their work, the organisation and its goals will be clear, well-structured and informative. Its purposes, methods and underlying philosophy will be clear and reinforced throughout. Conversely, the better structured the system, the easier it will be to spot any residual problems. But most importantly of all from the point of view of inculcating leadership, the values, purpose and opportunities it faces will be clear.

Hence the maturity management approach: wherever possible it replaces leadership by management. This is not because we should prefer management to leadership after all, but because we should reserve the special talents involved in leadership for tasks where they are really needed. If some leadership skills can be made so straightforward that they happen as a matter of course and the same results can be reliably achieved by the routine use of a management system, this can only strengthen an organisation, and release its true leaders to focus on areas that demand real leadership.

To summarise the whole above argument in terms of a contemporary management buzz phrase, the trick is not to rely on those who can ‘think outside the box’, but to learn from them, and so make the box the rest of us work in bigger. Much, much bigger.

Objective 3: A manageable management structure

If the purpose of maturity management is to achieve radical change by incremental steps, and its principle instrument is the conversion of leadership into management, it is clear that its next objective must be to define a management system that drives change. More precisely, maturity management must tell us:

• To define why the assignment exists, and so ensure that the assignment contributes to strategic goals.
• To define what the assignment will do, and so keep the assignment is kept on track to its goals.
• To define how the assignment will do this, and so ensure that an effective technical solution is delivered.
• To handle all the data and decisions needed to reach the above goals.

To achieve this, a maturity management methodology defines a complete, generic management system consisting of three core components:

• A generic management task model.
• A generic management system model.
• A generic management maturity programme model.

Defining generic management components makes it much easier to define management in terms of discrete units of management activity that are easily understood, easy to implement and use, and easy to revise or replace in the face of new problems and changing circumstances. It also provides the bedrock of the principles of recursion and iteration. Furthermore, by breaking the implementation process into short-, medium- and long-term changes and by embedding the components in a well defined hierarchy of maturity levels, systems and tasks, it is easy to adapt the generic components to local needs and the most appropriate methods, tools and techniques.

Two principles of management design

Although a great deal of effort goes into making many management systems intelligible to their users, many still suffer from a degree of opacity that follows from the way in which most systems are constructed: either by the ad hoc inclusion and generalisation of local practices or through the more or less mechanical incorporation of external ideas and structures such as public standards and guru-derived ‘concepts’. This makes for management systems that are not only hard to use but that would not work well even if they were used correctly.

To counter this a little, there are two general principles all management systems should implement: recursion and iteration.

Recursion

Recursion means that the same process is used at all levels of a given activity. For example:

• To ensure that we all mean the same thing when we speak of ‘management’, the same principles and generic process should govern management at every level of the organisation, from strategic direction to day-to-day operations.
• If a manager needs to define local processes in more detail, it should be possible to re-apply the main process recursively (ie, to its own components).

(If, like me, you like that sort of thing, the best definition of recursion of which I am aware was given by an early Smalltalk dictionary, whose entire entry for 'recursion' consisted of the words 'see "Recursion"'.)

Iteration

Iteration means that the same process is used across all parts of the organisation. For example:

• To ensure that the integrity of all processes and management activity is maintained, change-related processes such as change, issue or risk management should be designed so that they consist of the recursive application the standard generic process, not a special (and probably anomalous) processes of their own.
• However special they may feel that their work is, all specialist groups (such as legal departments and supplier management) should adhere to the same principles and generic processes as the groups responsible for the ‘main process’.

These principles are combined for managing individual assignments. To ensure that managers are empowered without increasing the risks inherent in allowing local groups to make critical decisions, the management system should consist of ‘black boxes’, within which the local managers can structure activity as they see fit, so long as the local management system adheres to the Lattice Methodology and they process the required inputs into the required outputs. This approach would also enhance local commitment to and involvement in system improvement.

The real challenge

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

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

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

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

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

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

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

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

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

What is a management system?

A ‘management system’ consists of the totality of structures, functions, processes and mechanisms provided by the organisation as a whole, that enables managers to carry out their work successfully. Depending on its overall maturity, a typical management system will:

Identify the strategic purpose of individual assignments:

• Translate corporate purposes, goals and objectives into assignment purposes, goals and objectives.
• Provide strategic, process, technical and work environment planning.
• Assignment definition and validation processes.
• Define the relationship between the manager’s work and the company strategies, including an organisational structure, communications networks, shared information and decision-making processes, and so on.

Define the processes needed to carry out an individual assignment:

• Define management’s authority and responsibilities.
• Define a range of generic methodologies for executing processes of different kinds.
• Define the detailed functions and tasks needed to carry out a process.
• Provide a range of options and alternatives within any single process, and supply the methods and tools you need to choose between them.

Provide the technical resources and materials needed to carry out any assignment:

• Skilled people.
• Tools and systems (production lines, computer-assisted development tools, test tools).
• ‘Delivery vehicles’ (such as templates) for common technical activities.
• Technical support (R&D, configuration management, standards, tools development, etc.).

Create a working environment that actively supports the assignment:

• Support services (recruitment, training, repositories, tools development, coaching and mentoring, etc.).
• Administrative services (clerical support, data management, record management, standards, analysis and reporting tools, etc.).
• Work facilities and infrastructure (space, hygiene, communications, clerical materials, etc.).
• Storage for interim products (filing, configuration management, etc.).
• Processes and mechanisms for reassigning the assignment’s facilities once the assignment is complete.

Create and manage generic standards and procedures:

• Establish and maintain management methods, tools and techniques.
• Reference metrics.
• Create common and generic work facilities.
• Create support organisations.
• Define the manager’s relationship to stakeholders and regulatory authorities.
• Define the manager’s relationship to third parties such as contractors, suppliers and consultants.

Looks like a checklist to me...

Another way of defining the ideal management system is to take the shortcomings of many existing systems, as described above, and see what would have to be done to remedy them Here is an initial list:

Unnecessary fire-fighting would be eliminated if each management task or function was defined and effectively implemented. Among these tasks would be that of constructing new tasks as circumstances require. The definition of any given task might include (amongst other things):

• Task-specific objectives.
• The steps that are needed to carry it out.
• Defined inputs and outputs.
• Parameters for adapting it to different types of assignment.
• Supporting standards and procedures.
• The methods, tools, techniques, skilled resources needed to execute it efficiently.

These management tasks would be integrated into single whole, thus creating a management system properly so called.

• That system would incorporate (again, amongst other things) clear task interfaces and a fully mapped flow of information and decisions connecting the start and end points of any given assignment.
• Such a system would not only translate organisational goals into assignment requirements, management processes, technical resources and administrative functions …
• …but also provide early warning systems that trigger realistic and appropriate action, before adverse trends and risks turn into crises.

An ideal management system would also be adaptable to the demands of individual assignments. Very many current management practice already include quality plans to deal with this situation, but a more sophisticated system would be truly systematic:

• It would define parameters and tools managers would need to configure the system to meet each assignment’s unique objectives.
• It would be based on business objectives, the assignment’s critical success factors and its intended business purpose (product/service quality, operating costs, time-to-market, etc).
• It would match system components dynamically, to each assignment’s functional needs, not statically and according to the formal management system’s structure.

The performance and outcomes of individual assignments would be recorded in reusable formats, from which other assignments could benefit.

• This would require global repositories for organising and distributing key timely and reliable information and decisions, accredited subject matter experts and information mining tools.
• Such an approach would also allow multiple assignments to be integrated into completely work programmes.
• And of course, you would have to structure assignments in appropriately flexible and multi-dimensional terms in the first place – otherwise dismantling them for reuse would become a major project in its own right.

Out of such a system and the experience that it generates is abstracted and systematised a comprehensive model of all the factors and forces affecting the organisation, and a system for their management and further development. Such a structure would allow management to be as precise as it needs to be (with any degree of precision being attainable), would look forward and backwards over any strategically meaningful timescale, would structure any degree of internal and external complexity and change into simple, manageable terms, and could deal with any meaningful and credible future scenario. Thus, it would enable the organisation to exercise genuine industry leadership, capable not only of ensuring the organisation’s attainment of its current strategic goals but also of achieving the ultimate strategic objective, namely control over the environment in which the organisation operates.

Of course, even the most sophisticated a management system alone cannot create the vision needed to see where an organisation should be going, but the kind of system that is described above would surely be able to integrate complexly interacting strategies, goals, processes, systems, and so turn any rational vision into reality.

Few organisations really provide such a system, so managers as seldom as efficient or effective as they could be. On the other hand, the lack of such a system means that both individual managers and entire organisations operate in a half-light of inefficiently, assumption, politics, ad hoc adjustment and barely concealed crisis management. Internal propaganda levels are high, but real expectations are low.

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.

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.