Tuesday 17 September 2013

7 Deadly Sins of Process Improvement/Change - #5 Carelessness


At number five on my list of deadly sins we have Carelessness, where a person or group fails to give enough attention to avoiding errors and mistakes. I deliberately chose to include carelessness in addition to ineptitude because I’d argue that people with good knowledge and understanding who have done their planning and preparation can still be careless and make clumsy and costly errors as a result. Carelessness is often a result of complacency. For me, carelessness is probably the number one sin for the quality professional.



We are all too aware of the consequences of our carelessness in everyday life. Forest fires, train crashes and motorway pileups are some of the consequences of careless actions. In cyberspace, harm caused through careless attention to phishing and social engineering attacks is becoming all too familiar.

The consequences of carelessness in process improvement endeavours may not be life threatening but they are very real to the business and will almost certainly have financial implications.

Manifestations

Failing to Perform Due Diligence

If you don't do your homework you can expect to get bitten on the posterior. It may not happen immediately (although it's usually better if it does!), but it will happen. And in a worst case scenario, it will destroy your business. Which is not only careless but downright stupid.

One of the largest IT contracts ever awarded failed to perform adequate due diligence and the organisation that won the bid was out on it's numbers by several orders of magnitude, underestimating the extent of what was required by 10s of years of effort and billions of dollars.

Join the Dots

I never cease to be amazed by the careless mistakes organisations make in their change initiatives. A classic that springs to mind is a business that moved it's HR, Time Management and Financials from SAP to Oracle. This particular business employed a large number of contractors which amounted to a significant expense. On D-Day (no transition, no parallel deployment - just a big bang implementation) somebody realised that contractors hadn't been included in the databases, ony permanent employees. It took months before the business managed to work out its real financial position.

In the same way that you need to perform due diligence to understand the true extent of your potential commitment, you also need to check that you have covered all bases in your change plans. Change will affect more than your immediate organisation - IT departments need to work with other groups like HR, Finance and Procurement for example. Build stakeholder maps that encompass the wider world and establish who will be affected and to what extent. Change will not succeed in a vacuum.

Consistency and Accuracy

As a management system grows there is more opportunity for carelessness to creep in, primarily on the part of the process engineers. Vocabulary, terminology and style need to be consistent across the whole of the system, particularly where processes and templates cross reference each other. Create a glossary of terms which is maintained and acts as the single resource for terminology across the management system. Build a set of process management templates, so that all processes and documents are developed using the same rules.

Regardless of how rigorous your review process, there will be mistakes that creep into your management system. Ensure that a change control process is in place that can address minor changes as quickly as possible, and that a certain amount of time is allocated to on-going maintenance fixes regardless of any development lifecycle that you have in place. In a major release, little things fall down to the bottom of the requirements list and consequently never get fixed. Fix them as soon as they surface.

Configuration Management

The configuration management tools available to software developers have become very sophisticated in the last decade, but it is still quite rare to see them being used for process engineering (or any project documentation for that matter), even though the principles are exactly the same. A management system must be placed under configuration control, and its guardians should be subject to the same processes and policies as software development and maintenance teams.

Laws to Overcome Carelessness

1st Law - Set up a rigorous peer review process for every deliverable within the management system with a real focus on detail, correctness and consistency

2nd Law - Use the same robust configuration management and content management processes and tools as your practitioners are expected to use

3rd Law - Think before you ink. Consider the way your messages will be interpreted by your many audiences

4th Law - Stakeholder Analysis and Management is a fundamental activity in change. Don't pay it short shrift.




Friday 6 September 2013

7 Deadly Sins of Process Improvement/Change - #4 Impatience




Whilst sin number two in my list is Inertia, sin number four is almost the opposite; Impatience, the state of restless eagerness. Typically this is a management problem but it can also stem from within a change team, or individuals caught up in the excitement of a change, or even in desperation for a change to the existing status quo. I have seen many change programmes wound down or cancelled because of management impatience for results, and many others fail because of impatience in change teams and sponsors, leading to insufficient preparation and planning and ploughing ahead with invalid assumptions, requirements and solutions.

Manifestations

Failing to Meet Expectations

