For more than 50 years, Auerbach Publications has been printing cutting-edge books on all topics IT.

Read archived articles or become a new subscriber to IT Today, a free newsletter.

This free newsetter offers strategies and insight to managers and hackers alike. Become a new subscriber today.


Partners




Contact

Interested in submitting an article? Want to comment about an article?

Contact John Wyzalek editor of IT Performance Improvement.

 

Process Improvement

Steve Neuendorf

Process improvement: The name belies its nature. Many people see it as the way to build products better, faster, and cheaper. In truth, there are many ways to be better, faster, and cheaper at whatever you are doing, and process improvement is only one of them. In addition, there are more aspects to process improvement besides just producing higher quality, quickly and efficiently. It is also important that we improve processes to make them more resilient. We will want to repeat and be able to build upon our success. Since software engineering is a labor-intensive process, we want to insure team stability when considering the changes that go along with improvement. We also need to include learning as a key element of process improvement to assure we can reliably repeat our successes and not repeat our mistakes. We also must consider what I will call "externalities" in improving our processes. We want to be better, faster and cheaper in ways that do not just pass quality problems or time considerations or costs on to others, either downstream along with our products or among others in our organization or in our business or community.

So we will look at process improvement is the most reliable because first it works on people and only then does it work on things like processes, procedures and products. First, you must understand how good, fast, and cheap a process is and why it is that way. You also need to develop an understanding of why alterations of a process or adoption of changes and altogether different processes may be better, faster, or cheaper. With this understanding, you can then implement the changes that will result in improved performance.

To paraphrase Dr. Deming, process improvement is not something you talk about, it is something you do. For process improvement in software engineering, it is very much talked about, but in the end a lot less is actually done. The inertia lies in "don't mess with success" and "we are way too busy to make any changes now." As an industry, there has been much formalization of process improvement ranging from abstractions like process maturity, to standardization of tools and methods, like Business Process Management (BPM) and to actual prescriptive processes, like Agile or ITIL (Information Technology Infrastructure Library). Of course, with most practitioners, success is generally defined as "not failing (or at least not too much) and no real measures exist that give real indication of results or the opportunity to improve results. The other generalization is that with improvement, you will accomplish more with less, so you could be less busy to do the same thing, or be just as busy but accomplishing more. What is worse though, far too much of what is done is done for process improvement is just plain wrong—the process is not better, and process improvement itself is besmirched. Let us look at process improvement, and see if there is a way to effectively and consistently improve software engineering processes.

Process improvement is part of the much bigger discipline of change management. This chapter will focus on the process issues and change issues associated with process improvement. Your success in effectively improving processes will depend much more on the resolution of people and commitment issues. People tend to naturally resist change. Change poses organizational risk, but it is perceived by many or most people as personal risk, where they may not like their changed job or be able to perform it as well as what they currently do, or maybe they fear losing their position. On the whole, people issues are the greatest risk to achieving effective process improvement. It is even common for people issues to be represented as commitment, process or measurement issues as a way to slow or stop the changes and their inherent risks and threats. After people issues, any organization undertaking process improvement must address commitment issues. There seems to be an irony that arises when asking for time and resources to end up saving time and resources, or even if trying to get commitment for an improvement that ultimately will end up in costing more or increasing time in one area while the benefit is realized elsewhere. And of course, one of the biggest commitment challenges is to obtain the commitment to abandon what has been done in the past. Resolving and managing people and commitment issues are beyond the scope of this chapter, but they must be resolved for the process of process improvement and measurement to work.

Two things need to be understood: the process or process improvement, and improvement, or the recognizable change in conditions and results. It may sound trite, but the number of different definitions and their imprecision lead to a great deal of confusion and misunderstanding about doing and achieving process improvement.

Process Improvement Defined

The operating definition of process I will use is "the definition of the way in which something is intended to be done." Any process has an accomplishment objective: what is to be done. A process must describe how to go about achieving (procedure) its objective (product), as well as identifying means (attributes) for execution of the process. For convenience, I will use product to mean a tangible object or a service or a mix of both. Since this definition could apply to anything, for software engineering, our process is assumed to have a sufficiently formal definition such that it can be nearly repeated. A prerequisite for process improvement is to have a comprehensive process definition. But that is not quite as simple as it may sound. There are many variations of process depending on what is done and how it is done, and even by whom it is done. Table 1 shows several variations of process based on the products produced, the process used, and the attributes.

Table 1. Characteristics of a Process

