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. Print this post