Friday 18 December 2009

Getting Value from the Quality Department (Part 2)

In this post I want to discuss the problem about Quality terminology and how it is chronically abused in the IT industry and in software development in particular.

Somehow in software development, the term quality is now generally taken to mean testing, and worse still it is often limited to testing after the event. In other words, once the code has been written and integrated, a group of people run a batch of test scripts using an automated tool and look for problems.

Without wanting to belittle the role of the testing team, this is not quality or quality assurance. This is testing, and it is a part of the software development lifecycle just like analysis, design and build phases. Any book on Software Engineering will explain this. Nowhere is it written that quality equals testing. You don't test for quality, you build quality into the system and you build an organisation based on quality principles. Once you move away from those central tenets you may as well pack up and go home. But look through the job adverts on any recruitment page and you will find positions such as Quality Engineer, Quality Assurance Manager, and in ninety percent of cases the associated job description talks about testing; developing test scripts, using testing tools, and more often than not having ISEB qualifications.

At my girlfriend's former place of work they even used to run testing bootcamps for graduates, which turned non-IT graduates into certified testers in four weeks. In my opinion, any organisation that works in such a fashion is certifiable itself.

If you read the ISO 9000 set of standards, which despite its faults, is still a reasonable place to start in a discussion about quality, you'll read about Quality Management which incorporates Planning, Control, Assurance, and Improvement. You really have to dig quite deep into the standards before you get to any serious mention of testing, and by that time you should have worked out that it is one of set of tools available to an organisation, along with reviews, audits, inspections, and other verification and validation methods.

Which brings me onto the subject of audits. I've worked in a number of organisations where the quality team only performs audits. Armed with nothing more than a checklist and set of pre-prepared questions, the person doing the audit goes into the project and runs through the questions, ticking the boxes. I use the phrase 'person doing the audit' advisedly. These are not necessarily trained auditors. Even those that are, often appear to have little understanding of the domain, whether it is project management or even software development.

Often the people assigned to the quality team are those with least experience of anything - it used to be common practice to place graduates and new starts into the quality team to keep them out of the way. Nowadays the quality team simply doesn't exist because it's just been made redundant to save costs.

The point is that audits performed by people without the necessary training, understanding and experience of the problem domain cannot add value to the process. We'll cover this in more depth in a future post but an organisation that relies on this type of audit, to identify problems after the event is unlikely to add any value to the organisation, and by that account, sets itself up to fail. A Quality Manager in this position deserves to be looking for a new role.

At the heart of these issues is the failure of the organisation to really address what it is trying to achieve. If the organisation sets itself objectives it needs to consider how to achieve those objectives, and it's very rare for one activity to work in isolation. Different methods and techniques (and tools where appropriate) need to be considered, and each needs to be evaluated from a value and cost benefit perspective. This is where the Planning element of Quality Management fits it. It's not enough to create a Test Plan or an Audit Schedule. A Quality Plan needs to align to organisational / programme / project objectives and customer requirements and it needs thought and expertise.

My challenge to today's quality teams is to put themselves back in the forefront of organisational operations and be counted as people who make a real difference by adding extraordinary value to the organisation and not restrict themselves to one dimensional entities who only do one thing, and don't even do that very well.



Thursday 17 December 2009

Getting Value from the Quality Department (Part 1)

It's a been a while since my last entry on this blog but I've been doing a lot of thinking in the meantime and I keep coming back to one of my favourite subjects which is the role of the Quality team in a typical software development environment, both in terms of what they think they are supposed to do and what they should actually be doing.

Over the next few entries I want to have a look at the problems I encounter in quality teams and organisations and what to do about them. I'm likely to get a bit sidetracked onto some connected bugbears so I'll beg forgiveness in advance and hope that it doesn't put you off reading!

I was introduced to the organisational concept of "Quality" quite late in my career. None of the first four organisations that I worked for had any documented processes or standards other than the Employee Handbook which was almost all HR oriented. One company took a tentative step towards ISO 9000 back in the mid-1990's, and even went as far as hiring a quality manager. They made him redundant after a few weeks when he told them how much it would cost them to get their ISO certification.

