Chapter 2: Beginning the Journey

This chapter is for those individuals who are just beginning a process improvement program. This chapter focuses on defining what a process is and why it is important; gives a brief comparison of improvement models; offers suggestions of where and how to start your program; and discusses some of the problems you can expect to encounter. This chapter should be considered introductory only. For more information, read subsequent chapters that delve into how to write processes and procedures, and how to set up a process improvement program.

What Is a Process?

A process is a series of steps that help to solve a problem. The steps must be defined in such a way as to be unambiguous ” that is, readily understood and capable of being followed in a consistent manner by anyone using the process. Why do we want to do things consistently? Are we promoting turning the workers into robots? No. What focusing on process does for your organization is to reduce redundant work. Why recreate the wheel every time you begin a new project? If you are required to submit a project plan, why not have a procedure that tells you how to write one, plus an example of one that you can copy and paste from? Is that not easier than just wringing your hands and worrying about it, and sweating blood devising a new project plan for your new project? OK ” you may not be a project manager, so you do not like the example about the project plan. Suppose you are a programmer. Does your manager ever ask you how difficult a particular program might be? Does he ever ask you how long it will take you to code each program? Or does he just give you a list of programs assigned to you and tell you when they are due? Do you ever have heartburn over his estimates? Do you ever say anything, or do you just work unpaid overtime because of his unrealistic schedule? Having a process for estimating schedules into which you have input will create a more realistic schedule and help relieve some of the burden on you of having to adhere to something that just does not make sense. Does this scheduling process always work perfectly ? Can you just say, "No, this schedule stinks, so my manager must change it?" Of course not! But it does give you some room for negotiation.

Processes are like recipes. A recipe tells you the ingredients, how to mix the ingredients, what temperature to use, and how long to cook those ingredients . However, it does not teach you the techniques of slicing and dicing, mixing, beating , whipping, blanching, grilling, poaching, etc. And recipes also leave room for some experimentation and modification. Some recipes even give you suggestions on how to make changes to the dish.

A process as used in process improvement is usually defined at a somewhat higher level, with associated procedures supporting the process. The procedures are written in much more detail than the process. Examples follow.

Suppose your organization is focusing on creating a risk management process. This risk process is being developed because the project managers in your organization have been unable to proactively predict troubling issues that end up affecting the delivery of their products to the customer. Perhaps they have delivered late because of high staff turnover and being unable to get enough people with the proper skills on their projects; or the people they get are pulled onto other projects when those projects run into trouble. Another risk may be that the budgets for the projects are usually overrun . So all of the project managers get together and determine a risk management process that they feel will cover all (or at least most) of the risks they encounter. The risk management process they come up with is to:

• Identify the risk

• Analyze the risk

• Categorize the seriousness and probability of the risk

• Mitigate the risk

We can be sure that these managers feel they have done a brilliant job, but what is the problem with this process? It is too general. If I had handed out this process for all of my managers to follow, each manager would have interpreted how to do this process differently. We are trying to find a way to document how we do work in the organization in a consistent way so that everyone will do things somewhat similarly, and so that people can benefit from the good work being done by others.

So now we go back to the managers and say, "Great ” you have a process. How do we do the steps in your process?" Well, that is a different problem. The managers are tasked with devising procedures for how to do what they have written as the steps in the process.

Using our process example, the first item says "Identify the risk." The managers would need to come up with how they identify risks. One of the ways they might do this identification is to start tracking the problems they have in delivering products and then find trends. From the list of trends, they would create a list of the ten most frequently occurring problems on the projects. The procedures would then discuss how to use the information in the list to estimate risks that might occur on another project. The third item in the list of steps in the risk management process says, "Categorize the seriousness and probability of the risk." Maybe your organization defines risks as 1 ” most critical and most likely to occur; 2 ” critical but work may continue; and 3 ” not critical, work may continue, fix this problem during the next phase or release. The managers would need to come up with procedures for how to determine what would put a risk into category 1, 2, or 3.

These scenarios are just simplistic examples used to illustrate process versus procedures.

