Knowing When Enough is Enough

In an increasingly unstable world, where corporations and individuals are being subjected to manifest and constant change it's frustrating to realise that there are still very few people who understand enough about the management of change to enable change programmes to have the best chance of succeeding. Often, even the simplest concepts are ignored. Given that change generally occurs over a period of time, it's not unreasonable to believe that some sort of lifecycle exists which can help us to manage the change. Even when change is spontaneous (such as when a person leaves an organisation), the effects still take time to manifest themselves across the organisational environment, particularly in the way that other people adjust and adapt. Some commentators actually resist the notion of organisational change altogether by talking about transitions by which we move from our current state to a desired state over a period of time. So our simple change or transition lifecycle consists of three parts; a beginning, a middle and an end. In reality, each cycle probably feeds into further cycles in a rolling wave of changes, but we'll come back to that in a moment. Despite the simplicity of the lifecycle, many organisations ignore both the beginning and the end, and focus all their attention on the middle. There's an element of human nature at work here because the middle is the part of the cycle where things are seen to happen, especially by senior management. In this respect, a transition project is just the same as any other project. Impatient sponsors or customers want to see action and results. Time spent doing up-front planning appears to have less value than time spent doing. And as for time spent reviewing at the end - well, clearly that's of no value at all since the project has delivered, so there's no point in paying for it. It's a bit like trying to get children to wrap up presents before Christmas and write thank you letters afterwards - generally they're not interested because there's no obvious reward for doing so. One of the key tasks that you need to perform during the beginning of your change cycle is to create the criteria to enable you to understand when the change is completed, which includes understanding when it's appropriate to begin the next change cycle. One of the main reasons that change initiatives fail is that new change cycles take place before the real success or failure of the preceding cycle is fully realised. I've come across several organisations that have embarked on rolling wave change initiatives where the current wave cancels out the achievements of previous ones - the old one step forward, three steps back scenario. Not only is this a waste of time, effort and money, but it leads to confusion across the organisation because change is never allowed to become embedded before it is swept out with the next tide. Confusion brought about through change initiatives will ultimately reduce the chance of success of future changes. The workforce will lose faith and trust in management that appear to be generating change for its own sake. During the start-up phase of your transition you simply must set SMART objectives against which the change can be monitored during the transition. These don't have to be particularly complicated, but they must be designed so that you know when to stop. Once you've reached that end point, as part of the review process, there needs to be some mechanism to ring fence those changes so that subsequent change doesn't eradicate all the good work you've put in. Unless of course, the change has been unsuccessful and you need to fix it. But of course, that wouldn't happen to you, because you will have spent adequate time at the start to make sure that you minimise your risk of failing! Next time, we'll look at the start phase of the change cycle in more detail.

Leave "Stealth Mode" to the spy planes

Over the years I've heard numerous references to "Process Improvement by Stealth". The New Oxford American Dictionary defines stealth as "cautious and surreptitious action or movement". Neither cautious or surreptitious are words that should be associated with process improvement or indeed any change initiative where the first three laws for success are Communicate, Communicate and Communicate. Stealth mode directly implies that you have something to hide or that something is not quite above board, and this in turn will anger, frustrate and disingenuate your key stakeholders, namely, the very people you are trying to change. If you can't be honest about what you are trying to achieve and the reasons behind it, and you cannot articulate those objectives in an open way then you shouldn't expect to be successful. Not only will the current change initiative fail, you will have sown the seeds for mistrust in future efforts. Is there ever a place for stealth in the world of business change? I believe there is, and there is evidence that it can be successful. The exception to the rule is when the change is initiated from below the management chain, where informal working practices are replaced by more rigourous processes, and adopted across teams and departments without formal process improvement or change management activities, and become the cultural norm. Whole businesses and industries have been born from this kind of stealth which tends to carry risks to individuals rather than organisations. In other cases businesses have been saved significant expenditure by individuals taking stealthy approaches to implementing management mandates which were born through ignorance and micromanagement. In general, however, leave stealth to the spy planes, and approach your change initiatives with open and honest communication and dialogue to minimise your risk of failure.