Failure to meet expectations have been implicated in project termination since projects began and business change initiatives seem to be more susceptible than most. There are two main problems with expectations. The first is the issue of unrealistic expectations which is generally an executive induced problem. The second is more about invisible results which is down to the change team.

In fact both issues are everyone’s problem so there’s an example of how apportioning blame is fairly useless in resolving the problem. What is really required is a collaborative approach to set realistic expectations in the first place, and then deliver incrementally against those expectations to demonstrate that progress is being made.

If that smacks of an agile approach, I make no apologies - although I would rather keep to the more traditional terminology and call it an "incremental approach".  Critical to this approach is the need for executives to ask the right questions during progress reviews and not allow themselves to be fobbed off with what the change team wants to tell them. When initiative leaders start to believe their own hype in an attempt to make things look better than they are, the whole improvement cycle goes into a tailspin and there will be fatalities! It's really important not to rely on common project measures like schedule and cost performance indicators, especially during the implementation or roll-out phases of an improvement programme. Mindsets won't change according to an arbitrary project schedule!

Return On Investment

Return on investment in process improvement doesn’t happen overnight, and may not be demonstrable for months or even years. The fact is that changing, documenting or even publishing processes doesn’t achieve process improvement. People achieve process improvement, and that requires behaviour change which, as any parent knows, can be a pretty drawn out affair.

In the worst case I've seen, a six months into a major SPI initiative, a senior executive gave a centralised process improvement group in the US five weeks to demonstrate significant improvement against the bottom line otherwise they would be disbanded, and there would be no further central process improvement initiatives undertaken. What the executive failed to recognise was that the main reason the improvements weren't meeting his expectations was because his colleagues were not supporting them. He was delegating full responsibility and accountabilty to the change team but without providing them with the executive sponsorship required to enable the initiatives to succeed.

Acting on Perception

Impatience for results can often lead to a situation where the wrong areas of the organisation become the subject for unnecessary change, resulting in critical things being left unchanged, and perfectly good processes being modified to fix and incorrect perception.

Laws to Overcome Impatience

1st Law - Work with your stakeholders to set and agree realistic expectations

2nd Law - Keep stakeholders informed about tangible progress by using measures they can understand

3rd Law - Break down big initiatives into smaller projects with clear deliverables

4th Law - Develop process measures that can demonstrate improvement

5th Law - Improving the business is everyone's responsibility not just that of the change team

5th Law - Fix what actually matters not what you think matters




Thursday 29 August 2013

7 Deadly Sins of Process Improvement/Change - #3 Ineptitude


People make mistakes. Apparently it’s what makes us human, although it most certainly isn’t a purely human trait, as mistakes take place in the animal world every time a predator catches its prey. What I mean by ineptitude in this context is either actively making clumsy, silly, avoidable mistakes, or forcing others to do so through your actions. There’s quite a close tie-in to our opening sin of arrogance, because often these kind of inept mistakes are brought about through arrogance. The key examples of ineptitude that we shall focus on are concerned with “wrongness”, where taking a bit of time and effort, doing some research and taking advice from others could eliminate these kinds of clumsy errors and the costs associated with them.

Manifestations

Wrong People 

Many of us will have faced the situation where an individual is put in charge of a project, an initiative or even a department without any of the pre-requisite skills or understanding needed to ensure a successful outcome. Sometimes we get lucky, and the individual will learn from or at least listen to more experienced or adept members of the team, adapt their behaviour and everyone will benefit. All too often however, the individual will simply try to hide their failings and stamp their authority on the project with scant regard for the rest of the team.

The appointment of the wrong people is both a management and a team member problem. Often managers appoint high flyers who have succeeded in different positions, or more likely, simply appoint an available senior manager. A common failing in process improvement initiatives is to appoint a technical project manager who does not appreciate the more people oriented aspects of business and organisational change.

Similarly, recognised subject matter experts may be appointed to lead initiatives associated with their expertise. Sometimes these experts do not have the management or leadership skills required. Unfortunately, some experts do not the communications skills required to successfully get their messages across. Change leaders need to have a number of key qualities. They must have good management, leadership and organisational skills, excellent communication skills and possibly most importantly, they need to have the respect of their peers, sub-ordinates and executives.