Later, I took on the role of "quality person" in my immediate department, and that's pretty much where everything else in my career started. I introduced a few things like code inspections, facilitated JAD sessions, and coding and documentation standards which were tolerated by the majority of our developers, and appeared to generate some improvements. Bearing in mind that my brief was pretty much "develop and implement some stuff to make us better" I'd like to think that I was quite successful. My only qualification for being given the role was "you're the only one who could actually give a fig".

About this time, we elected to change our development model from 'none' to Objected Oriented Development and Rapid Application Development using DSDM (Dynamic Systems Development Method). We engaged a consultant, Paul Allen who worked for Select Software at that time. As the person responsible for the implementation I worked closely with Paul and he taught me a lot about processes and process improvement. Our pilot project failed dramatically for various reasons, and I left the company before they threw me out, as it was quite clear that my final job title was going to be scapegoat.

I learnt a lot from that experience, but when I started my new job as a process improvement specialist in 1998 for a large global outsourcing company on a major British manufacturing account it quickly became clear that I was now in a different league. Quality wasn't just a buzzword; it was taken SERIOUSLY. Getting SW-CMM Level 2 was a priority objective and goal, along with maintaining ISO9000 certification.

Since then, my own role grew in size, influence and diversity so I got to see things in many different parts of the organisation. I later moved into consultancy and saw things from the outside looking in, rather than purely inwardly focused. And a dozen years later I have rather a different view and a much better understanding of the reality of Quality in the enterprise.

Very few of the quality and process improvement people I used to work with still have jobs with that corporation. Much of the cash spent on improvement initiatives has largely been flushed down the pan and the company has little to show for it. A few groups have been successfully been steered through CMMI L2 and L3 assessments, but regular reorganisations tend to dilute even that achievement - not to mention the loss of tens of thousands of developers and other staff. Quality is a necessary evil that has to be tolerated rather than embraced. It rarely appears on meeting or review agendas any more, and the higher in the organisation you go, the less likely the chance of it being mentioned. I've seen exactly the same happen at other companies, small and large, so this isn't an isolated case.

So where did it all go wrong and how can we get back on track to where we really ought to be after years of investment, research and more failure than success? Over the next few entries I'll look at Quality Perceptions, Management Responsibility, the Audit Process, Quality Metrics, and Quality People, and examine the issues and provide some ideas on resolution.



Thursday 22 October 2009

5 Facets of Change - Update

I've now made the changes to the 5 Facets of Change tool and this entry provides a quick summary of the modifications. I felt this was better than repeating much of the previous material. I've created a Quicktime movie of an Apple Keynote presentation which contains all the details, and this can be downloaded from my website. The central topic is now called Define the Change, and the five facets which support this are:
  1. Lead the Change
  2. Communicate the Change
  3. Manage the Change
  4. Deal with the Change
  5. Relate to the Change
The other key change is that the Changeability sub-heading is now part of Manage the Change rather than a part of the central theme. This is in keeping with the idea that any feasibility study needs to be part of the Start-up phase of the initiative. Otherwise the words in the previous blog entry still apply. Clearly there is overlap between the different facets in terms of who, what, when and how, and different projects will have different emphasis in each of the areas. However, any change programme needs to consider all of these facets, and failure to do so will almost certainly lead to problems. I hope this is useful - let me know if you're able to use it or if you have improvement suggestions. I'm planning to create a toolkit to support the 5 Facets which will include templates, checklists and other supporting materials to assist change managers and change teams. Watch out for more news.

Friday 9 October 2009

5 Facets of Change - A Tool for new Change Agents

In this blog entry, as promised, I'm going to run through a simple tool that will help newcomers to Change Management, and should be useful for seasoned practitioners. Only a brief summary is shown here - more information will be available on my website (www.allygill.co.uk)in the next few days. This is still a work in progress and may be subject to change. Specifically, I'm looking to simplify the names of each of the facets to make them easier to remember! However, even in this early state, the tool provides the user with the key elements that must be considered before embarking on a change programme or project. 5 Facets of Change describes the five key elements which need to be considered throughout the change lifecycle. They support a central concept which describes the actual change you are trying to embed in your organisation.
5 Facets of Change.jpg
Change Definition & Integration Defines the business process and/or technology needed to support the change, and determines how the change will be integrated into the business operations of the organisation. The 5 Facets of Change support this central theme. Sponsorship, Change Team and Changeability Defines the elements of change infrastructure required to initiate any serious change across an enterprise. These can be defined at the enterprise level and tailored for specific change projects.
  • Sponsorship - Builds sponsorship for the change and creates a learning organisation capable of planning, implementing and sustaining the change
  • Change Team - Establishes the team and support structures needed to plan, implement, and sustain the change
  • Changeability - Examines the propensity of the organisation towards change based on history, infrastructure and overall ability to change
