Wednesday 19 October 2011

Continuous Tinkering is not Continuous Improvement

If you take the time to read any of the standards, frameworks, models or manifestos associated with organisational maturity such as CMMI, Lean Software Development, ISO 9000, or Agile it won’t take you long to find a reference to Continuous Improvement. This is the “Holy Grail” of process improvement and the quest for organizational excellence and maturity, where the business finally reaches a state where it is stable enough to make small, effective and seamless  improvements on an almost daily basis.

I’ve worked in and with lots of organisations who believe they have continuous improvement embedded in their operations. Many of them have been appraised at CMMI Level 3, many of them are ISO 9000 certified, and lots of them have improvement programmes and projects in place which testify to the fact that continuous improvement is standard practice.

But dig below the surface and it doesn’t take long to realise that, in the majority of these organisations, continuous improvement is an illusion. Despite continuous improvement processes and on-going improvement programmes, what really happens is continuous tinkering.



There is a world of difference between continuous improvement and continuous tinkering. The most important is that to establish the bedrock for continuous improvement requires an awful lot of hard work and an inherent desire at all levels of the organisation to make it happen. All the appraisals and certifications in the world won’t help if that desire and commitment is missing at any point in the organisational structure.

Continuous tinkering, on the other hand, is really easy. Lots of managers do it every day. Lots of executives do it on a regular basis. Far too many process improvement and quality “experts” spend all their time doing it. Politicians devote their lives to it. Given the self fulfilling adage that the only constant is change, tinkering is a natural behaviour of many people in many organisations. Tinkering allows people to be seen to be doing something “useful” and to help establish themselves in their working environments. Following organisational restructuring or management succession for whatever reason, there is inevitably a spate of tinkering as new department heads and their new appointees strive to make their mark.

Most people would agree that tinkering is probably not a very good idea. This is confirmed by my dictionary[1] definition “do random, unplanned work or activities” and accentuated by an earlier definition from 1658 “to keep busy in a useless way”. This of course begs the question that if you think (or even know) it is a bad thing to engage in why do you do it?

But let’s first establish a shared understanding of why tinkering is a bad thing especially in an organisational context. (These are just a few reasons which spring to mind that I’ve had direct experience of. I’m sure you have plenty more of your own!)

  1. It rarely adds genuine value to anyone although it may add perceived value to the perpetrator
  2. It is generally disruptive and has a knock on effect of curtailing normal operations
  3. Changes are rarely managed properly and lack an articulated and shared vision, inadequate impact or cost analysis and no defined measures of success
  4. Tinkering rarely offers sustainable change as the next person will engage in their own tinkering activities to undo the current change
  5. It is usually top-down and staff rarely have any say or buy-in in the implementation
  6. Good practices may be lost in the change
  7. Effective teams are often split up in needless organisational tinkering
  8. Tinkering to address the “not invented here” syndrome is unlikely to be cost effective or gain much support from staff
  9. It really annoys staff

Now let’s think about continuous improvement when it is done properly:

  1. Changes are considered before being implemented, in other words they are scoped, planned, discussed, and staff have the chance to buy-in
  2. Continuous improvement is usually initiated bottom-up by the people closest to the problem being addressed
  3. Impacts in terms of cost, effort, time and expected behaviours are considered
  4. Impacts on existing processes, practices and organisational elements are considered
  5. Impacts on other parts of the organisation are considered, changes are holistic rather than sub-optimal
  6. Changes that do not add value to multiple stakeholders would not normally be undertaken
  7. Changes are managed and measures put in place to understand the success of the change (not targets and arbitrary metrics)
  8. Staff embrace the changes as being of value

It is quite clear from these basic differences that a different mindset is required to undertake continuous improvement as opposed to continuous tinkering. In the 25+ years I’ve been working I’ve only occasionally been exposed to an environment that is committed to genuine continuous improvement. Those very rare occasions share one thing in common –leaders who understand the difference between tinkering and improving. Sadly, those few environments have only been transitory and an organisational restructure or two later they have been consigned to memories of what could have been if that understanding had gone higher up the executive chain.

