7 Deadly Sins of Process Improvement/Change - #2 Inertia

Continuing on the theme of 7 Deadly Sin of Process Improvement and Change, my second deadly sin is Inertia, the tendency to do nothing or to remain unchanged. Inertia may be caused by a number of things including fear, ignorance, lack of confidence, uncertainty but it has the same effects regardless of the cause. At best, inertia will lead to nothing happening at all - a kind of nothing ventured, nothing gained situation. At worst, inertia will cause a groundswell of apathy and complacency which will have a long term effect on making change happen in the future. This is most likely to happen when change initiatives are launched with great hullabaloo from the leadership, promising great things, getting everyone excited and then doing nothing. Typically it’s a behaviour associated with leadership changes who then fail to deliver on their promises or policies, and particularly with politicians after their honeymoon period is over!

Manifestations

• Failure to Sustain Momentum : How often do organisations introduce a new initiative with great fanfare and gusto only for it to almost immediately disappear from view? Hype, without substance, is its own worst enemy, regardless of whether it's a product launch (think about previous versions of Windows, announced long before they are ready to ship), a government policy or a business improvement or change. The problem with hype is that it sets expectations which, unless there is substance to work with, will rarely be met. Rumours and innuendo become rife and now matter how good the initial premise, failure is the most likely outcome. Change management experts often rally their followers with calls to 'Communicate, Communicate, Communicate', and this is fine, as long as the communication is planned in advance and is consistent with the progress of the initiative. The best changes are only formally announced when a considerable amount of background work has been performed, including planning, feasibility studies, pilots, and other activities associated with change management. Once momentum is lost, it is very difficult to rebuild and will inevitably lead to additional costs as you have to go over the same ground again. Along the way, disenfranchised team members will be lost, and the hearts and minds that you won over in the initial excitement will turn against you. Not only will this project fail, but future projects will also be put into jeopardy as your reputation to deliver change is tarnished. It's not enough to whet people's appetites, you must continue to feed them.
• Analysis Paralysis : a common problem in traditional waterfall software projects is the tendency to spend too long performing analysis and then trying to rush design, development and implementation. This leads to poor design, poor quality software and partially untested products hastily implemented and ultimately leading to systems failures. Similar problems occur in change projects and are usually a sign that a change team simply doesn't know where to start. Organisations need to perform some basic change management activities prior to embarking on the actual change to ensure that they are fully prepared. Such activities include establishing whether the organisation is ready for change, whether it can absorb additional change, and even whether the change is right for the business. Again, good up front planning will help with this problem, as will 'agile' techniques such as time-boxing and incremental delivery. 

Laws to Overcome Inertia

1st Law - Plan the Change before you start broadcasting the message

2nd Law - Keep delivering morsels even if you can’t deliver the whole meal

7 Deadly Sins of Process Improvement/Change - #1 Arrogance

Just over three years ago I posted an article on this blog called 7 Deadly Sins of Process Improvement (or Change Management). It recently dawned on me that, although I said I would expand on the 'sins' I mentioned in the original post, I never got around to it, so I'm now trying to make amends for that oversight! 

The first of my deadly sins is arrogance. Arrogance is defined as “having or revealing an exaggerated sense of one's own importance or abilities”, and is most strongly linked with the notion of pride. Just about anyone involved in a change initiative has the potential to exhibit arrogant tendencies, be they the sponsor, managers, change team members or end users, and unless these are recognised, managed and controlled this could easily be the single biggest cause of failure to your improvement initiative.  

Having a sense of our own abilities is clearly a good thing. Quality depends on people who care about their work, their abilities and their place in the organisation. But quality is equally dependent on the humility of the individual, and especially the ability to recognise that someone else may have a better understanding of a specific situation or better knowledge to make a decision.

Arrogance (or pride) manifests itself in many different ways, but in the workplace especially, it is always associated with knowing better than everyone else. Given a traditional tiered hierarchy, an over-arrogant organisation will generate a culture of fear and dread, with the lowest members of the workforce being subjected to bullying and a fairly miserable existence. This is the kind of culture that dominated at Enron, with disastrous consequences.

In a process improvement context there are a multitude of examples of how arrogance puts a programme at risk.

Manifestations

