Friday 3 July 2009

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.

Tuesday 30 June 2009

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.