ALLYGILL.CO.UK Blog

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

2013-03-16T11:52:00.001Z

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

2013-03-11T11:11:00.001Z

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)

2012-05-16T10:52:00.000+01:00

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)

2012-05-13T11:30:00.001+01:00

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.

Unused Information Holds Many Answers

2012-04-19T11:41:00.001+01:00

Twitter can be a wonderful source of inspiration for a blog entry especially for an old pro like myself, who has encountered so many "coachable moments" that sometimes I forget what I want to share. So, thanks to the Standish Group for the inspiration for this entry with the following Tweet:

"44% of CIOs say it takes on average a day or less for their organization to reach a standard IT project decision"

This caught my eye and I responded by rhetorically asking how they measured that - probably a finger in the air. A few days later Standish came back to me with the response that "it was asked in our monthly DARTS survey of over 300 CIOs [which] had many questions on decision latency, complexity, & costs". It wasn't my intention to question how the Standish Group came about their data - rather how CIOs could actually provide a measured response in the first place?

In 28 years of working in the IT industry I have never seen a project, programme or business area maintain quantitative time related data on their decision making processes (except in my own projects!). If that sort of data is not available at the lowest levels of the organisation, I'm struggling to understand how a CIO can honestly answer the question on behalf of the whole business.

Standish have since tweeted lots more amazing stats based on their survey such as "39% of CIOs say it cost on average $500 or less for their organization to reach a standard IT project decision".

But how CIOs or anyone else responds to these questions isn't really the main point of this post. I'm interested in why teams (read departments/groups/functional areas as well as projects/programmes) don't record such data, and if they do, why they don't use it to better understand the way they operate.

Most projects maintain some kind of RAID log - probably using a standard template which came from the CMMI programme or PMO - and go through the regular motions of entering data and reviewing the outstanding items so they can close them. They probably prioritse each item, and assign a degree of severity. They may even put in open and close dates, but they rarely, if ever, do any analysis on the data, other than to monitor the number of open and closed actions over time (which generally tells you very little at all).

As a process management person I view these logs as an valuable source of input, if you're prepared to put in some effort and ask some awkward questions. Why do some issues take weeks or even months to close? Why should it take 10 days to reach a decision? Why don't open issues get reprioritised after a certain amount of time. Are there connections between the types of issue or decisions that cause the most problems?

These are the types of question that should be getting asked at departmental reviews, stakeholder reviews, and quality reviews but generally get ignored in favour of the familiar questions about timescales and budgets. If you ask different questions at these reviews, establish root causes and fix the problems, issues around budgets and timescales will probably start to fade into the background.

I find it bizarre that organisations spend so much time tracking code defects (rather than getting on with the business of fixing them as they arise) but seem to ignore management defects until they have actually caused operational failures.

While managemement continues to highlight time and money as the only critical yardsticks by which performance is measured, quality will always be an afterthought and the entire organisation will suffer as a result.

Good Customer Service Does Not Include Obfuscation

2012-04-06T10:40:00.002+01:00

This post is a slight departure from my normal entries and I wasn't even sure whether to put it in this blog. However, on reflection, it is quality related, or should I say, lack of quality! And it's about failing quality of both product and service.

I've recently had a couple of issues with my ISP (BT Total Broadband), one relating to the TV service (BT Vision), the second relating to their e-mail service (BT Yahoo Mail). In both cases I have posted comments on Twitter which have been picked up by the @BTCare customer service Tweeter, and have resulted in a series of farcical interactions and no resolution of the issues. But first let's quickly look at the problems.

The BT Vision Problem

BT Vision is BT's service offering set up to 'compete' in the Sky/Virgin TV space. The reality is that it only really offers Freeview TV channels, a limited On Demand service and a PVR Box. You pays your money and you makes your choice. It's adequate for my needs but that isn't the issue here. The issue is with the design of the software which runs on the BT Vision PVR box. As would be expected it is possible to record TV shows and series. And it's this latter task which drives me to despair. You cannot simply record a series on specific day/time/channel - the default setting is to record the "first run and any repeats". And given the number of repeats on UK TV this becomes a real issue. Simple example - I set BT Vision to record "Hairy Bikers' Bakeation" on BBC 2 on Tuesday at 20:00. By default this will also record the same show on BBC2 on Thursday at 19:00. Why anyone would want to do this is quite beyond me. To prevent the duplicate recording I have to edit the series recording settings and change the setting to "First Run Only". This is made quite time consuming because of the bizarre UI, but quite simply it shouldn't be necessary!

@BTCare picked up on my whinge on Twitter and I was asked to submit a problem form via the BT website which I duly did. I received no less than four telephone messages on my answer machine explaining how to change the settings (but not the defaults). This was after I had explained in no uncertain terms that the only solution to my particular problem was to redesign and rewrite the software!

The BT Yahoo Mail Problem

I use Apple Mail on my Mac to access my email from the BT Yahoo Mail service. Most of the time this works perfectly but on occasions the mail servers throw a wobbler and reject the password. This situation can last for minutes to hours and is well documented on the BT Forums (One query has generated 56 pages of related comments). Usually the problem goes away by itself, but it is clearly a bug and appears to happen on other third party mail clients (on Windows also) so is not an Apple Mail specific problem.

The latest "fix" that @BTCare suggested is that I shouldn't have more than one mail client trying to access mail at any one time. In other words, when I'm at home I have to turn off 'push' mail on my iPhone/iPad, and when I go out I have to close Mail on my Mac. Apparently this is also a requirement of Yahoo Mail policy (although no-one seems to be able to find the policy written anywhere).

Once again, I have been invited to submit my issue to BT via their website. On this occasion I've declined as it just leads to a series of useless telephone messages.

The Morals of the Story

There are two conclusions I have come to from these (so far unresolved) issues. The first is that Twitter is far from an ideal medium to manage customer service and customer relations. It may provide a "front" to demonstrate that the business cares about its customers and can be seen to be actively managing issues, but it is nothing more than that.

The second is that deliberate obfuscation of issues can hardly be considered as good practice for dealing with real problems. With both my issues, I have been palmed off with useless responses which show no understanding of the real problem, and exhibit little willingness to even try to really deal with the problems to any degree of customer satisfaction.

Even a basic acknowledgement of my issues and a genuine response (such as "we understand your frustration and have raised a change request for consideration") would help.

BT Customer relations managers and help desk managers could do with reading John Seddon's book "Freedom From Command and Control" and learn the difference between value and failure demand!

