Section 3.4. Identifying Improvement Opportunities | Process Improvement Essentials: CMMI, Six SIGMA, and ISO 9001

3.4. Identifying Improvement Opportunities

If you're new to process improvement, or if you're creating a new program for your organization, remember that the discipline of process improvement promotes the idea of starting small and growing over time. You don't have to tackle every opportunity at once. There's wisdom in carefully targeting your first improvement steps, shaping a program around those, implementing them, and then, as they take hold in the company, adding to them over time.

Naturally, the scope and push of your initiative will depend on multiple factors: management expectations, your current process position, and the resources made available to you.

But as you begin to identify improvement opportunities, keep these three considerations in mind:

Capitalize on your strengths.
Understand what you want to do better.
Target improvement opportunities with promise.

3.4.1. Capitalize on Your Strengths

People are often tempted to move into process improvement with an eraser in one hand and a new pen in the other. They feel an obligation to start everyone off on a clean slate, with a fresh start. That's not usually the best approach, at least not for an organization that's been around for a while. A better place to start is to look at what your organization does well. Process initiatives can easily focus solely on the problems that trouble an IT shop. But it's important to remember that what the shop does well is really the best place to start on a program.

There are three reasons for this:

First, the organization already understands those things that it does well. Somehow, no matter what the reason, those effective and beneficial activities have taken hold in the company. Your job might be as straightforward as documenting what these activities are and how they usually progress in your shop. By documenting these, you capture the best practices for new members while formalizing the behavior across your working groups.
Second, it's safe to assume that what the shop does particularly well probably ties to the organization's business objectives. If these practices were not in line with the objectives, they probably wouldn't have been around long enough to become efficient. So as you look at what your teams do well, keep in mind that what these practices will show you are very likely avenues that can be enhanced to further the needs of the business.
Third, by capitalizing on what your teams do well and by formalizing those things into your program, you'll begin with a program that is already, in many ways, familiar to the people who will be called on to use it. This familiarity is a big plus. If you build your program based on already successful work habits, your people will embrace it more readily, and it can then serve as a base for the development of new program extensions.

As you begin your process initiative, look at what your shop does well with a view to its business objectives and to the areas that you may want to improve (see the next section). Do this by moving out into the organization and talking to its members. Find out what management thinks are areas of strength. Talk to members of the various teams. This is a great opportunity to get a consensus of opinion of best practices, to identify sources of best practice data and activities, and to share the purpose and goals of the process program with members of the organization.

Once you have solicited this information, you should come away with a pretty good idea of the existing practices you will want to integrate into the new program. On top of that, you should come away with a sense of the areas of weakness in the organization: potential targets for focused process improvement.

3.4.2. Understand What You'd Like to Do Better

If you work to define the organization's business objectives and then examine your shop to identify those things it does well, you'll be in a good position to identify areas where things could be done better: potential targets for process improvement activities. Look to document these in your shop. Keep your focus on the business objectives you want to achieve. Then begin to look down to the activity level; look to the business activities that realize performance.

For example, one of the shop's objectives may be to improve IT's ability to meet scheduled release timelines. Stakeholder comments may have indicated that schedules are difficult to honor due to high levels of continuous change. Looking at this, you might see opportunities for improvement in at least two activities. The degree of change, you may decide, might be better managed, and so a good target for improvement might be to review and refine your change control procedures. Another side of this could involve requirements management. You might conclude that the volume of change indicates that the requirements aren't being properly reviewed, that they are arriving in an incomplete manner, or that they are not being tracked well. So here you may see an opportunity to improve your procedures for analyzing, understanding, and committing to customer requirements.

Third, remember the importance of stakeholder participation, especially when it comes to improvement targets. To work to their full potential and promise, all process programs need the support and backup of key stakeholders, particularly the members of your shop. So as you review potential targets, seek a degree of consensus concerning the opportunities. This will hopefully result in improvement choices that ring true with many of the people in the organization.