For products, the distinction is made as to how much influence the producer has on the product. There are two aspects for products that are of interest to our analysis: form and function. The consumer of the product generally controls the function of the product, either by specification prior to production or by the decision to consume an available product after it has been produced. The producer has control over the form of the product, at least to the extent which form affects the final product function. The next aspect of process is the procedure, which is generally the collection of events involved in the production of the product and the sequence in which they are performed. To a large extent, these are controlled by the producer, though the consumer may exert some influence over what those events are and when they are performed. For example, a software product customer may require 100% testing (and whatever that may mean) of a product before delivery. The product itself may also inherently prescribe some of the events and their sequence (precedence), but the producer has a large influence over what the events are and when they are performed. The procedure may be fixed, such as in having a machine or set of machines that do the same task using the same sequence each time, or it may be variable in that the problem implies or defines the exact steps and sequence and the process only offers guidelines and checkpoints. The final dimension of a process is what is defined as attributes. Our operating definition of attributes is any element of the process that:

  1. Influences the result of a measure or metric
  2. Can be controlled or significantly influenced.

Therefore, that introduces the need for an operating definition of measure and metric. We will define a metric as the product of one or more measures that provides useful information. We will establish an operating definition of measure as being some information about something, usually quantitative, but not always. For example, the measure of the functional size of a software product may be its Function Point count. Another example of a measure may be the number of hour recorded to develop that software product. In addition, we may also have a measure of how much the effort to develop that same software product cost. Given those three measures, we can identify the useful metrics of Function Points (FP) per hour, or per dollar or total cost, etc.

It is obvious the family of attributes included hundreds of items, so it is useful to have a classification approach. There are several well recognized and adopted approaches and I will just pick one because it is illustrative and it happen to fall into the order that I think matches the importance of the significance of each category in software engineering. PETT—or People, Environment, Tools and Techniques—is my chosen schema. A generalization of attributes is they are the assignable causes of variation in metrics. As such, it is also important to make the distinction between the common causes of variation and the special causes of variation. Common causes of variation are those conditions that affect performance consistently across several instances of the process. For example, the skill level of a team will influence each project where that team is assigned. Later we will examine the distinction between process and project, but for how, we can note that a project is an instance of process. Any improvement in process will be realized across any instance of project where that improved process is employed. However, there may be any number of attributes, by our definition that influence the metrics of a single project, peculiar that project, or perhaps randomly distributed across the total of projects. For example, a hardware problem would only affect those projects where that hardware was involved. Or perhaps a labor problem would only affect those projects in process when that labor problem occurred. Contrast that with a common cause of variation example where a particular class improved the proficiency of all of the attendees, and that improvement was realized in every project where those attendees were a part of the team.

In addition, there is the question of what about those items meeting our first part of the attribute definition (influences) but not the second part (control or influence). Those elements fall into the category of special causes of variation or more generally risks. Those fall more into the role of project management than they fit into process improvement.

Contrast process with project. A process is the intended way, while a project is the application of resources to that process. Since projects are tangible, the only way we can "measure" a process is to measure projects and use the information to make inferences about the process. As a measurement tool, process is the category to which we assign the common causes of variation, while projects are affected by both common and special causes of variation. Working on special causes is (or should be) risk management, problem identification and correction (firefighting), while working on common causes is process improvement. To go one-step further, using special cause tools and methods on common causes and vice versa is called meddling. Meddling invariably causes "fires" and firefighting does not improve processes.

Three characteristics or metrics describe any process:

  1. Efficiency (E)
  2. Cycle-time
  3. Quality (Q)

Efficiency (E) is the relationship of use of resources to accomplished results. Sometimes people will use "productivity" interchangeably with efficiency, and they are half-right. Later we will look at another definition of productivity and see its importance in overall process improvement.

Cycle-time (T) is the "design speed" of the process. Obviously, schedule is a very important aspect of projects as is duration and wait time. All are measures of how long. All are answers to "how long" questions, but all but cycle time include elements of variations in pace (the rate of doing work) and delay and idle time. Cycle-time applies to processes and makes assumptions about pace, delay or wait, and is generally constant for a process and may be adjusted for size or other considerations when applied to a particular instance of the process. The other time measures generally refer to a project and can be significantly influenced by factors that are not directly associated with the process being applied.

Finally, every process has a Quality (Q) characteristic. There are many aspects of quality associated with the product, the procedure and the attributes, and all play significantly in succeeding in software engineering, but for process improvement we will tend to focus on product defects and defect density. Definition of what is a defect may vary from organization to organization, but if it is consistent across measured instances of a process, it can be used to quantify the quality aspect of a given process. It seems counterintuitive, but the same process will always produce nearly the same number of defects in its outputs.

We always knowingly laugh when someone says, "good, fast, cheap—pick two." Actually, this is more insight than humor. For any process, there is a function:

ƒ(E,T,Q) = Constant K.

For better, and faster, and cheaper, you need a different process (change K).