Education, Training and Communication Describes all communication activities associated with the change
  • Education & Training - Specifies a training and education program that will provide stakeholders with the skills and knowledge required for planning, implementing and sustaining the change(s)
  • Communication - Identifies two-way communication necessary to successfully plan, implement and sustain the change(s)
Planning, Management and Measurement Defines all project management activities associated with implementing a change. Should align with organisational project management processes.
  • Planning & Management - Identifies the activities requirement to actively plan and manage the change to minimise the risk of failure
  • Measurement - Establishes a metrics program capable of tracking and monitoring business value measures, transition measures, and change readiness measures that will enable learning and continuous improvement.
People, Behaviour and Performance Management
  • People - Establishes how to deal with the people who will be affected by the change. Uses ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement)
  • Behaviour & Performance Management - Establishes mechanisms that will reinforce behaviours that support the change and eliminate mechanisms that reinforce dysfunctional behaviours
Stakeholder Relationship Management Identifies how to manage internal and external stakeholder expectations while planning, implementing and sustaining the change(s).

Friday 2 October 2009

Sustainable Change Requires Preparation

Last time I wrote about a simple change lifecycle with a start, middle and end, and I focused attention to the end phase. That may seem a topsy turvy way of looking at things, but the reality is that if we don't think about the end goal at the start, we are going to have serious problems throughout the change cycle. It is generally accepted that change initiatives should be managed as projects. This is not an unreasonable assumption as one definition of a project is

"a temporary endeavour undertaken to create a unique product, service or result."

In the case of a change initiative the unique product, service or result is the change itself. Given that our assumption is valid it becomes apparent that the start of our change cycle will involve some planning and analysis activities. The extent and nature of these start up activities will depend on the size and nature of the change, and will also vary depending on your position within the organisation.

The difference between change project and other projects is that the degree of rigour required in the start-up activities is much greater when initiating organisational change. There are some additional considerations which may not be obvious to a product project oriented organisation. When an organisation kicks-off a new project, for example to build a new piece of software, there should be some form of up-front benefit and impact analysis. It's a good idea to launch a project knowing that you will get some return on investment, and feeling relatively confident that the new work will not negatively affect existing business (although sadly this type of due diligence is often not performed, and projects with little chance of success are undertaken regardless of their implications).

When undertaking an internal change project it is also a good idea to perform some kind of analysis regarding the ability and the capacity of the organisation to change. This means looking at the change history of the organisation (how successful were previous changes), the capacity of the organisation to absorb more change (how much change has recently taken place) and for both new and old businesses it's important to ensure that the infrastructure to support change is in place and effective (is there a change method, are there competent change agents). It is important to actually take notice of the data that you gather during this analysis. Many organisations ignore the information and go ahead regardless of the facts which will dramatically increase the risk of failure.

Who should be performing this start-up work? A dedicated change team is key, and should consist of a core team and subject matter experts who are co-opted into the team. Change management and project management are intimately linked and the change leader should have experience of both. Technical project managers may have the appropriate hard skills but sometimes lack the understanding of the change management cycle and the inherent difficulties associated with changing habits and culture. Change agents without the discipline of project management will also endanger the initiative as key tasks and activities may be forgotten or under prioritised.

Management and control are paramount in a change programme just as they are in a technical one. A change project needs scope management, budgetary control, configuration management, risk, issues and resource management. Communications and stakeholder management need to be in place and followed with additional rigour.

All these activities need a degree of up-front planning and management to maximise your ability to succeed. And of course you need to define, document and communicate your SMART (specific, measurable, achievable, relevant and time-bounded) objectives, along with your measurement plan to help you understand when you've reached you goal.

 In the next entry we'll look at the Five Facets of Change - the keys to running successful change programmes.