Of course, here you may have to strike something of balance between want and need. You and management may see an important need for improvement in one area of the business, while the working teams may show a concern for another area. Here you'll need to weigh the appropriate target: tackle an improvement opportunity with a large need, or target an opportunity that, while not as pressing, shows broad support for change. There's not a clear answer here. You'll have to make that call in line with the culture and makeup of your organization. But as long as you keep both views in mind, you'll stand a better chance of making a choice that works to make a difference.

Finally, after you've looked closely at your shop, settle on a range of targets that you and your team can effectively evaluate. Depending on the size, ability, and experience of your team, these may be a few opportunities or they may be a good many. The thing to avoid is lining up too many opportunities, ones that sit on the shelf apparently ignored, or a large set of others that overwhelms your team. The goal here is to realize a core set of key opportunities and then begin a visible campaign to shape organizational activities around those opportunities.

3.4.3. Target Opportunities with Promise

Your process program will begin to take solid shape once you are able to target specifically what it is you want the program to address, what it is you want to improve. If you have a handle on your business objectives, if you understand those things your shop does particularly well, and if you've had an opportunity to discuss the program with members of your various IT teams, then you should be able to identify many potential improvement opportunities.

You might have a chance to extend an already successful activity. You might see an opportunity to support a relatively weak activity with some new tools. You might see big opportunities and small ones, complex ones and simple ones. It's a good idea to keep a list of these, but naturally you can't take on all of them at once.

When it comes to introducing new elements into you program, it's best to be selective, to choose strategically. You probably have limited resources. You may have limited time. You may be chartered with making a set amount of progress. So, if it's best to choose a few select opportunities, then look at the ones that hold the most promise for strong returns.

Here are a few tips to help you do this. They are not presented in any order but are simply considerations that can help you focus on targets with the potential for visible rewards.

A good way to select the strongest opportunities is to begin by looking again at the goals of your company (operating unit or work group). Which ones might your process program be able to influence, to support? If you can be successful at furthering these business objectives, there is no doubt that your process program will be a success. So examine the business goals with this in mind and select those that you are sure you can impact, that you have a pretty good idea of how to impact, and that you are comfortable you have a way to measure and report on.

AIMING FOR THE RIGHT SIZE

The purpose of the activities discussed so far has been to focus the scope of your process program along lines that support the business goals of your organization. The scope you begin to establish here will shape the rest of your process program activities. Sometimes people want their programs to have a broad scope, touching on many areas of IT operations. Other people prefer to start off with a very constrained focus, perhaps seeking to standardize only a few operational traits. Sometimes you may not even be in control of the scope of your program.

But you'll need to address the questions of when to aim low and when to aim high at some point, and it's usually best to think this through early on. There's no clear-cut answer here, but here are some tips you can consider when thinking through what's best for your organization.

Times when it's better to aim low include the following:

Soft commitment: Many shops realize that they need process, but they aren't deeply informed about what it takes to implement a process program. Consequently, they may be looking for quick benefits and fast returns before they are willing to invest in it properly. When you are faced with this type of soft commitment, it's best to begin with small, targeted efforts. Select one or two areas you can use as a proof-of-concept in order to demonstrate the value of process improvement to management.
Unfocused work groups: We mentioned this earlier. If the organization as a whole is unfocusedif it lacks any common idea of where it needs to improve or what its overall objectives arethen your program should begin small. It should serve as a candle that lights the way for future, more solid improvement. Select an opportunity or two that will be visible to all groups, work these through, and then see if this helps align the organization for extended efforts.
Cultural resistance: It's possible that your process initiative will reveal a degree of cultural resistance. Some resistance is always to be expected, but if it shows itself as dominant, you should avoid a large program that could be seen as intrusive. Often you'll find that resistance begins to soften when you're able to show progress in small ways. By aiming low, you can target a few areas specially selected because of their impacts on work loads, workplace fluidity, or quality. When these solutions have been implemented and begin working well, people once cool to the idea of process improvement may begin to change their minds and become open for broader implementation.
Soft benefits: Even when people know they need process, they may not know exactly what they need it for. They don't yet have a clear idea of the benefits they want to see from a program. And without a good fix on the benefits you're aiming for, you won't be able to readily measure the program's success. So it's best to aim low when the benefits are soft. Start with a couple areas of improvement, work those through, and carefully measure the advantages they deliver.