Of course, I could show my dissatisfaction by changing my ISP. All I would achieve by doing this would be to swap one set of issues with a different set and cause me a huge amount of inconvenience, time and money - not least of which would be caused by losing my primary email address which I have had for the past ten or more years!

In other words - bite off my nose to spite my face! No thanks, but at the same time - BT: thanks for nothing!

A Tough Nut to Crack

2012-03-29T11:21:00.000+01:00

A week or so ago I found a link to an article entitled "7 Reasons you shouldn't touch systems thinking" on the thinkpurpose blog. The link was posted by Bob Marshall (@flowchainsensei) on Twitter, and I tweeted back to him that I found the item "profoundly disturbing". His response was "Excellent! Care to elaborate?", to which I answered that I couldn't put my reasons into a 140 character tweet and might end up writing my own blog post about it.

The 140 character constraint of Twitter was only a partial reason for not responding to Bob's question. The main problem was that I couldn't actually articulate my reasons properly - I just knew that I was troubled by the post. I've had a bit of time to think about things now so here's my response...

Whilst the article was published under a Systems Thinking moniker I think the first line of the text really sets the context:

"Here's seven things you'll have to put up with if you start getting curious and learning."

It then goes on to list the seven reasons - all of which pretty much lead to the same conclusion. If you do start getting curious and learning there's a very good chance that in many organisations you'll just end up being frustrated, impotent and generally unhappy. But that's the price you'll have to pay for your efforts.

So. Is it worth it? Having spent most of the last twenty years getting curious and learning, I have been thwarted by many managers and colleagues (regardless of what position I've held in the organisation). I've dared to say and try things that aren't part of received wisdom and unsurprisingly have usually met with brick walls and head on collisions. Even when I've had a sympathetic ear, the discussion has often ended with something like "Of course, you're probably right, but that's not how we do things around here". And there's the rub! The system isn't generally geared up to cater to different ways of thinking, and most people don't want to listen to stuff they don't want to understand.

It's not just about Systems Thinking, it's about any paradigm that isn't already compromised by misinterpretation (wilful or otherwise) or distorted for 'political' purposes. This includes the current buzz regarding Lean and Agile in particular.

We (myself and others like me) end up playing games - chipping away at the surface of resistance in the forlorn hope that one day we might make a breakthrough. Make a difference.

And this is really why I found the article so disturbing - because it struck a chord inside me that suggested that all attempts to change the current status quo will ultimately fail, which made me question my whole 'raison d'être' for a few moments.

But what the heck - at the end of the day, human nature is a tough nut to crack. But that doesn't mean you should give up trying.

Lessons Learned about Lessons Learned (Part 2)

2012-03-23T09:55:00.002Z

In my last post I discussed a few of the problems that I've encountered with Lessons Learned reporting (a.k.a Project Post Mortem reviews). In this post I'm going to propose some of things that could be done to add value to a process that is often judged with contempt by project managers and team members, misused or misinterpreted by process improvement teams and managers, and generally misunderstood by the people who could most benefit from it. These ideas are intended to be method independent and can be adopted whether you're using CMMI, Agile, or any other model or lifecycle.

Before I go any further however, I want to pick up on some of the comments made on my previous post, namely the issues of Timeliness (@flowchainsensei) and Trust (@bruhland2000), because these have a significant bearing on any proposal for improvement of this process.

In many organisations the Lessons Learned process only kicks in at the end of the project. There are several issues with this:

the project cannot benefit because it is already finished
project team members cannot properly recall details of things that could be of value in the future, and anyway they are already busy thinking about their next project
funding is no longer available to do the job properly

The other problem about timeliness is that project lessons learned reviews rarely coincide with process update cycles. Valid improvement opportunities (or fixes to incorrect processes) may not be made available to projects for months. Projects who need the fixes and therefore use them before they are "official" face the prospect of being "non-compliant" unless process waivers can be used (another process that is often so bureaucratic and time-consuming that projects would prefer to risk a non-compliancy than jump through hoops to get the appropriate waiver!).

The second issue regarding trust (or lack of it) is common in organisations where there is still a dominant blame culture. Whilst good facilitation of reviews can minimise some of the issues around trust, a more stable and long term way to deal with the issue is to be more explicit about what constitutes a valuable lessons learned review in the first place and focus on the processes, system interactions and organisational quagmires that need to be changed to give projects a better chance of succeeding.

So what are we really trying to achieve in a lessons learned review? Who are the beneficiaries? How can we make the process more robust and of value to the participants? And most importantly, how can we effectively use the information gathered in these (and other reviews) to ensure that the process returns more benefit than it costs, and therefore adds value to the organisation? I'm not going to try and define a one-size fits all process here. What I'd prefer to do is offer up some ideas for consideration that you may be able to build into an existing process set, or to discuss with senior management to bring around a mindset change if that is what is required.

Some of the issues that an organisation needs to addressed (and you need to be honest when you answer these questions) are:

What is the real purpose of the process ? Is it intended to generate genuine improvement or is it in place to comply to some abstract model requirement? If you are not getting any tangible benefit from your lessons learned then you are doing this for compliance purposes and the process needs a major overhaul
Does the lessons learned review do anything to address systemic process or organisational issues in a timely fashion or does it simply generate outputs which are subsequently ignored because there is no real substance to them
Who is empowered to make process changes based on the lessons learned review? Can project teams make local changes to meet their specific issues? If they must wait for official changes to be released there is little incentive in them taking the time to participate in any such review - and the organisation is building a failure mechanism into its operations
Are successes identified by projects deemed to be "best practice" and built into the process set regardless of the specific set of circumstances which may have led to a specific success?
Do you have a repository of lessons learned reports and assets which consists primarily of similar findings and alternative templates and is rarely accessed by any project teams? Any genuine lesson learned should take the form of an actionable item leading to a direct improvement in the process asset library or change to company policy
Does your lessons learned report template contain sections like "what worked well", "what went wrong" and "what could be improved"? Focus the review away from these subjective descriptions and follow through on specifics like "which processes / interactions are causing us trouble and what can we do to resolve the problem?"
Have you considered adding some quantitative elements into to the report? This can be difficult as scoring issues is still very subjective, but if the same people contribute by scoring the same questions at regular intervals in a project you can at least begin to visualise how your improvement efforts are working. However, this shouldn't be used as for cross project comparisons. (I'll post an example of this type of template on my website in the downloads section in the next few days. This template has proven useful in the past and is still being used today)
Do you have any measures in place to assess the value of the process? If you assess the value using compliance audits or counts of reports submitted than you haven't. If you have a count of actionable items generated from lessons learned reviews you are at least on the way
Do process owners (or their equivalent) ever meet with project teams or do they rely on the SEPG representatives? Project managers with process issues should invite process owners to their lessons learned reviews (as non-project stakeholders) to hear the issues first hand (and not to defend their process)
Do you make a distinction between internal project reviews (status meetings) and lessons learned reviews? If projects have regular daily, weekly or monthly review meetings which address the purpose of the lessons learned process why should they be compelled to perform another process review just to tick the box. Don't penalise good practice for the sake of compliance or terminology!