Wednesday 23 September 2009

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.

Tuesday 11 August 2009

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.

Tuesday 28 July 2009

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.

Tuesday 14 July 2009

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.

Saturday 11 July 2009

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.

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.

Thursday 25 June 2009

SPEG Conference - People and Culture

This is the final blog entry for this year’s SEPG Conference in Europe, albeit a few days later than intended. In my blog from 16th June, I suggested that there were two underlying themes to the conference, namely multi-model synergies and people and culture. So what about people and culture? Previous conferences have had their share of presentations on Change Management, People-CMM and other people and culture related issues. It seems to me that this year there was an new energy about these ideas even though they were not particularly highly represented. I wonder how many of the issues the global economy now finds itself in could have been avoided through better understanding and actual usage of these concepts. SEPG Europe 2009 itself was a victim of a failure of organisations to take on board people issues. The lack of attendees suggested cutbacks in training and staff development activities. Talking to past colleagues and associates in different parts of the world (and not just in the software industry) makes it evident that this is a reality not a hunch. Quality and process staff are being cut back in droves, contract positions have all but disappeared of the radar. The false economy of mass redundancies leaves us with decimated work forces and organisations that will struggle when the market finally begins to turn round. The investment in people cannot be realised once they have gone - that money is also gone, a double whammy when one considers the cost of redundancy to the bottom line. Dr Paul Nielsen, Director and CEO of the SEI said in his keynote that the SEI was going to run a People-CMM programme in addition to their other improvement programmes. This struck me as one of the most thought provoking comments of the week. If an organisation truly values its staff, surely this is an area where they should be investing, regardless of the type of industry, product or service being provided. How many organisations currently disembowelling their workforce have a value statement that “People are our greatest asset” or something similar? An enterprise that embraces staff improvement programmes such as People-CMM are living their value statements about people. They recognise that holding on to their staff will help them ride out the tsunami of global recession, and will probably make them stronger and healthier. Since People-CMM applies to all levels of the organisation from the CEO downwards, all staff should understand and appreciate the need to retain the best, and look for ways to raise the bar for their other people. It would be naive to think that there will be no casualties, but these should really be kept to a minimum, and not viewed as pure cost cutting exercises. And surely the way to improve other parts of the organisation is to start with a mature and motivated workforce, who understand the need for change and have the understanding, ability, temperament, constitution, and enthusiasm to embrace that change? Maybe then, running a CMMI programme, or any other improvement initiative, would be a bit easier and really begin to realise the return on investment that we all believe they are capable of.

Wednesday 24 June 2009

Managing your Executives

It’s one thing for the executive to choose the right change leader as discussed in yesterday’s blog entry, but change leaders don’t have the same luxury - they have to deal with what they’ve got and try to make the best of it. 

If you have an enlightened management team, with an inspired leader there’s probably not much point in reading any further. I’ve been fortunate enough to be in this position, and, goodness, it makes a hard job so much easier and fulfilling.

But the trouble is there are many more executives out there who simply don’t get it. Sometimes it’s because they aren’t process oriented. It may be that they view process and quality activities as necessary evils but far less important than the real money making programmes within the enterprise. And sometimes it’s really because they genuinely don’t understand how change works and how to manage something so intangible.

The trouble is, that whatever the underlying cause of the issue with your executives, it’s down to you to fix the problem and it really must be one of your highest priorities. It’s going to take a lot of diplomacy, political manoeuvring, personality, patience and tenacity. Be prepared for tantrums, threats, personal abuse, circular arguments and discussions, and to repeat yourself persistently. But if you can hang in there, the eureka moment, when the message is finally understood, is one of the most satisfying achievements a change agent will encounter. 

Of course there’s still a lot of coaching and hand-holding required over the coming weeks and months, but the hardest job is over. So why is this so difficult? 

Firstly you are dealing with the boss, who will, most likely, naturally assume that they know everything, which is why they are where they are. They will not generally wish to display signs of weakness or ignorance; especially not to you, and definitely not in front of their management team. This requires you to take a tactful and humble approach, preferably in a one on one environment, where face can be saved in the case of any misunderstandings. Never accuse the executive of anything - especially of failing to understand their responsibilities or failing to demonstrate leadership. Don’t make the mistake of confusing the “leadership team” with the leader as the leader will usually see this as a personal attack.