So why is focusing on process important? Why not focus on the product, or the people, or the technology used? Let me explain.

Writing standards for what a Requirements Specification should look like is a product focus. You are focusing on the template itself. For example, you might want your Requirements Specification to list all of the requirements for the system and categorize them as to whether they are system-level requirements, software requirements, hardware requirements, safety requirements, performance requirements, etc. Great ” this is a good thing to do; but how does anyone know which categories they fit in? This is where a requirements process comes in. It will tell you not only what the Requirements Specification should look like, but also how to write it ” how to fill in the blanks for each paragraph in the specifications. The requirements process would also tell you how to elicit requirements from your stakeholders (e.g., customers, end users, requirements analysts) and how to manage the changes to the requirements. The product focus would then continue on to what a Design Specification should look like, what coding standards should be followed, what test cases should consist of, etc. The process focus would then give guidelines to the people responsible for doing this work on how to do it.

Why not focus on the people? Puhleeeeez! Whenever anything goes wrong on a project, is not the first, visceral reaction to blame the people doing the work? Well, that is highly motivating (not!). We do not want you to think that people are not important ” they are the most important part of any project or any work undertaken. But not everyone can be as brilliant as everyone needs to be every day. It is not like we wake up one day out of 300 days and say, "Yesterday I was just OK. Today I will be brilliant." Focusing on process puts the emphasis on having good processes to follow, not on hiring only brilliant people. Rather than having people work harder, have them work smarter . That is what process does for you.

Why not focus on technology? Have you ever heard the saying "garbage in, garbage out"? Well, that is what just plastering new technology onto an old problem does for you. This author has been paid big bucks for converting existing systems from one language or database to another. There are even tools now that will do that for you (with a lot of work). What do you get? The same system you always had with both the old problems and the new ones. Technology does not provide a quick fix, but it is the one answer that executives are most likely to choose because technology is easily quantifiable and easily budgeted. Look at the dot.com bust. Most of those companies sold quick-fix technologies without any underlying analysis of the problems organizations faced. Most of the dot.coms that operated without this sort of planning are out of business. Technology is our friend ” but it is not the only answer to our problems.

Why focus on process? What personal benefit can you gain from all this work? What is in it for you? Well, the following examples are drawn from personal experience in some of the organizations we have helped along this path .

• Configuration management. One individual had spent hours trying to find the correct version of source code to make a simple change. He was never sure before whether he had the latest copy of the source code. Now, after following procedures for change control, he is reasonably sure that the code he is using to make updates is actually the code used in production. No more searching for hours to find the right program.

• Testing. Prior to this effort, developers handed the system to the testers and told them, "Here ” write a test plan and test this. These are the changes I made." The test people were never quite sure how thorough their testing was, and they spent hours trying to figure out what the actual requirements for the system were. (You test to ensure that the requirements have been met.) Now, with a process for the Requirements Traceability Matrix and the Requirements Specification, the testers spend less time figuring out what to do, and more time actually testing. It has greatly simplified their jobs and greatly improved the testing of the resulting products.

• Planning. Prior to this effort, the organization could not predict the number of projects that needed to be scheduled ahead of time. Now, with the use of the process for devising a Statement of Work and the focus on the Project Planning process area, the organization is aware of the number of projects requested , what their initial requirements are, the approximate number of staff needed, the approximate size and complexity of the project, and how to prioritize the projects. Requests for support have actually been deferred, based on these measures. Time is not wasted on developing systems that will not be used or fixing problems that go away by themselves .

• Communication. There is more communication up and down the chain of command as well as across the organization. For example, the Director of Software Engineering is talking to developers, and in some cases the developers are talking back. This is good. Quality Assurance (QA) is reviewing products and processes across several projects, and seeing the results of these processes and the problems, as well as the differences between the ways project teams perform. QA is also talking to the EPG (the process improvement team) and, in some cases, swaying them to change some decisions made, based on how things are actually working (or not working).

So, is process the only answer? No. Process is part of the answer. Process, when supported by training, enough money, enough skilled people, proper tools, and management commitment, can help your organization.