As I wrote in the previous post many lessons learned processes are in place to fulfil a misinterpretation of a requirement, whether it be CMMI or ISO or whatever. The process is often designed to create evidence to demonstrate that the process is been executed, but it fails to address the real objective which is to provide feedback into the management system to try to stop bad history repeating itself. Far more effort is put into creating the outputs and monitoring compliance to the process than in addressing the real needs of the organisation - which is to improve. If the current effort wasted on Lessons Learned processes can be re-channeled into addressing the issues uncovered by the process then the people who are required to use it may start to respect it more because they will actually begin to reap some benefit from it.

As will the whole organisation.

Lessons Learned about Lessons Learned (Part 1)

2012-03-15T11:06:00.002Z

My last post about "Best Practice" was something of a personal peeve rather than a major hurdle to successful business improvement, although lessons should be learnt from the story I told, namely:

your improvement focus shouldn't be about creating templates and completing documents to provide evidence for appraisals and audit
measures that you put in place need to be thought through from the perspective of those being measured if you want to avoid costly and wasteful dysfunctional behaviour
best implies that there is no room for improvement

Ultimately, I also suggested a relatively quick fix; simply stop using the term "best practice" and come up with something more appropriate.

"Lessons Learned" (learnt?) is a different kettle of fish however. Most organisations have some kind of lessons learned mechanism in place (very often associated with their "Best Practice Repository"!) and in my experience very few of these mechanisms add any real value to the organisation. They are put in place to meet the "requirements" of CMMI, etc. and as is so often the case, fail to even to do this adequately because people fail to understand what the model is really trying to help the organisation achieve.

There are a whole bunch of issues associated with the Lessons Learned process, many of which would appear to be associated with the origins of the idea. When I first started working in Software Development over 25 years ago we never did Lessons Learned - but then again, we didn't do much of the stuff commonly considered as integral to the development process today. My first memory of anything resembling the concept of a lessons learned review was when I read an article by Tom deMarco on Project Postmortem Reviews * some time towards the end of the 1990s. This made a lot of sense back in those days - at least in the organisations I worked in where we had a small teams of developers who stayed together and worked on project after project. It made sense in projects that lasted for years, where phase postmortems could be used to identify and correct mistakes prior to starting the next phase. And in the days before I started getting involved in SW-CMM initiatives I introduced the concept and practice into several groups with some small success.

On a small scale the Project Postmortem Process defined in that paper can be very useful as long as two conditions remain in place:

The same teams of people are used in a "product development environment" so that they have a shared understanding of the issues which cause problems
There is a management environment that allows the problems to resolved internally within the teams rather than imposing inappropriate solutions on the team without really understanding the underlying issues.

The Project Postmortem Process fails as soon as:

It is scaled up to become an organisational process - e.g. the focus changes from an internal review and change exercise to a management mechanism for fixing organisational issues
Project teams are constantly rearranged and staff treated as interchangeable resources
Emphasis changes from internal and potentially informal communication within a team, to a demand to codify the findings for wider use
Managers and process experts attempt to implement CMMI without understanding what the model really implies - i.e. that the process is part of the feedback mechanism to improve the business, not an exercise to generate paperwork to fill up a repository
The process is used to apportion blame

Over the years since first reading about the Project Postmortem Process I have been seen numerous lessons learned systems in numerous organisations. Most of them suffer from exacly the same problems.

Lessons Learned reports are documented and filed away and the feedback element to improve process rarely occurs
Lessons Learned are purely qualitative and can easily be distorted by the strongest or most vocal members of a team
Not all project team members or stakeholders are invited to participate in the process so not all perspectives are represented
Most staff perceive the process as a waste of time (and in most cases they are right)
Reviews are usually focused on project failures and successes and the process improvement opportunities are not realised
Managers or SEPGs that do any analysis on the results attempt to implement heavy handed changes based on their interpretation of the results without understanding the underlying circumstances or, most significantly, the differences between the environmental characteristics of the originating team (project or programme, agile or waterfall, etc.)

In fact many Lessons Learned reviews and reports have become so worthless that I can often predict the findings without knowing anything about the project or people. Typically the section on Things That Worked Well include:

Excellent teamwork and communication between project team members
Everyone went the extra mile and worked hard to complete the project under extremely difficult circumstances
The pizza brought in by senior management on the nights we had to work was really tasty and much appreciated

And in the Things That Could Have Been Better you'll see:

Really difficult relationship with the key stakeholder made this project a major challenge
Customer was never available
Requirements were so poorly specified we had to make them up as we went along
Technical procurement issues led to long delays
The CMMI initiative caused us a huge amount of extra work which didn't add value to the project

So very often, project lessons learned reviews tell us what we already knew, and probably have known about for some time. And the only thing that future projects can learn is that they are doomed to follow a similar pattern because nothing is being done to correct the organisational issues. The most likely outcome is that new status report and requirements specification templates will be imposed on the projects.

In part 2 I'll have a go at look at some of the things we might be able to do to make Lessons Learned a more valuable tool for the organisation, by extracting value for both projects and processes.

* Collier, DeMarco and Fearey: "A Defined Process for Project Postmortem Review" IEEE SOFTWARE 0740-7459/96/$05.00 © 1996 IEEE Vol. 13, No. 4: JULY 1996, pp. 65-72

Good Practices, Recommended Practices but never Best Practice

2012-03-12T11:06:00.002Z

If you've read previous posts on this blog, or if you follow me on Twitter, you may be aware that one of my current bug bears is the wilful misuse of the term "Best Practice". I have no idea where this concept originated, but it can't have been anywhere that believed in Continuous Improvement (or in any improvement for that matter!).

