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.

Where waste is rife but apparently acceptable

This blog entry may not sit easy with some readers but will have others nodding their heads in sad agreement. In the current recessional climate, many large organisations are bending over backwards to divest themselves of their staff. Loyal, hardworking and smart people are being laid off in their scores and face an uncertain and uncomfortable future. At the same time, those left behind appear to demonstrate that poor management and general incompetence is normal and acceptable behaviour, and continue to be rewarded for it. It seems that the Peter Principle is now a key criteria for promotion. Organisations that have become accustomed to working with bulging levels of untrained and unqualified middle management are now burdened with an unprecedented amount of waste which they appear to be unable to prevent. In most cases, the inability to deal with this waste is because it goes unrecognised and unnoticed, except in the worst cases where it is actually ignored. Some of the problems are due to the fact that many managers now act purely as conduits. Their sole function in life is to delegate everything down the chain until it reaches the lowest level at which point everything flows back up the chain to the original source. Additional requests for information or action then repeat the journey until the next set of demands appears. At no stage in the process is value added. In fact the reverse is more likely to be true as “Chinese Whispers” take effect. Good managers lead by example. They get their hands dirty, not to the point of micro-management, but they recognise that there are some tasks they can or should undertake themselves without having to disrupt their staff. Constant delegation without thought actually puts staff into difficult positions. I’ve heard of organisations delegating activities associated with pay-cuts and layoffs to junior members of staff who do not have the appropriate levels of authority or access to deal with such information. In other situations, procurement departments are circumvented at management request to expedite purchasing activities. Again, it is often non-managerial staff who are put in the firing line for failing to adhere to policy and process. Management by pure delegation is often associated with management by email. Staff are given insufficient detail, information and time to deal with orders handed down by vague and curt emails. The premise is that if you are at the bottom of the chain you can clearly stop everything to deal with the most recent urgent demand. In big organisations, it’s all too easy for poor managers to hide behind each other. This is unacceptable waste, and managers found to be lacking should be reminded that they have to add value to the organisation just like everyone else. A failure to deal with this will ultimately cause catastrophic failure in the organisation, as managers who don’t “do“ suddenly find that there is no-one left to ”do“ for them. And the people who know how to ”do“, have long since left the building.

You need more than Hot Air

Another tell-tale sign that an Improvement initiative may be in trouble is where the programme is deluged in meetings, reviews and general talking shops. It is well recognised that you can never communicate enough when it comes to managing change, but the requirement is for effective communication, not merely the production of hot air. If your programme is a “Process Improvement Initiative” then it is probably being run as a project, and some form of governance is in place. Typically this will consist of a top level Steering Group, a lower level Change Control Board, and a number of Process Review Boards supporting the pyramid. The core process improvement team will be involved at all levels to provide continuity, consistency, guidance and facilitation. It is important to make the distinction between governance and work (by which I mean the physical activities involved in designing, building, and implementing the change). Governance provides the mechanism for management and control, and strategic and tactical decision making. It supports the work activities of the process group. Governance bodies do not perform the work of the process group or associated working groups. Often an organisation has a governance structure that is similar to the one outlined above in which the improvement leader simply spouts out the same old progress updates to a different audience at different levels of the governance chain (albeit with different levels of granularity). The governance bodies listen to what they are told, perhaps ask relevant (or not so relevant) questions, may even make a minor decision (usually by agreeing to the initiative leader’s suggestions) and generally leave the meeting under the impression that everything is fine. However, at some stage in the initiative someone at an executive level is going to realise that in actual fact progress is not as expected, costs are increasing, and all is not well. For the next few months, the improvement leader is repeatedly warned that things must change or the programme will be canned, before finally the axe comes down. For some reason, executives rarely treat internal programmes with the same degree of rigour as client facing programmes. Steering Groups are led but don’t steer, Change Control boards argue about how things should be done rather than making decisions, and Process Review boards write processes. In other words the governance system fails, and problems are not uncovered until it is often too late to take effective corrective action. I believe that there are several reasons for this failure of governance. Firstly, the governance process for the initiative is not properly defined, communicated or understood. Often it is assumed that executives and sponsors fully understand their roles and responsibilities, but this is often an invalid assumption especially in change management initiatives. Secondly, the wrong people participate in the governance process. Individuals who do not have the knowledge, understanding, authority and responsibility to make effective decisions should not be part of the process (although individuals may be given responsibility and authority to do this under the terms of the governance charter). Finally, governance bodies need to be provided with relevant and objective data, against which they should be making decisions. If such boards are not provided with such data they must demand it, rather than rely on subjective information selectively produced by the initiative leader. If participants in governance meetings find they are spending much of their time in fruitless discussions, repeatedly reviewing historical data of little relevance, and generally going nowhere, they have a responsibility to do something about it. Their first step should be to review the governance process itself. Actions and decisions bring about change, not hot air.

Tool-itis: A Cause for Concern

There are often some tell-tale signs that not everything is going well in an improvement programme. Often these are activities which are brought to management attention to create an illusion of progress whilst more important tasks are allowed to slip. Sometimes this is conscious behaviour on the part of the initiative leader, but more often it is a reflection of the fact that the organisation is not really engaged with the change and the improvement team focuses on things it finds easier to deliver. Whilst gathering of low-hanging fruit may be good in terms of demonstrating success, it must not be at the expense of the core improvement activities, as without these, early successes will quickly fade and will fail to be sustained. We’ll look at some of these activities in future blogs, but today I’m going to start with Tool-itis. Here I’m referring to the creation of tools to support process management and improvement. These often take the form of dashboards, databases, repositories, and intranet tools. There is no question that a solid infrastructure is required to support all aspects of process management, but an overall architecture and strategic approach is paramount in order to ensure all the “-abilities” associated with a successful infrastructure such as suitability, maintainability and sustainability, etc. In an organisation that is showing signs of Tool-itis, tools are typically created in an ad hoc fashion. Each tool is created to fit the needs of a specific purpose (often along the lines of the CMMI Process Areas) rather than as part of the big picture. Of course, when I say “created to fit the needs of a specific purpose” this is largely wishful thinking. In a Tool-itis situation, tools are knocked up using the standard MS-Office suite, usually in Excel or Access. The principles of Software Engineering and Product Development which the process management team is demanding of the rest of the organisation are generally glaringly absent. The CMMI is the key source of requirements rather than the organisational needs and objectives, and the process group acts as the design and technical authority, as well as end user acceptance authority. In large organisations, Tool-itis can reach pandemic proportions, with independent process teams all creating their own sets of tools establishing a thriving cottage industry (often in parallel with project teams who are creating tools to fill the void created by having poor infrastructure in the first place). Valuable process improvement resource is easily gobbled up by this wasteful effort with very little genuine return on investment. So what can be done to help cure Tool-itis and put the improvement programme back on track? The main responsibility lies with the senior management who must not let the wool be pulled over their eyes. In particular the organisation’s Chief Architect should sit on the main governance body for the programme or steering group, to ensure that the infrastructure required to support process management is clearly architected and design in accordance with company requirements and existing architecture. Any tool developed internally must be subject to a similar degree of rigour as client facing products; at the very least, it should follow a defined lifecycle including requirements development and management, adequate design, quality control and assurance, and internal review and testing of the operational product. Tools should be designed with interoperability and scalability in mind, and must focus on the needs of the business, not the perception of the process group. At management review, if the process group is extolling the successes of process management tools in place of critical process management activities, some serious questions need to be asked. There is almost certainly something being hidden, and you need to establish what it is and why it’s being put to the back of the queue.