‘So, you love bureaucracy,’ said the researcher from the BBC. ‘Can you tell us why?’ She’s calling in response to my response to a BBC blog piece entitled ‘Are there too many bureaucrats in the UK?’, where I had indeed admitted to loving bureaucracy.
‘Well,’ I reply, ‘“love” would be putting it a bit strongly. But I do think bureaucracy is the most important thing humanity has ever invented.’
I see. Not content with loving these crushing administrative behemoths – he thinks these embodiments of all that is wrong with the modern corporate world are our greatest achievement. What will the funny man say next – that toothache is a much undervalued pleasure?
But it’s true. Bureaucracy is the nervous system of society, and has been for five millennia. It puts electricity in the wires, food on the supermarket shelves and controls business and government’s every move. It puts these words in front of you right now.
So what does a bureaucracy do that society finds so invaluable? It controls the flows of information and decisions an organisation needs to carry out its activity. Different bureaucracies do this more or less well, but as long as society includes lots of different individuals doing lots of different things, and they need to collaborate across wide spaces and long periods of time, then something has got to organise them, and it’s hard to imagine any alternative that won’t be bureaucracy by another name.
But why does bureaucracy have such a bad name? Why does so much of it seem to degenerate into red tape? Why are politicians constantly planning to cut it?
The full answer is complicated, but the first part is simple. Contrary to popular feelings of frustration – feelings I share whenever they break down on me – bureaucracies rarely go wrong. A past colleague of mine, Melissa, had a useful analogy: bureaucracies are the brains of society. But, she would add, like the brains that control our bodies, ‘we only notice society’s bureaucratic nervous system when it stops working. Any idea what your visual system is actually doing right now? Me neither. But we’d all find out soon enough if it stopped doing it’.
Hence the ease with which a bureaucracy gets a bad name. Most work just fine practically all the time, but who gives thanks for the good old bureaucrats when the lights go on or our salaries arrive on time? When it goes wrong, though – the wrong tax demand, the double booking, the failed delivery – who doesn’t automatically curse the idiots who made this mistake? And if it it’s only when it goes wrong that we notice bureaucracies, how can we help but have negative feelings about them?
Actually it’s astonishing that bureaucracies work as well as they do. Even to professionals, it’s quite intimidating how much information and what a complicated process you need to come to what seems a simple decision. It takes careful thought, a strong sense of purpose and a great deal of effort to design, build and manage a bureaucracy of any size, let alone having it perform note-perfectly. And as soon as its parent organisation starts to change – which can well happen unintentionally – the bureaucracy also has to change. Given that change is increasingly a way of life for organisations, it’s not a recipe for easy success.
On the other hand, the fact that bureaucracies are as imperfect as any other human creation is no argument for less bureaucracy. That would be like saying that, because cars sometimes break down, we should have fewer of them. Now, there are lots of reasons for having fewer cars, but that isn’t one of them. And just like your car, bureaucracies need occasional maintenance – which, in my professional experience, they seldom get.
Not that I’m complaining. Most of my living comes from fixing management systems that have been allowed to wither – just recently one of the biggest UK supermarkets, a major player in the City exchanges, a healthcare company. They’re all equally lax about keeping themselves sharp – which is, after all, what even they say their administrations are for. Rather worryingly, though, I haven’t had to learn much in the course of two decades advising companies – there are still plenty making the same old mistakes.
And every time I hear about some big consultancy or software company building yet another huge IT system for the government – often to the tune of hundreds of millions of pounds – I just remind myself remember that an IT system is simply an electronic bureaucracy. Given how badly we handle the paper variety, it is small wonder that so many major IT programmes – private as much as public - turn into a ‘bureaucratic’ quagmire. Years late, millions over budget, and few happy with the final result.
In fact the way these huge government projects have so often failed illustrates what is wrong with the way bureaucracies – paper and electronic - are often treated by their owners. No one is quite sure what they are for, and executives are often allowed to make endless new demands for new information, new reports, new updates, without thought for the cost and disruption this entails. They’re also often allowed to change their minds in midstream. In fact the stream of fundamental mistakes seems to be as endless as it is easily repeated.
Middle managers and staff then have little option but to turn their administrations into all things for all men: saying ‘No’ is too often a definite Career Limiting Move. And from then on, many bureaucracies face a constant demand for more and more, frequently with little budget or resource to do more than kludge together a jerry-built ‘solution’, which its ‘stakeholders’ then expect to have at their disposal forever. And if you add to this the number of reports that bureaucracies dutifully prepare and are then never read, you can perhaps imagine the disillusionment felt by many bureaucrats.
So what is the end result? Ask the people at the sharp end. Call centre staff – the modern face of faceless bureaucracy – are quite routinely the butts of public scorn. Usually paid little more than the minimum wage, they are expected to answer perhaps 60 calls a day, day in, day out. Could you do that? I’m not sure that I could. And then there’s the abuse – not least the racial abuse routinely received by Indian call centre workers.
As one anonymous call centre worker put it on The Weekly Gripe website, ‘It's shocking how badly these people are treated. First of all they are blamed for a multitude of sins by the customer about things that are completely beyond their control. As if that isn't bad enough, next they are treated like cannon fodder for the company to blame when it all goes wrong’.
Or perhaps it’s in the nature of call centres: ‘I am sure a lot of people have the kind of mind set that means if they cannot see the person they are talking to, it is somehow perfectly acceptable to be rude, abrupt and patronising’.
Do the staff deserve it? Of course not – and no doubt most abusive callers know that. But faced with delays or not being able to get what they need, who else is there to explode at but the anonymous, faceless innocent at the other end of the line?
All in all, it’s astonishing how pleasant and polite the average call centre worker remains – but less than astonishing that the industry as a whole has staggering turnover rates. Industry figures suggest about 20% each year – which in turn suggests that the average call centre worker stays for five years. Hard to imagine. But research by George Callaghan of the Open University has challenged the official figures, concluding that the average worker stays only eighteen months.
‘Many employees expressed extreme frustration with their jobs. They were under the impression they were employed for their great people skills, but then not allowed to use those skills’, Dr Callaghan observes. ‘This is one white collar environment where employee performance is measured by the second.’
It’s a familiar accusation: bureaucracies crush the life out of professionals through their constant demands for risk assessments and reports and the constant micro-management of every aspect of their work. The public services especially seem to be prone to this – scrutiny of them is so much more intense.
Yet this is not really the result of bureaucracy as such. It is perfectly possible to design the rules that govern an organisation to include great latitude for personal discretion. They can also be built to be extremely flexible and adaptable and to be responsive to change, personal experience, unique circumstances and individual needs. It’s not bureaucracies that are at fault, any more than word processors are to blame for bad novels.
Bureaucracy as such requires only that information and decisions are designed and organised well enough to get the larger job done. In a public service organisation like a hospital, a school or a social services department, it would be perfectly possible to treat broad sweeps of professional activity as ‘black boxes’, leaving precisely what is done and how to the professionals.
The bureaucracy might also need to know a little more about how the job is carried out – who actually did the work, what resources were used (for inventory purposes only), and so on – but more than that? Only if there was a compelling reason. These people are, after all, professionals. You have employed them because they know how to do the job better than you do.
So what counts as a compelling reason for more bureaucratic control? Well, one thing shouldn’t: a media frenzy. Because even where tragedy strikes, it’s hard to imagine a better recipe for creating the wrong answer than covering your back.
After the Baby P tragedy, ‘The front-line professionals – teachers, health visitors, doctors - took fright’ recalls one healthcare worker, who prefers to remain anonymous ‘and started to make far more referrals to their local social services department. But at the same time, our own local social services department started to block direct calls between outside professionals and their staff. They even changed their telephone numbers so we couldn’t call them personally. Then we’d have to go through a long Q&A session – who we were, the child’s name and address, a lot of other details – when all we wanted was to have a quick chat, professional to professional, about whether they needed to know more about our cases. Mostly they probably wouldn’t have wanted us to refer them, but we had to go through the same rigmarole every time.’
A typical bureaucratic response to a crisis. It’s hard to see how this sort of control over professional communications made a child any safer, but it’s easy to see how it would protect the organisation.
‘Of course, when we finally got through, we just exchanged our direct phone numbers anyway, so the system was side-stepped almost as soon as it came into existence’, added my informant.
But this isn’t really the result of bureaucracy. It’s the result of managerial paranoia. Well, perhaps not paranoia – after all, a social services department’s fear of another media feeding frenzy is well founded.
So the answer is, not more bureaucracy or less, but getting bureaucracy right. But this is not something that is likely to be achieved by politicians and business executives who understand little about their own organisations’ administrations beyond the a priori assumption that it must be a bloated monster.
So the first step is to take a serious look. No, don’t hire a consultant to do it for you – go and look yourself. Martin Long, founder and ex-Managing Director of Churchill Insurance, insisted that every single Churchill employee spent regular mornings doing someone else’s job, including a turn on the call centre phones, and then suggesting three things to improve the work. Nor was he above taking a turn himself – indeed, pictures of Martin on line to customers were familiar to everyone.
I have often thought that every MD and CEO should spend some time anonymously taking a closer look at their own organisation. Like King Harry before Agincourt, a stroll past the foot-soldiers’ tents might teach them a thing or two – a very surprising thing or two – about the organisations they imagine they understand. (They just need to avoid the shameless logic chopping Shakespeare puts into Harry’s mouth.)
It’s not hard to do better than most organisations are doing right now. In fact there’s a bit of a vogue these days for so-called ‘lessons learnt’ systems that actively prompt a bureaucracy’s operators and users to feed their experience – good and bad - back to the managers who can do something about it. But it’s too early to get excited - this is only the latest of many rounds of self-improvement technique that have not quite solved the problem. Or rather, quality circles, kaizen, ‘lean’ management, Six Sigma have all helped to make bureaucracies more efficient, but whether they have made them better for their workers, customers or even the organisations that own them is a question that remains to be answered.
Still, lessons learnt systems need to be tried, if only because, unlike many other improvement tools, they ask the fundamental question of what the bureaucracy is ultimately for. It’s a bit fiddly and for many organisations deeply counter-cultural. But it’s a lot cheaper than the millions they dole out every year to consultants like me to dig their existing bureaucracies out of the pits they have created by years of poorly thought-through initiatives, weakly managed change and simple neglect.
In sum... One cheer for the general idea of bureaucracy, though it’s seldom carried out well. Another cheer for the poor bureaucrats, the butts of everyone’s scorn. But no cheers at all for the many organisations – private as well as public – who just don’t get it.
[Listen to the original BBC broadcast here.]
Wednesday, 21 April 2010
Saturday, 10 April 2010
What are the Key Success Factors for a new CIO?
I've been following the above discussion on LinkedIn here. Some interesting stuff, so I thought I'd summarise what I have read so far.
The whole thing seemed to me to break into three parts: the first 90 days, creating the day job, and justifying the 'C' in CIO. Here goes...
The first 90 days
The whole thing seemed to me to break into three parts: the first 90 days, creating the day job, and justifying the 'C' in CIO. Here goes...
The first 90 days
- Find how you can save the company money immediately.
- Ask everyone who reports to you for 10 ideas to save the company money.
- Find out how you can make the company money.
- Understand the business – goals, strategy.
- Identify your key customers and stakeholders, and set up KPIs and CSFs forthem.
- Tap existing desire for change.
- Poll IT and business for quick wins.
- Establish your credibility.
- Sell IT actively to executive & stakeholders.
- Evangelize how information makes business competitive.
- Lead how organization thinks about performance.
- Build shared view & alliances with peers.
- Know your department.
- Operations, development, governance, architecture, support.
- Define KPIs & results-based reporting.
- Learn the business
- Always have a backup plan for whatever the IT department does.
- Build a strong team.
- Talent, performance, delivery, R&R.
- Stakeholder-facing responsibilities.
- Self-managing, self-starting.
- Integrate IT and business.
- Business ownership of projects.
- Shared/interlocking governance.
- Budget/investment interlocks.
- Portfolio management, etc.
- Make sure IT do the basics right first time.
- Emphasise speed of decision-making & delivery.
- Get to grips with your basic technologies.
- Bring development and operations closer.
- Do change management simply but well.
- Routinise governance, architecture, infrastructure and operations.
- Build active innovation and self-improvement into IT.
- Lesson learnt, empowerment, etc.
- Track stakeholder satisfaction.
- Develop backup plans for whatever IT does.
- Create a credible organisational plan that embeds the dynamism of your first 90 days in IT.
- Be a business executive – not a techie.
- Define a credible but radical vision that creates a quantum jump in IT’s competence and performance.
- Goal: To move IT from technical enabler to business leader.
- Create an IT strategy that solves real business problems.
- Subordinate all tactics to this strategy.
- Manage the politics.
- Foster innovation and change.
Thursday, 4 March 2010
BPM, SOA and the relationship between business and IT
I am struck by the fact that discussions about the perennially fraught relationship between business and IT always seems to omit reference to the very different natures of business and IT. IT reality has always worked more or less at right-angles to business reality - an engineering discipline in the midst of business. The links between are generally limited to very high levels at which the relationship is mediated by very general language that does not really require either side to have any insight into the other (i.e., requirements), and at very low levels that actually have little influence over the relationship as a whole (i.e., day-to-day system users).
While this remains the case, there is no practical need for this relationship to get any better, and each side will continue to prioritise their owns engineering/business perspective over the other side’s concerns. And while IT technology always reverts to a strictly engineering mode of thought and the business side lacks a genuine ‘engineering’ element of its own, it is very unlikely that this impasse will be overcome. We can all agree that ‘something should be done’ and even agree what it is, but however important this is, it will never be urgent, and certainly not capable of being built into both sides’ day-to-day ‘common sense’.
However, my own impression is that there are developments in the pipeline that will overcome this. On the one hand, the emergence of service-oriented architectures in IT is forcing IT people to define what they do (even for themselves) in terms even the business can understand. On the other, the (rather slower) emergence of formal business process management is creating a kind of ‘business engineering’ that obliges businesses to thing of their own activity in quasi-technical terms that even an IT person can recognise. Between them, SOA and BPM are creating the language, the conceptual framework, and the technical toolkit business and IT need to create that ultimate goal, a unified business/IT worldview.
Not that this is either all that is wrong or likely to offer a complete solution. All the same, I doubt that there will be any solution until business and IT alike learn to think of themselves in such terms. This does not mean that IT people need to understand business or vice versa, but it does mean that they need to think of themselves in mutually compatible terms. Which is what, I think, a combination of SOA and BPM will achieve – without either side intending it.
While this remains the case, there is no practical need for this relationship to get any better, and each side will continue to prioritise their owns engineering/business perspective over the other side’s concerns. And while IT technology always reverts to a strictly engineering mode of thought and the business side lacks a genuine ‘engineering’ element of its own, it is very unlikely that this impasse will be overcome. We can all agree that ‘something should be done’ and even agree what it is, but however important this is, it will never be urgent, and certainly not capable of being built into both sides’ day-to-day ‘common sense’.
However, my own impression is that there are developments in the pipeline that will overcome this. On the one hand, the emergence of service-oriented architectures in IT is forcing IT people to define what they do (even for themselves) in terms even the business can understand. On the other, the (rather slower) emergence of formal business process management is creating a kind of ‘business engineering’ that obliges businesses to thing of their own activity in quasi-technical terms that even an IT person can recognise. Between them, SOA and BPM are creating the language, the conceptual framework, and the technical toolkit business and IT need to create that ultimate goal, a unified business/IT worldview.
Not that this is either all that is wrong or likely to offer a complete solution. All the same, I doubt that there will be any solution until business and IT alike learn to think of themselves in such terms. This does not mean that IT people need to understand business or vice versa, but it does mean that they need to think of themselves in mutually compatible terms. Which is what, I think, a combination of SOA and BPM will achieve – without either side intending it.
Tuesday, 10 November 2009
Twenty five years of government IT project failure...
Last Friday’s Computer Weekly included an article by Tony Collins entitled ‘Twenty five years of government IT project failure’. It’s the same old same old – this time it’s the National Offender Management Information System, aka C-Nomis – half-a-billion pounds-worth of cock-up, on which (among much else) ‘nobody was sure how £161m allocated to the C-Nomis project had been spent’.
I’ve seen enough of large-scale IT programmes in the private sector to ask a few questions, however – if not in defence of public-sector IT projects then at least to suggest that the public sector is hardly unique in its talent for dire failure.
I’ve seen enough of large-scale IT programmes in the private sector to ask a few questions, however – if not in defence of public-sector IT projects then at least to suggest that the public sector is hardly unique in its talent for dire failure.
- Who actually failed here? Who were the main delivery organisations for this and other notorious public IT failures? Were they not mainly private sector suppliers?
- Where are all the private sector successes against which the public sector is implicitly being compared? I have worked on many large private sector programmes and I cannot remember one that was not massively over budget, late and signally failed to deliver what was promised? There is for example currently a very large private health company that is currently struggling to complete an IT programme that is 400% over budget, several years late and has been descoped by 70%.
- Are we really comparing like with like? C-Nomis is spending hundreds of millions of pounds, whereas (in my experience) the private sector thinks it’s got a big job on its hands when it hits £100m. Public sector programmes are the size of minor wars – the private sector would flounder just to organise the tea breaks.
- As for the underlying faults, regular talk of undefined requirements, politicking, interminable scope and mission creep, inadequate contract and supplier management, lack of accountability, ludicrous optimism, failures of core management practices and procedures – these only go to show how much the private and public sectors have in common.
Tuesday, 25 August 2009
You don't say? Sun tells it like it is
As part of what should surely be a UNICEF programme to name and shame those who would besmirch the human mind by destroying language, here is Sun's opening on the topic of cloud computing:
I feel this terrible urge to stone someone ...
High-density horizontal computing — Sun is pioneering high-power-density compute-node architectures and extreme-scale Infiniband fabrics as part of our top-tier HPC deployments. This high-density technology is being incorporated into our large-scale cloud designs.
I feel this terrible urge to stone someone ...
Thursday, 18 June 2009
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.
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.
Thursday, 11 June 2009
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:
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).
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).
Monday, 8 June 2009
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:
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!"
"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?
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!"
Wednesday, 3 June 2009
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.
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.
Wednesday, 13 May 2009
Management quotes
Well, everyone else seems to have a list of favourites, so ...
- The way to secure success is to be more anxious about obtaining than about deserving it. William Hazlitt.
- 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. Tom Hopkins.
- 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.
- Activity is not achievement.
- Nothing great was achieved without enthusiasm. Ralph Waldo Emerson.
- Who begins too much accomplishes little. German proverb.
- 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. James Allen.
- It's only common sense? Common sense is what you think when you're not thinking. RJ Robinson.
- '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.
- All successful men are men of purpose. They hold fast to an idea, a project, a plan, and will not let go.
- 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.
- 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.
- What you don’t know will hurt you.
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.
Wednesday, 11 March 2009
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).
Tuesday, 7 October 2008
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.
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.
Thursday, 25 September 2008
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.
Thursday, 18 September 2008
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.]
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.]
Tuesday, 2 September 2008
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
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:
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.
Thursday, 28 August 2008
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.
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.
Subscribe to:
Posts (Atom)
Posts