My first hands-on experience of "Best Practice" was with the introduction of a new global Quality Management System being adopted by a multi-national IT Services company across its Applications Delivery group. All the corporate assets such as templates and guidelines were stored in a "Best Practice Repository" (BPR) and tailored versions of these could be uploaded by local delivery groups. As a relatively naïve practitioner I welcomed this approach initially. All staff had access to the local assets by default, and if no asset was locally available they were shown the corporate asset. Part of my job was to manage our local assets and their incorporation into the BPR. Various metrics were provided to understand how assets were used which I used to monitor and report on to my local senior management.

As a relatively mature organisation (compared to other delivery centres around the world) with a large number of tried and tested assets already in use in hundreds of projects, my team uploaded most of our templates into the BPR unless we felt that the corporate standard was an improvement on our own.

This was when the first warning bells started ringing as we became plagued with questions like "should we be using the corporate or local standard?". Notices of Instruction were duly posted with appropriate advice but the real question remained unanswered by the QMS owners - the question being "how can you have multiple Best Practices?". Either it's Best Practice or it isn't.

The second warning bell came when the European management team decided to compete with the rest of the world as to who could provide the most best practices, and all European organisations found that the number of assets uploaded and downloaded in the BPR became part of the balanced scorecard for process improvement teams. A frenzy of activity saw dozens and dozens of best practices appearing over the next few years and PMs and developers had free reign to download whatever took their fancy regardless of the quality of the materials. Many organisations simply edited the corporate standard, added their delivery centre name and logo, and renamed it to reflect their own identity. As is so often the case, the focus of improvement degenerated into wasteful template production rather than adoption of process into the mindset. What started in Europe soon filtered out across the world and the BPR became an unmoderated morass of templates and guidelines.

After several global reorganisations a new version of the global applications QMS was developed and I was a member of the design team. Some lessons from the past were learnt, and although the BPR still existed we cleaned out 90% of the contents and put in strict controls on how assets could be added which involved several levels of review (local, regional and corporate). The B still stood for Best however.

This story isn't unique sadly. I've seen it repeated in organisations all over the world, in big companies and in small ones. As long as CMMI is interpreted as being about the production of templates and documentation the nonsense will continue. But until that happens, at least refer to your Process Asset Library as that, or if that's a bit too difficult to understand call it a Good Practice Repository.

Best implies that it can't be improved, and that there can only be one. Neither of these implications has a place in the world of continuous improvement.

Postscript - there's no prizes for seeing the other moral of this tale; that's right…the one about how a carelessly considered measurement can cause totally dysfunctional behaviour which could cost you dearly.

A Dilemma Regarding Defect Tracking

2012-02-14T10:49:00.001Z

In my previous post I harked back to the good old days when I wrote code for a living and used to pride myself that I could pretty much guarantee that there would be very few bugs in my production code. This was a good thing for the organisations I worked in because we really didn't have a process model for software development. Most people in those organisations had never heard of development models and the software groups tended to be structured around functional roles - analysts and designers, who handed huge specs to programmers, who delivered completed systems to testers. There weren't even any real project managers - the role was shared between the lead analyst and a business/product manager.

So producing relatively defect free code was good because we didn't have defect tracking systems. We had lists of defects that came from the testing departments which programmers then had to track back to their own work and fix the issue long after it was initially created.

Since then defect tracking and management systems have proliferated and maintenance crews mop up the bugs long after they were created by someone else. Defect prioritisation meetings soak up stakeholders time and product release cycles stay the same regardless of the advances of technology and the power of new hardware and software tools.

No wonder that defect management is regarded by the lean community as waste, and why new techniques have been developed to better integrate the development functions and activities to find and fix defects as they are created rather than at the end of the development cycle.

As a software engineer, process person, and business improvement guy, I heartily approve of this and wish that more organisations could understand what a difference it could make to their release cycles and the overall quality of their products.

But as a user I find myself with a dilemma, primarily with big organisations who are responsible for product portfolios of millions of lines of code. I'm thinking in particular of the operating systems and hardware providers like Apple and Microsoft, where it's clearly impossible to test for every eventuality.

I'm reminded of the legend about Rolls-Royce when they built motor cars in the UK and owned the brand name for their cars. The story was that if your Rolls broke down you would have to ring a secret number and a service engineer would arrive on the scene with a spare car and take yours away, in a covered truck, to be repaired before returning it back to you. Rolls-Royces simply didn't break down and to prove it, you never saw one by the side of the road or being towed away.

Companies like Apple don't acknowledge bugs in their systems very often. If they do it's usually buried in the release of an update, and stated in very high level terms, like "fixes an issue with wireless networks and wake-up". I'm certain that Apple employs sophisticated defect tracking and management systems but as a user I don't know whether my specific problem is a known bug, a personal issue because of my system configuration, or a previously undiscovered problem. I can search the support forums and I can send feedback to Apple but these never get officially acknowledged, and many of the forums are populated by the blind leading the blind.

It would be so useful if Apple, like many smaller companies already do, could publicly provide a list of known issues, along with official work arounds where they exist. It would save us consumers hours of time trying to understand whether we can fix something or not. It would save hours of Genius Bar and Apple Support time and costs. And it would make Apple look better as their current system makes them look like they don't care.

As a developer I don't want defect lists. As a consumer I'm desperate to see them!

A Message to the New Breed of Software Developers

2012-02-13T11:05:00.003Z

With the advent of the "App" and their associated distribution stores (Mac, iPhone, Android etc.) the act of developing software has never been more popular or more accessible. The opportunity to create the next "Angry Birds" in your bedroom or living room and become an overnight millionaire is clearly very enticing to many individuals.

Before I became involved in Quality and Process Management, and long before I became a consultant I earned my living as a software engineer. I use the term advisedly - I wasn't just a programmer; I was a systems designer, architect, tester, requirements engineer, configuration manager and I learnt my trade over the course of many years from some great and passionate people.

I was driven by simplicity, elegance and efficiency in both design and code. But mostly I was driven by a desire to be a brilliant engineer with acute attention to detail, and a self motivated need to write as near perfect code as possible. It helped that in those days we were constrained by both hardware and software limitations. Compliers were command lines driven, terse and unforgiving, and IDEs were few on the ground. Memory and disk space was grossly expensive and processors were slow. A build that today might take a minute or two would take half a day, so silly mistakes were costly and time consuming. Most people, including myself coded away from the machine, only committing when we had desk checked everything to iron out as many problems as possible. All these things led to the disciplines of efficiency and care that we learnt back then.

Today, computer resources are plentiful and cheap. Software development tools are powerful and much easier to use. The constraints we suffered are resigned to our memories and computer museums. The only constraints that haven't changed are time and money which are clearly still in short supply in all commercial development shops.

