GovernIT » Quality Assurance

3 Ways Your Process Improvement Initiatives Can Go Wrong

Sridhar — Wed, 22 Dec 2010 19:31:32 +0000

Your Process Improvement initiative or even a simple process definition has failed. You have taken the necessary steps to see that you are not defining a stupid process and provided guidance on how to define processes. It still failed, sob. Once you have gotten over it, read on.

The 3 most common ways you can fail at Process improvement, that I have personally seen are:

1. Blind Adherence to Frameworks

Process frameworks such as CMMI or SPICE are intended as guiding principles to help

you develop processes that, in turn, help you achieve your business goals. Trying to incorporate each and every aspect of a framework without regards to its applicability in your organization can result in bloated processes that no one can or will follow.

Usually, process improvement begins with Gap Analysis of existing processes against the chosen Process Framework. This is where you can take a wrong turn.

Understand the intent behind the Framework when performing the Gap Analysis. One tried-and-trusted practice is to extract the objectives from the process (in CMMI, these are neatly defined in the Specific Goals) and then use them to see if the goals are met by your current processes.

2. Committees

Yes, Practitioner-led process improvement is the way to go. But that doesn’t mean that you try to get “representation from every section” of people into your process definition team! After a certain threshold, an increase in the number of people is only going to hold you back.

From my experience, the magic range is 3-5, but that may vary if you are in a business process improvement scenario. One symptom of a dysfunctional large team is endless bickering over every word and its intent when drafting the process – in one case, there was a 2-hour discussion on using “measurements” vs “Metrics”!

3. Endless Alternates

This can be a standalone issue or an offshoot of the first two. I have seen teams debate over different scenarios which they might face, when the probability of these scenarios occurring is really small! Usually, there are a few critical paths where the teams might need direction and then there is a catch-all section (which is usually an escalation path for more guidance).

This situation arises when

People don’t trust themselves and others to do the right thing and/or
Managers are not very forgiving when their teams take decisions using judgement and then mistakes happen. Only a learning environment is a growing environment and without it, you cannot help people become mature. Without mature people, you cannot have a high-maturity organization!

Yes, there are more ways in which you may fail, but I’ll follow my own advice and stop from listing out all other scenarios . That, however, does not prevent you from adding your own experiences in the comments. They may be a bigger cause of failure!

Do share in your experiences in process improvement and of course, subscribe to the blog.

Practitioner-led Process Improvement:For “sticky” processes

Sridhar — Thu, 16 Dec 2010 21:38:29 +0000

In previous posts, we have seen how to use the Six Honest Serving Men to define the elements of a process, while keeping it from becoming stupid. In the latter, one of the items we briefly touched upon was to make Process definition “Practitioner-led.” Today, we’ll dive into this inclusive way a little more.

[In industry jargon, Practitioners are the people who perform the tasks indicated by the process - software development teams, for example.]

Why Practitioners have to participate in process definition? Some common objections encountered are:

They are not experts in process development
It is not in their job description or they have other work to do
If they do it, why do we need process specialists?

While these are valid to some extent, lack of ownership of the very people who have to use the process is the single biggest reason for failure of processes. This isolationist, ivory-tower approach results in processes that are out of touch with reality, do not take into account established practices and a general feeling of “process policing” among the development and project management community.

Most people that I encounter, including die-hard Agile champions, agree that some agreement on how things will be done is necessary when such activities involve many people. A process is such an agreement. When we trust people to develop mission-critical software for us, it is foolish to think that they cannot define an effective way of doing things!

Are you convinced yet? If yes, let us move on and see how we can implement this effective means of defining processes. The title points below are meaningful enough without me trying to elaborate on them.

Assemble the right team
Identifying process requirements
Identifying current practices
Defining the process
Piloting
Implementing

Assembling the right team is probably the most important part of this whole exercise. You need to bring in people of all kinds. You need process champions, critics as well as technical experts.

What about you? You are there to assist them in wording the process, doing the documentation work, creating simple flows and probably to see that process requirements are defined right.

One other thing I have found helpful is to incorporate as many current practices, documents and tools as possible. To do this, you as the process specialist have to talk to people, do the research and generally make it easy for the team to define the process.

