Introduction to Process Definition and Process Improvement -by Jim D. Hart

Abstract

I have found that, although process and process improvement concepts have been applied in the software development world for some time now (more than twenty years), there are still a lot of misconceptions about what these concepts are really all about. In the early days at the Software Engineering Institute, we taught these concepts in courses such as Software Process Assessment and Software Process Definition. However, by the mid 1990's, we began to see that a growing minority of course attendees already understood these concepts; and as a result, some of the more basic concepts of process and process improvement were dropped from the classroom setting. In the recent revision of the Software Engineering Institute's (SEI) Defining Software Processes Workshop, for example, we decided to make these basic materials part of a pre-read package for future course attendees. A modified version of those materials is presented here for the interested process beginner.

After reading this paper, you should be able to:

compare and contrast process terms commonly used
describe the benefits of focusing on process in improvement
describe process performance and predictability
describe how processes are improved
know when a process is "defined"
show how a defined process supports continuous improvement
state the principles of process change

The following concepts are presented in this paper. Each concept builds on previous concepts, so if you are new to process engineering and process improvement, you may wish to read the materials in the order in which they occur. You can jump directly to the section by clicking on the section title, or you can read the paper from start to finish.

Basic Process Concepts

Process
Software Process
Activity
Task
Procedure
Method

Managing Processes

Process Management
Process Focus
Process Performance
Predicting Future Performance

Improving Processes

Process Improvement
Continuous Process Improvement
Process Maturity
Process vs. Process Maturity
Process Wheel
Process Maturity Standards
Quality Leverage Points
People Implications
Technology Implications

Defining Processes

Defined Process
Process Description
Process Model
Linking Process Models to the Process Wheel

Managing Change

Principles of Process Change