But despite these advances in technology those quaint old values that I shared with my colleagues, my mentors and mentees, should still be forefront in every developer's mind. Cutting corners is not acceptable. Shipping products that fail is not acceptable. Thinking of your customer simply as a cash cow is not acceptable.

I use mobile devices for many activities during the course of the day - some critical for business and some which are critical for my relaxation. I expect these devices to work without having to reboot them during the course of the day (as I do with my laptop and desktop machines). Far too many apps crash my devices and memory management is often diabolical. New versions of software reintroduce old bugs suggesting that no proper version control is in place.

I think it's great that people have the ability, imagination, enthusiasm, capacity and desire to create software and there are a number of apps I use regularly on both my iOS devices and Macs which are a pleasure and delight to use. These are often sourced from those one person outfits whose desire to create great software outweighs the desire to get rich quick. They also tend to be great at supporting problems and always willing to go the extra mile to help fix things when they occasionally go astray. These people understand that they have a responsibility to focus on the details and to get things as right as possible as often as possible.

So my message to all developers, commercial and freelance, whether part of a team or solo artists, is simple. Please reassess your values and your methods next time you start to work on a piece of code or a new design. The best processes in the world are worthless if you - as an individual developer - fail to actually give a toss about what you are responsible for, and fail to give true consideration to your customers and their basic needs and requirements.

Maybe Process Management Isn't Enough

2012-02-01T11:37:00.001Z

For the past five or six years I've been evangelising about moving from a Process Improvement culture to one of Process Management. I've written about it in these blogs, I've spoken about it at conferences, and I've tried to encourage and promote the adoption of the concepts and principles in the workplace. I generally find my arguments are well accepted:

Process Improvement activities tend to be short term, project based endeavours which peak in the run up to an appraisal or audit and then fizzle out
Improvement teams spend much of their time recreating processes in their own image rather than building on existing processes to actually improve them
Process improvement activities are often top down and more aligned to compliance than aimed at the generation of added business value
We think in terms of Quality Management which encompasses planning and control, assurance, compliance and improvement, but only talk about process improvement

So when I talk about Process Management I'm thinking about a truly operational activity which is a defined and managed function that works holistically across the business and is aimed at generating improved business performance at all levels.

But I'm now having my doubts about whether this goes far enough, and reading a post earlier this week has encouraged me to write this entry. Chris Taylor published an article on BPM For Real entitled "Has process lost its meaning?"

Now I don't necessarily agree with Chris' views in this particular instance (although I totally agree about that fact that management speak and jargon has completed clouded our use of vocabulary and have written about that before!) he said enough to make me step back and think about my experiences over the past few years.

Some organisations simply did not have effective processes in place which was preventing them from achieving the levels of performance they could have expected from their people
Many organisations wasted their "improvement dollars" fixing perceived issues rather than genuine failures, often because they believed their process experts rather than listening to the process users
Too many managers simply didn't understand what they were really doing and initiated improvement activities aimed at doing the wrong things better
Lots of teams were involved in Continuous Tinkering rather than focused improvements
Business value was not being realised because it wasn't even part of the dialogue for consideration
Arbitrary quality targets were set and improvement activities were channelled into meeting these
Reactive quality compliance had higher management priority than proactive prevention of future quality issues

Some of these are genuine process issues which could be addressed by more rigorous process management. But fixing some of these problems requires more than new or improved processes. They need better understanding of business and management realities than many managers have. They need better trained and educated managers. They need process experts who have a better understanding of core business activities and values and who operate in the real world of the people who execute the processes (commonly called workers!).

My biggest problem is that I don't have a convenient label for what this discipline really is. It could be Performance Management, but that's already been hijacked by HR in the guise of personnel reviews. In the old days, it could have come under the moniker of Quality Management, but that's been hijacked by Testing and the compliance police.

Maybe I should just invent a word - Proformance perhaps. It's got a big red line under it as I'm writing this, so it doesn't appear to exist yet. Yes, I like that...

Business Proformance Management - the act of ensuring the right things are being done properly across an organisation, with the aim of improving business value and outcomes for all stakeholders including the people doing the work.

I shall reflect on this further and let you know how I get on. I'd welcome your thoughts on Proformance Management.

Acting Under Pressure - Free Thinking or Conditioning

2012-01-18T12:04:00.003Z

I've been having some pretty restless nights since I came back from Switzerland and last night was no exception. I woke up at 04:45 clutching at some snippets of a rather bizarre dream, but sadly wasn't conscious enough to jot them down. The gist of it was that I was in a war zone with some close friends from both work and personal life and I was questioning some of the decisions that were being taken, both tactical and strategic.

In those immediate moments after waking I realised that I had been thinking about was the difference between doing the right things and doing things right (regardless of whether they were the right things to do). As I rubbed the sleep out of my eyes, my mind started darting around all over the place. I started thinking about Verification and Validation process areas in CMMI (as you do!); I thought about jobs I had left because I had had tried to do what I thought was the right thing whilst all around me people were doing what they'd always done and still failing; and I thought about all the projects I've been involved in which might have succeeded if leaders had focused on doing the right things rather than doing the wrong things righter. It's sad to say that far too many of us have worked in organisations and projects that have resembled war zones and how much of our office language reflects conflict, with our war rooms, death marches, and battle plans.

Finally I started wondering how much of our behaviour changes when we're under pressure and we start to behave according to our genetic ancestry (fight and flight) or our social or workplace conditioning (command and control in most cases). I even wondered whether there is a genetic disposition that make some people behave like leaders and others act like sheep, particularly when the going gets tough.

Many of you will have seen coverage of the terrible events in Italy this week involving the cruse ship Costa Concordia. We'd all like to think that if we ever found ourselves in such a situation that we'd behave with dignity and calmness and make sure that we did the right thing in that context. The tragedy is that when we're faced with the reality of such a disaster, very few people live up to their ideals. It's much easier to do what you're told (rightly or wrongly) and to follow the majority. To do something that goes against the grain, to think differently, to take a different course of action that might go against all common sense is much harder.

But in an organisational context or a project context the pressures that we are up against are not life threatening. We not only have the opportunity to think or react differently to everyone else - we have an obligation to do so. And managers and leaders have an equal obligation to listen and make decisions accordingly based on analysis of what is being said and not against received wisdom or ingrained ideals of what is right.