A good Practitioner-led process improvement initiative reduces the inertia and encourages others to follow what has been defined by their fellow clan members.

In fact, many guidelines from the SEI show that the use of practitioner-led process improvement journeys lead to sustained improvements in appraisal ratings as well as in achieving project maturity.

Share with me your stories, criticisms and your experiences in the comments below.

Process – How to develop one that is not stupid

Sridhar — Sun, 05 Dec 2010 06:46:52 +0000

“Process” in the software development world has been characterized with colorful adjectives. I am here to defend it.

What is about the word “Process” that makes people run fro cover? I see a lot of people who turn to Agile, not because they realize its worth, but because they think it frees them to do what they want, how they want. Agile is discipline, folks and you can do it only if you have the maturity to handle that discipline on your own.

Here, I am defending a process that is simple, provides clear roles and responsibilities, is changed appropriately when needed and most importantly, the one that is applied well. I am not defending a rule book written in circa 1800.

I hear you. You are saying that process as I defined is not the one that you see everyday in countless organizations. Right. But I ask you, is that the fault of the process? Did it slowly creep into your organizations? No, we wrote it. We are the ones implementing it. We are the ones hiding behind it.

A process is nothing but a set of steps we write to accomplish a particular task. We write it down so that others may follow the path easily and when we have thousands of people doing the same task, we don’t want everyone to do it differently, unless circumstances require.

These exceptional circumstances occur more frequently in the SW dev world than in other places like manufacturing (that is why concepts in manufacturing don’t lend themselves well to SW, but that is for another day).

So what do we need? We should define processes that result in desired outcomes. We need to create awareness that a process needs to be adopted and adapted as the situation changes to make it effective. Let us look at some things that we can do to define a process that is not stupid.

1. Define the Why

There is a better chance that people will follow the process if it is clear why and the why is “reasonable”

For example, for software configuration management, the “why” is to ensure that code is checked-in frequently (to avoid crashes or overwrites), follow naming conventions (to easily determine what the file does/belongs by looking at the file name), follow the structure (to modularize code) etc.

2. Minimize Forms

If people have to fill out forms for every step of the process, be sure that will never be followed. While some amount of paperwork is necessary, it should not detract from actually performing the task. The biggest mistake I see people make is trying to get a lot of information filled out, even when that information is not required or may not be used. There are two reasons for this:

Incorrect interpretation of process frameworks like CMMI or ISO
When something goes wrong, find out where and why. The failure points are minimal, but to have some documentation for those failure points

3. Practitioner-led

Every activity, whether defined by a process or not, has to be done by someone. Why not ask those people to define the process? It is well-recognized that when a team of practitioners own the process, the adoption is much higher. Do we want someone sitting in an ivory tower to tell me what to do? Nah.

4. Automate

Look for ways to automate as much of the process as possible. If you are capturing information, don’t provide forms for people to capture data. Use tools or write scripts to capture and present that information.

5. Teach people to change it

Make it clear that the process is not sacred. When people start to feel it is not working or not comfortable any longer, change it. Fiercely implement a culture where people can voice their concerns about something that is not working for them.

6. Never talk about the stick

We all know about the “Carrot and Stick”. In this case, however, never ever use the stick. Are we cattle to be driven ahead? Lead us and we’ll follow. What this means is don’t penalize when someone does not follow it. It could be that the process is not usable under stressful situations or the leadership does not care about it. If the manager asks the team to forget about the process just for this urgent request, it shows that the manager does not think the process is useful!

If we follow some of the common-sense principles, any process can be made simple and usable. Otherwise, we will end up defining a complex “Agile” process!

Do you still think Process is stupid? What would you do to help people follow a method that can help them be productive, yet have fun?

Metrics Definition – Gaining Agreement from your Stakeholders – Part 1

Sridhar — Thu, 18 Nov 2010 03:00:00 +0000

The most common problem in a Metrics program is defining the "why" for each of the metrics. The second most common problem is getting agreement from all stakeholders on the "what-when-where-which-how" parts of the definition. In this 2-part series, we will look at what you can do to make this easier for your stakeholders to understand what to expect from your metrics approach.