In looking at process, we must also consider sequence. Sequence is the order in which things are done. There are two types of sequence: required (precedence) and discretionary. Required sequence is an order that must be followed. For example, putting on a second coat of paint requires that the first coat already be applied and cured. In software development, it is best to start coding after the requirements are gathered. Discretionary sequence is the order in which it is decided that something will be done. The required sequence must be observed. In practice, precedence and means availability control the process execution sequence decision. Later we will discuss continuous improvement and innovation. Note here that some of the greatest opportunity for process improvement comes from innovation regarding the sequence of a project. For example, agile methods probably make the greatest changes over traditional development in the area of sequence than in any other aspect, and with usually great results.

After sequence, comes the attributes, as mentioned before, which will carry out the steps or tasks. We talk about a project being "the application of resources to a process to produce a result." We usually think of resources as labor, time and money, but for understanding the process, we must consider other resources, such as tools, techniques, technology and factors particular to "resources" such as the skill and experience of the team members. Therefore, we define the attributes to include all aspects we need to consider to understand and improve processes. It is helpful to consider the means in categories such as management, technology, teams (or people), tools, techniques, and environment.

Practically, an organization must consider all of its processes collectively. As defined so far, a process is a sequence and a set of attributes. By this definition, each organization would have an infinite number of processes (possible combinations of E, T, and Q). This introduces two more dimensions of process we must address: the capability and capacity. Each combination of E, Q and T possible defines a capability. The current ability of the organization to execute a capability defines capacity. This is not as complicated as it may sound. For example, one of the attributes defined as "Red Team" is comprised of members with certain experience and knowledge. Red Team projects are done faster, better and cheaper than "Blue" or "Green" team projects. Red Team performance levels are a "capability." However, within the organization there are only enough members qualified to form Red Teams, so there is a capacity associated with the Red Team capability.

There are two categories of improvement: continuous improvement and innovation. Continuous improvement of processes is the systematic upgrading of lower capability attributes to give higher capacity at a higher capability. To use the prior example, continuous improvement of team capability would be providing training to Blue and Green Team members so more Red Teams can be formed at a time. Innovation is the introduction of new capability. Again, using the prior example, innovation would be training everyone in a new technique. Everyone, even the Red Team would have a greater capability to execute the new technique. The distinction between the two types of improvement is not so clear, but the important point for organizations is that innovation usually introduces learning curve dynamics and a risk of failure to a greater extent than continuous improvement.

Let us make another distinction between strategy and process improvement. Again using our example, if we were to just adopt a strategy to "let go" Green and Blue team members and replace them with Red Team qualified candidates (at similar cost) we would rightly expect better values of performance (E and Q and T). The reality is that Red Team caliber candidates are expensive and much harder to find and keep. On the other hand, effective process improvement requires understanding the process. That is we need to know what it is that will actually improve a process and by how much. That is, using our team example, we must first figure out the cost of making our Blue and Green team members perform like the Red Team, and then figure out the benefit of improving team performance.

As in anything complex, what is "obvious" is not always true and what is true is not always obvious. Only by improving our understanding of the process can we manage the risk that changes will not result in the desired improvement.◘

Read more IT Performance Improvement

This article is an excerpt from:

The International Function Point Users Group (IFPUG), a nonprofit and member-governed organization, has become the recognized leader in promoting the effective management of application software development and maintenance activities. Edited by IFPUG's Management and Reporting Committee, The IFPUG Guide to IT and Software Measurement brings together 52 leading software measurement experts from 13 different countries who share their insights and expertise. Covering measurement programs, function points in measurement, new technologies, and metrics analysis, the text is useful for IT project managers, process improvement specialists, measurement professionals, and business professionals who need to interact with IT professionals and participate in IT decision-making. It includes coverage of cloud computing, agile development, quantitative project management, process improvement, measurement as a tool in accountability, project ROI measurement, metrics for the CIO, value stream mapping, and benchmarking.

About Steve Neuendorf

Steve Neuendorf is an independent consultant. He has over forty years experience in industrial engineering, measurement, management, education development and teaching, and process improvement with the most recent thirty plus years directly related to software engineering. He also has over twenty years as an independent consultant, working with a wide variety of clients representing many different types of organizations and opportunities. He has worked extensively with, and is currently working with the David Consulting Group as an independent contractor. He worked 14 years as an industrial engineer for, specializing in "white collar" process measurement and improvement, particularly in software engineering. He has also worked for various consulting companies, focusing on Function Point and process improvement activities. He also has recently been a principal in a global project management benchmarking organization, doing analysis, research, and training, significantly for NASA. He has published many books and articles on the subject of process measurement and improvement, including Six Sigma for Project Managers and Project Measurement, both published by Management Concepts. He has a Juris Doctorate from Seattle University School of Law (1989) and an MBA (1984) and BA (1983) degree from University of Puget Sound.