Sadly, our much of our legacy seems built around the fact that the only constant is worthless change, and change for the sake of change rather than for the sake of the pursuit of excellence.





[1] Wordbook XL for iPad


Sunday 4 September 2011

The Sleepwalkers Have Taken Over the Asylum

There's an English Bookshop on the main shopping street in the centre of Zurich. It's quintessentially English and apart from books you can purchase such goodies as Marmite and Coleman's English Mustard. I always wander in to browse whenever I'm in town with a few minutes to spare even though the prices here are astronomical so I have to demonstrate a huge amount of self-constraint. There isn't a great selection of "business" books, but there's usually something that catches my eye. Yesterday was no exception, and I was drawn to a title called "The Art of Non-Conformity" by Chris Guillebeau. Having spent most of the past 49 years being "different" you may ask why I need a book on the subject, but I did purchase it, along with a baby jar of Bovril for gravy making, and started reading it on the tram home.

The first chapter is entitled "Sleepwalkers and the Living World" and it got me thinking about some of the organisations that I've worked in, and how so many of them appear to have been organised by Sleepwalkers and are now managed along the same lines. In truth, some of them may even have employed the Living Dead rather than Sleepwalkers.

How many organisations have you been involved with that pride themselves of values like "People are our most valuable asset", "Employer of Choice", "People are our key differentiator against our competition", and of course "We Cherish and Promote Diversity"? Behind the self serving glossy brochure mission statement and value statements, most of these companies treat their people like idiots, stifle genuine efforts of bottom up improvements, and most importantly still deploy basic command and control organisational structures which lead to vast amounts of work being performed which adds no value to any of the real stakeholders, namely the customers and the staff performing the work.
Multiple governance structures, which are rarely joined up, create industrial strength status reporting and a plethora of obstacles which need to be overcome before real work can be performed. Chicken and egg scenarios are common place;  body A needs a form to be completed which needs body B to approve it but only when it is accompanied by another document which can't be approved until body A has approved the first form. You get the picture. And despite projects being reviewed to death by all and sundry, major issues are still rarely picked up until it's too late and corrective action is required because the preventative action was not taken in the first place. Status boards never take responsibility for their failure to spot the problem, it's always the project team that takes the flack.

But why the reference to the Sleepwalkers I hear you asking? The common factor in all these organisations is that they follow perceived wisdom, like Sleepwalkers, without thinking or questioning the logic or consequences of their actions. It's always been done this way, therefore it must be right. Well, the evidence doesn't really support that in my opinion. Projects still fail, budgets still overrun, products still have fatal flaws, and people who do the real work are still at the bottom of the food chain.

Far too many managers do Sleepwalk their way through their lives. It's time that organisations stood back a little way and started to look at the lumbering monstrosities of bureaucracy they have created. It's time that people in charge started to look at being non-conformist, and being genuinely different. History has given us precedents. Toyota, Apple, Amazon, Google and Facebook changed the rulebook in many ways, although some of them may have used questionable alternatives, and some may be losing their way a little. Agile methods (when used according to the original principles) have shown that traditional project management techniques are not the only way. Lean (again when used properly) has shown how much non-productive work really goes on in the workplace, and Systems Thinking has shown us how flawed many of the internal processes companies traditionally use really are.