Defining a Metrics catalog
Creating standard data collection, reporting and presentation templates

In this part, let us take a look creating a Metrics Catalog to hold the metrics definitions and communicate in an unambiguous way on what the metrics mean and how they will be reported.

Part 2 will look at creating standard templates for the execution, once the metrics are agreed. However, it is often best to gain agreement on the templates along with the definition, since any major change in the templates can cause changes in the mechanics of the definitions.

A Metrics Catalog

A metrics catalog is simply a table with information on the collection and evaluation of Metrics. It can be a spreadsheet with columns for the different parts of the Metric. A set of columns given below can be used as a starting list

Name: Define the metric name. Be careful to make the names consistent (calling one "defect density" and the as "other % reduction in defects across testing cycles " doesn’t help!)

Inputs: What are the raw inputs that you will be using for this metric

Tip: A Metric is always a relationship between two entities")

Formula: How will be the metric be computed? Describe the relationship in mathematical terms.

Objective: Describe the intent of this metric – how will you interpret the values of this metric

Tip: Use general descriptors for the interpretation – don’t say, for example, "if the value is <99%, it means we are not doing good." Rather, say "the values for this metric will help us determine how our customers perceive our services")

Data Source: Identify where the inputs will come from and if possible, who is responsible to collect this information. This is one of the fields where the more detailed the information is, the easier it is for everybody later.

Unit of Measure: Describe the units for the values of the Metric. Is it % or defects/Lines of Code or just a number. Be very careful with this as this will impact how you will report the metrics in a visual form

Target Values: Describe the acceptable range of values for the metric

Tip: Be cautious with this, if you don’t have historical data. Leave it blank for the first few periods and then fill it in with the best performance of the actual values. Once you have sufficient samples, you can devise a proper target value).

Tip 2: Be extra cautious with “industry benchmarks”. Unless they are really similar, don’t thrust them on your organization or you will encounter lot of resistance to the metrics initiative)

Frequency of collection: Describe how often will you collect the inputs, compute and report the metric

Tip: As much as possible, try to keep the frequency constant for all the metrics in the Catalog. Think Collection=Reporting -just because data is available weekly, it doesn’t mean you need to collect and report it weekly.)

Area: Describe which area of the product/service lifecycle does this metric belong to.

Type of metric: List if it is a leading metric or lagging one

PMO Series: Quality Management

Sridhar — Wed, 06 Jan 2010 12:44:10 +0000

The first part of this series provided an overview of the PMO, types of PMOs and typical functions.

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

This post looks at the Quality Management/Assurance responsibilities of the PMO.

Quality Management is a less-emphasized function of the PMO. In large IT organizations, primary Quality guidance is provided by a centralized Quality function and actual implementation guidance by the PMO. For smaller IT organizations, the PMO.

However, it is important that the PMO incorporate the Quality Management aspects into its guidance and governance systems, since process-orientation can bring in discipline and streamline all activities in the Programs/projects.

The key responsibilities of a PMO for Quality Management include:

Setting up quality standards if none exists or tailoring organizational standards
Provide guidance on defining acceptance criteria to measure successful completion of the project
Provide guidance on setting up Program and project specific metrics for monitoring, tracking progress and quality
Schedule, conduct and review Program and project audits to ensure they are following the guidance provided by the PMO.
These aspects can be detailed out in a Quality Management Plan. A well-structured QM Plan can help the Program/Project adhere to the accepted practices in their projects. In addition, the PMO may also provide
Quality management support to projects through a dedicated team of people.

A typical QM Plan will have the following Table of contents (sections):

Reference to organizational processes (if available)
List and reference to any adaptations to the organizational processes, templates and checklists
List and reference to program/project specific processes, templates and checklists
List and reference to all standards/guidelines (including technical, industry-specific regulations, domain etc)
Release Reviews performed by the Quality function before any customer/production release
Program/Project specific metrics and tolerances
Work product reviews that will be performed by people in the Quality function
Tools and techniques used for Quality activities
Defect prevention, causal analysis activities and techniques
Reports and Dashboards
Frequency and timing of project reviews and audits by the Quality function

If you have implemented the Quality Management function as part of the PMO, we would love to hear your experiences and challenges.