Secondly, executives are used to dealing with information in their own domain, usually financial data, and they are used to asking questions for which they get answers they can understand. In an alien domain the executive may become uncomfortable because the questions they are used to asking may no longer be so relevant or useful, and the answers given may not help them understand. 

You need to work with the executives to help them understand the sorts of question to be asking and how to analyse the answers. This is a tricky dichotomy because you are the person who is generally going to be in the firing line. You need to step backwards and take yourself out of the picture but put yourself into the position of the executive. Encourage them to ask the questions you would ask if you were sitting where they are. Help them with the pointers they should be listening for. 

I believe that a number of change programmes fail because the change leader presents the executive team with what he or she wishes them to see, knowing full well that they don’t really understand what they need to be asking. This self-serving view of a project will only work for a short time, as executives become frustrated at seeing the same data each month without any real idea of where things are going.

To build a successful and mutually beneficial relationship with your executives you need to start educating them from day zero. Hard facts, humility, perseverance, coupled with your own knowledge of individual’s reactions to change should stand you in good stead.


Tuesday 23 June 2009

Getting the Right Change Leaders

It’s not easy leading and managing Change Programmes. In fact it’s bloody hard, because ultimately you need to aim to please all of the people all of the time. An executive who initiates and sponsors a change programme needs to look very carefully at the person they choose as their key change agent - selecting the wrong individual will doom the programme from its outset.

In software process improvement initiatives, especially in an organisation which is relatively new to the experience, an executive will often look to one of two places to find their change leader. The first is an experienced and successful technical project or programme manager. The second is the quality manager, because process improvement is considered to be a sort of quality thing. Whilst individuals in these types of role may succeed as change managers, the selection process should really be more thorough because neither of these roles naturally leads to a change management role.

Let’s look at the quality manager first of all. What I call “old school” quality managers have often moved through the ranks over a number of years until they have exhausted all potential opportunities and their experience and seniority makes them ideal candidates to run the quality team (or in some cases become the quality team). 

Quality in such organisations tends to be oriented towards compliance to standards and procedures, and highly focused on checklist based audits. Projects tolerate the quality activities, by and large, because they realise there is no escape, but they make no secret of the fact that the quality activities are a waste of their time and effort and add no value to the real work of the organisation. In this environment, adding change management to the quality manager’s responsibilities is a recipe for disaster because the key change agent is either unable or unwilling to change either themselves or their behaviour. 

The successful technical project manager is likely to perform best within their own project environment, where they have a large element of autonomy, power and control, and live in the world of the tangible. Good project managers who keep their eyes on all the balls they are juggling will often succeed, especially in a relatively stable and competent organisational environment, with good controls and balances, and senior staff who support their project managers. These project managers will often still succeed if small elements of the project or the environment destabilise, but may become vulnerable when the destabilisation is of greater magnitude. These managers are also unlikely to make the transition to become good change managers, where destabilisation is the project norm and where the intangible is the order of the day.

I believe that the best change managers are those individuals who are difficult to put into pigeon holes. They have a good understanding of project and quality management principles, they are great communicators and are personable and approachable, they have a passion and an indefatigable belief in what they are trying to achieve on behalf of the organisation. Critically, these people are able to look at their own behaviours and adapt them as necessary, they are prepared to accept when they are wrong or when they make mistakes and will learn from the experience. Above all, their enthusiasm is infectious, their attention to detail is meticulous, and they genuinely care about the impact of their work on their colleagues. With these types of change agent at the helm, the organisation will find it difficult to resist them.


Sunday 21 June 2009

Thoughts on Process Ownership

Received wisdom tells us that the role of the Process Owner is vital in any organisation, and that processes without senior management ownership will fail. Although I understand where this idea is coming from, I have some major concerns about the way that many organisations implement it.

In my experience many organisations tend to allocate process owners on an almost random basis, fail to inform them of their real roles and responsibilities, occasionally empower them with the potential to do significant damage to an organisation's process management and improvement activities, and fail to realistically monitor and measure process owners in the execution of their duties.