Projects and organisations fail most often because they allow themselves to be persuaded by convention without thinking about the real consequences. Far too many decisions drive the types of behaviour which lead to people focusing on doing the wrong things, and trying to get better at doing them rather than simply doing the right thing because it's different.

UPDATE : Just before I went to post this entry I discovered someone else thinking similar thoughts today as I saw this on my Twitter feed...

flowchainsenseiAlways, always the toughest decision I have to make as a coach; whether to behave as management expects OR to coach teams effectively.

I fully empathise with this dilemma. In the end my heart usually rules my head and after towing the line for a while I'll edge towards trying to do what's right. Sometimes I'll end up paying the price, but at least my conscience is clear, and there are always some folk around who thank me for trying!
.

Continuous Tinkering is not Continuous Improvement

2011-10-19T21:20:00.000+01:00

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!)

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

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

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

The Sleepwalkers Have Taken Over the Asylum

2011-09-04T09:30:00.003+01:00

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!

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

2011-05-08T18:49:00.000+01:00

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:

Reaching a specified maturity level was the primary organizational objective
Leadership and managers only paid lip service to the “Improvement Programme”
The initiative was called “The CMMI Programme”
Resources (people and budget) for improvement were only planned up until the end of the appraisal
Main output from the programme was the creation of dozens of artefacts, primarily templates
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.

The Madness of Starting Point Schedules

2011-02-03T10:57:00.001Z

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!

.

A Trip Back to the "Bottom of the Ladder"

2011-02-02T14:39:00.002Z

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?!

.

When Measurement Programmes go Viral...

2010-11-10T18:52:00.006Z

I think it’s a fair comment to say that only a foolish manager or leader would try and run an organisation, department or even a project based on subjective judgment alone. Gut feelings and intuition should not be ignored but they need to be backed up and supported by facts and often the best facts are quantitative. I have come across plenty of managers who follow the ostrich tendency and genuinely believe that they understand how their organisations perform but reject any type of data collection. Luckily they are in a minority and they aren’t the focus of this post.

If ever you attend a course, seminar or conference presentation on the implementation of a metrics programme in an organisation there are usually several repeating themes:

Metrics collection is only worthwhile if you use the numbers to take actions
The cost of data collection must not outweigh the value of the data
Data quality is paramount – poor quality data is usually worse than useless
Start off by collecting the most useful data, based against your objectives, and build your programme on that basis
Continuously review the data you collect and get rid of those measures which no longer add value
Don’t use the numbers to beat up your people

The Measurement and Analysis process area of CMMI is one of the easiest PAs in the model to understand. In the main, it is written in jargon free English and it follows both a logical and a chronological path. In short, it ain’t rocket science.

Yet in almost every organisation I’ve worked in it brings fear to the heart of the process teams, fills project managers with dread and often has so-called metrics subject matter experts rubbing their hands with glee at the thought of the power they will be able to wield. In some organisations some managers will also delight in the prospect of new ways to command and control their workforce whilst others will react with complete apathy (“we’ve seen it all before and it won’t work”), and still others will share the same fear as their staff.

So why do so many organisations get it so badly wrong?

There are a few places that get a good balance with their measurement programmes, but too many fall into one extreme or the other. Some organisations simply pay lip service to the requirements and do just enough to think they’ll get through an appraisal. But in this piece I want to look at the organisations that go to the opposite extreme and overwhelm the organisation with useless, redundant and time consuming measurement activities – again with the simple objective of meeting the needs of an appraisal rather than focusing on the real needs of the business. These are the organisations where measurement programmes have gone viral.

Imagine the scenario; an organisation has set a goal of achieving CMMI Level 3 within 24 months (I know – it’s a bad goal, but we all know it happens). The SEPG and steering committee agree that they need to ramp up the measurement programme because they don’t have enough going on to achieve Level 3 based on arbitrary perception rather than a genuine business need. Someone is appointed to head up the programme who is a naïve but ambitious PMO manager as opposed to a management or business expert (or even a software engineer).

Within weeks, a deluge of new measures are mandated and the already overextended project managers now have the burden of collecting and submitting each and every new measure through a system of manual data entry sheets within yet more arbitrary timescales. No explanations are available as to how the data is to be used or how it will benefit the organisation. Of course, none are necessary because collecting data is a “good thing” and a CMMI requirement, and therefore it must follow that more is better. A team is put together to generate a set of internal dashboards which are built using complex excel spreadsheet and macros and a compliance team is set up to monitor the whole activity to ensure that there are no missing values. The spreadsheets are published to senior managers and a series of compulsory review meetings is established. Each and every aspect of each and every project is examined and corrective actions are created to bring deviants back in line. CMMI requirements are therefore addressed and the outcome of the forthcoming appraisal is in the bag. Everyone is happy (except the PMs, but they don’t count).

With this success story behind them, there is only one place to go for the measurement programme – the accumulation of more data, the development of bigger and better dashboards, and the total domination of the PMO across the enterprise. Yup – we’ve gone viral.

Of course the reality is that behind the scenes, the project teams are making up the numbers to comply with the data collection process – putting something in is better than getting in trouble for failing to submit anything at all. Managers largely ignore the data, because they are overwhelmed by it, and don’t really understand what all the numbers mean anyway. Dashboard reviews become repeats of the other management review meetings, and no real or useful analysis can be performed at any organisational level because the data is just one humongous and homogenous blob.

In many cases the organisation will achieve its goal of reaching Level 3 because they’ve done “enough” to get away with it, but everyone knows that it’s a bit of a sham. Emphasis on measurement falls away over the next six months (along with all the other non-institutionalised processes), and the pre-appraisal status quo is restored, until the next appraisal in three years time when the frenzy will start all over again.

So what can you do to inoculate yourself against this behaviour?

Look at the M&A Process Area in detail – nowhere does it tell you that a certain number of measures should be in place to be operating at any specific CMMI Level
Align a few key measures against your specific business objectives, and focus on getting good quality data. Involve business leaders in the selection of the measures so that they can get nearer to the solutions to the problems that cause them pain
Look for measures that will help projects and project teams not hinder them, and don’t overburden projects with demands for duplicate data or data that can be found elsewhere
Provide explanations of how to interpret the data. If you can’t do this, you have no right to demand the data in the first place. You also need to remember that different groups of people will have different objectives so do not take a one size fits all approach
Perform appropriate analysis and publish findings along with recommendations of collective actions that can/should or must be taken
Review your measures on a regular basis and throw out redundant ones or ones that don’t add value to the organisation. Review the cost of data collection at the same time.
Get reactions from the “shop floor”. If your metrics programme is causing your people pain, it’s probably doing something wrong and it needs fixing
Align the expectations of managers and information providers – in others words perform some serious stakeholder analysis and relationship management
Instead of worrying blindly about compliance in providing data, concern yourself with why the data may not be being provided, and instead of analysing missing data, examine outliers and significant deviations from expected values
Stop treating CMMI as an objective and focus on doing the right thing for the business, with CMMI as a (one of many if possible) reference model to guide you