As a manager you need to take the time to appoint the right person. If an individual doesn't believe they have the necessary skills and qualities required to perform a certain role then don't punish them for pushing back. Groom them and help them gain the skills they need for future endeavours. And managers should never agree to take on more than they can handle - everyone will suffer.

Perception vs Reality

One of the most common manifestations of ineptitude is where an organisation focuses on its perception of what is wrong, rather than making an effort to elicit the real problems. Expensive and time consuming initiatives are set up to correct a problem that may not really be there.

An example that I've seen on many occasions is where executives faced with a sequence of failed projects declare that there is an overarching problem with project management. Typical corrective actions include redesigning project management job families, retraining project managers, insisting on PM certifications or even embarking on a CMMI initiative.

In almost every situation the real root cause of the project failure has been anything but poor project management. Usually, if it wasn't for the heroic efforts of project managers (who should never be put in the position of having to be heroes or heroines) the situation would be far worse.

Poor executive oversight and governance, bad contracts and poor stakeholder management were almost always at the heart of the problems, and many failed projects should never have been sanctioned in the first place.

Addressing perceived problems rather than real problems is like chasing rainbows. When the perception is external rather than internal the appropriate course of action is to address the external perception rather than to blindly assume that external people really know what the cause is and fix something that isn't broken.

Process vs People

