Some years ago I implemented DSDM (then the preferred flavour of Agile) at Churchill Insurance. As far as the core processes were concerned, there was no great difficulty (admittedly we threw everything at it), but the business was a problem for two key reasons: empowerment and availability.
The nub of the empowerment issue was asking the business to allow their own representatives on the project enough authority to approve of what was going on on the spot (e.g., prototypes, changes, reprioritisations, etc.), without constantly referring to senor management. In short, they could not let go of the strings. As anyone who has worked in IT projects for any length of time will know, there is a ludicrous irony in this, because quite a lot of the problem with delivering successful IT projects of any kind is the business’s ambivalent attitude the ownership. In all too many companies, the business want to be in control of the project (i.e., able to make make-or-break calls about it) without taking responsibility for its delivery. The implicit question is always, do you prefer delivery to control?, and all too often the effective answer is ‘control’. This is as much a problem for Agile as it ever was for waterfall projects.
The second problem was getting the required effort from the business representatives to the project. These individuals were necessarily very experienced and valuable people (who else would you empower?) but that was precisely what made them hard to replace in their day jobs. So we needed them to spend about three days a week on the project, but they still needed five (usually very long) days for their BAU work. No surprise, then, that project work soon started the back seat to day job, the quality and speed of decision-making plummeted and the project started to look pretty wonky.
So although the business was keen on an Agile approach, they could not participate effectively. It was a long struggle – only partially successful – to deal with this problem.
Showing posts with label Risk. Show all posts
Showing posts with label Risk. Show all posts
Wednesday, 19 May 2010
Moving to Agile - Creating an Agile environment
In my experience a crucial precondition for achieving agility is a certain level of maturity. Although the core processes, roles and tools are critical, so is the presence of quite a wide range of highly standardised core mechanisms of which the agile operations can take advantage.
The classic example, familiar from IT development (whence agility sprang, of course) is test automation. Without this the development team is unlikely to be able check its day’s labours swiftly enough to move on confidently the next day. But test automation itself can only be adopted by an organisation that already has standardised test classes, a well established test process, a clear understanding of the basic mechanisms of test scripting, and so on. Without all of these (and much more), test automation will fall flat on its face – becoming either ineffectual or rigid – and quickly start to turn agility into paralysis.
Of course, in a vey small, simple project or activity, the preconditions for agility are very limited. But in a more complex situation, such as BAU operations or a large-scale programme, agility can be achieved, but only ensuring that a full ‘agile environment’ is also in place. The elements of this environment can themselves be agile, but they certainly must be present and specifically geared to allowing other areas to take them completely for granted – it is, after all, the most basic basis of agility that the would-be agile activity can either omit or take for granted that everything in their environment.
Hence one of the key task – perhaps the single most important task – when implementing agile methods is to investigate what the organisation’s ways of working can offer to the agile area – and what they demand from it too.
A few (there are many more - this is just a flavour) of the areas you need to get right include:
The classic example, familiar from IT development (whence agility sprang, of course) is test automation. Without this the development team is unlikely to be able check its day’s labours swiftly enough to move on confidently the next day. But test automation itself can only be adopted by an organisation that already has standardised test classes, a well established test process, a clear understanding of the basic mechanisms of test scripting, and so on. Without all of these (and much more), test automation will fall flat on its face – becoming either ineffectual or rigid – and quickly start to turn agility into paralysis.
Of course, in a vey small, simple project or activity, the preconditions for agility are very limited. But in a more complex situation, such as BAU operations or a large-scale programme, agility can be achieved, but only ensuring that a full ‘agile environment’ is also in place. The elements of this environment can themselves be agile, but they certainly must be present and specifically geared to allowing other areas to take them completely for granted – it is, after all, the most basic basis of agility that the would-be agile activity can either omit or take for granted that everything in their environment.
Hence one of the key task – perhaps the single most important task – when implementing agile methods is to investigate what the organisation’s ways of working can offer to the agile area – and what they demand from it too.
A few (there are many more - this is just a flavour) of the areas you need to get right include:
- A governance system that allows for rapid validation and approvals of many incremental releases.
- Business and operational organisations and processes that are capable of assimilating frequent change.
- Office arrangements that support closely collocated teams.
- Extremely slick mechanisms for remote groups – vendors, outsourcers, other offices, and so on.
- System architectures that support rapid change.
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).
Sunday, 17 August 2008
How stage boundary reviews work
Stages are a basic concept in project management these days, and whole methodologies such as Prince2 and practically every other delivery method, from waterfalls to DSDM assume the same stage-based structure. But although all such methods conclude each stage with a stage boundary review, I have found little coherent thought on this topic. So here is my tuppence-worth.
This rather unhelpful diagram (click to expand it) shows the basic position reviewers finds themselves in: the orange oblong is the project, with the vertical lines marking the stages. The current review is right there in the middle – some way through, but still a way off the project’s end.
So how can you tell how well you are doing? There are basically four questions about the project itself you want answers to:
So that is exactly which the next four diagrams explain. Firstly, looking back on the most recent stage, how did it go?
For example, was product quality as required, specified and planned? Were milestones and deliverables as expected? Was the stakeholders’ involvement as agreed, and even if it was, was it enough? When coming up with a stage boundary review checklist, you could do a lot worse than start from these basics.
Next, looking back right to the project start, how has it gone so far?
In particular, what have the trends been? How has the project’s profile evolved over time – stage by stage, how have its basic features such as scope, delivery, cost, quality and risk unfolded? Are there recognisable trends? If so, what were they, what do they mean and what do you plan doing about them?
The next question involves a complete about-face, and requires you to stop looking back and start looking forward. And the basic question is now, What are your project’s prospects? Looking to the end of the project, are there any unexpected obstacles? Risks? Threats? Opportunities? If there are, again, what do you plan to do about them?
Finally – at least as far as the project itself is concerned - now that you know how you are doing and what the longer-term picture looks like, are you ready to start the next stage? For example, are the following all well defined and has provision been made for the all to be managed? Your plans and estimates? All outstanding issues and risks? Your project’s dependencies? The right team + resources? The right technology, facilities and environments? The right stakeholder awareness, commitment and involvement? If not, now is the time to do something about it.
But of course, projects do not exist in isolation. Unless you are operating in your own private universe, the project must also be evaluated from the point of view of the organisation on whose behalf it is being run. So there are four more questions that need to be answered before you can call your stage boundary review complete:
Conversely, exactly how well is the project doing from the organisation’s point of view? Hence the next question, which is to evaluate the project against its business case. Costs? Benefits? Risks? Without answers to questions like these, it is hard to see how the project continues to be justified.
There is also a more practical side to a project’s ‘fit’, which is illustrated in the final two pictures. The essential question posed by the following diagram is this: Does the project comply with all relevant policies and standards? These might take many forms – regulatory requirements, quality standards, corporate policies, business roadmaps – anything that defines the broader shape into which the project must fit to be considered a success.
Finally, the project is part of the wider organisation from an operational point of view too. It needs to fit in in the sense that it is being tracked and recorded and measured and analysed and all those other things middle management do. This naturally raises a range of essentially administrative questions about whether the project is up-to-date regarding things like records, reports, escalations, change control, lessons learned, and so on. If not, perhaps now is the moment to do something about it.
Once you have this basic logic, the next issue is to identify specific questions (and perhaps measures) you would use to work out the answer. You will probably end up with a hundred or so. Usually people react to this number with horror – surely it will take days to review a project against more than 100 criteria? But in practice this is not a problem. After all, the stage is presumably only ending because the project manager believes that the project has met all that stage’s requirements (or if not, has obtained the necessary exemptions and waivers and re-baselined the project accordingly). That means that deliveries are complete, records and reports up to date, change requests all dealt with, all residual issues and risks under control, and so on. If that is the case – which is a logical entry condition for a stage boundary review – then the answer to every single one of your hundred questions is going to be simple and straightforward. The entire review should take literally seconds per question, and minutes for the review as a whole. Well, that may be a little optimistic, but if the review does take a lot longer than that, it should not be because there were so many questions to answer.
It is quite simple in concept. However, there are also certain things you do not want your boundary reviews to deal with. Unfortunately quite a few review systems I have worked with fell into these mistakes. Perhaps the most common is repeating tasks that should already have been put to bed – checking that the right people signed of the last stage’s deliverables, even reviewing them again, and so on. This mistake is usually indicated by the kinds of question the review checklist contains – about the content of documents, not the state of the project.
That in turn brings up a further important point: that the purpose of the review is to check the viability of the project as a whole. It is crucial that the review process is designed to perform this task and this task only. Everything else should have been completed as an entry condition for the review itself. If it isn’t already done, most people won’t be interested or qualified to participate. After all, stage boundary reviews are governance events, and the way they work – and do not work – should reflect this fact.
Another typical error is to attempt to score the results. Although not a mistake in principle, it usually doesn't work. Recently I worked with a client whose reviews include scoring each item, and the review has to reach a pre-defined target if it is to pass. I don’t really understand this.
Firstly, it is the Project Board’s job to make that call – not some artificial calculation. Secondly, most such systems are not in fact measuring anything. In some cases, the scores are completely subjective. That is, reviews are asked to give the item a score. But by and large they do this without any objective guidelines as to how to score and in full knowledge what the ‘pass’ score is! So if they want the review to pass and they know that the pass score is, say, 3 out of 5, they give the item – at least 3! Not only are scores of this kind quite meaningless but by using numbers an illusion of objectivity is created.
In other cases, the scores stand in no real relationship to any quantified metric of success or failure. So even if you really can tell that this item is worth only 3 out of 5, there is little or no link between the criteria and the overall success of the project. So the number, interesting though it may be, is completely unconnected with the purpose of the review!
Finally, problems that arise during a stage boundary review should not usually derail or even delay the project. Again many companies take the view that ‘failing’ a review should stop the project until everything is fixed. In the first company I ever worked in that used SBRs, the whole of the previous stage had to be repeated! This is bonkers, of course.
The right approach, I think, is to treat the review as a whole as an key moment of consolidation for the project as a whole, but to treat the problems it raises as individual risks. It is possible that the outcome of the review will be the project’s cancellation or a fundamental re-structuring, but this should be rare. More usually, most work should continue as planned while the review is taking place, and only things connected with the specific issues raised by the review should be delayed as a result of the review. If there is something so fundamentally wrong with the project that it should simply cease, it should not take a stage boundary review to work this out!
This rather unhelpful diagram (click to expand it) shows the basic position reviewers finds themselves in: the orange oblong is the project, with the vertical lines marking the stages. The current review is right there in the middle – some way through, but still a way off the project’s end.
So how can you tell how well you are doing? There are basically four questions about the project itself you want answers to:
- Did the last stage go as planned?
- Is your project making satisfactory progress as a whole?
- Will your project deliver as expected?
- Based on the above, what exactly do you need to do about the next stage?
So that is exactly which the next four diagrams explain. Firstly, looking back on the most recent stage, how did it go?
For example, was product quality as required, specified and planned? Were milestones and deliverables as expected? Was the stakeholders’ involvement as agreed, and even if it was, was it enough? When coming up with a stage boundary review checklist, you could do a lot worse than start from these basics.
Next, looking back right to the project start, how has it gone so far?
In particular, what have the trends been? How has the project’s profile evolved over time – stage by stage, how have its basic features such as scope, delivery, cost, quality and risk unfolded? Are there recognisable trends? If so, what were they, what do they mean and what do you plan doing about them?
The next question involves a complete about-face, and requires you to stop looking back and start looking forward. And the basic question is now, What are your project’s prospects? Looking to the end of the project, are there any unexpected obstacles? Risks? Threats? Opportunities? If there are, again, what do you plan to do about them?
Finally – at least as far as the project itself is concerned - now that you know how you are doing and what the longer-term picture looks like, are you ready to start the next stage? For example, are the following all well defined and has provision been made for the all to be managed? Your plans and estimates? All outstanding issues and risks? Your project’s dependencies? The right team + resources? The right technology, facilities and environments? The right stakeholder awareness, commitment and involvement? If not, now is the time to do something about it.
But of course, projects do not exist in isolation. Unless you are operating in your own private universe, the project must also be evaluated from the point of view of the organisation on whose behalf it is being run. So there are four more questions that need to be answered before you can call your stage boundary review complete:
- Does the project still fit the portfolio?
- Is the project’s business performance acceptable?
- Does the project comply with all relevant policies and standards?
- Is all project information and decisions under formal control?
Conversely, exactly how well is the project doing from the organisation’s point of view? Hence the next question, which is to evaluate the project against its business case. Costs? Benefits? Risks? Without answers to questions like these, it is hard to see how the project continues to be justified.
There is also a more practical side to a project’s ‘fit’, which is illustrated in the final two pictures. The essential question posed by the following diagram is this: Does the project comply with all relevant policies and standards? These might take many forms – regulatory requirements, quality standards, corporate policies, business roadmaps – anything that defines the broader shape into which the project must fit to be considered a success.
Finally, the project is part of the wider organisation from an operational point of view too. It needs to fit in in the sense that it is being tracked and recorded and measured and analysed and all those other things middle management do. This naturally raises a range of essentially administrative questions about whether the project is up-to-date regarding things like records, reports, escalations, change control, lessons learned, and so on. If not, perhaps now is the moment to do something about it.
Once you have this basic logic, the next issue is to identify specific questions (and perhaps measures) you would use to work out the answer. You will probably end up with a hundred or so. Usually people react to this number with horror – surely it will take days to review a project against more than 100 criteria? But in practice this is not a problem. After all, the stage is presumably only ending because the project manager believes that the project has met all that stage’s requirements (or if not, has obtained the necessary exemptions and waivers and re-baselined the project accordingly). That means that deliveries are complete, records and reports up to date, change requests all dealt with, all residual issues and risks under control, and so on. If that is the case – which is a logical entry condition for a stage boundary review – then the answer to every single one of your hundred questions is going to be simple and straightforward. The entire review should take literally seconds per question, and minutes for the review as a whole. Well, that may be a little optimistic, but if the review does take a lot longer than that, it should not be because there were so many questions to answer.
It is quite simple in concept. However, there are also certain things you do not want your boundary reviews to deal with. Unfortunately quite a few review systems I have worked with fell into these mistakes. Perhaps the most common is repeating tasks that should already have been put to bed – checking that the right people signed of the last stage’s deliverables, even reviewing them again, and so on. This mistake is usually indicated by the kinds of question the review checklist contains – about the content of documents, not the state of the project.
That in turn brings up a further important point: that the purpose of the review is to check the viability of the project as a whole. It is crucial that the review process is designed to perform this task and this task only. Everything else should have been completed as an entry condition for the review itself. If it isn’t already done, most people won’t be interested or qualified to participate. After all, stage boundary reviews are governance events, and the way they work – and do not work – should reflect this fact.
Another typical error is to attempt to score the results. Although not a mistake in principle, it usually doesn't work. Recently I worked with a client whose reviews include scoring each item, and the review has to reach a pre-defined target if it is to pass. I don’t really understand this.
Firstly, it is the Project Board’s job to make that call – not some artificial calculation. Secondly, most such systems are not in fact measuring anything. In some cases, the scores are completely subjective. That is, reviews are asked to give the item a score. But by and large they do this without any objective guidelines as to how to score and in full knowledge what the ‘pass’ score is! So if they want the review to pass and they know that the pass score is, say, 3 out of 5, they give the item – at least 3! Not only are scores of this kind quite meaningless but by using numbers an illusion of objectivity is created.
In other cases, the scores stand in no real relationship to any quantified metric of success or failure. So even if you really can tell that this item is worth only 3 out of 5, there is little or no link between the criteria and the overall success of the project. So the number, interesting though it may be, is completely unconnected with the purpose of the review!
Finally, problems that arise during a stage boundary review should not usually derail or even delay the project. Again many companies take the view that ‘failing’ a review should stop the project until everything is fixed. In the first company I ever worked in that used SBRs, the whole of the previous stage had to be repeated! This is bonkers, of course.
The right approach, I think, is to treat the review as a whole as an key moment of consolidation for the project as a whole, but to treat the problems it raises as individual risks. It is possible that the outcome of the review will be the project’s cancellation or a fundamental re-structuring, but this should be rare. More usually, most work should continue as planned while the review is taking place, and only things connected with the specific issues raised by the review should be delayed as a result of the review. If there is something so fundamentally wrong with the project that it should simply cease, it should not take a stage boundary review to work this out!
Friday, 20 June 2008
Yes, but what are processes for?
Just this morning I was talking to a colleague about scaling methodology, and how often organisations seem to lump quite diverse projects and tasks together as small/medium/large (or something like that), and force everything into what is often a quite inappropriate (not to say brainless) approach. So we end up insisting that some major document is produced or some sign-off given that is wholly irrelevant or out of proportion to the problem the work is designed to solve or the real problems it might face. But we do it anyway, apparently for want of any clearer idea of what we should be doing.
My suggestion was simple in concept, although I suspect that most organisations would have difficulty making it real. It is based on the principle that methods, processes, standards and procedures exist for just one reason – to control a risk. We don’t have standards and procedures for things that can be assumed any way. For example, shortly after the fall of the Soviet system, I was working on a group of projects for the EU (the old EC Phare programme) in Poland. While I was there I discovered that the electricity was so erratic that I would have been ill-advised to plug in my laptop, and that in most factories there was no loo paper because it was a precious commodity that was usually nicked as soon as it was put it. So my personal ‘being a consultant in Poland’ procedure included ‘leave your laptop in the hotel’ (where the current was more reliable) and ‘put some toilet paper in your briefcase’. But of course these weren’t risks here in the UK. So they are not in my ‘methodology’ here.
And so it should be for any methodology or process: if it is not controlling a risk, take it out. Likewise, if you don’t know what risk you are controlling, find out what it is and adapt the process accordingly. And in the case of the question from which we started this morning, you will only be able to make your methods truly adaptable to need if you can map the products and processes it contains to specific risks.
For example, I was recently involved in a simple project that required a standard rate table to be updated from time to time. The table fed the public website, so its potential impact was enormous, and in many organisations this alone would be enough to trigger the full-blown development lifecycle. Yet the risk was extremely tightly focused, and there as a single simple and quite fool-proof method of mitigating it – conduct a proper acceptance test before any change is allowed to go live. There was no merit in insisting on business or functional analysis, on a detailed design or a formal build process, and technical testing was completely trivial.
So triggering the full lifecycle would be stupid. Yet for many organisations it is the only option. No wonder so many developers and managers are so irritated by processes and methodologies!
The solution is simple. Most organisations have some kind of work classification tool or procedure for deciding how the standard processes should be applied. Many are based on pointlessly trivial issues, like the sheer size of the work involved, but even where there is a proper evaluation of the risks involved (e.g., novelty, organisational complexity, regulatory impact, and so on), there is no direct link to the specific products, procedures, verification methods, approvals and other things the work will have to include.
I have already given one simple example of what this might mean that most organisations could implement today. But our processes are seldom so little defined by the risks they control that it would take a considerable effort to unbundle all the different components ended to control specific threats. In other cases a single item effectively controls multiple risks and vice versa. Yet I am quite sure that a great deal of flexibility could be built into our methods, tools and standards that would make work much more risk-driven – and so much more intelligent and intelligible – than it is now.
My suggestion was simple in concept, although I suspect that most organisations would have difficulty making it real. It is based on the principle that methods, processes, standards and procedures exist for just one reason – to control a risk. We don’t have standards and procedures for things that can be assumed any way. For example, shortly after the fall of the Soviet system, I was working on a group of projects for the EU (the old EC Phare programme) in Poland. While I was there I discovered that the electricity was so erratic that I would have been ill-advised to plug in my laptop, and that in most factories there was no loo paper because it was a precious commodity that was usually nicked as soon as it was put it. So my personal ‘being a consultant in Poland’ procedure included ‘leave your laptop in the hotel’ (where the current was more reliable) and ‘put some toilet paper in your briefcase’. But of course these weren’t risks here in the UK. So they are not in my ‘methodology’ here.
And so it should be for any methodology or process: if it is not controlling a risk, take it out. Likewise, if you don’t know what risk you are controlling, find out what it is and adapt the process accordingly. And in the case of the question from which we started this morning, you will only be able to make your methods truly adaptable to need if you can map the products and processes it contains to specific risks.
For example, I was recently involved in a simple project that required a standard rate table to be updated from time to time. The table fed the public website, so its potential impact was enormous, and in many organisations this alone would be enough to trigger the full-blown development lifecycle. Yet the risk was extremely tightly focused, and there as a single simple and quite fool-proof method of mitigating it – conduct a proper acceptance test before any change is allowed to go live. There was no merit in insisting on business or functional analysis, on a detailed design or a formal build process, and technical testing was completely trivial.
So triggering the full lifecycle would be stupid. Yet for many organisations it is the only option. No wonder so many developers and managers are so irritated by processes and methodologies!
The solution is simple. Most organisations have some kind of work classification tool or procedure for deciding how the standard processes should be applied. Many are based on pointlessly trivial issues, like the sheer size of the work involved, but even where there is a proper evaluation of the risks involved (e.g., novelty, organisational complexity, regulatory impact, and so on), there is no direct link to the specific products, procedures, verification methods, approvals and other things the work will have to include.
I have already given one simple example of what this might mean that most organisations could implement today. But our processes are seldom so little defined by the risks they control that it would take a considerable effort to unbundle all the different components ended to control specific threats. In other cases a single item effectively controls multiple risks and vice versa. Yet I am quite sure that a great deal of flexibility could be built into our methods, tools and standards that would make work much more risk-driven – and so much more intelligent and intelligible – than it is now.
Wednesday, 21 May 2008
Taking quality back from the bureaucrats
I have spent a good deal of my career around quality management. Be it pure ISO 9000- and TQM-style quality management, more tangential activities such as methodology and process architecture or innovation and research management, I think I have done pretty much everything in this field.
One persistent theme in all this experience – and in most organisations this seems to be as true today as it has ever been - is the tendency of quality to degenerate into bureaucracy. For serious professionals quality should be the sexiest thing on earth, but in fact most people find that quality management is a tiresome chore of jumping hurdles, filling in forms, being subjected to irksome and apparently pointless audits, and being admonished to do better by tiers of senior management who plainly haven’t a clue about what your working environment is really like.
Hence the collapse into bureaucracy. If I can’t/won’t join up all the dots, then some of them will have to remain mysteries and I can only get you to do what I want by simply ordering you to do it. It doesn’t have to be a direct order – I can just create a system of bureaucratic controls and reports and you will do as you re told anyway.
Well, that’s the theory. But as every real manager knows, it just doesn’t work like that. In fact, if I wanted to design a system for stifling commitment, creativity, and passion, that’s how I’d do it – replace a real understanding of quality with a bureaucracy.
So how to take back quality from the bureaucrats? Not easy. Perhaps, ultimately, not possible. But here are three steps that should take you some way towards that goal.
Step One – Define quality as excellence
If you want passion, commitment and creativity, then your quality management system absolutely must nurture professional, managerial and operational excellence. If you want to create a culture in which everyone wants to do their job and then some - the basis of every truly triumphant organisation – then there is no alternative.
But is this not already the norm? Although there are many preliminary definitions of quality (e.g., as compliance with specification, as fitness for purpose, as customer satisfaction, and so on) surely everyone in quality management would probably like to define quality as ultimately about excellence?
True so far as it goes, but as so often, it’s not far enough. The problem is that these definitions tend to stay on the rhetorical level. In the absence of a genuine culture of quality, it is extremely difficult to move quality on any further. So what is needed to make that move? What is needed is a practical definition of what excellence is. I would suggest the following key elements that, if accepted, provide a basis for practical change. In a sense this is quite simple and already very familiar.
For example:
One persistent theme in all this experience – and in most organisations this seems to be as true today as it has ever been - is the tendency of quality to degenerate into bureaucracy. For serious professionals quality should be the sexiest thing on earth, but in fact most people find that quality management is a tiresome chore of jumping hurdles, filling in forms, being subjected to irksome and apparently pointless audits, and being admonished to do better by tiers of senior management who plainly haven’t a clue about what your working environment is really like.
Hence the collapse into bureaucracy. If I can’t/won’t join up all the dots, then some of them will have to remain mysteries and I can only get you to do what I want by simply ordering you to do it. It doesn’t have to be a direct order – I can just create a system of bureaucratic controls and reports and you will do as you re told anyway.
Well, that’s the theory. But as every real manager knows, it just doesn’t work like that. In fact, if I wanted to design a system for stifling commitment, creativity, and passion, that’s how I’d do it – replace a real understanding of quality with a bureaucracy.
So how to take back quality from the bureaucrats? Not easy. Perhaps, ultimately, not possible. But here are three steps that should take you some way towards that goal.
Step One – Define quality as excellence
If you want passion, commitment and creativity, then your quality management system absolutely must nurture professional, managerial and operational excellence. If you want to create a culture in which everyone wants to do their job and then some - the basis of every truly triumphant organisation – then there is no alternative.
But is this not already the norm? Although there are many preliminary definitions of quality (e.g., as compliance with specification, as fitness for purpose, as customer satisfaction, and so on) surely everyone in quality management would probably like to define quality as ultimately about excellence?
True so far as it goes, but as so often, it’s not far enough. The problem is that these definitions tend to stay on the rhetorical level. In the absence of a genuine culture of quality, it is extremely difficult to move quality on any further. So what is needed to make that move? What is needed is a practical definition of what excellence is. I would suggest the following key elements that, if accepted, provide a basis for practical change. In a sense this is quite simple and already very familiar.
For example:
- Excellence must be the explicit, overriding goal. Not conformity or standards or even customer satisfaction.
- Your organisation can only excel as a whole. Privileging supposedly ‘key’ functions is self-defeating.
- Excellence can only be known through practical results. These results must be defined in terms of achievements, not activity.
- Excellence must be driven. Leadership should be the goal at every level – corporate, functional, individual. To achieve this, innovation must be actively pursued and external research, benchmarks and resources vigorously exploited.
- Excellence is suffocated by ignorance, distraction, trivia and noise. Excellent people need excellent leadership, processes, systems, skills, tools, information, and support.
- Excellence is founded on a personal desire to excel, not a bureaucratic procedure. Translating a corporate plan for excellence into a personal desire for demand recognition and reward, for contribution to every level.
All quite familiar, really. But how many of these are embedded in management systems that facilitate accomplishment, development and leadership? In my experience, very few. And they are almost invariably confounded by the presence of countervailing forces, such as the standard ‘Not in this financial year’. ‘Not in my backyard’ and ‘Not invented here’ syndromes. There is seldom any investment in standing back and looking at the organisation as a whole or in looking to what other have achieved, and little reward for creating change.
Step Two – Mapping your management system onto your definition of excellence
Hence step two – creating the management system that will actually communicate, support and track this translation of corporate goals into local objectives. Here are some basic elements of such a system:
- Quality is defined and measured by intrinsic values – delivery, satisfaction, ROI, etc., not formally correct ‘quality metrics’.
- Quality management is recognised as a key investment, not just an overhead or cost.
- Quality is a cultural value. Not only does everyone routinely ask ‘How can we do this better?’ but there are regularly meetings and improvement systems for making sure that they really do get better.
- Your management systems are intrinsically adaptable – and regularly adapted. That is to say, they are rigorous but not rigid, and driven by explicit objectives that are traceable to real corporate goals.
- The Quality System itself is driven exclusively by identifiable risks, not by formal models or methodologies. If you can’t say what risk your management system is responding to when it makes me follow some formal routine, then what is the point in my doing so?
The management system is owned by its users and stakeholders, and no one else. The ultimate test of this is that your management systems are valued by its users, not imposed from without.
Again, not exactly startling. At least, I hope not, after a couple of decades of consultants like me ranting on about this sort of thing.
But again, how much of this is real in your organisation? Have you ever looked? Have your ever gone about your organisation, in disguise like a medieval prince, to see what life is really like for the teeming masses? You don’t believe your own subordinates’ and HR department’s protestations that all is well, do you? You don’t read Dilbert? Ye gods…
Step Three – Make it happen
Finally, some basic mechanics of a management system that will deliver all this. There are endless things that could be done, but I always feel that these are the most directly useful.
- Insist on black-box management – it's the ideal way to combine empowerment with responsibility. But make sure that you define all four 'outside' sides of a black box - the expected output, the standard inputs, the underlying infrastructure and information sources and the overarching context information that tells your team what they are contributing to - but also the 'inside' side - the basic standards, frameworks and tools for doing the job. Otherwise you will end up with everyone making it up as they go along.
- Promote your best to managing the management system itself. Respected individuals with vision and imagination who really get things done.
- Make a stint in some form of quality management a precondition of promotion. You might be astonished how must there is to learn from a simple exercise like conducting a quality audit or building processes.
- Build systems that explicitly connect your strategic goals and tactical activities together. And make sure that they work both ways - top-down and bottom-up.
Tuesday, 20 May 2008
What we can still learn from Mao's Little Red Book
I am old enough to remember Mao’s Little Red Book. It was a collection of advice, analysis and sayings, and if you were a leftie in the Sixties there was no chance you hadn’t at least got a copy on your bookshelves. (No need to actually read it.)
I remember quite a few of the spectacularly unconvincing sloganeers that demonstrated more the chasm that separates Chinese from English ideas about language than anything specific about Maoism. My favourite was ‘Peoples of the world unite and defeat the US aggressors and all their running dogs’. I so wish I had said that.
So what has all this to do with management? At about the same time there was a story in the British media that seems to have been published primarily to ridicule Maoist revolutionism. It was about a lathe operator in a factory somewhere in China who had said that once he had read the Thoughts of Chairman Mao his lathe had turned three times as fast.
Of course everyone in the West laughed. What a fool. What a typical piece of irrational propaganda.
A little later another journalist found the man and took the trouble to ask him what he had meant. His answer was illuminating. Before he read the Little Red Book, he replied, he has simply come to work each day and followed orders. He had known all along that there were things wrong with his lathe that could easily be fixed but he did not think it was his job to do anything about t it. Just obey orders. But once he had read the Great Helmsman’s book he realised that it up to him to do something about it. So he did, and lo and behold, his lathe worked a lot better.
Not really very astonishing, of course. Yet I spend my life surrounded by staff and managers – often quite senior managers – many of whom would rather die than challenge the way things are done. And no wonder – after all what would happen if really they took the initiative and did something on their own authority?
Perhaps I can answer that slightly rhetorical question by my own recent experience. I recently attended a long offsite management meeting led by my immediate boss. He’s a good guy – I like him, and he once told me that he had chosen to work in this company precisely because he was tired of bullying corporate cultures.
So far so good. But in the course of this same meeting we happened to talk about whether the company's managers are empowered. Of course they are empowered, he insisted. I have told them they are. Of course they aren’t, I replied (over and over again – it was perhaps not the most constructive of discussions) – not until both the means and the authority are explicitly put into their hands. Which they had not been.
We came to a bit of an impasse, and started to talk about another subject. As he spoke my boss gave a little dig to one his other team members about a project that had overspent without his permission, and how the project manager had had a dressing down as a result. The amount the project manager had overspent was a small fraction of the total project costs, but this allegedly empowered project manager was in trouble. Most absurdly of all, my boss made it quite clear that, had the manager in question simply asked for permission to do what he did before he did it, he would have been authorised to do it anyway!
Apparently empowerment meant empowered to do things that work, but not things that don’t. Bearing in mind that empowerment is of significance only when you need to make a serious decision, this puts the project manager in an impossible position – damned if you do, and damned if you don’t.
I think I would rather have been Mao’s lathe operator.
I remember quite a few of the spectacularly unconvincing sloganeers that demonstrated more the chasm that separates Chinese from English ideas about language than anything specific about Maoism. My favourite was ‘Peoples of the world unite and defeat the US aggressors and all their running dogs’. I so wish I had said that.
So what has all this to do with management? At about the same time there was a story in the British media that seems to have been published primarily to ridicule Maoist revolutionism. It was about a lathe operator in a factory somewhere in China who had said that once he had read the Thoughts of Chairman Mao his lathe had turned three times as fast.
Of course everyone in the West laughed. What a fool. What a typical piece of irrational propaganda.
A little later another journalist found the man and took the trouble to ask him what he had meant. His answer was illuminating. Before he read the Little Red Book, he replied, he has simply come to work each day and followed orders. He had known all along that there were things wrong with his lathe that could easily be fixed but he did not think it was his job to do anything about t it. Just obey orders. But once he had read the Great Helmsman’s book he realised that it up to him to do something about it. So he did, and lo and behold, his lathe worked a lot better.
Not really very astonishing, of course. Yet I spend my life surrounded by staff and managers – often quite senior managers – many of whom would rather die than challenge the way things are done. And no wonder – after all what would happen if really they took the initiative and did something on their own authority?
Perhaps I can answer that slightly rhetorical question by my own recent experience. I recently attended a long offsite management meeting led by my immediate boss. He’s a good guy – I like him, and he once told me that he had chosen to work in this company precisely because he was tired of bullying corporate cultures.
So far so good. But in the course of this same meeting we happened to talk about whether the company's managers are empowered. Of course they are empowered, he insisted. I have told them they are. Of course they aren’t, I replied (over and over again – it was perhaps not the most constructive of discussions) – not until both the means and the authority are explicitly put into their hands. Which they had not been.
We came to a bit of an impasse, and started to talk about another subject. As he spoke my boss gave a little dig to one his other team members about a project that had overspent without his permission, and how the project manager had had a dressing down as a result. The amount the project manager had overspent was a small fraction of the total project costs, but this allegedly empowered project manager was in trouble. Most absurdly of all, my boss made it quite clear that, had the manager in question simply asked for permission to do what he did before he did it, he would have been authorised to do it anyway!
Apparently empowerment meant empowered to do things that work, but not things that don’t. Bearing in mind that empowerment is of significance only when you need to make a serious decision, this puts the project manager in an impossible position – damned if you do, and damned if you don’t.
I think I would rather have been Mao’s lathe operator.
Wednesday, 14 May 2008
Principle 1: Quality vs Risk
A basic conflict that arises again and again is that between quality and risk. It does not often show up in quite that form, though. Often it takes the form of a manager wanting to ignore some kind of established practice – a procedure, a standard, or whatever – in favour of anything from a well thought-through alternative to the gung-ho ‘Just Do It!’ sloganeering that has served Nike’s marketing department very well but is otherwise all but designed to cause you to screw up royally.
And I have lost count of the number of manager’s who heroically declared that they were willing to ‘take the risk’ of proceeding without the right review, with half a dozen fatal flaws outstanding, and so on. As if it were they that was taking the risk at all! Surely it is their employer who is taking the risk – after all it’s not likely that the manager will have to cough up for the mistakes they make.
But there is an important principle here. There is a real issue that, because most of us work in environments we don’t really understand, there is a marked tendency for work to drift to one of two extremes. Either rules are followed slavishly or they are simply disregarded. The latter is especially common where there are no mechanisms for actually tracking and enforcing compliance with the rules – which seems to be the norm for most organisations, outside truly hallowed ground such as filling in timesheets. In both cases –and in most of the intermediate cases, such as simply pretending to comply – is a huge amount of squandered effort. It serves no one, and we all hate and despise it.
So what is the underlying principle that allows us to extricate ourselves from this dilemma? It is simply to acknowledge that quality (and with it all those tiresome policies, rules, standards and procedures) exist solely for the sake of risk management. If a standard exists it is because it cannot be assumed that achieving that standard will happen as a matter of course. Conversely, if I can demonstrate that the risk a management control is designed to control either does not exist in my case or is better managed by other means, exactly why should I comply? If the keepers of your rules – the quality department, the accountants, and so on – cannot tell you the answer, then they aren’t doing their job.
An example may explain this better. Some years ago I was involved in a handful of EU quality management projects in Poland. This was just after the fall of the Soviet Union so the place was in a pretty bad state – so much so that I was warned that the local electricity supply was so flaky that it would damage my laptop. At the same time I was warned to take my own loo roll, because toilet paper was such a precious commodity that it was invariably stolen from offices. Neither of these are issues I would expect to have to deal with in a project in western Europe, North American or on most of the Pacific rim. But if I was to assure the ‘quality’ of my work to Poland in the early 90s, then the rule was simple – no laptop but lots of loo roll.
On the other hand, by the time I had (regretfully) stopped working in Poland, neither was a problem any more. So this particular quality management procedure was now obsolete. But in how many companies, I wonder, would it have continued to be enforced for years afterwards?
So, a question. Can you actually say you know what risk each of your management controls is designed to control? Do you really know? And if an exemption is asked for, is the answer ‘Certainly – if you can explain how your proposed alternative will manage this risk better than the standard approach’?
If the answer to any of these questions is No, then you don’t have a management system. You have a bureaucracy, in the worst sense of the word.
And how many of them have long since ceased to solve any significant problem? Many years ago I worked for a major global consultancy. Part of my job was to manage the engagement reviews conducted by partners on one another. After building the basic administrative database, I started to look at the checklist the reviews were expected to complete. They had lots of strong points, but also quite a few of major defects.
And I have lost count of the number of manager’s who heroically declared that they were willing to ‘take the risk’ of proceeding without the right review, with half a dozen fatal flaws outstanding, and so on. As if it were they that was taking the risk at all! Surely it is their employer who is taking the risk – after all it’s not likely that the manager will have to cough up for the mistakes they make.
But there is an important principle here. There is a real issue that, because most of us work in environments we don’t really understand, there is a marked tendency for work to drift to one of two extremes. Either rules are followed slavishly or they are simply disregarded. The latter is especially common where there are no mechanisms for actually tracking and enforcing compliance with the rules – which seems to be the norm for most organisations, outside truly hallowed ground such as filling in timesheets. In both cases –and in most of the intermediate cases, such as simply pretending to comply – is a huge amount of squandered effort. It serves no one, and we all hate and despise it.
So what is the underlying principle that allows us to extricate ourselves from this dilemma? It is simply to acknowledge that quality (and with it all those tiresome policies, rules, standards and procedures) exist solely for the sake of risk management. If a standard exists it is because it cannot be assumed that achieving that standard will happen as a matter of course. Conversely, if I can demonstrate that the risk a management control is designed to control either does not exist in my case or is better managed by other means, exactly why should I comply? If the keepers of your rules – the quality department, the accountants, and so on – cannot tell you the answer, then they aren’t doing their job.
An example may explain this better. Some years ago I was involved in a handful of EU quality management projects in Poland. This was just after the fall of the Soviet Union so the place was in a pretty bad state – so much so that I was warned that the local electricity supply was so flaky that it would damage my laptop. At the same time I was warned to take my own loo roll, because toilet paper was such a precious commodity that it was invariably stolen from offices. Neither of these are issues I would expect to have to deal with in a project in western Europe, North American or on most of the Pacific rim. But if I was to assure the ‘quality’ of my work to Poland in the early 90s, then the rule was simple – no laptop but lots of loo roll.
On the other hand, by the time I had (regretfully) stopped working in Poland, neither was a problem any more. So this particular quality management procedure was now obsolete. But in how many companies, I wonder, would it have continued to be enforced for years afterwards?
So, a question. Can you actually say you know what risk each of your management controls is designed to control? Do you really know? And if an exemption is asked for, is the answer ‘Certainly – if you can explain how your proposed alternative will manage this risk better than the standard approach’?
If the answer to any of these questions is No, then you don’t have a management system. You have a bureaucracy, in the worst sense of the word.
And how many of them have long since ceased to solve any significant problem? Many years ago I worked for a major global consultancy. Part of my job was to manage the engagement reviews conducted by partners on one another. After building the basic administrative database, I started to look at the checklist the reviews were expected to complete. They had lots of strong points, but also quite a few of major defects.
- One was that there were four different checklists, even though they did not seem to serve different purposes. But no one ever complained.
- A second was that many of the question were simply repeated – in one case the same question was asked three times. But again, no one ever complained.
- Finally, it soon became clear that the answer to quite a few of the questions was always Yes. The checklists were worded in such a way that the ‘right’ answer was always Yes, so what this told me was that we were constantly harking on about things that simply weren’t problems.
So I revised them very thoroughly. In fact I got 7 pages of questionnaire down to 1½ pages and one diagram. And no one complained about that either. Because the result was perfect? No, because they didn’t know what the new version was for either – they just did as they were told. And this was, as I say, a vast global consultancy whose principal service is being more clever than other people. But not as clever as all that, it would seem.
Subscribe to:
Posts (Atom)
Posts
