NATURAL PROCESS IMPROVEMENT THROUGH WEEDING AND NURTURING

What exactly is natural process improvement and what is the slash-and-burn approach to process improvement? This information in this section assumes you understand the characteristics and consequences of the slash-and-burn approach to process improvement. If not, familiarize yourself with these concepts by reading the applicable text in Chapter 1 ” News Flash! There Is a Level 1! This section is devoted to providing you with some concrete examples of the weeding and nurturing approach to process improvement.

In its simplest construct, weeding and nurturing your organization s process improvement effort is exactly what it sounds like. It means temporarily parking and shutting down your bulldozer (CMMI) and taking a look at your organization s processes. It may look like a weed-choked, tangled mess ” in other words, chaos ” but there are things worth saving in that tangle which you were about to wipe out with your CMMI bulldozer.

Weeding

The first part of weeding and nurturing process improvement is weeding. Weeding an organization s processes is a matter of finding the policies, standards, processes, and procedures which don t help people in the organization do their work and removing those things.

Process weeds are usually not hard to find and you and your process group will find that there is no shortage of volunteers who will point them out. If the process weeds are not obvious, here are some good clues to finding them.

Possible weeds which may need to get yanked out of the organization are those practices people bemoan about. Go investigate the practices about which you hear comments like:

I don t know why we do this.

Doing that is a waste of time.

What do we produce that for nobody looks at it.

We haven t done that since 1990.

If people don t volunteer such information, just walk around a bit and start asking questions. Don t interview people. Gain their confidence and trust first and then ask questions like:

Are there any rules or procedures which you think unnecessarily waste your time or frustrate you?
What part of your job is the most difficult or frustrating? Why is it frustrating?
What activities are we doing that our customers complain about?
What work do you do that takes way more time than you think it should?
Do you produce anything that you re not particularly proud of or to which you don t pay much attention?

Other possible weeds that are candidates for pulling are documented processes and practices which ostensibly haven t been used by anyone in a long time. If the organization has documented process assets (e.g., policies, processes, procedures, forms, templates, checklists), review them and make note of the date of the last version or revision. If you find process assets that are more than one year old, there s a good chance they re no longer valid. Why? Because over time, people naturally find ways to improve their work. And if they ve gone a year or so without updating their defined processes to reflect the way they work, then the defined processes probably no longer affect the work being performed.

An article in the Harvard Business Review ^[36] uses a metaphor similar to our weeds only with a more aquatic theme. The article quotes the Texas insurer USAA; they refer to their process of weeding ” simplifying structure and processes ” as painting the bridge.

That is, once you ve finished painting a bridge, prudent maintenance requires that you go back to the other side and start over. So it is with bureaucracy: Once a company has assessed all its core processes and scraped off the bureaucratic barnacles, it s time to begin again.

Be cautious in your search for weeds or your attempt to scrape off the barnacles. Sometimes, you might find a patch of the process garden that looks like it is mostly weeds, yet that patch could belong to someone who will be threatened by you and others wanting to get rid of his weeds. He might not even think that what is growing in his area of the organization is weeds or he might know they are, but it s still his patch and you re not allowed to touch it. Get out of my patch or get off my turf will be the clear message to the process improvement team.

On the other hand, the process people should not assume that just because people don t have a procedure manual open next to them while they re performing work that they re not following defined processes. Truly institutionalized processes are those which have become so ingrained in the culture that people perform them consistently without having to read the documented version.

Finally, remember that what now may look like a process weed to you and others might have at one time been an efficient, well-designed, fruitful process which has now gone to tangle due to neglect. Be aware that some processes and process assets you find might not need to be pulled out of the organization and discarded; they might simply need to be pruned to fit in the current organization.

Nurturing

The second step in weeding and nurturing is nurturing. Process nurturing means finding process assets which look like they might meet the organization s business and process needs if they could just grow a little. In our garden analogy, such process assets and practices just need a little more light, food, and water in the way of design, improvement, and training or communication for them to bear fruit for the organization as an effective and efficient process or practice.

In most software and systems organizations, you will find process seedlings that are worthy of your attention. Some of the more common things to look for and nurture are identified in the following subsections.

System or Product Change Practices

No matter how chaotic an organization may appear to be at first glance, I haven t come across one yet that did not have some form of a process or practice for introducing change to its products or services. In the CMMI world, these rudimentary processes can often be nurtured into requirements management processes and assets.

In working with organizations, all of the following terms have been employed to describe some form of a request for a change to an existing product, system, or service:

Application Report (AR)
Change Request (CR)
Engineering Change Request (ECR)
Enhancement Request (ER)
Network Service Request
Service Request (SR)
Software (or System) Change Request (SCR)
Software Problem Action Report (SPAR)
System (or Software) Problem Report (SPR)
System Enhancement Proposal (SEP)