• Ivory Towers : The idea of Ivory Towers derives from the 19th century where it was used to designate an environment where intellectuals engage in activities that are disconnected from the realities of everyday life. A common criticism in process improvement is that the group tasked with implementing improvements becomes an ivory tower. 
• Blind Leading the Blind : In organisations where formal organisational process improvement is a new concept it’s not uncommon to have a situation where all the non-experts get together and muddle through. Someone, often a manager with a loud voice or dominant personality, will be asked to take the lead, regardless of their underlying ability, and they will arrogantly drive the initiative forwards. Even if other individuals show expertise or desire to perform they are discouraged and their ideas go unnoticed and unrecognised. 
• Not Invented Here : Not Invented Here syndrome is relatively common in the software development world. It is the situation where teams or departments refuse to take on board ‘components’ that have been created outside of the team or group. Certain types of programmers are notoriously bad about accepting code that someone else has written and will rewrite everything to suit their own egos. Sadly, the same behaviour is often true in process improvement initiatives. In certain disciplines, there is no need to ever write a process from scratch, even if no documented process exists in an organisation. Peer Review, Risk Management, Configuration Management and Requirements Development processes can easily be found on the internet or in standard reference books on project management or software engineering. These off-the-shelf processes need some tweaking to conform to the language and culture of your organisation but there is no point in reinventing the wheel. But I’ve seen dozens of teams writing their own project processes rather than use the (perfectly adequate) corporate standard, and even more commonplace, creating their own document templates. Sadly I don’t have any data, but I would guess that more money and time has been spent creating unnecessary process documentation than in any other activity associated with process improvement, and that alone is the biggest cause of failure for process improvement initiatives. This in itself causes further failure, because new initiatives will almost always begin by reviewing and rewriting the previous documentation set.
• Ignoring other Initiatives : It isn’t uncommon for an organisation to be running numerous initiatives simultaneously. Large organisations are constantly in a state of flux and there may well be dozens of improvement activities in operation, or at the very least in plan. The trouble is that most of these initiatives are running independently of each other, with different objectives and goals, different sponsors, and different change teams with vastly different levels of skill, ability and competence. To make matters worse, they are almost all competing for the same resources in terms of time and money, and many of the initiatives will be aimed at the same groups of people who are probably already overwhelmed with change and most likely struggling to find enough time in the day to perform their day jobs. I was asked to project manage an infrastructure metrics programme in one organisation of about 4000 people and in the first week we discovered 23 other metrics initiatives had been launched across different levels of the business that no-one knew anything about. That in itself was a shock, but not one of the initiatives had any documented objectives, scope or requirements. The result that management closed them all down with the exception of ours, but by that time it was impossible to discover how much time and money had been wasted. What’s all this got to do with arrogance? Each individual or team that goes off and does their own thing without looking around at what else is going on is guilty of arrogance, because they think they know best.

 Laws to Overcome Arrogant Behaviour

1st Law - If it ain’t broke, don’t fix it

2nd Law - If you don’t know something, ask someone who does

3rd Law - Find out what else is going on and how you can collaborate

4th Law - Locate your experts (including outside resources) and use them

5th Law - Work collaboratively with the people you want to change

6th Law - Read about the subject matter and related disciplines and learn from other people

 

Learn all you can from the mistakes of others.
You won't have time to make them all yourself.

-Alfred Sheinwold

 

Are You a Slave To Your Quality Management System? (Part 2)

In my previous post I proffered up some suggestions as to why many organisational Quality Management Systems end up as Quality Management Shambles. My hypothesis is that too many management systems (quality or otherwise!) are created for the wrong reasons, and generally get created without due care and attention to quality principles, systems principles or architectural and design principles. Over time, without a strong foundation on which to build, the QMS grows chaotically and incongruously, and ceases to be able to serve the people it should have been intended for in the first place. Instead, the organisation becomes a slave to the QMS.

In this second part, I'm going to expand on the five questions I posed in part one, with specific regard to the principles mentioned above - Quality, System, and Architecture/Design.

Question 1 -  What is the purpose of your QMS?


I surmise that if I asked that question in a certified ISO 9000 organisation (or many organisations successfully asssessed at CMMI L2/3) I would get a  different answer for each person that I asked - and certainly different answers from different levels of the business). Typical responses:

• Developers - it's because of this ISO/CMMI initiative
• Middle Management - to ensure compliance
• Senior Management - so that our staff know what they have to do
• Executive Management - so that we can standardise operations and efficiencies across the business

The real reason for a QMS has most likely been forgotten or distorted over time. If you cannot articulate you reasons for having a QMS (think elevator speech here) then it's probably time for a major review. Adherence and compliance to standards may be valid reasons for a QMS but they really must not be the primary drivers. You also need to consider whether your QMS has become a substitute for training. If your induction speech for new starters includes "you need to read the quality manual to understand how we do things round here" you probably need to rethink both your QMS and your training strategy, not to mention your induction techniques!

Question 2 - Who is the intended audience?


Most managers will glibly answer this by saying that the QMS is mandated for all staff, but the truth is that the mandate (and usage) will also certainly be biased towards the lower levels of the organisational hierarchy. In far too many organisations senior managers cannot even tell you where to locate the corporate policies never mind being able to explain them or even abide by them (even though they are responsible for them!).

Ideally a QMS will be architected from multiple viewpoints; a developers needs will differ from someone in HR or Finance, so it makes sense to organise a management system accordingly. That said, it doesn't follow that HR related material should be restricted to HR staff. A good QMS must be transparent across the enterprise.


Question 3 - How do we intend our staff to use it?

This is linked to elements of the preceeding questions. Ideally, the QMS will be a simple to use, easy to navigate, supporting reference for staff. Inexperienced 'users' can see as much detail as necessary, whilst more experienced 'users' can filter out the information so that the material acts as a memory jogger when they need guidance.