New starters: What a Waste...?

2010-07-15T10:51:00.006+01:00

It never ceases to amaze me how poor organisations are at taking on new staff. I don't mean the recruitment process per se (don't get me started on that one), but the set of physical activities that need to take place in order to get a new employee (whether full or part time, permanent or contractor) up and running and being able to contribute to the organisation in as profitable manner as possible. I'm sure everyone has experienced the frustration of getting to work on the first morning of a new job, and finding a set of obstacles in your path.

Examples include :-

finding that the people supposed to meet and greet you aren't available
there's nowhere for you sit
no computer is available
security passes and building access are not set-up
network access is not configured
you weren't expected for another week…

Even if most of these elements are in place, very often the first few weeks are spent sitting around reading piles of mind numbing documents, meeting huge numbers of complete strangers who you'll probably never deal with again (and whose names you instantly forget), figuring out how to get an outside line on your phone, having lunch on your own, and generally waiting for something to happen so that you can start to feel useful.

In my experience IT companies or departments are usually the worst places to start working in, generally for most of the technical issues listed above. It also seems to the case that the bigger the organisation, the longer it takes. Here, the problem is often exasperated by the fact that the HR, facilities management and corporate purchasing departments have been outsourced, increasing both the timelines, number of communication lines and the number of issues needing resolution.

Given that the recruitment process often takes several weeks - if not months, even for critical hires, there is really very little excuse for not having everything ready for the new starter on day one, or at worst day two. Sometimes signatures are required on contractual, legal and security documents and photographs need to be taken for ID cards, but at least time could be allocated on day one for these activities to take place.

If an employee is to be productive he or she generally needs somewhere to work and some tools to work with. Computers can be pre-ordered if not already available. These machines can be pre-configured according to the new starter's role. Network access can be pre-arranged and appropriate shares to project data repositories and corporate tools allocated in advance of the start date.

But for some reason, organisations seem to be quite content to have their new, sometimes very costly, resources hanging around twiddling their thumbs, pretending to look busy, and trying not to feel guilty for something completely out of their control. In these days of cost cutting and the insurgence of "lean management" it is a complete mystery to me why organisations are quite happy to waste tens of thousands of pounds, dollars or Euros by having keen and eager employees loitering with intent to become productive.

Criteria for Creating Project Artefacts

2010-06-09T14:15:00.000+01:00

If I take a look at the people I follow on Twitter (currently about 1100) they fall into roughly several main categories listed here but not in any specific order:-

Process and Quality Experts (including CMMI, ITIL and ISO specialists)
Apple technical experts (including magazines and developers)
Apple fanboys and girls
Business leaders (non-IT)
Musicians and other "celebrities"
Journalists
IT professionals

Out of all the IT professionals, nearly all of them are self proclaimed Agile practitioners, managers or gurus. Why do I mention this? Well mainly because I don't believe that this reflects the real state of the larger world where I suspect the Agile sector is much smaller than the more traditional development approaches. Even within the Agile sector, I suspect there are only a tiny percentage of people "doing Agile properly". Of those who do, most of them seem to spend most of their time on Twitter, so I'm not sure how much they really practice what they preach!

By and large businesses still run fairly old fashioned IT programmes and projects, and very often these projects follow quality management systems that are somewhat over-engineered and overblown. Personally, I think I fit somewhere between the two places - I don't count myself as an Agile practitioner although I was part of the DSDM movement many years ago, and I have an aversion to heavy weight development and management processes and methods.

Even with heavy weight process sets, most standards encourage tailoring of the process and the project documentation so that it aligns with the specific requirements of the project. In other words, you do what is necessary and ignore what is irrelevant. Quality and process 'experts' are on hand to assist the project or programme manager make these 'difficult' decisions, and to help the project team members create the project artefacts that are deemed to be required.

Which brings me on to the real gist of this post, namely that there is something wrong with this approach. If a project manager doesn't know what a specific project artefact or process is all about or cannot make a decision about whether or not a particular artefact should be created or process followed then there should be some serious questions about whether he or she should be managing a project in the first place.

This isn't aimed solely at project managers, but anyone involved in the planning and execution of a project, including developers, testers and business analysts.

For me, there are really only three criteria which should be used to judge whether a project artefact should be created or not.