And I m sure you know of other similar terms. In all cases, these were instruments or vehicles by which someone was able to request or describe a condition or capability needed by a user to solve a problem or achieve an objective or to request or describe a condition or capability that must be met or possessed by a product or product component to satisfy a contract, standard, specification, etc. ” in other words, a requirement. ^[2] Also, in all instances and implementations in which I ve witnessed such instruments being used, there was a process, at least commonly understood and followed even if not defined, for initiating and processing the change instrument.

Such processes and instruments are easy to overlook. People will say, oh, that s just our bug tracking system and you instinctively won t think of requirements management although you may be thinking about peer reviews or validation. Be creative and stretch your understanding and interpretation of CMMI and recognize such a process or system as the seedling that it is for a requirements management process or system or a configuration management process.

Project Management

Even in organizations in which it is difficult to uncover any sign of consistent project planning practices, you will still almost always find some consistent project monitoring and control processes. Again, every organization I ve worked with has evolved some form of project status or progress reporting or some form of project reviews. Don t throw these practices out with the weeds. Salvage the pieces of these practices that are satisfying a need in the organization and grow them through incremental improvement into project management practices that satisfy the business needs and are consistent with CMMI practices in PMC or IPM.

Quality Assurance

Software and systems delivery organizations have had quality departments since the word was first brought into the information industry. Traditionally, the quality organizations have focused on the quality of deliverable products such as hardware, software, and firmware. Yet, think about what the people in quality organizations do, think about the reason for their professional existence. They live and breathe to ensure that something works the way it was supposed to work in the environment in which it is supposed to work. Traditionally, they have achieved their goals through testing. Traditionally, they have come close to satisfying the product P in PPQA. It is not a quantum leap to grow quality units into satisfying the process P in PPQA.

You can just as easily call a process a product. These words are in the public domain and your organization gets to decide what they mean for your organization. As a product, a process can be monitored , tested , checked, looked at, inspected or evaluated to ensure that it also works as intended in the intended environment. Nurture the quality people in the organization to adopt this view and you will soon see PPQA blossom. You ll also be well on your way to establishing some of Verification and most of Validation. Yahoo!

These ideas are just the beginning. Here are some other places to look for promising signs of process life and some clues for nurturing them to maturity:

Marketing or sales departments. (I know what you re thinking, but try to be gracious!) People in sales and marketing, for all their shortcomings, are the life-blood of the organization. They keep you in a paycheck and a mortgage. Yes, they do sometimes sell things that don t yet exist or can t exist, but they also are very much in touch with what the market wants and is willing to pay for. Marketing is the preeminent source for requirements for enhancements to products, systems, and services and, with your help, they can mature into a prime contributor to the feedback loop between the customers and the organization s process improvement work.
The help desk or customer support center. At the back end of the organization (which I m sure reflects exactly the way people in such organizations often feel) is customer support. This is the other side of requirements; the side that requires a capability in the system product to resolve a problem. Along with marketing and sales, they should be nurtured to be a relevant stakeholder in any REQM and requirements development (RD) process. They will also frequently come up with some amazingly brilliant and simple solutions to problems (think TS).
Personnel. The stigma of personnel departments is tragic. Executives, managers, engineers , and other professionals have for too long viewed personnel departments as a necessary evil. Get over that. In personnel departments, you will often find gold mines of knowledge and skill that you need for your CMMI-based process improvement work. Personnel professionals frequently have a deep understanding of the organization s knowledge and skill baseline and needs (can you say OT? ). They also possess the psychological, sociological, and anthropological knowledge that the process focus people need to successfully execute an organizational change on the order of CMMI-based process improvement.
Accounting and finance. You ll be surprised at what the bean counters count besides dollars (or Euros or Yens or whatevers). Hidden in their formulas and algorithms are all kinds of information and measurements (MA and GP 3.2). Go to them; talk to them. You might be able to get baseline measures for productivity or resource utilization, customer satisfaction, unit production costs (UPC), efficiency, and other measures you will need to later understand the effects of CMMI-based process improvement.

Do you get the picture? CMMI and process improvement is not just for process people and engineers anymore. Almost every team or unit in an organization, almost every individual, has something to contribute to the organization s process improvement work. It is the job of the process experts and change agents to build their CMMI project such that it includes all of these relevant stakeholders and that they are nurtured and fed so that they contribute to the overall success of the organization.

^[36] Nohria, N., Joyce, W., and Roberson, B., What Really Works, Harvard Business Review , July 2003.

^[2] The Capability Maturity Model IntegrationSM ” SE/SW/IPPD/SS, V1.1, CMU/SEI-2000-TR-030 , Carnegie Mellon University, March 2002.