Consider all your Stakeholders

Over the next few days I'm going to change tack a little bit and post some bite size blog entries focusing on some critical success factors and key points of failure associated with operating an effective process management function and performing process improvement. Each of the entries I'm going to post represents an element of process management that is often overlooked, especially in inexperienced organisations or teams, but which may make or break your process related efforts. Today I want to pick up on the need to consider all your stakeholders, not just the immediately obvious ones. This is particularly relevant in the context of Software Process Improvement, where it is easy to focus your efforts in the project management and software engineering process areas. This is even more likely if you are attempting to run your improvements as part of a CMMI project rather than a business improvement programme. Clearly project management and software engineering groups and their managers are key stakeholders in this type of improvement programme. However, spare a thought for some of the other people you need to engage with. A few groups spring to mind immediately:

1. Finance
2. Human Resources
3. Procurement / Supply Chain Management

In most enterprises, there will be very few, if any, Applications Development/Maintenance projects or programmes that do not interface with these groups to some degree. Get the department heads involved in your process activities as early as possible. You need their support, and you need to know what improvement activities they themselves may be undertaking. There is no point in creating wonderful PM and engineering processes if they do not properly interface to the rest of the enterprise. A failure to take a holistic view of process improvement will cause no end of problems in the long term even if you appear to get away with it in the short term.

Watch out for Waivers

Tailoring the software process is a fundamental aspect of software process management but is often poorly understood by inexperienced process teams and badly executed. This generates confusion amongst project managers and project team members and often leads to an undesirable behavioural response whereby tailoring is ignored in projects and process anarchy gains a foothold in the organisation. One key failure is to confusion between the tailoring process and the waiver process. Process tailoring (as defined by the SEI) is :

"The activity of creating a process description by elaborating, adapting, and/or completing the details of process elements or other incomplete specifications of a process. Specific business needs for a project will usually be addressed during process tailoring."

Typically a process element is an input, output, role, activity or procedure, but not restricted to these. Crucially, the act of tailoring does not change the underlying purpose of the process or process element. An example of process tailoring is to select which of the standard project management deliverables a specific project will create. Similarly, small projects may tailor the standard lifecycle to follow a less rigourous start-up process than a large project. Process tailoring decisions are made during the project launch, should be based on tailoring guidelines and are agreed with the relevant stakeholders according to specific business needs.

A Process Waiver on the other hand is a mechanism that allows the applicant (for example a project or business area) to refrain from applying or following a process. Very often process waivers are a mechanism to allow a project to perform non-conformant processes or activities.

An example where a process waiver might be used is when project is contractually required to use the client process set rather than in-house processes. Process Waivers are usually granted on a temporary basis according to an agreed business case, and are reviewed on a regular basis to ensure their currency and validity.

Neither process tailoring nor process waivers should be performed as 'get out of jail free cards' undertaken because an individual or team has elected that they don't wish to perform certain activities.

Process tailoring should be performed by all projects as part of their launch. Process Waivers should be exceptional. If projects are generating large numbers of waivers there are likely to be three possible underlying causes. Firstly the distinction between tailoring and waivers is not understood. Secondly, the tailoring process and guidelines are inappropriate, or in the third and worst case, the process set itself not properly aligned to the work being undertaken. The process group (or equivalent) should be maintaining records of all waivers and performing trend analysis against the data to establish potential process improvement opportunities. Records of tailoring decisions should also be kept for the same purpose.

One final thought is to pay attention to the granularity of process tailoring guidelines. At a minimum, process areas and process inputs and outputs should be included. Some organisations attempt to tailor at a lower level, such as tailoring of sub-sections within documents. Unless there is a very good reason for such a level of control this is probably a step too far and will generate mistrust and resistance from those people who have to create and use the documents. A good review process and culture should trap potentially critical documentation errors whilst still allowing the authors the ability to make some decisions for themselves, and will also allow a best practice culture to grow and thrive.

There's enough of a nanny state out there without needlessly bringing it into every aspect of working life as well.