For some reason many process improvement initiatives seem to focus on the creation of vast amounts of documentation. Massive amounts of time and energy are spent updating project documentation, creating new process descriptions, writing new policies and procedures and building unmaintainable web based repositories. Even when, often, many of these already exist and in many cases are utterly fit for purpose (or at least were until they ceased to be useful because they weren't maintained).

Far more care and attention is devoted to the process than the people who have to do the work. Blind compliance takes precedent over common sense and archaic review mechanisms reward those who follow the leader rather than those who seek to change a faulty system.

The best processes and documentation sets in the world will not help if the people who are expected to use them are not motivated or treated with respect. (I realise this is only scratching the surface of this crucial issue, and a subject that merits its own post in the future)

Laws to Overcome Ineptitude

1st Law - Think about the types and skills of people you need to manage and lead the change and make the appropriate appointments

2nd Law - Listen to front line staff who understand the real issues the best before embarking on wasteful improvement initiatives

3rd Law - People matter more than processes and documentation

4th Law - Don't be afraid to say 'no', and don't punish people when they do


Tuesday 30 July 2013

Trials and Tribulations of an External Process Management Consultant


I've spent the last five years outsourcing my process and change management skills and experience. Most aspects of being freelance suit me perfectly well, and I doubt that I'd ever go back to being permanent staff. I used to say that if the perfect job came up I'd consider it - but I've had several perfect jobs as both a permie and as a contractor, and they've generally turned out to be anything but perfect.

There are some real downsides to trying to practice my specific skills as a temporary employee and interestingly these problems seem to reflect the state of process management in the IT industry in general and may help to explain why it has such a bad track record in terms of generating prolonged and sustainable benefits.

The contracting consultant's standing in a command and control environment is even more unstable than for an internal consultant. Organisations bring in externals for a range of different reasons - missing skills in-house, alternative perspectives, proven track records of success - but often appear intimidated when the consultant starts to perform. No matter how sensitive one tries to be and how well one tries to soft sell the issues that may need to be considered - and no matter what anecdotal evidence one can supply - very often the response is along the lines that "we are different, we aren't making the same mistakes, so we're going to do it the way we always have. Thanks and goodbye". These are the sorts of business that have graveyards full of failed change initiatives.

Hiring managers with good intentions often take on consultants but fail to be up front with their teams about the reasons and the contractor starts life on the back foot. On several occasions I have arrived in a department with an understanding that I would have overall responsibility for an initiative only to find that internal politics have already ensured that my role has already been taken by an existing (well intentioned but less experienced) manager who felt their position was being undermined. Inevitably in this situation I have found this results in over engineered solutions which fail to get genuine buy-in and eventually the initiative will slowly fizzle out until the next silver bullet comes along.

The most frustrating experience is when there is insufficient leadership to make things happen. Insufficient in this context means either inexperienced or unavailable because of over-commitment. When a team has no direction it will run to the agenda of its strongest members, regardless of whether this is the appropriate strategy, and often, as an external, one is left out of the loop (as are some of the more introspective internal team members). Leaders who make decisions can generally be challenged. Absentee leaders aren't available to be challenged and anarchy will prevail until higher authorities are able to step in and fix the problem - usually by disbanding the team and dispensing with the external's services.

The primary common trait in these three scenarios is a lack of communication and especially an inability to listen. Hiring managers need to really think through why they want to use external consultants and be able to articulate those reasons to their teams in advance. Once you have acquired the skills of the contractor (assuming they are what they claim to be!) it would normally pay to listen to their ideas, heed their warnings and ensure that you get the benefit of what you are paying for.

And it normally makes sense to nurture the relationship with your consultant in the same way you would with permanent staff and other stakeholders. You never know; they may actually help you achieve the success you wanted. They may even do better than that and help you realise success that even you didn't know you could achieve!




Tuesday 16 July 2013

A Short Rant About Rogue CMMI Consultants


If you've been waiting patiently for the next part of my seven deadly sins posts, I do apologize. The post has been written for some time, but the subject matter could have been misconstrued by the folk I was under contract with and I didn't want to get caught up in a needless conflict. That contract is now over so I will post in due course when I feel that the time is right. If I'm brave enough, I might also reflect on some of the issues that have made the past twelve months even more challenging than usual!

In the meantime, a Twitter post caught my eye last week which sent me reeling. Actually, it wasn't so much the post, but the link behind it that caused my kernel panic - which got worse as I read more articles by the same indvidual on his website. Again, to avoid unnecessary unpleasantness, I'm not going to directly reference the person or provide a link to the website in question, because, at the end of the day, that person is entitled to their point of view, just as much as I am.

The post that sparked this off was about "creating a Quality Management System designed for a company going for CMMI Maturity Level 3". (I'm sure regular readers can already see where this is going!)

My first reaction was to respond by asking - "why would you want to do that?" - to which I have never received a response! My second, was to follow the link and read the underlying article and some associated posts. It turned out that the author has a list of CMMI and ISO certifications as long as your arm, and is a specialist CMMI consultant. And every post on the blog was directly or indirectly about getting through a CMMI Appraisal (or ISO certification).



Not once did I read about adding value to the customer or the underlying business. The overall impression was that a 'CMMI Implementation" will lead to success in your software development organisation, regardless of the context of a wider set of business requirements. There was no mention about the principles and concepts underpinning process improvement. A document centric approach was the focus - perhaps unsurprisingly as the company could provide an off-the-shelf QMS to meet any specific CMMI Maturity Level requirement.

Some of us have been around long enough to understand that this kind of attitude and approach is precisely why CMMI (and other models and standards) have such polarized reactions to their usefulness, and why in so many cases, improvement initiatives fail so dismally.

If your focus is on achieving an arbitrary maturity level through appraisal or pinning a certificate or badge on the wall without having clearly defined business objectives, it is highly unlikely that you will manage anything more than a short lived success. You will not achieve much in the way of a return on investment and you will probably unfavourably prejudice future improvement opportunities.

What I find most sad about this whole episode is that a consultant can hide behind their own set of certifications and peddle such nonsense to an unwary, often ill-informed, lemming like audience as an absolute truth. In the past it was easy to lay some of the blame at the hands of the SEI - after all CMMI was their cash cow. It's easy to turn a blind eye to what is going on in the real world when the cheques keep appearing in the bank. Let's hope the CMMI Institute has better values, morals and principles regarding the messages they wish to convey. Certainly some of the people involved in the new venture believe whole heartedly about how and why CMMI can be used as part of a suite of tools and techniques to improve a business, and many have written passionately about its short comings in the past.

Even then I doubt they can exert much control over rogue lead appraisers, or trainers, who have paid their money and done the necessary work to achieve their qualifications, any more than they can exert any control over people like me, who only have years of hard earned experience and a set of notebooks full of horror stories of how it can all go so badly wrong.







Saturday 16 March 2013

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

Monday 11 March 2013

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