So here are a few ideas on how to be a bit more non-conforming in your organisation.
  • Dump the multitude of status reports and status reviews up the organisational hierarchy and get project teams to review each other. The people who do the work are much better placed to really see what's going on then a group of managers five levels up the line. Real project managers (not the people who call themselves project managers but are really line managers or team leads) have much more objective and subjective understanding of what's going on in a project. Of course, to do this you need to rethink much of the reliance on traditional project management KPIs and target setting, but that's probably a good thing as well.
  • Lose the process owners who haven't used "their" processes in real life for the last 20 years, and put ownership back into the collectives that do use them.
  • Question the role of line management which often doesn't understand what their reports actually do in the system, and which interferes in project because they happen to work at a particular level of hierarchical seniority.
  • Question the role of HR and a recruiting process that prefers inexperienced graduates over street wise project managers, engineers and internal consultants with proven track records of delivering.
  • Challenge the wisdom of hiring outrageously expensive external consultants (I'm cheap by the way!) who deliver little value, which is unsustainable after they leave, especially when some of that expertise may already be in-house, but you haven't been bothered to look for it
  • Think carefully about your next reorganisation and how it will affect the people who do the work. If you are going to disrupt your workforce, which are, after all, your most valuable asset, do it in such a way that they get the benefit not just the pain.
In any event, before you make any changes in your organisation, perhaps you could actually consult the workforce before the event, and get them involved throughout the change, maybe they could even lead it. Because there's a pretty good chance that they are only people in your organisation who are still awake!

Sunday 8 May 2011

Dodgy Decision Making In the Wake of a “Successful” SCAMPI A Appraisal

So your organization now has a huge deck of PowerPoint slides produced by the SCAMP A Appraisal team, and somewhere towards the back there’s one particular slide that tells you your rating (you hope!). It’s probably taken you a long time to get to this point, maybe even years, and the relief from those intimately involved in the whole exercise is palpable. Your SEPG can relax and everyone can look forward to the party. Congratulations – you’ve earned it!

But for those of you either in Leadership positions or who have influence over the Process Improvement strategy within your organization, just hold on a moment longer. Because right now you are probably about to make a bunch of decisions, either consciously or subconsciously which could seriously jeopardize all your efforts so far.

In this article we’ll look at some of the worst decisions you could take, why they are not good decisions, what their impact might be, both short term and long term, and what perhaps you should be thinking about doing instead. Not all organizations are going to find themselves in this situation, but there are some characteristics which are common to those that might. These are:

  1. Reaching a specified maturity level was the primary organizational objective
  2. Leadership and managers only paid lip service to the “Improvement Programme”
  3. The initiative was called “The CMMI Programme”
  4. Resources (people and budget) for improvement were only planned up until the end of the appraisal
  5. Main output from the programme was the creation of dozens of artefacts, primarily templates
  6. Management of change at the organizational level is not really understood or practiced

If you find yourself thinking that one or more of these attributes applies to your situations, then read on…

Dodgy Decision #1 – Disband the programme team and reallocate resources

It’s highly likely that you created some kind of team to manage and direct the CMMI initiative – most likely a small core project team supported by an SEPG of subject matter experts. Their brief was to “get CMMI Level ‘n’ by such and such a date” and their plan and budget was aligned to that end date. After that the team was to be reallocated to proper work (e.g. revenue generating) and the overhead budget reduced back to a bare minimum.

There are two problems with this decision and both are associated with the misconception that you have genuinely succeeded in your mission. The first problem is that, in the course of the appraisal and as part of the final findings, the appraisal team will have documented a number of improvement opportunities. In the spirit of the improvement process, it is incumbent on the organisation to address these findings and to take the appropriate remedial actions. This may be more difficult than it seems, sometimes because of the wording of the final findings (which is deliberately obfuscated to maintain the non-attributable nature of the findings), but often because the longer it takes to draw up the action plan the harder it is to remember what the real issue was in the first place.

The second problem is that, realistically, you have probably only done enough work to achieve your desired maturity level in an appraisal environment. The real effort is still to come as the outputs from the improvement become part of the organisational DNA and its culture. Organisations simply do not change their behaviour overnight on the basis of a successful appraisal.

To overcome these issues, the people most likely to succeed are those who have been closest to the action – namely the improvement team members and the SEPG. They are the people who have the best understanding of what the defined issues are, and what actions need to be taken. If you disband the team, not only will this experience be lost but there is a very good chance that perceived problems will take the place of genuine improvement activities. As soon as you start focusing on perceived issues you lose your focus and start wasting time, effort and money on problems that may not really exist.

The improvement team will have learnt a great deal about process and change management during the course of the improvement programme, and it would be foolish to fail to take advantage of this. Not only may future initiatives benefit from the knowledge, but there is still much work to be done and those skills are going to be critical in the next few months.

The recommendation is to keep the team together for as long as possible after the appraisal. The team can take on new objectives and responsibilities, and the allocation of the SEPG may be reduced, but in general, if the team has worked well and achieved its goals, then it makes sense to allow them to continue their good work. At the same time, you are demonstrating an on-going commitment to continuous improvement, which was surely the reason for getting involved with CMMI in the first place!

Dodgy Decision #2 – Relax the rules – take your foot off the pedals

Now you’ve been recognised as a CMMI Level ‘n’ organisation (and you’ve reallocated your team and budget) you can afford to focus on other things, safe in the knowledge that you successfully negotiated the appraisal and that your organisation has made the step change required. Wrong!

As suggested in our first dodgy decision, there is still a lot of work to be done. At the very least there are action plans to be drawn up and implemented in order to address the findings from the appraisal. More likely though, your effort has been concentrated on a small number of projects which were directly impacted by the appraisal – those focus and non-focus projects that were in scope and whose team members took part in appraisal interviews and provided input into the appraisal document review.

Much of the organisation will have fallen under the radar in terms of appraisal, and it is important to bring all those other projects into line. More importantly, projects are probably still only “doing CMMI” because they are filling in the templates you created as part of the improvement programme. The underlying principles are probably still a mystery to most projects and project staff, and an outsider walking through the development barns would regularly hear comments about how much extra work projects have to do because of CMMI.

Trying to get projects and staff in the mindset of organisational change takes much more than an appraisal or a group of compliance auditors beating deviants with big sticks. If you’ve taken a bottom up approach to “implement CMMI” by focusing on templates and CMMI specific practices, rather than a value add approach which promotes good practice through shared understanding of the principles involved, you still have a lot of work to do to win people’s hearts and minds (in some cases so much damage has already been done that this will never happen).

If you haven’t really done so, now is a really good time to start learning about organisational change management, not to mention brushing up on your people (and other soft) skills. The key to successful process improvement and change is to understand that people execute the processes that you have in place, and they will be happy to follow (and use) worthwhile processes and documents. They will not forgive you for burdening their lives with worthless overhead and nit-picking compliance officers who have never used the processes they are enforcing on your people.

Quality is not about compliance, and process improvement will not succeed if you ram it down people’s throats.


Dodgy Decision #3 – Focus all management attention on a new major initiative

Remember how exciting CMMI was when you first started – your Executives couldn’t talk about anything else, even though most of them didn’t even know what CMMI stood for (either as an abbreviation or as a set of principles for process improvement). But after those first few months their enthusiasm started to wane as there was no obvious tangible benefit from all their improvement dollars. And until that all important slide went up on the screen, CMMI had become nothing more than a bottomless pit – a black hole absorbing vast amounts of time, effort and cash.

Now you’ve successfully achieved your goal, the executives are looking for the next silver bullet – Agile and Lean perhaps, and so the cycle begins again.

As we’ve already seen there is still a lot of work to be done with your existing initiative. But equally important is the need for the organisation to catch its breath. People can only absorb a certain amount of change in a given period, and there should be a bedding down of the previous set of changes before starting a new round of major change. Without this break, it may not be possible to understand where change has been successful (or not). Changes arising from the new initiative may negate the benefits about to be realised from the previous round of changes.

I’ve heard lots of organisations talk about “relentless change”. Just take a moment to think about the use of language here. Relentless only has negative connotations (synonyms include grim, inexorable, and unforgiving). Is this really the burden that you want to place on your staff? Continuous improvement works best with small steps, and certainly does not imply big initiative after big initiative.

By all means, start thinking at the next round of changes, but be smart about it. Look at ways to synergise the previous initiative and the new one. Do the feasibility analysis, start making plans, learn the lessons from the previous change. But just hang fire on a big bang approach, and find small rapid improvement opportunities which start to make a difference immediately. The organisation will be in a much better position to adapt to small incremental changes than big capital investment changes. The chances are that your bottom line will end up being a lot healthier as well.

Dodgy Decision #4 – Adopt a new process set or management system

As part of your CMMI programme you built a new management system closely aligned to the CMMI Process Areas with a wealth of templates and other artefacts to help your projects become CMMI compliant. As part of the institutionalisation process all projects were mandated to use the new system, and many overtime hours have been spent by project teams meeting that mandate. Now, as part of your next major initiative (and in order to become lean and agile!), you plan to use a system that has been successfully used in another part of the organisation.

What is going on in your head here? You just spent a sack full of money building something that you now want to decommission before the ink is dry on the reams of templates and other paperwork you created. Which bit of “continuous improvement” didn’t you really understand? And of course you do appreciate that if you replace your existing management system you pretty much invalidate the results of any appraisal you’ve just been through.

And what message exactly are you sending to your staff? “Well, we built this system to get us through the CMMI appraisal, but we knew it was crap and that we’d have to do it right in the future”. “So, it’s fine for you guys to develop crap software for now, and we’ll give you a chance to get it right later on – if we still have a business…”

If you find, for whatever reason, that your process set is not fit for purpose then stop the improvement programme right now. Put any thoughts of having an appraisal on hold. Take a step back, look at your approach and strategy for improvement and start re-planning. Replacing a management system on the back of a successful appraisal will generate an enormous amount of resentment amongst the people who have to use it that you will lose their support for any future quality initiative.

If it really is too late, then you have to be smart about the approach you take. Don’t announce and implement a new system. Take an incremental approach, and slowly replace elements of the old system, as part of your continuous improvement programme. Prioritise on areas where genuine value will be realised as early as possible. And learn the biggest lesson of all when it comes to management systems – that simple and small is best! It was probably an over-engineered system that got you into this mess in the first place. Get the people who have to use the system to help design in with the support of the process engineers, not the other way around.

So there you have it - four dodgy decisions that you could take if you weren't thinking clearly. I have seen plenty of organisations doing one or more of these things, and ultimately they all ended up reversing the decision(s). However, the delay cost them all in terms of cost, effort and more importantly in their credibility and their ability to introduce further changes and improvements.




Thursday 3 February 2011

The Madness of Starting Point Schedules

Even the most passionate supporter of the CMM and CMMI families of process improvement frameworks can't help but admit that they have caused organisations and individuals to do some pretty stupid things in the desire to achieve a Maturity Level. I also find it interesting how things I once thought of as super cool, now really annoy me, partly because I never really thought through the implications myself, and partly because as I've become more experienced I understand better about how and why these things should never have seen the light of day. One of these things that has been in my mind a lot recently is the project management starting point schedule.

Let's just clarify what I mean by a "starting point schedule". I use the term to refer to an MS-Project template which has a set of predefined entries on a Gannt Chart. It will usually have standardised headers and footers which conform to the organisational standard, and may have some standardised calendars and rates set up in the resources sections.

Why is there a need for such a template? In my experience, quite often, the most significant part of an organisation's initial approach to process improvement is a frenzied effort to create a library of standardised document templates. It's as if they simply think in terms of CMMI as being document oriented (not unreasonable for a novice SEPG who have "achieve CMMI Level 2 by the end of next year" as a goal, and who have learnt that a SCAMPI A appraisal will require the production of thousands of project documents as evidence). If you are going to create templates for all your other project management documents, it kind of makes sense to create a template for a project schedule also. Regardless of the rights and wrongs of this approach, I'm just going to focus on my starting point schedule in this post.

So having acknowledged that you are going to create a starting point schedule template for the sake of completeness, the next discussion is usually around the matter of what activities you put in it. And this is often where the first signs of madness manifest themselves. Because it's usually the SEPG who create these templates, they focus on all the process activities, and the initial schedule consists of all the process steps in the quality management system associated with projects. And to make matters worse, the schedule is actually organised by process area. It's as if they are saying to the appraisal team: "look, all the process activities are in the project schedule, therefore it's obvious that they are planned and managed".

The end result of this activity is that our starting point schedule consists of between 100 and 200 activities, not one of which is actually of any value to a project manager who is only interested in delivering product rather than performing process.

But the next bit of madness manifests itself when the Enterprise PMO gets hold of the template. They have to put their imprint on it, and now a set of arbitrary milestones are embedded into the starting point schedule. These enable the PMO to keep an enterprise level view of all projects and programmes so they can see when milestones are missed and can enforce corrective action (!)

Next the accountants and invoicing team get their hands on the template and insist on their work breakdown structures being embedded so that the project activities and the project accounting and billing systems align without anyone in the billing department having to do any work.

By now you have a starting point schedule (which senior management have mandated to be used on all projects) with 500 entries on a Gannt Chart of which not one is actually related to doing any real work in respect to a project delivering a product or outcome.

The starting point schedule is no longer a tool that the project manager can use to track the progress of their project. It has become a noose by which to hang the PM when non-project specific activities are missed out or delayed.

And people wonder why PMs go off and use their own schedules and tools to actually manage what they are paid to do.

The project schedule is a PM tool - it's not an accountancy, billing or invoicing tool. It isn't a workforce management tool, and it most certainly is not a process compliance tool. I agree there are some overlaps, but use the right tools for the right job, especially if you want the job done right.

And a reminder to SEPGs who create the templates - if you want to do it right, you should create the work breakdown structure template first. Let's see you trying to put 200 process activities on a work breakdown structure using MS Organisation Chart! Now, if you must create your starting point, keep it simple! An over complex starting point schedule will actually lull a PM into a false sense of security because they fail to focus on project specifics amongst all the detritus now living in the schedule.

One final argument I often hear for the all encompassing starting point schedule is that it helps non project managers who are running projects understand what they need to do. Actually, I think you'll find that reading a book on project management might be slightly more effective, or maybe a training course? Or, perish the thought - get project managers to run your projects!


.

Wednesday 2 February 2011

A Trip Back to the "Bottom of the Ladder"

I've worked as a "management" consultant, either internally or externally, for the best part of 20 years now, and I've often heard people say that all consultants should occasionally step down from their ivory towers, and go back to their roots. It's not very often that I've heard of any consultants taking their own advice, unless it's a career move, but recently I did just that, although not through choice or design. I've spent the last six months working back at the coal face as a project quality manager. Now I can let you into a secret: it was not a fun experience! It was interesting, challenging, frustrating, and at times just damn hard work, but fun is not an adjective that readily springs to mind when talking about the engagement.

So why on earth would I want to write about it? That's easy; I now fully understand why every consultant should do the same thing and that's what I really want to share with you.

Before I go any further however I want to make an important statement. The organisation I was working for showed me nothing but respect and I would gladly work for them again in a different role. The people I worked with on a day to day basis were professional, open to new ideas and accommodated my slightly maverick and off-the-wall approach and this included both managers and project staff. The organisation itself is a very large, world renowned, and highly respected financial institution, and it won’t do me any harm whatsoever in having it listed on my CV. It has its headquarters in continental Europe where English is not the first language (but where it is the accepted business language), and as a financial institution it is part of a highly regulated and somewhat conservative industry, especially when it comes to quality. Of course, as a large organization with a distinct culture built up over many years, change can be difficult to manage, and therein lies the heart of my discontent during my tenure there.

I’m used to leading change in organisations, either directly as a programme manager or in an advisory and consultancy capacity. I like working with the “big picture”, although I’m happy to work amongst the weeds to better understand what’s really going on and I have no problem understanding and working with the little details. In the project quality management role, I experienced first hand the deficiencies of an industrial level process improvement programme and set of quality policies which I have fought so hard to change in the past. As an external contractor, on the lowest rung of the quality ladder, my day to day existence was spent adhering to internally imposed quality standards and practices which, for the most part added little or no value and which I was unable to push back against. More frustratingly, my views were clearly shared by many of those around me including my managers who were also manacled by these policies created by an apparently intransigent central process and quality team which was deaf to genuinely useful feedback and refuted that they have any obligation to change their own behaviours. It is one of the worst cases of ivory tower syndrome I have ever encountered, made even worse by dint of their being geographically removed from the hub of the delivery operation.

The quality culture, as applied to process improvement, was partially diluted and confused by the decision to outsource a large tranche of the process improvement activity to an external consultancy from India. Although senior managers were home grown, the volume of external consultants overwhelmed the internal staff, and they effectively imposed their own process improvement culture on the organisation. Now I'm all in favour of bringing in external consultants to assist in developing process management capability; otherwise I'd be permanently unemployed. However, I don't agree in outsourcing, en masse, something which has to be developed organically.

During my incumbency the organisation underwent the scrutiny of a CMMI Level 3 SCAMPI A appraisal and two of the projects I was working on were in scope as non-focus projects. This gave me an even better understanding of how and why some things were as they were, but still did not excuse the basic errors that were being made in terms of overall process and quality management. It was as if this was the first process improvement programme in history, and there was no history to learn from. However, I won't dwell on that just now.

Regular readers of these posts will be able to recognise how frustrated I was by the end of six months, and why I just wanted to get out and come home. But it was important to come home with something other than negative thoughts, so I spent some time reflecting about my own behaviour in the past, and what lessons I could learn to apply to future engagements. This is my list, and it is specific to quality and process management consultants

You are a Change Agent First

You are first and foremost an agent of change and if you don't understand the basics of change management, stakeholder management and relationship management go and find another job. Changing they way people do things needs their cooperation and collaboration. You need to listen to them and engage in dialog with them.

Command and Control Doesn't Work

Old fashioned command and control management doesn't work for quality and process management. People need to understand why they are expected to do certain things (which may appear to be completely worthless) and if your only explanation is "because we tell you to" they will find ways around it and everyone could suffer as a result. If you only make recommendations that add value it will help, but you still need to win hearts and minds.

Be Prepared to Admit You Are Wrong

I've often used the phrase "I'm not always right, but I'm never wrong", but only in jest (I hope). Sometimes you will come up against people who may be wiser or smarter than you, and you need to acknowledge that and let them correct you. Don't just sit there and rely on your authority; listen to what is being said and make the appropriate changes and acknowledgements.

Look Out for Learning Opportunities

Only the very arrogant think they can get by without improving themselves and learning from others. Sadly, I've met a lot of very arrogant consultants and managers. Sadly, too many younger consultants have no actual work experience other than as consultants and they are unable to accept that those who have done things (or are still doing them) have any value or anything to offer.

Don't Impose Your Standards on Others

Just because you have a tried and tested way of doing things doesn't mean it's always going to work. And that is true with individuals, teams and organisations. You cannot and must not try to impose your culture and values on others. Instead, work with them, and let them choose what is appropriate for them.

If It Isn't Working, It's Probably Wrong

When you've put a plan or a system or a mechanism or a programme in place and you aren't seeing the desired or expected results one of two things may have happened. You didn't know what to expect so you can't recognise it when it happens, or more likely, you've done something wrong and it needs changing. This is a bit of an extension to my third point but on a larger scale. It's no good persisting with something in the hope that it will improve. Learn from what's happened, change what needs to be changed, and move on. If necessary consider whether it is time for you personally to move on permanently...


I hope these six values are already engrained in my own ethos as a consultant and as a person. I'm sure I've been guilty of not following all of them in the past, and this experience has made me acutely aware of potential pitfalls in my chosen area of expertise. All experiences are learning opportunities, and this was a timely reminder of what to think about next time I set foot in someone else's organisation and before I start to tell them what they need to do!

As for you, dear reader...take a six month break from consulting, and go back and do some proper work for a change. You might just find it changes your outlook on life! And besides, why should I be the only one to suffer?!

.