Does it add value?
Will the project be at risk if it is not created?
Do you know why you are creating it? (because I've been told to is not a valid answer)

If the answer to the last question is no, then the next question should be "Am I the right person to be doing this job?"

.

8 Quality Principles that everyone should adhere to

2010-05-20T10:04:00.002+01:00

At various times in my career to date I've held the role of Quality Manager or Quality Leader either at project, programme or organisational levels. Over the years I've developed a set of eight simple Quality Principles that are easy to understand and more importantly, easy to achieve by everyone in the organisation. In fact these aren't so much Quality Principles as common sense principles which often fly out of the window in times of stress. However, if you follow these principles, and communicate them across the team, department or enterprise you may find that some of the things that cause the problems in the first place will start to disappear. Print them out and post them on your noticeboards, issue all members of staff with a laminated copy to keep on their desks. And make sure that you follow up on them by ensuring that at the very least you yourself adhere to them whatever pressure you find yourself under.

Quality is a collective responsibility

Everyone must be actively involved
Your actions and what you produce reflects on all of us

Honour your commitments

Create a realistic estimate prior to making the commitment and document your assumptions
Don’t commit to something you know you can’t achieve
Provide an early warning if you cannot fulfil a commitment you made

Right first time, every time

If you don’t have time to do it right initially, when will you have time to fix it ?
Perfection is not a contractual requirement

A second opinion is not optional

All contractually required deliverables that you create must be reviewed by a person other than yourself
Allow time for review and rework in your estimates

If in doubt…ask

No question is stupid if it helps you to do your job, as well as helping others…
…but use your common sense

If you see something wrong (or know of something better) …tell someone

All processes can be improved
We can’t fix things we don’t know about

Plan your meetings

Make sure you have a clear purpose, a published agenda and the right participants
Record critical decisions and actions in meeting minutes

Keep It Simple, Stupid (KISS)

Life is complicated enough – don’t make it any more so

The SPI Manifesto - What's It All About ?

2010-04-15T12:24:00.003+01:00

It's election time in the UK, and this week the major parties have all released their manifestos outlining their policies and plans for the next five years should they be elected into government. Earlier this year the SPI Manifesto was published; the work of a group of people who attended a workshop in late 2009 in conjunction with the EuroSPI Conference in Spain. The publication of the manifesto appears to have polarised the SPI community into staunch supporters and those who are rather more sceptical about it. For myself, the manifesto certainly raises more questions than it answers, and in this entry I'll try to explain why. However this is not going to be an in depth analysis of the manifesto - although that may come later!

The Facts The SPI Manifesto is a 17 page pamphlet which is structured as three values and ten supporting principles. The three values are concerned with People, Business and Change, and each consists of a context and problem statement, a section explaining the value and a number of "hints and examples". The values are statements of what the authors truly believe. Four principles support the People value, three support the Business value and a further three support the Change value, and are explained as principles that the authors trust to support the values. Each principle consists of an explanation and an example. The front page summarises the values and principles, followed by an explanation of how the manifesto came into existence and what to use it for, and the final page is given over to the presenters, authors and reviewers.

Manifesto or Manifest ?

The dictionary definition of a manifesto is

"a public declaration of policy and aims, especially one issued before an election by a political party or candidate"

The word originates from the 1644 Italian word "manifesto" which means a public declaration explaining past actions and announcing the motive for forthcoming ones". My first issue is trying to figure out what this document actually is. It is titled the "SPI Manifesto", but in the description of what it is, it suddenly becomes a manifest which, when used as a noun, is defined as a customs document listing the contents put on a plane or ship. Clearly this isn't one of those! Semantics aside, this is the first of numerous inconsistencies which percolate through the document.

Three Unanswered Questions Despite having read through the document several times and having been in discussions with various knowledgeable colleagues I cannot find the answers to three fundamental questions. Quite simply these are:

What is the real purpose of the SPI Manifesto ?
Who are the intended audiences ?
Why was it thought necessary to create such a manifesto in the first place ?

A basic principle of process improvement teach us that we undertake a change or improvement activity in order to fill a requirement or to meet a need. A second basic principle is to identify the stakeholders impacted by the change or improvement. However, the SPI Manifesto, at no point that I can see, addresses either of these principles. And without these critical issues being addressed, the manifesto is left in a state of limbo. In a real life business environment, such a document would never see the light of day without having a requirement to meet or a defined target audience.

An Academic Exercise ? Given the failure of the manifesto to address the three questions I posed above, can we surmise that the undefined purpose of the document was to purely to complete an academic exercise to see whether such a document could be created? Without wishing to demean the contributors, when I cross-referenced the list on the back page of the manifesto, I wasn't surprised to find the vast majority appeared to be academics rather than practitioners. There is a certain irony in this because the first value regarding People talks about the failure of ivory towers in the drive for successful SPI!

Methinks there may even have been an unstated desire to create something akin to the Agile Manifesto simply because nothing existed in the SPI space. Unfortunately it's probably 20 years too late! It is probably fair to say that most of what is written in the SPI Manifesto is available in standard industry texts on process improvement and change management. It may not be as concise, but it is often written in a more appealing way, better explained and, almost always, with a specified target audience in mind.

Missing the Real Target

When you look around at the attendees of SPI conferences, seminars and SPIN groups, it doesn't take long to realise that most of the attendees are either SPI or Quality consultants or people suddenly faced with the prospect of leading or participating in process improvement initiatives for the first time.

Rarely do you see the CIO, CEO or CFO of an organisation, unless they are sponsors or key notes speakers at the event. In fact it is very rare for any decision making executives to turn out to these events. Clearly, they are busy people and cannot take four days out to attend conference. But these are the very people who we, as an SPI community, should be addressing. If I was a C-Level executive and this came to my attention I'm fairly certain my reaction would be along the lines of "So What?".

The trouble is, even as an experienced consultant and practitioner, my initial reaction to the SPI Manifesto is also pretty much "So What?"...

The Trouble(s) with Software Process Improvement

2010-03-22T10:44:00.002Z

Fifteen or more years of software process improvement efforts have not lead to the remarkable changes that people like Watts Humphrey may have envisaged when he wrote "Managing the Software Process". The reality is that despite our efforts software development projects continue to fail either completely or to meet their intended budget, time and quality objectives. Even high maturity organisations deliver poor quality software, and the return on investment from quality and other process improvement activities remains low. That’s not to say that SPI has failed and we should give up on it, but if we continue to perform the same actions and fall into the same traps we can expect the same relatively poor results. Even companies that were early adopters of CMM and CMMI and have reached the highest levels of maturity now find themselves struggling to retain their status and suffering the mediocre results of more naïve organisations. Some of the reasons for failure are:

Insufficient management sponsorship, ownership and responsibility - SPI is viewed as a technical activity and management directives are delegated to groups without sufficient authority to “Just go and do it”
Software Process Groups lack the discipline and management skills required to undertake improvement projects, with the apparent effect of causing a “Do as I say, not as I do” environment
Expectations of return are grossly over-exaggerated in an attempt to secure funding, and funding is removed before any real benefits are realised
Supplier management is poor, and outsourcing suppliers often mismatched against the organisation’s values and beliefs, especially with respect to quality
Focus on CMMI, maturity levels and specific goals rather than doing what is best and right for an organisation using diverse methods, tools and techniques
An unmanaged approach to change leading to employee resistance at all levels of the organisation
Failure to adopt a holistic approach across the organisation, with associated confusion, duplication of effort, and critical activities falling between the cracks
Decision makers are informed about SPI activities rather than consulted and involved
Waves of initiatives roll on without pausing to understand the effects of the previous initiatives and often undoing the good that has gone before
Improvement plans are based on perception rather than fact - data is not used to verify that the right areas are being targeted
Quality and process teams undermining their own efforts by failing to add genuine value to the organisation and its business

If you pick up any book on process improvement you will see that these and other issues like them have been identified and understood for many years, yet some or all of them still abound in any organisation currently running SPI initiatives. Given that those same books often provide the solutions on how to avoid the problems, I can only assume that there must be something more fundamental going on which is causing the software industry to fail to rise to the challenge, namely the people problems I described in my last post on the 7 Deadly Sins of Process Improvement (or Change Management). Next time I'll describe the first of these - Arrogance.