Before we go into details about the problems observed above, let's step backwards and think about what we mean when we talk about process owners. Traditionally the process owner is a senior manager who acts as a sponsor with respect to the process. He or she :-

  • is expected to work with the process improvement group or SEPG to ensure that appropriate process management activities are undertaken to maintain the integrity and effectiveness of the process
  • should have a good understanding of the process in question to be able to advise, coach and mentor on its usage
  • liaises with other process owners to ensure consistency across dependent processes

But the reality is often very different.

Some process owner take their roles very seriously, sometimes to the detriment of the organisation. Cases in mind are where no changes may be made to the process without the express permission of the process owner, who because of their seniority is never available to discuss changes or improvements. Similarly, these individuals take sole responsibility for education and training activities, again leading to considerable time delays in the the dispersal of the required information.

Other process owners are so far removed from the process that they are totally ineffective. Consider a senior executive owning the Software Configuration Management process but who has a background in HR. Or the Application Development Lifecycle process owner who has not been directly involved in development for 25 years.

Rather than insist on process ownership, I prefer the idea of Process Custodianship. In this environment, a group of practitioners is assigned custodianship of the process rather than direct ownership. This group should comprise of subject matter experts, process specialists, and practitioners. Time and budget is made available for these groups as part of the process management function. A senior manager is assigned to the group as a sponsor who has the responsibility for oversight of the group to ensure that they are doing their job, but who is a facilitator rather than a authority. The group itself elects a chair to act as a spokesman, liaison officer, and representative on necessary governance boards. This model provides continuity in the event of staff changes, allows staff with direct process knowledge and understanding to drive the process management activities, and ensures that multiple points of contact are in place to support the organisational requirements with respect to that process area.

As with any role, there should be a clearly defined, documented and communicated set of roles and responsibilities set out for the Process Custodian team and its members. These need to be consistent across all process groups perhaps though a charter. Measures should be put in place to monitor the activities of the team, and these measures reported at appropriate governance meetings and reviews, such as Steering Group meetings. Senior executives must be held accountable for groups they have responsibility for, and should report progress at executive operational level reviews.

Finally there needs to be a mechanism to ensure business continuity so that individuals are replaced as and when necessary, either because of attrition, or simply because staff are no longer in a position to effectively carry out their responsibilities.

This relatively simple change reduces much of the risk associated with single point of contact process ownership, allows practitioners to influence the processes they are expected to follow, and should better help to keep processes effective and under control.


Friday 19 June 2009

When is a project not a project?

I'm regularly perplexed by the lack of precision of language used in the IT industry in general, and particularly in software development and maintenance. I have no doubt that this will be a recurring thread as this blog matures. One example that causes me grief is the use of the term "quality assurance" as a synonym for testing. At this year's SEPG conference we saw a resurgence of another old favourite - the 'P' word - being abused. I'd like to think that we generally understand what a "project" is, and whilst I quite like the definition from the PMBOK, namely "a temporary endeavour undertaken to create a unique product, service or result", I prefer the ISO 9000:2000 definition which adds some useful clarity - "unique process consisting of a set of co-ordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements, including the constraints of time, cost and resources". There's another definition of project from the CMMI, which goes "in the CMMI Product Suite, a managed set of interrelated resources which delivers one or more products to a customer or end user. A project has a definite beginning and end and typically operates according to a plan. Such a plan is frequently documented and specifies the project to be delivered or implemented, the resources and funds to be used, the work done, and a schedule for doing the work. A project can be composed of projects". CMMI for Services by necessity uses the term project in order to align with the common core process areas across the CMMI Product Suite. So Project Planning and Project Monitoring and Control feature as key Level 2 process areas. By its own admission the SEI recognises that this may (and already is) causing confusion for service oriented organisations who don't run projects, but manage services. The advice from the SEI currently is that, in the CMMI for Services world, the term "project" can be taken to mean work or tasks, or pretty much whatever it is that you do that isn't running projects...the term is a bit woolly! Over the years I have had enough trouble with the term project when dealing with Application Maintenance and Support functions, who quite clearly tend not to run projects. The usual comment, especially when CMMI is mentioned is, "this doesn't apply to us - we don't run projects...". It seems that now we are going to unleash the misuse of the word project in a whole new arena, and as usual it's the process people who will have to deal with the fall out.