Process	There are many definitions for process. The following are just a few examples which reflect the diversity of the definitions: "any set of conditions, or set of causes, which work together to produce a given result" [AT&T Statistical Quality Control Handbook, 1956] "a sequence of steps performed for a given purpose, for example, the software development process" [IEEE-STD-610] "a logical organization of people and technology into work activities designed to transform information, materials, and energy into a specified result" [CMM for Software, Version 1.1, 1993] "a system of skilled people using documents, tools, and resources to plan, perform, and improve activities that produce specified products or services" [SEI's Defining Software Processes Workshop] However, we can synthesize these to a basic form. A process, in essence, is the way in which a system of people, technologies, and methods work together (or don’t!) to produce the desired results.
Software Process	A software process is "a set of activities, methods, practices, and transformations (performed by people) to develop and maintain software and the associated products." [CMM for Software, Version 1.1] The only real difference between software (development) processes and other human-intensive processes is the domain of work. Thus, as will be discussed later, many practical experiences in process technologies are directly applicable to the software domain.
Activity	An activity is "any step taken or function performed, both mental and physical, toward achieving some objective. Activities include all the work the managers and technical staff do to perform the tasks of the project and organization." [CMM for Software, Version 1.1] Thus, an activity is work accomplished within a process.
Task	A task is work accomplished within an activity. A task is distinguishable from an activity in that an individual or group often performs a task, while an activity is often a complex web of interrelated tasks performed by several groups. A task is a "sequence of instructions treated as a basic unit of work" [IEEE-STD-610] A task is a "well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post-conditions)." [CMM for Software, Version 1.1]
Procedure	A procedure is a written description of a course of action to be taken to perform a given task or set of tasks. Thus, procedures often have a defined ordering or sequencing of how tasks are to be performed.
Method	A method embodies a procedure, along with "specific set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result." [CMM for Software]
Example	Suppose we establish "software size estimating" as a process on our project because it is something we want to plan, perform, and improve. Then, activities in this process might include: plan an estimation meeting review the software requirements (used to derive the estimate) generate a size estimate Then tasks within the "generate a size estimate" activity might include: distribute estimating worksheets to the estimators record estimates and assumptions collect, tabulate, and return the results discuss the results The above task sequence would be repeated until the results converge. We could then detail these tasks in a procedure document, which would show task flow and cycling of tasks. Finally, the tasks identified in the "generate a size estimate" activity might be part of an estimation method such as the "wide band delphi technique" developed at the Rand Corporation, and described in Watts Humphrey’s book Managing the Software Process.
Process Management	Process management is a way in which an individual, a group, a project, or an organization thinks about, and manages, its work activities. It is based on the following process management premise: The quality of the product is governed primarily by the quality of the process used. Most organizations today do not manage the process, but instead manage their products, as evidenced by the state of the practice reports on process maturity [SEI Technical Reports]. This is the classical American management style documented and described in many books. Based on the process management premise, however, process management can be said to be fundamentally different from product management in the following key ways: Customer satisfaction is more than just meeting requirements specifications, it is focusing on finding ways to delight the customer. Suppliers know who their customers are (internal or external) and what they need. Practices are documented and understood by those performing the work. People have the skills needed to do their tasks successfully. People are committed to following the process because they know it will get them through good times and bad. Work is completed when the defined exit conditions have been met, not when there is no more money or time. Process and product measures are taken to compare quality, schedule, and cost (actuals) to estimates. Corrective actions focus on process problems and process solutions, not on blaming people, the environment, or the tools. Process changes are managed and controlled.
Why is it important to focus on process?	It isn’t, unless we are interested in improving the way we work, and then it is extremely important. By "improving" we don’t mean just being more productive, although that is often a key improvement objective. It is critical that organizations learn how to work smarter, not just harder. We need to be more than efficient; we need to be effective. So improvement can mean making work: more efficient - doing things right more effective - doing the right things Covey, in his book The 7 Habits of Highly Effective People, uses the following analogy. Efficient is about climbing the ladder faster; effective is about making sure the ladder is leaning against the right wall. Likewise, when we focus on how people are performing their work, while making the work more efficient, we must also find ways to be more effective.
Process Performance	Process performance is a measure of the actual results achieved by following a specified process. This implies we have identified the metrics we are using to measure performance. Common metrics include effort, defects, cost, and size.
Predicting Future Performance	So why should we be interested in collecting process performance data on a process? Because, in order to manage the process, we need to (1) be able to predict the future performance of the process, and (2) reduce variations in the process results. Another way of saying this is: You can’t control what you don’t measure (and understand). This is the foundation for continuous process improvement.
Process Improvement	When people perform work to change their processes, they should focus on improving the performance of that process. If there is no effective change in the process’ capability, then there is no improvement. That is: Changing a process does not guarantee process improvement. All forms of process change must therefore focus on establishing and improving the capability of the process, not on just changing the process for change sake. This raises issues about how you know whether a change is an improvement if the existing performance is not known (which is common in low maturity processes). We will discuss this later in this section. For now, it is important to remember: Improving a process is strongly linked to the ability to demonstrate (e.g., to management) that the capability of the process is better. So, how do we know if a process is getting better? Improving process capability takes two forms: (1) reducing the amount of variations in the process (equivalent to squeezing the edges on the capability graph towards the middle) and (2) reducing the amount of chronic waste in the process (equivalent of moving the entire graph to a more effective point). When one or both of these occurs, then we can say the process is better. Dr. Joseph M. Juran described quality improvement as a three phase process. In the first phase, you identify the level of quality you are planning to achieve. Quality is expressed quantitatively in terms of what is important to your customer(s): in terms of cost, schedule, functionality, and defects. In the second phase, you measure the performance of the process, focusing on getting the process within the zone of quality control (based on the quality goals identified during planning). When measures fall outside of the accepted boundaries, corrective actions are taken to ensure these special cause variations do not occur again. The focus, therefore, is on eliminating sporadic variations. Chronic waste can only be tackled once a process is under sufficient control that sporadic variations are unlikely to occur. In the third phase, the process is examined for common cause variations, which, according to Dr. Juran, represent at least 85% of all root problems in the process. By eliminating chronic waste (in the process), a new zone of control is achieved and quality is improved.
Continuous Process Improvement	Continuous process improvement (CPI) is a never-ending cycle of identifying new(quality) performance goals, performing the process according to specified guidance, and eliminating sporadic and chronic (or systemic) problems in the process. Such change is based on small, well-defined evolutionary steps (known as kaizen). This is in extreme contrast to the historically western world philosophy of revolutionary innovations.
Process Maturity	There is now more than half a century of experience and knowledge available from which to draw upon concerning CPI. The principles of the CMM, for example, are based on lessons gained from that knowledge. By defining a mature process as one that exhibit the behaviors as demonstrated in the Juran Trilogy described above, then an organization’s primary improvement objective should be to attain such a level of maturity for all of its processes. Yet this is an arduous undertaking. A decade or more is not unreasonable for most organizations to consider realistic in achieving this objective. While holding to this long-term objective, an organization needs more to guide them in the short term. One way is to view maturity as a evolutionary process rather than a state of being. This can give one insights into what a mature process looks like in addition to how it behaves. Mature processes share a number of process characteristics: practiced - consistently performed documented - the processes, as practiced, are described in text and graphics trained - those performing the work have the skills to do so controlled - process documents are kept under configuration control, versioned, and changes are approved before they are instituted supported - staff, tools, and resources are provided to ensure the process is successfully performed maintained - supports continuous evolution of the process over time suitable - help the people do their work, rather than getting in the way tailorable - allow some flexibility in how the process is performed, based on the specific needs of the customers measured - product and process measures are taken, consolidated, and analyzed to better understand process capability improved - by reducing variations or eliminating chronic waste Thus, process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled and effective.
Process vs. Process Maturity	One common point of confusion to newcomers to process engineering is distinguishing between having a process and having an immature process. If people are working and producing something, then there is a process. (Remember the definition I gave of process?) However, the process may be quite immature: it may not be documented or consistently performed, and thus, is likely to be "invisible" to those who are not involved in performing the work. Yet, there is a process. An example that illustrates this point is size estimation for a project’s effort. Many organizations assume that since projects do not generate visible size estimates during project planning, then projects do not have a size estimation process. However, with some deeper investigation, process modelers often discover that even if the estimators only document effort and/or schedule estimates, the estimators almost always begin with some intuitive "guess" of the size of the effort. This guess is usually based on historical experiences similar to the work being estimated. Even the estimators may not be consciously aware that they are estimating a size because it is done mentally and automatically. In either case, the process does produce a result. The fact that there is no objective, tangible evidence of this process should not mislead an organization to conclude a size estimation process does not exist.
Process Wheel	From the Juran Trilogy diagram described above, we can draw another distinction about mature processes: they all comprise planning, performing, and improving activities. The "process wheel" shown below is a variation of the Juran Trilogy, focusing specifically on the process. The "wheel" begins with the planning activity, producing a plan of how to perform the work. Next, the plan is followed in performing the work, producing both products (or services) as well as measurements. These products and measurements are then analyzed, resulting in lessons learned, which are fed back into the next planning (or replanning) activity. This cycle, like the Juran Trilogy, is fundamental for continuous improvement of any process. While all processes (which produce results) have performing activities, immature processes often lack effective planning, and fewer still have any form of improving activities (effective or otherwise).
Process Maturity Standards	Process maturity standards are models by which an organization or project can compare its existing processes against, to determine where it may have weaknesses in its processes which lead to waste and/or variability of results. Three common maturity standards being used in the software community today are: the Capability Maturity Model for Software ISO-9001 SPICE (Software Process Improvement for Capability Determination). These standards also give organizations a means to benchmark their process maturity against other segments of the software industry. For example, the graph below shows the state of the practice as of September 1996 in terms of the CMM for Software and 542 organizations [Process Maturity Profile of the Software Community 1996 Update]. Other process maturity standards can be found in books. For example, many books on software configuration management and software inspections might be considered standards an organization might adopt and set a goal to mature their processes to those standards.
Quality Leverage Points	In making improvements to any system, there are three basic quality leverage points to consider: process, people, and technology. These three are the major determinants of software cost, schedule, productivity, and quality. We have already mentioned the process leverage point. The people leverage point includes hiring the best people you can find, motivating them to do the best job possible, and training them on the skills needed to perform their jobs effectively. The technology leverage point includes acquiring and installing tools that help automate or otherwise improve how the work gets done or the quality of results, and using new software languages (e.g., Java, Visual Basic, and Delphi). Altering one component impacts the other two leverage points. For example, an organization that acquires a new testing tool must consider how it will impact the people and process. Staff must be trained how to use the tool and need to understand how the new tool will make their job better. New technologies always impact the process. The organization must consider if the tool will affect when and how testing is performed, and whether the tool is adaptable to different software development processes. Even though this paper focuses on maturing processes, you cannot overlook the implications for the system's people and technologies as maturation occurs.
People Implication	Earlier, I stated that people perform process. Even if the primary tasks of the process are automated (performed by tools such as automated code and test generators), people still oversee these tasks and ensure their successful completion. As a process matures, you must consider its impact on those performing the manual tasks. Some commonly experienced implications include: reliance on defined processes, rather than on "heroes" to pull the project through higher sense of teamwork across groups, rather than on finger pointing when problems occur focus on fire prevention, rather than on fire fighting
Technology Implication	Likewise, maturing processes will impact technologies used. Some commonly experienced implications include: Process changes lead technology changes, rather than the other way around Organizations have a better understanding of the impact of injecting new technologies on the organization Organizations are more likely to install the "right" technologies
Defined Process	With this idea of what a mature process looks like, we can now give a clear and precise definition of a defined process. A process is defined when the way that it is performed is the same as the way it is written, and the way it is trained. That is: *Documented = Trained = Practiced* The extent to which this equation is true is known is process fidelity. A defined process is a necessary first step for maturing a process. Why? Because achieving high process fidelity is a pre-requisite to getting the process under quantitative control. In other words, you need to have a process that is followed consistently before measurements will provide meaningful insights into the process’ sources of "chronic waste." To begin measuring a process without having the process first defined will result in analysis that tells you: "People are performing the work differently. Increase process fidelity." The greater the degree of process fidelity, the more meaningful measurements will be in helping to quantitatively control and manage the process.
Process Description	A process description is a document describing either how a process is actually performed (an "as is" or descriptive process description), or how it is expected to be performed (a "to be" or prescriptive process description). A process description is not a process, since a process involves actually performing the work. The objectives of documenting a process include: to facilitate more consistent process execution to improve communication and understanding of current practices to capture "corporate knowledge" and best practices to identify where and how to measure the process to establish a baseline for analysis and improvement of the process From a well-documented process description, organizations can write training materials and process guides. Process guides are descriptions specifically written for those performing the work.
Process Model	A process description is documented with one or more graphical and textual process models, which are formalized representations of a process. Models describe in detail the activities, objects, and roles of the process, as well as how they are related. Their primary purpose is to communicate an understanding of a process. There is a wide variety of modeling notations that can be used to produce a graphical process model. Each has its own strengths and weaknesses. We will spend time in the workshop studying several notations commonly used in modeling software processes.
Linking Process Models to the Process Wheel	The extended Process Wheel diagram below shows one way to visualize how process models and guides are used. Process models and guides can provide support to all aspects of the process. During planning, models and guides help document the process plan, and train staff. During performing, models and guides assist management and staff in what measurements to record, and how to use the measurements to control the process. During improving, models and guides assist in analyzing the process’ outcomes, and in generating lessons learned and recommended changes. Process Wheel While process models help to define and understand how the process is performed, process guides are derived from the process model(s) and often describe how the process is performed from the implementer’s point of view.
The Principles of Process Change	When engaging in process change, the following principles are critical for success. Major changes must start at the top. Senior management must provide the leadership and direction for the change. Changes have little chance of success without sponsorship. Focus on fixing the process, not blaming the people. Remember that less than 15% of all problems are within the power of the individuals to do anything about. Focusing on "fixing people" is of minimal leverage for improvement. Understand the current process before changing it. As Watts Humphrey coined from an ancient Chinese proverb: "If you don’t know where you are, a map won’t help." Change is continuous. As our graphs in this section imply, change is a never ending cycle. Reactive changes will most likely make things worse. Collect enough data about the process to be fairly certain about how a change is going to impact performance. Organizations must begin to view defects in the process as opportunities for improvement. Most organizations hide their defects like unwanted warts. Real learning will happen only after people are willing and capable of seeing facts as reality. Improvement requires investment. Processes don’t improve by themselves. Someone must exert energy to improve them. Think of improving processes as climbing a down escalator. Improvement requires periodic reinforcement. Management must provide a reward system, and build on existing known strengths

Latest News

IDC principal consultant Jim Hart will give two presentations at the 2004 EuroSTAR/ EuroSP3 Conference (Thursday, 2 December 2004). One is on Experiences with a Risk-Based Approach to CMMI Improvement. The second is on The Use of Systems Thinking to Break Down Barriers and Resolve Conflicts Between Teams.