Times when it's better to aim high include:

Big business: If your IT shop is an enterprise dealing with major clients and large projects, you may find that you have to aim high because your clients require it. This is becoming more and more common. And it's understandable. If a company is going to allocate tens of millions of dollars and a piece of its future to your shop, they should very well want to know that you're operating against some kind of established process or quality program. Ten years ago, you hardly ever heard of this requirement. As a result, billions were scattered to the wind in the dot-com bust, much of it due to cowboy management and charge-up-the-hill business strategies. But the industry has gotten smarter now. Big business now knows that big projects require mature management, most often through the full use of recognized process management programs.
Big risks: Jail time and ankle bracelets have done a lot for the process improvement industry in the last five years. The Sarbanes-Oxley Act, legislated in the wake of corporate scandals like Enron, Worldcom, and Qwest Communications, established standards for controlling, accessing, managing, and reporting on corporate data. Process programs like ISO, Six Sigma, and CMMI happen to address the same kinds of concerns for IT operations. As a result, corporate IT shops are being pressed on by CEOs and CFOs to implement recognized quality controls that build data protection into their business systems.
Big stakes: If you want to do business in certain sectors of the IT industry, you will be required to operate through a recognized quality program. Many major companies in Europe will not grant IT contracts to any shop that is not registered as ISO 9001-compliant. In the U.S., large federal agencies like the Department of Defense and the Department of Housing and Urban Development are requiring that their major IT contractors demonstrate compliance with CMMI. And in the commercial space, companies like GE are requiring their vendors to demonstrate levels of quality control and oversight that reflect the standards of Six Sigma. When you wish to participate in these high revenue markets, you'll need to aim high with your process program.

Now you're ready to look at the organization. Once you know the business objectives that you'd like your program to address, look for "accessible" business activities to build your program on. I put quotes around "accessible" for a reason: accessibility here holds several meanings. One is that you'll need to obtain access to work groups that will exercise your program. They will need to be willing to take on the learning and discovery curve and invest in the time and resources needed to get your program into its initial, workable form. Another is that you'll need access to the kinds of business activities that tie back to the business goals you've selected. Even if a group is willing, if it turns out that their business domain does not impact the goals you've selected, they may not be the best choice. So accessibility requires relevance as well. Another consideration is access in terms of authority. In other words, will the organization grant you the authority to potentially reshape operational processes that might be critical to business success? Try to lock down your domain of influence early on here; know where you are allowed to move and with whom you are allowed to work. With access, relevance, and authority duly considered, you should be able to select proper business activities to assess and report on.

Now that you know the business goals you want to support, and you know the work groups that impact the goals and will partner with you on the program, you can zero in on specific opportunities to target. If you're selective about this choice, you'll end up with a finite yet focused approach to build out your program, one that links directly to business objectives, one that capitalizes on those you do well, and one that extends your capability into new realms of quality management and control.

Note: Reminder on controlling scope: Process improvement enthusiasts often reach a little farther than their grasps allow when they set out on an improvement initiative. By its very nature, business is full of processesdocumented, undocumented, well done, poorly done. Designing a program that fits well with your IT shop requires focus, time, and attention to detail. You'll want to do it properlythat is, you'll want to do it well. So at first, don't try to do too much at once. Don't try to manage too much or address too many issues. If you keep the scope of the program sized to the capabilities of your team, you're probably scoping to the right level.