Thursday 18 June 2009

SEPG Conference - Multi-model Synergies

Over the past few years there's been a growing recognition that the use of multiple reference models provides organisations with a much broader perspective than using a single model such as CMMI-Dev. In Europe this started in the early days of SW-CMM as a result of many European organisations already working to the then ISO 9000-1994 Quality standard. The synergies between ISO 9000 and SW-CMM / CMMI have been extensively documented, as have synergies between Six Sigma and CMMI, especially with regard to higher maturity. As the costs of formal CMMI accreditation continue to rise, there is an even greater opportunity for organisations to mix and match their models to obtain better results in their improvement efforts and translate these into genuine benefits for their operational activities. At this year's conference sessions around this topic looked at mixing CMMI-Dev and CMMI-Acq; CMMI for Services and ITIL; CMMI, People CMM, and EFQM; as well as CMMI-Dev and Agile. In future I'd like to see this extended to areas like SPICE, ISO 15504, and BPM. I'm also a firm believer in looking for models taken from outside of the IT industry. The richness of all these models, including the usual subjects mentioned above, enables us to focus on areas and disciplines previously considered out of scope of the improvement domain. This can only be a good thing.

Tuesday 16 June 2009

SEPG Europe 2009 - Themes

Most conferences have a theme which provides a focus for the proceedings, and prospective presenters are invited to submit proposals aligned to that theme. This year the SEPG Europe 2009 theme was "The Next Generation of Process". My initial reaction to this was one of some surprise: many commentators and practitioners would argue that we've still not mastered the first generation of process so perhaps this would be a case of running before walking (but more on that another time!). I wasn't entirely surprised to see that there were only a few sessions which were really aligned to the focus theme. However, my experience is that conferences tend to generate their own sub-themes as presenters independently or collaboratively hone in on certain common topics. This year was no exception, and in my opinion there were several predominate sub-themes in evidence.
  • People and culture
  • Multi-model synergies
  • CMMI and Agility
  • CMMI for Services
Of course some of these themes are recurrent at conference, but this year I felt that there was an energy pertaining to the first two items on my list in particular. CMMI for Services was clearly on the agenda as the latest offering from the CMMI product team and the SEI was on a hard sell mission. The debate about CMMI and Agility will no doubt continue ad nauseam, primarily because so many of the arguments are generated by people who nothing about either subject or who cannot understand their counterpart's viewpoint. I'd rather not get involved in the discussion - life's too short! So the key sub-themes are around People and Multiple models, both of which are concepts I've been advocating for the past few years. Next blog entries will speak to these in more detail...

Monday 15 June 2009

SEPG Europe 2009 - Initial Reflections

I spent last week in Prague, attending the 14th European SEPG Conference. These conferences are an excellent opportunity for IT process people at all levels of competancy to be able to share ideas and concepts, find out what's going on in the world of process improvement, and do all the other fun things that people do at conferences. My primary purpose for attending was as a speaker at the event, to look for consulting opportunities, and to raise the profile of both myself and my business. As a bonus, there were a number of exceptional speakers due to attend, and I was looking forward to a learning experience. I've been associated with the SEPG conferences in Europe for the past seven years as a reviewer for submitted abstracts and I attended the 2005 event in London so I had some notions of what to expect. However, as the start of the conference drew closer I was beginning to have some doubts about this year. The early bird registration was extended right up until the conference start, and various incentives were being offered, clearly in an attemp to try and boost numbers. Previously the conference has attracted 500 or more delegates. The financial crisis certainly seems to have had an impact on the SPI community. My guess is that this years' total attendence was around 200 over 4 days, but probably peaking much lower than that. Given the overall cost of attendence, I have to sadly reflect that this year's conference was not a good investment, at least for me, and I know this view is shared by some of my colleagues in similar positions. It's not helped by the fact the presenters have to pay (albeit at reduced rates) to attend the conference. To put the boot in further, the conference rate for the hotel was almost twice what I could have obtained if I'd booked on-line independently. More fool me for not checking this first, but I'll know better next time - if there is a next time! More to follow on conference specifics...