Having a good, well maintained QMS does not abrogate the organisation from ensuring that staff are 'trained' in company policy and procedure - and this should be on-going for all staff across the business, especially as changes and modifications are made.

Failure to design and architect a QMS from multiple perspectives will devalue it over time, and once it becomes 'shelfware' (or whatever the cyber equivalent is) it becomes a potential source of many other cultural problems.


Question 4 - Does the QMS reflect the way we actually work and our culture?

In the same way that failing to architect and design a QMS according to our basic principles initially will ultimately devalue it, the QMS should be continuously updated to reflect changes to working practices, regulations, and cultural changes. Most importantly, things that are wrong, inappropriate or outdated must be modified or removed as early as possible. Users do not want to be placed in a situation where they are required to demonstrate compliance to a process, policy or procedure which may be detrimental to their daily work. A mechanism for emergency fixes is critical and a queuing system for change requests is not good enough. A waiver system must be in place to allow teams to bypass incongruous instructions, and this process must be quick and simple. [Note that a waiver is a temporary mechanism and requires appropriate governance to prevent abuse!  - see my blog entry from July 2009 for more about waivers]

As a user of dozens of management systems over the years the things that annoy me most are (in no particular order) - over complexity, difficulty to navigate, response times and missing or inconsistent information. Which brings us onto the final question...


Question 5 - Is the QMS aligned to the system that is our organisation?

For me, this is the fundamental question. If we accept the basic premise that an organisation is a system, then it goes without saying that the QMS should map against that system and should mirror the entities, interactions and flows that exist in the real world of the enterprise. It should reflect the internal corporate culture and use the organisations language and terminology. Most of all, it should reflect what you do, not what you think the auditors or assessors are expecting you to do. When it comes to the QMS too many organisations waste too much time and effort doing the wrong things.

So, there you have some quick answers to my five questions. A good QMS will be an valuable asset to everyone in the organisation. A well designed and architected QMS that aligns to the business systems, objectives and values, and is maintained accordingly will be welcomed by the majority of staff and most importantly it will get used - for the right reasons.

Take back control of your QMS today, and stop being a slave to it!

Are You a Slave To Your Quality Management System? (Part 1)

When I first started working, IT businesses tended to fall into one of two categories - those that had a Quality Management System and those that didn't. Those that did tended to have a library of management standards (literally - there would be rooms stacked full of folders with thousands of pages of policies, processes and procedures) which employees were expected to obey without question. The whole purpose of the Quality Department was to maintain the Quality Management System and to ensure compliance to it. The Quality Management System not only represented thousands of trees, but the amassed knowledge, understanding and wisdom of the organisation over its lifetime.

Over time, these libraries have been (mostly) replaced by equally enormous libraries of on-line documents much to the relief of trees and tree huggers over the planet (but to the chagrin of printers). More and more companies have moved from the "have none" category to the "have" category thanks to the relentless movement towards ISO, CMMI, ITIL and whatever other set of standards, models and frameworks you wish to add.

What most of these companies share is that what they call a Quality Management System is anything but a system. In many cases it's actually a shambles, so for the rest of this piece when you see the acronym QMS it stands for Quality Management Shambles.

So how does something that starts off with a (hopefully) good intention end up in such a mess and what can you do about it?

Many organisations signed up to ISO 9000 because they were required to in order to do business with other organisations, especially government ones. Some did so because they saw that having a Quality Standard behind them help differentiate them from their competitors. Some probably did because a Quality Consultant told them it was a good idea. Whatever the underlying reason, one thing was certain - the first thing they did was to create a QMS in order to meet the requirements of the standard and then mandate that all employees followed the QMS to the letter so that the organisation could get (and subsequently keep) its certification. In many organisations, you can see that the QMS is actually organised according to the original headings of the standard in the same way that many businesses now organise their QMS to align with CMMI Process Areas. Over time, new bits got added to correspond to new departments, regulations, legislation, management proclamations and other influences. In the good places, old bits got updated or achived, and in the very good places improvement programmes were initiated to replace the bits that weren't working and so the ISO quality cycle was fulfilled. And the QMS became more and more shambolic.

By making the QMS meet a relatively arbitary standard (albeit globally recognised) the most crucial questions and drivers were generally ignored, namely:

• What is the real purpose of the Quality Management System?
• Who is the intended audience?
• How do we intend our staff to use it?
• Does it reflect the way we actually work and our culture?
• Is it aligned to the system that is our organisation?

In other words - do we control our Quality Management System or are we slaves to it?

If you don't have answers to these questions, then you should really start to reconsider whether your Quality Management System has any place in your business other than as a stick to beat your staff with, or a tool to demonstrate compliance to a standard that may or not add genuine value to your business.

Next time, I'll look at the critical success factors in designing a [Quality] Management System that is fit for purpose and can be used to enhance the working environment rather than choking it.