The art of progress is to preserve order amid change and to preserve change amid order. | ||
| --Alfred North Whitehead (1929) | ||
Organizations that stand still can neither prosper nor survive. Many of us find ourselves in organizations that want to do things “better, cheaper, and faster” but are not sure how to get there. And, in many cases, an organization’s culture can’t support its aspirations to reach world-class status as the best of the best. We find that leadership isn’t there, we don’t have effective teams, functional groups are more focused on preserving their territory than producing results, problem-solving processes are superficial, and attempts to implant best practices here and there with good initial results often seem to be rejected shortly thereafter—especially when we must focus on averting the next crisis.
Welcome to the world where most of us live. The scenario just related describes symptoms of an underlying inability to sustain change. And sustaining change is hard work. But examples from many industry and government projects have shown that this hard work pays off over time. The most successful organizations adapt to and sustain change to remain ahead of the competition. So where should you put your energy to accelerate becoming and staying the best acquirer of technology solutions?
To do so, you must ensure that you continue to progress in implementing the activities required not only to meet the best practices set forth in the CMMI-ACQ, but also to meet the underlying challenges of leading and sustaining change. If you can successfully recognize and manage this duality, you will be well on the way to achieving and sustaining progress within your organization.
What is crucial in accelerating acquisition improvement is to gain insight and understanding about how your organization works in practice. Letting imitation or adherence to the status quo guide your improvement won’t result in a better, more efficient, more accurate way of delivering technology solutions. Organizations tend to imitate those organizations they admire. However, replicating the behaviors of these role models without a clear understanding of how it affects performance in your own context is a certain recipe for disaster. Solving the problems that limit performance requires a detailed understanding of the root causes of those problems as they play out in the specific circumstances of your organization’s acquisition processes.
A key ingredient is to learn from experience, not only to introduce change but also to sustain significant improvements in the acquisition of technology solutions over long periods. This applies equally whether you’re in a commercial firm outsourcing help desk services to an IT service supplier, or you’re managing a large-scale Department of Defense program, buying control system software developed by a defense contractor.
Another key to accelerating improvement is to avoid management-induced oscillations that result from adopting the management approach “de jour”—a practice that seems to govern some organizations. Often, managers read articles about good management practices and adopt these practices simply because they have been labeled “good,” without knowing how these practices affect their economics as acquirers. This is a sure way to get tangled up in the web of management fads, while the organization treads water. Instead, if you are to succeed you must adopt an approach and maintain focus and purpose, and you must do so as efficiently as possible. Following a model-based approach such as the CMMI-ACQ is an effective way to maintain focus and dampen the effect of management-induced oscillations.
Critics of the process improvement approach for acquirers of technology solutions argue that the process takes too long and incurs too high an overhead cost, so why not just adopt the suppliers’ processes? If you have done a good job of picking a supplier, what’s the problem? You can rely on their process maturity—after all, that’s what you’re paying for, isn’t it?
Not so fast! You have a legal and fiduciary responsibility to oversee the acquisition process and the quality of the product or service being purchased. As discussed in the previous chapters of this book, some of these processes necessarily differ between supplier and acquirer. However, many processes can be shared, and among these, there is a need for harmony. It’s not uncommon for suppliers to have a higher process maturity than you have. If there is a mismatch between supplier and acquirer processes, the equation is pretty simple:
Process degradation = inefficiency and rework = increased acquisition costs
So one very important reason that acquisition organizations should be interested in improving their process maturity is to reduce acquisition costs by avoiding inefficiency and rework. It’s ironic that many outsourcing efforts or acquisitions are critical to the success of an enterprise, and yet few resources are allocated to ensuring that the acquisition is staffed adequately and that personnel have the proper tools and training to manage the job successfully. Because you’ll most likely be given a minimal amount of resources to accomplish the outsourcing project, this means that you need to do so as efficiently as possible.
But cost avoidance is not the only reason to adopt an improvement philosophy. Applying best practices and disciplined processes improves risk management and mitigation activities, generates better early warnings about budget and schedule trends, fosters improved planning and forecasting based on historical evidence, and improves the overall ability to leverage lessons learned (some of which an organization may pay for dearly).
Some organizations begin process improvement to “check a box”—that is, to comply with a regulation or requirement imposed on them, such as a mandate by the executive leader of the organization. However, once begun and properly supported, process improvement is like a snowball rolling downhill. If it is done right, acquirers that embrace process improvement and properly support it realize improved efficiency and a better ability to perform core acquisition functions, such as solicitation and contract monitoring, systems engineering, requirements management, and insight and oversight into the supplier’s development activity. Also, they realize the benefit of the overall maturity improvement of the acquisition project, as described earlier.
So what do you do? You have to start somewhere. Let’s discuss some approaches to assist your acceleration of process improvement to realize business bottom-line returns quickly and efficiently.
Getting off to a good start is critical to any project or program, but especially in an acquisition. Acquirer and supplier processes, particularly where they interact or intersect, need to be stabilized as quickly as possible. In this way, you avoid costly rework and potential negative impacts on the supplier agreement and schedule, not to mention legal ramifications.
When you first start to think about adopting a model-based improvement approach for an acquisition, it is difficult to know where to begin. Looking at the CMMI-ACQ, you quickly realize that the model is comprehensive and complex, with many interrelated best practices. Few acquisition offices have the luxury of dedicated staff to devote to process improvement. The reality is that you can’t work on all the process areas at one time, especially if your project has a limited budget for improvement activity. In most cases, improvement must be done incrementally over time.
Let’s look at some suggestions for understanding the business goals of the project and seeing how they interrelate with CMMI-ACQ goals and practices. This will help you prioritize your improvement efforts and follow a measured, incremental approach to improvement that begins to return business value quickly.
Working with Paula Ressel, the internal customer of our fictitious acquirer, is an experienced project manager named Steve Reiter. In a meeting with Paula, Steve has identified some important milestones in the acquisition process and has begun to relate them to the CMMI-ACQ. They’re pondering a question: What are examples of important, stable processes that we share with our supplier?
After discussing it for a while, they both realize the importance of the contracts area. It’s especially crucial in managing the relationship with the supplier as the supplier agreement is put in place and the supplier begins work. So they decide to start there, with acquisition management as an example of a process that must be stable.
Paula: I reread a section of the CMMI-ACQ last night. One key process that we need to stabilize is acquisition management. Let me read the list of what’s involved: maintaining ongoing communications and mutual understanding with the supplier, resolving issues and disputes, devising and closing the supplier agreements, accepting delivery of acquired products, transitioning acquired products to the project, and managing the payment to the supplier.
After I read this, it really hit me. If we don’t get this stuff right early on, we’ll have a lot of problems later. Especially since legal issues are involved with contract compliance and performance.
Steve: And when problems occur later, they’re more expensive to fix, since they usually involve schedule or budget slips.
Steve agrees with Paula because he knows the story well from firsthand experience. He worked on several projects earlier in his career that required contract termination actions. He wants to avoid these kinds of situations on this project. For one thing, they’re potential career killers. What’s more, when contracts get to the point that they require remedies involving potential legal action, no one really benefits. Both the supplier and acquirer stand to lose a lot, so Steve emphasizes with Paula the importance of having the best people for the job in the contracts area.
Steve: We’re interviewing a really sharp contracts person this week to come on board with the project. I want to make sure we’re rock solid with the contracts aspects of this project.
Steve and Paula discuss the importance of eliminating redundancy and waste from the contracts process. Paula recalls that on another project, they saved significant amounts of time by streamlining the post-award acceptance of supplier deliverables. Working together, the acquirer and the supplier were able to collaborate on a process that enabled parallel reviews of specifications and deliverables, cut cycle time, and improved teaming between the two parties.
Paula: We eliminated the “over the wall” approach to contract specification and acceptance, which traditionally is a serial process. You know, that’s where we complete a task, throw it over the wall to the supplier, and then wait. The supplier does their analysis, which may include many of the same elements, throws it back over the wall and waits, and so on. The only way we could break this vicious cycle was through constant communication.
Steve: We had the same issues on another project I worked on. But we never got over the issues created by that wall!
Paula and Steve agree that it’s important to maintain appropriate ethical behavior. They know that certain legal and fiduciary functions can’t be shared with the supplier, but most functions can and should be subject to open sharing through routine communication.
Steve recalls another example of shared process—risk management—that paid benefits on a previous project. He relates his opinion that a shared risk management database for the current acquisition project would be key to its success.
Both Steve and Paula agree that contract administration and risk management are examples of processes that can be shared initially and can offer big paybacks in improved communications and reduced overall project cycle time. The key is to stabilize these shared processes early on.
Steve tells Paula about a speech given by their boss, Matt Vauban, to the other company executives. In the presentation, Matt talked about the “hidden truths” of successful acquisition processes. One of the hidden truths was, “Strategic partnering is essential.” Steve quotes from his notes of the briefing:
Coordination costs for outsourcing are incurred by both the acquirer and the supplier in this relationship; the acquirer largely assumes the risks of the supplier. Acquirers and suppliers must acknowledge these costs and risks and mitigate them through ongoing collaboration.
Steve points out to Paula that one of the most important ways that this strategic partnering can occur is through shared processes. He’s pleased that they’re beginning to define and implement the high-level strategies to which Matt and the other executives had agreed.
Steve: This process improvement approach just might work after all.
Paula: When you came in here today, you mentioned process stability, Steve. We’ve talked around this concept. I think I know what you mean, but could you explain a bit more how we can implement it?
Steve: Sure, Paula. Question 1, which we’ve talked about, is what can we collaborate on and share between us and our suppliers? That’s important, but the “what” isn’t the whole story. You also have to define the “how”—how can we work together? A crucial part of this is process stability up front. In a manufacturing setting, you have all kinds of measurement and analysis to define things like upper and lower control limits for a process. But we’re not ready for that. What are the alternatives?
I’ve been discussing this project with Rosa Gonzales. Do you know Rosa? She’s our resident process improvement expert. Matt loaned her out to another division to help them get a project started, but now she’s back and we’ll have her as a key adviser.
Steve explains that Rosa has given him a chart that shows activities that occur at maturity and capability level 4 in the CMMI framework. He shares his impressions of it with Paula. He believes strongly that using measurement to manage process performance at the organizational level is an important goal. The issue is that they just aren’t ready to do that.
Steve: No way will we have “statistically managed subprocesses” any time soon! These are important concepts, and this is what many people mean by stable process performance. I think we should keep them in mind as we move forward, but we’re nowhere near ready to implement them at this level of detail yet.
Paula: Well, then, what do you mean by process stability for our project? How will we know it when we see it?
Steve: Good question. Here’s my thought. If we and our supplier collaborate on managing and measuring the performance of our common processes and reduce process churn as much as possible, we’ll go a long way toward establishing stable processes. In other words, start small, measure how we’re doing, and base corrective actions on performance, not management whim. Later we can get more sophisticated in our methods.
Tip
Be mindful of higher-level maturity processes even at the beginning, but don’t try to do too much too soon.
Paula agrees with this approach. She notes that “touch points” between acquirer and supplier are a good place to start to think about collaboration opportunities. But other topics are pressing, so they agree to talk about touch points at a later time.
Paula: Steve, I think you just answered another question for me. I’m thinking about applying the CMMI-ACQ to another project I’m already working with. That project started about six months ago, and I think we can do a better job of stabilizing our processes. It seems that what you’re saying can apply equally well to a project that’s just starting up as a project that has already established a relationship with suppliers. What do you think?
Steve: I don’t see why not, although it’s probably a good idea to talk to our contracts people first. You need to avoid asking for a change that will incur additional cost without realizing that you’re committing us to that change. It definitely needs to be done with the help of our contracts people.
Tip
Acquisition process improvement can start at any time in the acquisition life cycle, not just at project start-up.
How do you begin to accelerate improvement? You need to establish where you are before you can determine where you want to go. What are the strengths on which you can build, and what are the weaknesses that need to be addressed?
Steve decides to consult with Rosa Gonzales again. They meet in a small conference room and close the door so that they can discuss the challenges of process improvement in private.
Steve: Something that has been troubling me, Rosa, is that five process areas in the CMMI-ACQ have the word “organization” in the title.
Steve is concerned that in terms of what the CMMI-ACQ requires, his project doesn’t necessarily have a robust organization structure supporting it. How can he implement the model without one?
Rosa: Well, without a solid organizational structure, you may not be able to comply with all aspects of the model. But that doesn’t mean you can’t begin a process improvement effort. It depends on what your process improvement goals are. You should identify these in the project’s process improvement plan.
So far, this sounds good to Steve.
Tip
Process improvement efforts can start at the project level even without an organizational-level support structure.
Rosa continues.
Rosa: The CMMI-ACQ permits projects to get a maturity or capability rating by going through a formal appraisal process. Some organizations undergo an appraisal to not only help guide and plan improvement efforts, but also for other business reasons. For instance, some contracts require suppliers to demonstrate a certain level of maturity or capability before they’re allowed to bid. If your goal is to quickly get a level rating for the project, you may have some issues. You don’t have the organizational process areas in place that you can tailor for this project. That means your project can’t meet all the model requirements, and your appraisal would expose some areas that aren’t fully covered by your implementation.
Rosa: Well, it depends on your goal. If your goal is to begin a process improvement program to take advantage of best practices, there’s nothing keeping you from getting started! In fact, the CMMI-ACQ is structured to support best practices at the project level.
Steve: It’s really about improving the business for us, making it more efficient and improving the quality of products we deliver to our customers. I think that’s more important to us than a rating.
Rosa smiles knowingly.
Rosa: In some cases, the project becomes the prototype or flagship for the organization, which then takes what the project has done and builds on that to expand it to the larger organization. Using the materials you develop can help me expand process improvement throughout our entire organization.
Now Steve starts to get nervous all over again. He must complete this outsourcing effort with minimum resources, and the process improvement manager is telling him that along with all the other things he has to be concerned about, he has to help the entire organization, too. This isn’t scoped in his project plan, and he doesn’t see how he can sell this to Matt and the leadership team. The impacts on cost and schedule will be too great. Steve makes this point emphatically to Rosa.
Rosa: Whoa, slow down! I think you misunderstood my meaning, Steve. Many of the things that can contribute to building an organizational capability are really just good project management practices. They really shouldn’t be an “over and above” burden to the project. For instance, collecting metrics about project performance and generating ideas for improving performance are good practices for any project.
Tip
Project improvement efforts can be harvested for successful practices that can be used across the organization.
Steve feels a little better, but he’s still skeptical.
Steve: I wonder how we know where to start, Rosa. The CMMI-ACQ is very comprehensive, and many of the process areas seem interrelated. Dropping this entire effort onto our project team right now is a non-starter. We can’t possibly do everything we need to do if we’re spending all our time on process improvement. If we try to do it all at once, we’ll frustrate our people and miss our deadlines.
Rosa: What you need is a place to start building an understanding of where you are. I think you should start with the Organizational Process Focus process area.
Your first step is to get with the stakeholders—Paula, Matt, and the others. Find out what they think your potential problem areas are, and what your strengths and weaknesses are. To help with this, you might want to try a tool called the Strengths, Weaknesses, Opportunities, and Threats analysis. It’s a pretty simple exercise, and it helps you identify the project’s weaknesses and threats and understand how to turn them into strengths and opportunities. And identifying strengths and opportunities may give you ideas about how to build on these and maybe pick some low-hanging fruit.
Steve: Wait a minute. I thought we just said we didn’t necessarily have the organizational process areas in place around here. So how can we use them in this project?
Tip
You can’t do everything at once. Understand what your business objectives are. Then start small with focused improvement efforts that return business value quickly.
Rosa: Well, in an ideal world, you’d have them in place. Your project could draw them from a process asset library, and you could tailor them to your needs. But you don’t have that. So your best bet is to take a bottom-up approach and get started at the project level. As we move forward, we can start to build up our organizational assets.
Steve: I like the idea of picking low-hanging fruit, Rosa. That will help us demonstrate early wins and help build and sustain momentum for the project and our organization.
Rosa: Steve, I think one of the most important things about getting started is to understand where you are. Watts Humphrey, the founder of the SEI Software Process Program, once said, “If you don’t know where you are, a map won’t help!”
There’s a lot of wisdom in this. One thing that distinguishes high-performing organizations from the rest of the pack is that they’re brutally honest about themselves, and they do their best to get an objective view of where they are. Sometimes a third-party assessment or appraisal can help. Our process group does informal assessments, and in the past we’ve contracted with some companies for formal appraisals. What this does is set a baseline for where you are. Then you can decide where you want to go.
Tip
Baseline where your project is in terms of the CMMI-ACQ. Inexpensive, informal assessments that target a few process areas are a good way to get started.
Steve: I don’t mind being self-critical, but I’m afraid we wouldn’t learn much from an appraisal. We don’t have any processes documented, and we don’t have time to do that now. Remember the schedule we have!
Rosa: I don’t agree, Steve. You have a lot of processes in place already and many artifacts that show you’re following them. Maybe these processes aren’t documented, but they sure are in our organizational DNA. You just don’t realize it. We’ve had success in the past with doing an informal assessment and then identifying one or two areas to focus on. Then build from there.
Steve: Okay. Maybe an in-house assessment would help us baseline where we are. But we need to talk some more about how many resources it will take.
Rosa: We’ve done quite a few of these, Steve. They take very little time and have very little impact on your people. Let me work up a notional schedule for us to discuss next week.
Steve: All right, Rosa, I’m about half convinced. I hear what you’re saying. If we do an assessment, we can use it to flag our problem areas and focus on them to get started. But I really want to see your plan before I sign up for it. I’m still concerned about the time commitment from my project team. What else do you have in your bag of tricks that can help?
Rosa: Well, how about risk identification and metrics? Risk identification is one of the first steps in a risk management approach, and it engages the relevant stakeholders. Let your customer help you decide where your high-risk areas are, and use the CMMI-ACQ to help identify process areas or practices that can address those risks.
You use metrics to baseline where you are. This lets you set goals and then measure your progress as you move forward with the improvement effort.
Rosa and Steve agree to get together again soon to continue discussing an internal assessment to baseline Steve’s project. They also plan to create an outline for an improvement approach that makes sense given where the project is in its life cycle.
The CMMI-ACQ provides specific recommendations on how to plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets (see Table 5-1). The organization’s processes include all the processes used by the organization and its projects.
Table 5-1. Organizational Process Focus Goal 1: Practices and Tips
CMMI-ACQ Process Area: Organizational Process Focus | ||
1. Goal: | Strengths, weaknesses, and improvement opportunities for the organization’s processes are identified periodically and as needed. | |
Practices | Tips | |
1.1 | Establish and maintain the description of the process needs and objectives for the organization. |
|
1.2 | Appraise the organization’s processes periodically and as needed to maintain an understanding of its strengths and weaknesses. |
|
1.3 | Identify improvements to the organization’s processes and process assets. | |
The organization’s processes operate in a business context that must be understood (Table 5-1, practice 1.1). The organization’s business objectives, needs, and constraints determine the needs and objectives of the organization’s processes. You obtain candidate improvements to the organization’s processes from various sources, including measurement of the processes, lessons learned in implementing the processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations’ processes, and recommendations from other improvement initiatives in the organization.
The organization’s process needs and objectives cover aspects that include the following:
Characteristics of the processes
Process performance objectives, such as time to market and delivered quality
Process effectiveness
Before you evaluate processes against the CMMI-ACQ or other industry standards such as ISO 9001, it is critical to obtain sponsorship of the process assessment or appraisal from senior management. Assessments can be informal efforts (even done by an in-house team) that result in a quick snapshot of process performance. Standard CMMI appraisals are more rigorous; they follow Software Engineering Institute (SEI) guidelines and must be led by SEI-trained and approved team leaders.
Senior management sponsorship includes the commitment to have the organization’s managers and staff members participate in the assessment or appraisal and to provide the resources and funding to analyze and communicate the findings. Process assessments can be performed on the entire organization or on a smaller part, such as a single project or business area. The scope of the assessment depends on the following:
Definition of the parts of the organization (e.g., sites or business areas) that will be covered by the assessment
Identification of the project and support functions that will represent the organization in the assessment
Processes that will be evaluated
It’s critical to identify opportunities for true improvement to the project’s and the organization’s performance (Table 5-1, practice 1.3). You have a myriad of ways available to identify improvements:
Measure the processes, and analyze the measurement results.
Review the processes for effectiveness and suitability.
Review the lessons learned from tailoring the organization’s set of standard processes.
Review process improvement proposals submitted by managers and staff as well as other relevant stakeholders. A relevant stakeholder is one who is identified for involvement in specified activities and is included in a plan.
Solicit inputs on process improvements from senior management and other leaders.
Examine the results of process appraisals and other process-related reviews.
Review results of other organization improvement initiatives.
Review process improvement proposals submitted by your suppliers.
Obtain feedback from suppliers on your processes and supplier-acquirer interface points.
To focus energy on those improvement opportunities with the highest impact, you must prioritize them. To do so, you consider the estimated cost and effort to implement the improvements, evaluate the expected improvement against your improvement objectives and priorities, and determine the potential barriers to the improvements and develop strategies for overcoming these barriers.
Many organizations make the mistake of trying to document all processes simultaneously, or they attempt to create highly detailed process descriptions. Organizations that attempt these approaches soon realize that they are not effective. Steve consults with Rosa to get some guidance about starting the process.
Tip
Adopt CMMI-ACQ practices incrementally, and prioritize them according to the value they add to the organization.
Steve: Okay, Rosa, so the CMMI-ACQ gives us some pointers on how to prioritize our efforts. But once we decide on what to focus on, what do we do next? We can’t afford the time to run around documenting all our processes at once! How do we communicate what’s important?
Rosa smiles.
Rosa: You’re right! Remember, I’ve been down this road before. I know your driving force is the need to meet your project schedule, come hell or high water. So we have to demonstrate how adopting the model is going to help you get predictable on your schedule.
What you need is a playbook approach, one that builds on what your organization knows about itself from its good hard look in the mirror. Simple, concise, objective statements that are unambiguous and communicate the improvement goals clearly are worth much more than a set of complex “shelfware” that is too cumbersome to be used in daily practice.
Rosa continues to encourage Steve.
Tip
Build an improvement playbook that states goals and measures simply. Use the playbook to guide your efforts.
Rosa: In this first process improvement project, remember that you’re looking for the low-hanging fruit. If you start small and demonstrate success quickly in some area of the project, even a small one, it will help build momentum. Remember how we started this conversation? You can’t do it all at once!
Steve nods.
Rosa: This approach keeps your team motivated, too. If they get positive feedback more often and see progress with incremental steps, you’ll have a much easier time keeping them enthused than if you attempt the “Mother of All Process Improvement Efforts” that seems to take forever and is too complex.
Steve: Okay. But it needs to be worthwhile, too, not just a showpiece.
Rosa: Absolutely. Later on, after you’ve gotten some stable processes in place, one of the most productive techniques for understanding where you can improve efficiency is something called value stream mapping. I’ve used this a lot. You use it to eliminate areas of little value-added activity that add time or effort to your process without much return.
Let me tell you a story.
I have a friend who works at the Department of Defense. Their office supports military aircraft. Okay, so the field maintenance techs would find a failed component. They’d remove it, pack it up, and ship it back through the government transportation system to begin the repair cycle. In between these guys and the repair facility was this checkpoint. At this checkpoint, they unpacked the item, compared it with the paperwork, and then packed it up again and put it back in the shipping cycle. All this took three days or more.
Well, guess what? More than 90 percent of the time, the items were already properly documented and addressed. All this checking was a holdover from an attempt to fix the process that had failed years ago. But meantime, the world turned, and the checking process had outgrown its usefulness and was now a drag on the system. So they did value stream analysis, and it told them to cut out this non-value-added step and save a bunch of cycle time in the aircraft repair value chain.
Steve: Well, the value of that kind of thing is obvious.
Rosa: Still, making this change wasn’t easy. It meant a potential loss of jobs, maybe closing facilities. That’s what I mean by being brutally honest. Matt is big on driving out waste from our processes. I think he’ll implement changes we might come up with, if they’re well supported and make good economic sense.
Steve nods.
Rosa: These are some things to think about for later, after you get initial process stability. I feel your pain, Steve. Obviously, you can’t do all this at once and still keep the project going. Let me think about how to help you get the most return for your time commitment, and which technique or combination we might use first to get started.
Let’s look at your project. Can you give me an example of a strength of your process?
Tip
Use sophisticated techniques such as value stream mapping appropriately, as project processes mature and stabilize.
Steve: Sure—contracts. I’ve been talking with Paula, and we both agree that we have to get the contract right up front. Our contracts process has been in place for a while—I think you would call it a stable process—and it’s laid out pretty completely. Maybe this is a strength we can build on.
Rosa: Good idea! The CMMI-ACQ gives us a couple of relevant process areas with some best practices: Solicitation and Supplier Agreement Development, and Acquisition Management. I’ll bet our contracts shop already meets many of these. This might be the quick win or low-hanging fruit we’re looking for.
Steve smiles.
Steve: Well, that was easy.
His tone tells Rosa he’s only kidding. But a small step is still a step.
Rosa: If you want me to, I can help you with some of the documentation. And I can use what we produce to start up our corporate knowledge repository of project process artifacts. One of these days, we’ll be able to give projects like yours some templates and checklists to help get them started, but we’re not quite there yet. You’re going to help us get there.
Now, Steve, don’t be nervous. It’s true, I’m using your project work to help us get started with our improvement goals at the corporate level. So, for instance, your lessons learned will help people all over the company with their own improvement activities. For you, the beauty is that you get my full attention—and, well, I know how to do this. You’ll help me, and I’ll help you. This incremental implementation of processes is reflected in the structure of the CMMI framework, which supports building project-level capability before organizational capability.
Let’s look at the structure of the model. Table 5-2 lists the five generic goals.
Any project that is accomplishing work, delivering products, and meeting its project goals is performing processes. They may not be documented processes, and they may not all be repeatable, but the project is following processes nonetheless. A key point is to understand which ones should be documented and repeated because they add business value through efficiency or effectiveness. These processes can become the foundation for describing the way a project routinely does its work and how it should continue to do its work in the future.
Once a project begins to manage its processes, it has begun to institutionalize specific practices at the project level. The CMMI-ACQ defines a managed process this way:
A managed process is a performed process that is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. The process may be instantiated by a project, group, or organizational function.
Tip
Look carefully at the processes that your organization already has in place. They may be a good place to start improvement activity.
Steve: You know what Matt was saying the other day? What we are really doing with this project is building on our foundation practices and our core competencies to come up with a strategy for what we do in-house and what we want to outsource [Prahalad and Hamel 1990]. This is getting back to basics at the organization level.
What we’re talking about here is extending our work, and getting back to basics at the project level.
Rosa: Yes! You have to start with the basics. In the CMMI-ACQ, just as in the entire CMMI framework, there are ten generic practices that satisfy the generic goal of institutionalizing a managed process. They’re really pretty straightforward and follow a logical progression. And they apply to any process area in the model.
Table 5-3 shows the list of generic practices that Rosa showed Steve.
Table 5-3. CMMI-ACQ Generic Practices
GP 2.1 | Establish an Organizational Policy |
Establish and maintain an organizational policy for planning and performing the process. | |
GP 2.2 | Plan the Process |
Establish and maintain the plan for performing the process. | |
GP 2.3 | Provide Resources |
Provide adequate resources for performing the process, developing the work products, and providing the services of the process. | |
GP 2.4 | Assign Responsibility |
Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process. | |
Train People | |
Train the people performing or supporting the process as needed. Refer to the Organizational Training process area for more information on training the people performing or supporting the process. | |
GP 2.6 | Manage Configurations |
Place designated work products of the process under appropriate levels of control. | |
GP 2.7 | Identify and Involve Relevant Stakeholders |
Identify and involve the relevant stakeholders as planned. Refer to the Project Planning process area for information on project planning for stakeholder involvement. | |
GP 2.8 | Monitor and Control the Process |
Monitor and control the process against the plan for performing the process, and take appropriate corrective action. Refer to the Project Monitoring and Control process area for more information about monitoring and controlling the project and taking corrective action. Refer to the Measurement and Analysis process area for more information about measurement. | |
GP 2.9 | Objectively Evaluate Adherence |
Objectively evaluate adherence of the process against its process description, standards, and procedures, and address noncompliance. Refer to the Process and Product Quality Assurance process area for more information about objectively evaluating adherence. | |
GP 2.10 | Review Status with Higher-Level Management |
Review the activities, status, and results of the process with higher-level management, and resolve issues. | |
This makes sense to Steve, and he begins to see the point Rosa is making. The model requirements for generic processes address foundation practices and include most of the things that a project should do anyway: Establish goals or policy, plan how to accomplish the goals of the process area, resource it and assign people to it, make sure the people are adequately trained, configuration-manage your work products (whether they’re contractor-provided or generated by the project office), ensure that the project’s stakeholders are involved, monitor and control project activity, provide quality assurance over work products and the project’s adherence to its established policies and processes, and make sure that higher management is informed routinely about project status.
Steve: Rosa, the project is already doing or planning to do much of what’s called for in the Solicitation and Supplier Agreement Management process area.
Rosa: You’re beginning to break the code! Much of what the CMMI-ACQ requires is just good management practice that you’re probably doing already. What it does is raise your awareness of processes in use and ensure that they’re supported, standardized, and institutionalized over time. The generic practices are a great place to start. And remember, the model doesn’t tell you how to meet its requirements. It focuses on what constitutes a best practice, but it leaves the “how” up to the project.
Steve: Yes, it’s making sense.
Rosa: Let me share something with you. I have a friend who works for a big government agency in Washington. Up until about a year and a half ago, they were using the Software Acquisition Capability Maturity Model [SA-CMM] as a reference model. My friend and his process guys and a couple of functional subject matter experts went off in a corner and hammered out beautiful processes and took them back to the projects.
You know what happened? They crashed and burned!
Beautiful processes that don’t match reality are about the last thing projects want to see or use. I’ve come to realize that this simply isn’t the way to do it. And this is also in the overall CMMI model, and it’s something our consultants have told us, too.
Steve: I’m glad to hear that. I was afraid of trying to meet some impossible goal that would turn out not to be very helpful anyway.
Rosa: Look at the generic practices. One is to “plan the process.” What we’re trying to do is work with a couple of projects to plan out the activities to implement the necessary practices in their project. Then see how that goes. Based on that, those two projects will pull back and say, “Here are the eight steps you had planned for getting requirements management going. So how did that go? If you had to do it again, what would you do differently?”
Steve nods.
Rosa: At that point, we’ll begin to document the process steps by looking at the planned activities that occurred in those projects. We’ll be documenting the “as-is”—build on what we already have. We’ll just work with the teams and say, “How have you done it? How will you do it on this particular project?” With no judgmental notion about it. Just put it on paper, write it out, plan it out, and then let’s watch it and see how it goes. See where the bottlenecks are, see what really happens.
Then based on that experience, we begin to document the process descriptions. Now, of course, all along we had the CMMI model in our hip pocket and our mind, and we’re looking for those practices to be planned into these efforts. We do it as we work with the project, or if not, we help them understand the reason it needs to be done. But certainly we don’t go off and write a process first in some ivory tower with the intent that everybody has to use it.
Tip
If you take a discovery and experimental approach, you may find that you are changing the process a little through each review cycle. Don’t “lock down” the process until you are finished with the cycles.
Steve: No ivory tower. Check.
Rosa smiles.
Rosa: Ultimately, once the two projects are done, we’ll let the dust settle, pull them together, and say, “What did you do? What worked?” Then document a process formally from that. That’s really what “plan the process” means. That’s what we’re trying to get to.
It’s very, very fundamental, and a lot of times it’s very soft—you know, GMA.
Steve: GMA?
Rosa: “General milling around.” People are sort of doing stuff, but it isn’t clear exactly what they’re producing and who’s doing it. Is it us or them?
Steve: Now I’m a little bit lost.
Tip
Often, only suppliers produce a project plan. The acquirer also needs a project plan to manage its activity and its various interfaces with the supplier.
Rosa: No problem. Let’s look at Project Planning again. We go in and ask a project manager, “Do you have a project plan?” He says, “Well, yes, that’s what we’re getting as a deliverable from the supplier.”
Uh-oh. We say, “No. Do you have a project plan for your effort?” The project manager says, “Just the one the supplier’s delivering.” So all of a sudden, you crack into the supplier’s plan, and you see very few acquirer activities in there. It’s all about what the supplier’s going to do for this project and how they’re going to execute the task order, and that sort of thing.
So what we’re trying to do is say, “Look, the basic concept is that we have to plan, write our own project plan specifically on the acquisition side. The roles and responsibilities have to be explicitly stated in there, so it’s very clear to everybody who does what.”
There is a pause while Steve thinks through what Rosa has said.
Steve: Wow, you’ve said a mouthful, Rosa. I like your good practical advice about avoiding the ivory tower approach to document the “perfect process,” and how to build on what we have in a practical way by using basic building blocks like the generic practices. I also like the points you made about making sure we exercise our responsibilities.
Rosa: Good. You understood me perfectly.
Steve: But I think some of the team, including some of our managers, thought we could just adopt contractor processes and plans without effort on our part.
Rosa smiles.
Rosa: I told you—I’ve been down this road before.
The CMMI-ACQ provides specific recommendations on how to plan and implement process improvement activities (see Table 5-4). To implement your process improvements successfully, the process owners, those who perform the process, and support organizations need to participate in the process definition and improvement activities.
Table 5-4. Organizational Process Focus Goal 2: Practices and Tips
CMMI-ACQ Process Area: Organizational Process Focus | ||
2. Goal: | Improvements are planned and implemented, organizational process assets are deployed, and process-related experiences are incorporated into the organizational process assets. | |
Practices | Tips | |
2.1 | Establish and maintain action plans to address improvements to the organization’s processes and process assets. |
|
2.2 | Implement process action plans across the organization. | |
2.3 | Deploy process assets across the organization. | |
2.4 | Incorporate process-related experiences into the organizational process assets. | |
The acquirer involves stakeholders such as process owners, process action teams, and the management steering committee to obtain buy in of the process improvements. This approach increases the likelihood of effective deployment (Table 5-4, practice 2.1).
Process action plans are detailed implementation plans. They typically cover the following:
Process improvement infrastructure
Process improvement objectives
Procedures for planning and tracking process actions
Strategies for piloting and implementing the process actions
Responsibility and authority for implementing the process actions
Resources, schedules, and assignments for implementing the process actions
Methods for determining the effectiveness of the process actions
Risks associated with process action plans
Process action plans differ from the organization’s process improvement plan in that they target specific improvements that have been defined to address weaknesses usually not covered by appraisals. If the processes that define interfaces between acquirer and supplier are targeted for improvement, suppliers may be involved in developing the process action plans.
You should implement process action plans and deploy organizational process assets or changes to organizational process assets in an orderly manner (Table 5-4, practices 2.2 and 2.3). It may not be appropriate to implement some organizational process assets or changes to them in some parts of the organization (for example, because of customer requirements or the current life-cycle phase being implemented). It is therefore important that those personnel who are or will be executing the process, as well as other organization functions (such as training and quality assurance), are involved in deploying changed or new processes. In the supplier agreement, you define how changes to organizational process assets that affect the supplier (e.g., standard supplier deliverables, acceptance criteria) must be deployed.
You derive lessons learned from defining, piloting, implementing, and deploying the organizational process assets (Table 5-4, practice 2.4). For example, projects collect lessons learned from a project activity such as a design review or user acceptance test so that they can improve the process the next time. This requires effort on the part of projects to identify and collect useful improvement information, and on the part of the organization to designate a method and a place to store this information and make it widely available. Many firms and agencies use electronic collaborative workspaces for this purpose.
“Standardize whenever possible” was one of the hidden truths that Matt spoke about in his briefing to the other senior managers.
Processes, contracts, requirements, products, and product components are all viable candidates for standardization. Don’t buy in to the myth that standardization stifles creativity. On the contrary, teams have more freedom to be creative and productive when they are allowed to focus on a handful of requirements that are specific to the project and can leverage predefined requirements and reuse products and product components.
Steve believes that implementing this concept (especially with standardized processes) is critical to the start-up phase of the project. He realizes that the project is already following a standard process in the procurement area. All projects must follow the standard procurement rules, or else they don’t get funded. Contracting and procurement seem to him to be a good example of a process that is already standardized across the organization.
Another is metrics. The organization requires routine earned value reports on project status and requires a standard way to present project cost and schedule data. Using these existing processes as starting points for process improvement makes sense to Steve. The existing processes are not very far out of line with the best practices called for in the CMMI-ACQ.
Tip
Standardized processes already exist in many organizations. If possible, build on what is already there.
Steve mentions this observation to Rosa. She tells him that those two examples touch on several process areas in the model, such as Acquisition Management, Measurement and Analysis, and Project Monitoring and Control.
Rosa: This is why I really like the model. It’s not just theoretical. We can use it to translate a real-world issue and guide our thinking about how to implement best practices.
Steve: Come on, Rosa, you know I’m a fan of this approach. I just wish you had a magic wand sometimes! The acquisition management suggestion is a good one, and it fits with what Paula and I were thinking. Thanks for the idea.
Even though things are starting to fall into place, Steve is still struggling with the issue of how to standardize work with the supplier. He thinks the answer may lie in touch points, a topic he and Paula have agreed to discuss further.
The buyer-seller relationship between acquirer and supplier implies that not all processes can be shared between them. But it’s important to look at the entire value chain embodied in the acquirer-supplier relationship to understand the effects of collaboration (or the lack thereof). If the supplier and acquirer don’t or can’t completely share all processes that they have in common, they can easily find themselves in a maturity “mismatch.”
A growing body of evidence suggests that just because a company, a government program office, or a supplier has a certain maturity or capability level rating, it is no guarantee of future performance. In fact, as illustrated in Figure 5-1, a high-maturity supplier paired with a low-maturity acquirer can experience degradation in their supplier processes. The cause is the acquirer tends to take actions such as encouraging shortcuts. To use a statistical analogy, both organizations can tend to “regress to the mean” of their combined maturity levels. This is why it’s important to collaborate and cooperate at key points in the overall process value chain. Not only does it make the entire cycle more efficient, but also it vests both supplier and acquirer in the success of their mutual enterprise and binds them together toward the common goal.
What are the boundaries of processes in the acquisition context? In this instance, we’re addressing not only the internal processes of the acquirer and the supplier, but also the fundamental and important linkages and touch points between them that are critical to the success of the acquisition.
Figure 5-2 illustrates the flow of acquiring a product or service, including the critical touch points between supplier and acquirer. Note that the acquirer and the supplier adopt different primary roles as the acquisition process progresses and also that linkages occur throughout the process. For instance, the acquirer adopts an insight and oversight role during development of the technology solution, whereas the supplier adopts a builder role. Their touch points can take the form of meetings, artifacts (such as source code and test results), and many other forms. The individual processes of the acquirer and the supplier must be in harmony to maximize efficiency and throughput of the overall acquisition.
Tip
Support standard roles and responsibilities through clearly defined acquirer-supplier touch points.
Note that throughout the development of the product, even though you are not directly producing the product you must maintain insight into and oversight of the supplier’s processes. You must do this in a disciplined manner that doesn’t impede the efficiency of the process. This is an example of how the CMMI-ACQ applies to the processes of both the supplier and the acquirer.
When Steve and Paula get together in the morning, Paula begins the discussion.
Paula: We talked yesterday about the need for process stability. You remember that I mentioned touch points, and how we might use them to decide what our most important collaboration opportunities might be. Let’s talk about touch points.
Steve: I hate to admit it, but I’m not sure what the term means exactly. Can you help me out, Paula?
Paula: I think that “touch points” originally comes from marketing and advertising. It’s how a company “touches” a customer. Hold on, I think I have a good definition here.
Paula reads from her laptop screen (http://www.livework.co.uk/home/research0/glossary.html).
Service touch points are the tangibles that make up the total experience of using a service. Touch points can take many forms, from advertising to personal cards, web, mobile phone, and PC interfaces, bills, retail shops, call centers and customer representatives. When we design services, we consider all touch points in totality and craft them in order to create a clear and consistent unified customer experience. The tangible touch points of the service are one of the key factors that determine people’s experience of service quality.
Steve: Oh, okay.
Paula: In our context, I think of touch points as part of the overall value chain that creates, delivers, and maintains our product. When you look at the value chain as an overall process, the interfaces where we and the supplier interact are the touch points.
Paula brings up an image on her laptop and turns the screen toward Steve (see Figure 5-3).
Paula: I originally drew this on a cocktail napkin, but I’ve cleaned it up a little. It may not cover all the touch points, but I think it’s a good start.
Steve: Okay, so look at the solicitation and source selection phases. What touch points does the supplier have there?
Paula: We often do RFIs to try to identify whether the supplier has the capability to perform—or even to identify potential suppliers. This is before we begin formal solicitation, bidding, or source selection. So to respond to that, the suppliers need to begin to plan their potential product design early on. So the RFI is our first touch point with them.
Matt Vauban has talked to Steve and Paula about the relationship that needs to be established between the acquirer and the supplier during development. This is the phase in the life cycle when the acquirer adopts the role of monitoring and overseeing the supplier’s development process. In many cases, acquirers opt out of this role and more or less wait passively for the acceptance test of the final product. Paula and Steve know that this practice often has dire consequences.
Paula: You know, Steve, we talked yesterday about the formal contract relationship between us and the supplier, and how we have a legal and fiduciary responsibly over the development. I can think of many touch points along the way that we need to define.
Steve: You’re right. A lot of these are pretty straightforward, like specifications, system test, formal acceptance and sign-off, and so on. But some of them aren’t so obvious—like shared risk management and configuration management over work products that we use to manage the project. It’s really important to look at this entire process as a value chain that flows back and forth between us and the supplier.
Paula: I see what you mean. We have to look at the whole supply chain, not just one segment. If we don’t, we’ll be suboptimizing our efforts.
Steve: I think we need to get our brain trust together to develop a list of the most important touch points. Then we can evaluate the ones we already have a process for and the ones we don’t. This will help us focus on the most important ones first.
Paula agrees, and they plan how to proceed by listing the key acquisition functions: contracts, systems engineering, the customer or functional representative, and others. With input from these stakeholders, they’ll be able to list key touch points and use this list to guide and prioritize their process improvement activity.
Paula and Steve talk briefly about the steps that will follow this initial work: documenting and verifying existing processes and beginning to address the activities that don’t have documented processes. After a supplier is identified, this effort can serve as the beginning of collaboration and standardization of the interfaces between the acquirer and the supplier.
Steve leaves Paula’s office believing that they’re on the right track with their decision to base collaboration opportunities on touch points. In the hallway he runs into Matt, who pulls Steve into his office.
They sit and talk about the idea of using touch points, and then Matt waxes philosophical about the difficulty of changing the way an organization functions.
Matt: What we’re trying to do is adopt a life cycle that’s standards-based so we have some sort of underlying framework that ties everything together. But it’s hard work.
In any organization, as you go along in time, the way people do their work gets ingrained in their day-to-day activities. The longer that occurs, the more resistant they are to understanding or moving to a common framework. So that presents challenges to us.
Steve agrees. He tells Matt that he’s concerned about managing change within his team. He relates Rosa’s point that the ivory tower approach to improvement doesn’t work and talks about his commitment to small, practical steps.
Matt: That’s good. The team is more apt to engage with you if you do it that way. Coming to a functional group with a nice clean-looking process makes their eyes glaze over. You have to adopt different roles in different situations: mentor, coach, or teacher. If you work with them and show them you understand where they’re coming from, you open the door. And then as you work with them, you’re teaching, you’re guiding. Then they begin to contribute: “Hey, how about adding this step in here?” And so they feel a part of the whole effort. They like that. And they know the big boss is really all into this. So, it all works together.
Matt leans back in his chair.
Matt: I have a friend who still works for a big industrial firm where I used to work—huge company, international. They’ve gone into outsourcing in a big way. They use what DoD calls the “alpha contracting” approach. Here, Steve, here’s a write-up.
Steve reads from a Navy reference that Matt has downloaded and printed (http://acquisition.navy.mil/navyaos/content/view/full/132).
Alpha Contracting streamlines the acquisition process and reduces cycle time for contracts. It emphasizes conducting actions concurrently, with a close relationship between an integrated Government team and the contractors. For example, under Alpha contracting, the Government and contractors may work together to develop a solicitation package that meets the Government’s needs, while also eliminating contractor questions or concerns with it. Similarly, as the contractors complete development of portions of their technical and cost proposals, an integrated Government team, including representatives of the program office, the contracting office, the contract administration office, and the Defense Contract Audit Agency (DCAA), may review the proposal and attempt to resolve issues the team identifies. When the completed proposals are then formally submitted to the contracting officer, much of it may already be negotiated. This approach is much more likely to result in an optimized program with an achievable scope, improved performance or quality, and the avoidance of non-value added requirements, at a lower overall cost than what was originally contemplated.
Matt: You get the picture. The acquisition is viewed as a collaborative effort between supplier and acquirer. Both parties participate mutually to ensure that the overall process and touch points, such as solicitation, proposal review, and so on, are collaborations and not adversarial.
Steve: It sounds kind of like what we’re trying to do.
Matt: Let me tell you a story. My former company adopted this philosophy in outsourcing their IT work. They were heavy users of IT services, but IT was not their core business. So they brought in all the suppliers to develop the process and the overall operational environment they’d be living in for the next few years. They jointly defined and developed common global IT execution processes. By having the potential suppliers work together with the company, it fostered a “one-team” mentality. So they were able to identify and resolve problems early. It let them leverage the best thinking in the industry. The suppliers, even before they were suppliers, got an early, up-close look at the operability of the processes.
The bottom line is, those suppliers have a sense of joint ownership. So the company can focus on delivering innovation and business value instead of spending much of their time managing supplier interactions.
Tip
Use touch points between acquirer and supplier processes as guides for beginning collaboration on improving your processes.
Matt pauses and then continues his story.
Matt: The suppliers also work with each other, so the company doesn’t have to mediate all the time. This frees up management to focus on being an IT “broker,” which I think is the wave of the future. The company focuses on their core competencies: IT strategy, operations oversight, and supplier management, and the suppliers handle the tactical day-to-day execution and delivery. They determine “what” and “how well,” and the suppliers determine “how.”
Steve: This reminds me of an article I read about “swim lanes.” You know—how you map ownership of all your tasks so everybody knows what lane to be in.
Matt: Yes! Swim lanes is a good way to look at it.
Touch points are a key innovative element of Steve’s model. Touch points are the formally defined interactions in a process, each of which typically has predefined deliverables. You define touch points not only for acquirer-to-supplier interactions but also for supplier-to-supplier interactions. The result is a clear and consistent understanding of what is expected during the execution of a process between all parties involved, including those between different suppliers. It removes you as the intermediary between multiple suppliers, improving cycle time and freeing up your resources. Reinforce touch points by including them as requirements in the contracts.
Matt: There are quite a few lessons learned there, Steve. I can put you in touch with a friend of mine who still works there, if you want to follow up. In fact, I think he’s coming to town in a couple of weeks. I’ll see if he can spend some time with us and share some of his insights.
Steve: That would be great. Thanks!
Steve leaves this meeting feeling that he’s taking the correct approach, at least as far as Matt is concerned. Steve feels better knowing that he has an experienced resource from whom to draw lessons learned. If this is what Rosa is trying to do to help projects get started, Steve is all for it. He decides to visit Rosa again soon.
Tip
You are not the first to begin improvement activity. Leverage lessons learned from as many sources as possible.
You must provide a “home” for process improvement activity—a so-called process asset library. This repository can have humble beginnings and might be as simple as one person using commonly available desktop programs such as spreadsheets and presentation software to document processes. Starting simply, this effort can be initiated from the bottom up, starting project by project. However, without higher-level management support, it is difficult to sustain this activity over time and expand it across the organization (where even larger benefits can be realized).
Tip
Combine bottom-up and top-down approaches to begin building the process asset library as soon as possible, using early improvement projects as a starting point.
The CMMI-ACQ provides specific recommendations on how to establish and maintain a usable set of organizational process assets and work environment standards (see Table 5-5). Organizational process assets support consistent process performance across the organization and provide a basis for cumulative, long-term benefits.
Table 5-5. Organizational Process Definition Goal 1: Practices and Tips
CMMI-ACQ Process Area: Organizational Process Definition | ||
1. Goal: | A set of organizational process assets is established and maintained. | |
Practices | Tips | |
1.1 | Establish and maintain the organization’s set of standard processes. |
|
1.2 | Establish and maintain descriptions of the life-cycle models approved for use in the organization. | |
1.3 | Establish and maintain the tailoring criteria and guidelines for the organization’s set of standard processes. | |
1.4 | Establish and maintain the organization’s measurement repository. | |
1.5 | Establish and maintain the organization’s process asset library. | |
1.6 | Establish and maintain work environment standards. | |
An organization’s set of standard processes typically includes technical, management, administrative, support, and organizational processes (Table 5-5, practice 1.1). Your set of standard processes also describes standard interactions with suppliers. Supplier interactions are typically identified in terms of deliverables expected from suppliers, the applicable acceptance criteria, standards (e.g., architecture and technology standards), and standard milestone and progress reviews.
Basing standard processes on industry standards and widely accepted models, using common terminology, enables seamless interactions between you and the supplier. In a multisupplier environment, this is most important for your standard processes that directly interface with the supplier processes. Also, you may gain cost and coordination benefits from having suppliers work together to develop or reconcile common support processes that are aligned with your processes.
Standard processes can be defined at multiple levels in an enterprise, and they may be related in a hierarchical manner. For example, an enterprise might have a set of standard processes that is tailored by a division or site to compose its own set of standard processes. The processes may also be tailored for each business area or product line. Thus, your organization’s “set of standard processes” can refer to standard processes established at more than one level, although some organizations may have only a single level of standard processes.
When you work with more than one supplier or when technology solutions must be delivered to different customers and markets, you may identify more than one life-cycle model for use (Table 5-5, practice 1.2). The life-cycle models describe acquisition life cycles, depending on the specific acquisition strategy chosen. The acquisition life cycle typically begins with the pre-award phase of a supplier agreement, continues through the phases of awarding and managing the agreement, and ends when the agreement period of performance ends. The latter is usually marked by the acceptance and completion of the warranty for the acquired product and the transition of the product to a support organization.
Tailoring is a critical activity. It allows for controlled changes to the processes to meet the specific needs of a project or a part of the organization (Table 5-5, practice 1.3). Processes and process elements that are more directly related to critical business goals and objectives should usually be defined as mandatory (allowing less variation), but those that are less critical or only indirectly affect business objectives may allow for more tailoring (and therefore more variation). The degree of tailoring can also depend on the life-cycle model of the project, the supplier, or the acquirer-supplier relationship.
To fully leverage the supplier’s process capability, you may choose to minimize the tailoring of the supplier’s standard processes. Depending on the interfaces between your processes and the supplier’s processes, your standard processes may need to be tailored to allow the supplier to execute its standard processes.
For process improvement, it is critical that you establish and maintain a measurement repository and a process asset library (Table 5-5, practices 1.4 and 1.5). The measurement repository contains product and process measures related to your set of standard processes. It also contains or refers to the information needed to understand and interpret the measures and assess them for reasonableness and applicability. For example, the definitions of the measures can be used to compare similar measures from different processes.
It is equally important for you to establish work environment standards (Table 5-5, practice 1.6). These standards allow the organization and projects to benefit from common tools, training, and maintenance and to realize cost savings from volume purchases. Work environment standards address the needs of all stakeholders and consider productivity, cost, availability, security, and workplace health, safety, and ergonomic factors. Work environment standards can include guidelines for tailoring and the use of waivers that allow you to adapt the project’s work environment to meet specific needs.
It seems that getting started is one of the most difficult things for an organization to do in the process improvement arena. Most successful efforts start small. If the project resides in an organization that already uses defined processes, it can get a start by tailoring them. But just like trying to do things on too grand a scale, unbounded tailoring also can be a pitfall.
As he planned, Steve is meeting with Rosa in her office.
Steve: Last time we talked, Rosa, you gave me some really good ideas. I need to present them to the team so we can plan our kickoff. I’ve been thinking about that quite a bit—the issue of how to get started in the right way and then keep momentum going. Any lessons you can share in this area?
Rosa: Well, Steve, remember what you don’t want to do. You don’t want to try to document all your processes. What we’ve been talking about is picking your targets for quick payback first, and then tackling the more complicated problems.
Let’s get started by looking at the flow of work and the work environment to identify the bottlenecks. I’ll tell you a secret. We process people love to draw boxes with arrows between them almost as much as engineers do!
My point here is that you have to get the basic things right first. Hire good people, train them, and give them the right tools. Plan the activity and measure progress. You know, the basics!
After we get started with this project, Steve, I’m going to host some of your project templates and checklists in the process asset library I’ve started. We have a long way to go, but you have to start somewhere, right?
Tip
Make it safe for the project and the organization to experiment and to make mistakes. But capture lessons learned for next time in a process asset library.
Steve nods and writes on his yellow notepad.
Rosa: Remember, one size doesn’t fit all. Don’t be afraid to make mistakes. If you find yourself in a box, try something else. Don’t take no for an answer. You can get a good start by removing non-value-added controls—low-hanging fruit, right? Remember my story about the military package inspectors? Cutting out an activity is just one approach.
I was talking to Paula the other day. She’s a big advocate of making detailed plans for small increments of projects that can be managed more easily. She claims she’s been successful in starting and maintaining measurable progress because she’s able to quickly manage increments to closure. This helps her keep the overall effort on track. She can make midcourse corrections before problems get too big. It also helps staff morale, since team members get quick feedback and frequent closure on tasks.
But Paula likes the small-ball game most because her customers like it.
Steve: Small ball? I didn’t know you were a baseball fan.
Rosa: I’m originally from D.C.! Whenever I’m home, I try to catch a Nationals game.
Steve and Rosa briefly discuss the merits of the National League versus American League styles of play, and then Steve brings them back to the subject at hand.
Steve: You were saying that Paula likes her incremental project management style because her customers like it.
Rosa: Yes. Instead of waiting for a “big bang” delivery that might be off target, they’re happy to get incremental delivery and have the chance to make corrections along the way.
Steve: Good. That makes sense. Any more ideas?
Rosa: I think one of the most fundamental issues is, you must manage the process improvement effort as a project, with all the rigor and discipline you’d apply to any other project. It’s critical to get quality and process performance objectives documented and agreed to by all the key players. The worst thing you can do—and believe me, I’ve seen this happen—is to go in and brief your boss and Matt with a wishy-washy, touchy-feely program status review. They’ll cut you off and tell you to come back when you’re prepared and have your data. They absolutely make decisions based on facts and evidence, not intuition and feeling.
Steve: Thanks, Rosa. That’s good advice. I’ve worked for these guys for a while now, and I know exactly what you mean! It’s a great idea to manage this effort as a real project, with milestones, metrics, program reviews, decision points—the whole nine yards.
Rosa: So Steve, are you using the CMMI-ACQ to help you build your project plan for the improvement part of the project?
Steve: Hmmm. I hadn’t thought of using it like that. But now that you mention it, we could use the process areas to structure our plan. Maybe ... Project Planning, and Measurement and Analysis, and Project Monitoring and Control.
Rosa: Exactly.
Steve: That would also give our team more practice with using the model before we get deep into the acquisition. I’m going to take this back to our team and get it started.
A fundamental aspect of managing process performance is the ability to manage multiple improvements simultaneously, whether they occur in individual projects, at the organization level, or in process areas. It’s a good idea to take a portfolio approach. You manage improvement projects individually, but you manage the overall set of improvements as a portfolio.
This portfolio management approach requires that the process improvement manager as well as senior management have a view of the enterprise and a set of goals to guide their execution and improvement efforts. For example, a stock portfolio is managed to reduce risk and maximize return. In the same fashion, a process improvement portfolio is tied to business goals, with an objective such as maximizing efficiency in the overall acquirer-supplier value chain. Setting such overall objectives is critical to guiding a portfolio of improvement projects.
Tip
Use quantitative analysis to understand any constraints that impede the overall performance of the organization.
To set objectives that target those areas that yield the highest impact, you can also apply the theory of constraints to the project portfolio. For instance, suppose that an overall goal of a supply-chain system is to move from a forecast model to a replenishment model. In a forecast model, acquirers forecast their demand and provide it to vendors, and then vendors plan to meet the demand accordingly. Inaccurate forecasts or data latency can often cause shortages or stock-outs or, conversely, oversupply and excess inventory handling costs. In a replenishment model, a just-in-time approach is used to ensure that vendors have an accurate view of a production line in nearly real time. This enables a vendor to replenish necessary items to the line as close as possible to the time they are needed. Applying the theory of constraints provides a methodology to evaluate the existing condition, model the desired end state, and then provide implementation steps to begin the transformation process.
One afternoon, Matt calls Paula into his office.
Tip
Keep the overall objective in focus, and communicate how every individual and every project contributes to the overall success of acquisition in the organization.
Matt: Paula, I’ve been thinking about our process improvement program. I think we have a pretty good handle on managing at the project level, but I’m not so sure we’re doing as well at the overall organizational level. If we don’t look at the entire flow of work between us and our suppliers as an interrelated system, I’m afraid we’re missing the point.
Paula: You’re right, Matt. Everything I’ve read indicates we need to manage this effort as a set of interrelated activities that contribute to our overall objectives.
Matt: Yes! We need to keep managing projects individually, but we also need to take a big-picture view of our entire value chain and determine the contribution of each project to it. If we don’t look at the big picture as well as the individual project, I’m afraid we will be suboptimizing our scarce resources—both human and capital.
Here’s my issue. If we do each acquisition as an individual procurement, our suppliers will treat our work as a one-time thing every time. We’ll pay for each buy as if it’s the first time, and we won’t realize as much benefit as we should. Even worse, we won’t have a handle on our overall performance from the standpoint of our bottom line. What we need to create is a funnel of solutions that moves smoothly through the acquirer and supplier acquisition process and gives results when the customer needs them—not too early, and certainly not too late.
After you have stable processes and process measures in place, how can you understand where to start in optimizing the overall acquirer-supplier process? First, you need to determine what the process chain looks like for your project—or, more important, for the family of projects, if you have multiple projects ongoing within the organization. Then you can refer to the Organizational Process Performance process area in the CMMI-ACQ. It provides best practices for selecting processes for improvement focus, setting goals for organizational processes, and then tracking progress toward meeting the goals.
A good place to start is with the pacesetters in the integrated process chain (i.e., the subprocesses that determine the “delivery speed” of the joint acquirer-supplier capability). You can identify the pacesetters by using a number of project management techniques, such as critical path or critical chain analyses. These techniques are based on the idea that resources and processes determine delivery capability and that you must have a good handle on available resource capacity on the critical tasks and processes.
Again, think about not only how these processes operate at the individual project level, but also how you can apply them beyond a project or program to the entire organization. This thinking should account for the context of the acquisition strategy and the organization’s overall strategic and business objectives or mission. When starting out, often projects don’t yet have the means or the data to quantify process improvement, because they don’t have stable processes that can be repeated and measured over time.
Tip
Gradually expand your process performance model to encompass your entire value chain from end to end.
After you have identified these pacesetters, you baseline their performance and set their performance objectives. Here again, the CMMI-ACQ provides best practices, and again, it is important to emphasize that these practices are established at the organizational level so that projects don’t reinvent the wheel.
However, because acquisition activity often occurs at the project level, remember that these objectives can be tailored for a project according to guidelines already established by the organization. Additionally, to apply portfolio management to the entire set of activities requires a means to manage according to a master plan and schedule. Note that this activity is described in the Project Planning process area. Naturally, these aggregated plans and schedules must be based on and support the overall acquisition strategy and strategic objectives of the organization.
The CMMI-ACQ provides specific recommendations on how to establish and maintain a quantitative understanding of the performance of your organization’s set of standard processes in support of quality and process performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization’s projects (see Table 5-6).
Table 5-6. Organizational Process Performance Goal 1: Practices and Tips
CMMI-ACQ Process Area: Organizational Process Performance | ||
1. Goal: Baselines and models that characterize the expected process performance of the organization’s set of standard processes are established and maintained. | ||
Practices | Tips | |
1.1 | Select the processes or subprocesses in the organization’s set of standard processes that are to be included in the organization’s process performance analyses. |
|
1.2 | Establish and maintain definitions of the measures that are to be included in the organization’s process performance analyses. | |
1.3 | Establish and maintain quantitative objectives for quality and process performance for the organization. | |
1.4 | Establish and maintain the organization’s process performance baselines. | |
1.5 | Establish and maintain the process performance models for the organization’s set of standard processes. | |
Process performance is a measure of the actual results achieved by following a process. It is characterized by process measures (e.g., effort, cycle time, and defect removal effectiveness) and product measures (e.g., reliability, defect density, capacity, response time, and cost). Most organizations are not ready to begin rigorous quantitative organizational process improvement until stable processes exist at the project and organizational levels that can be repeated and measured over time.
Nonetheless, keeping these practices in mind can guide near-term activity in other process areas and facilitate migration to organizational process performance when the time is right. Many organizations have adopted approaches such as “lean,” often supported by six sigma or other quantitative techniques. These approaches complement the improvement framework set forth in CMMI-ACQ. Organizations that have adopted these approaches have a strong foundation on which to base a robust measurement and analysis capability, organizational process performance, and quantitative project management when required to meet organizational and business needs. The CMMI-ACQ provides a means to institutionalize these approaches over time and realize long-term organizational change.
Typically, it is not possible, useful, or economically justifiable to apply statistical management techniques to all the processes or subprocesses in your set of standard processes (Table 5-6, practice 1.1). When you select the processes or subprocesses for analyses, it is critical to understand the relationships between the various processes and subprocesses and their impact on your and the supplier’s performance in delivering the product specified by the customer. Such an approach helps ensure that quantitative and statistical management is applied where it has the most overall value to the organization.
Here are examples of criteria that you can use for selecting a subprocess for organizational analysis:
The relationship of the subprocess to key business objectives
Current availability of valid historical data relevant to the subprocess
The current degree of variability of this data
Subprocess stability (e.g., stable performance in comparable instances)
The availability of corporate or commercial information that can be used to build predictive models
To measure your quality and process performance objectives, you may need to combine existing measures into additional derived measures to provide insight into the overall efficiencies and effectiveness at a project, program, and organization level (Table 5-6, practices 1.2 and 1.3). You can use the analysis at the organization level to study productivity, improve efficiencies, and increase throughput across projects.
The expected process performance can be used in establishing the project’s quality and process performance objectives and can be used as a baseline for comparing actual project performance. This information is used to quantitatively manage the project. Each such project, in turn, provides actual performance results that become a part of the baseline data for your process assets.
You derive process performance baselines by analyzing the collected measures to establish a distribution and range of results that characterize the expected performance for selected processes when used on any individual project in the organization (Table 5-6, practice 1.4). You use process performance models to estimate or predict the value of a process performance measure from the values of other process, product, and service measurements. To estimate progress toward achieving objectives that cannot be measured until later in the project’s life cycle, process performance models typically use process and product measurements collected throughout the life of the project (Table 5-6, practice 1.5). These measurements are also used to set performance objectives for the suppliers and to provide data that can help suppliers achieve them. The results of your process performance models are frequently shared with the suppliers so that they can ensure synchronized delivery of products and services.
Changing human behavior at the individual, group or team, and organizational level is a complex subject about which volumes have been written. In this section we discuss the cultural changes that can be accomplished within the context of the CMMI-ACQ.
Most change management authors agree that for change to succeed, the organization’s management must be involved at multiple levels: Top, middle, and team or group leadership must be engaged. This ensures that the effort focuses on the behavioral and cultural aspects that need to be addressed if change is to be successfully begun and sustained. Communication, training, and rewarding behavior that supports the change are key aspects of reinforcing cultural change. The CMMI-ACQ offers best practices to help in the “charge for change.”
Successful organizations have made the internal transformation to a culture of identifying problems and solving them as quickly as possible. This transformation must be reinforced at the individual and team levels to become institutionalized as “the way we do things here.”
Matt calls Steve in for a short meeting.
Matt: I just want to touch base with you on something I’ve been thinking about. With this process improvement, I think we need to remind ourselves how important it is to motivate people and keep them enthusiastic about the process.
Steve: Yes, I agree.
Matt: This goes along with something I’ve been reading about—the idea that process improvements need to deliver short-term wins that contribute to the overall project goals [Kotter 1996]. Here’s a handout I picked up yesterday. This is a list of the value of short-term wins.
Matt hands the paper to Steve, who reads through it quickly.
Provide evidence that sacrifices are worth it! Wins greatly help justify the short-term costs involved.
Reward change agents with a pat on the back: After a lot of hard work, positive feedback builds morale and motivation.
Help fine-tune vision and strategies: Short-term wins give the guiding coalition concrete data on the viability of their ideas.
Undermine cynics and self-serving resistors: Clear improvements in performance make it difficult for people to block needed change.
Keep bosses on board: Provide those higher in the hierarchy with evidence that the transformation is on track.
Build momentum: Turn neutrals into supporters, and reluctant supporters into active helpers.
Steve: Good stuff. We all should be really aware of these issues day-to-day. If we don’t walk the talk, how can we expect our people to?
Matt: Exactly.
Steve: Okay if I take this handout for reference?
Matt: Sure thing. Oh, and another great book is 1001 Ways to Reward People [Nelson 1997]. Here, take my copy.
On his way to his team meeting, Steve stops for a cup of coffee. When he arrives at the meeting a few minutes late, his project team members are already there. He begins by giving a brief summary of his discussions over the past several days.
Steve: One of the things we need to do is to apply the model to ourselves as we plan this acquisition. And one of the things I’ve heard over the past few days is that it’s extremely important to plan process work just as much as we expect our project managers to plan their projects. We have to take that pill ourselves, and keep ourselves from getting off track.
You know I’ve always been a real believer in planning, tracking to a plan, and learning from it. Maybe I’m a CMMI zealot now, because I think I get it. I see where it’s so much nicer to have something on paper that you’re tracking against instead of dreaming it up every time you have a meeting and rehashing the same stuff again.
The team members begin to discuss how to do this, focusing on two process areas in the CMMI-ACQ: Project Planning and Project Monitoring and Control. The first will help them build the plan, and the second will show them how to track its progress. Steve has prepared a slide show, and it guides the discussion. When he is satisfied that everyone understands the concepts, he brings up a related topic.
Steve: Another issue I’ve been thinking about is culture change. We have to address the human relations aspects of this. I know I can be a little too task-oriented sometimes, but maybe you can teach an old dog new tricks! I’ve been trying to get a handle on how we can make sure we sustain the changes we’re bringing to our organization. We need to focus on two things, and in my mind they’re related: process changes and short-term wins.
We need to encourage everybody to identify process changes as often and whenever they can. These are our first line of defense against “business as usual.” Companies like Toyota have done this successfully, so why can’t we? [Liker 2006]
Steve looks around the table.
Steve: Do we have barriers to process change ? What are they?
Team Member 1: Shoot the messenger! People have good ideas for improving things, and they bring them up to managers. But if it’s going to affect schedule or budget, it’s discounted and you’re told to stick to the job. It’s no wonder people stop reporting problems.
Team Member 2: Right! And another thing, remember the suggestion program they introduced last year? I never hear about any feedback from it. Did you ever see anyone here get an award for a process improvement? This sends the message, “Why bother?”
Steve: Obviously, we need a new approach. I know I can get my boss and Matt Vauban to put out the word top-down that we’re going to make a fresh start on employee improvement suggestions. That’s a great idea.
Team Member 3: Speaking of suggestions, I have one—pizza at every team meeting.
Team Member 3: So what have you done for us lately?
Steve: Hey now, behave yourselves. Settle down.
Steve smiles.
Steve: Okay, pizza every time someone brings me a serious problem on the project.
General approval is expressed.
Tip
Employee recognition can send a positive message that can help accelerate improvement efforts. Recognition can be formal or informal, and it need not be expensive to be very effective.
Steve: Meanwhile, I have another concern. How will we identify, elevate, and track improvements? Didn’t one of you work on the IT help desk a while back before you saw the light and joined our team?
One team member half-raises her hand, wincing.
Steve: Please, I’m really not picking on you, Carrie. I want to see whether we could use something like a trouble ticket system to track process improvements. Doesn’t have to be sophisticated, but I think it could help us get started.
Carrie: Well, I think we could make that work. It could be Web-based.
Steve: Yes! With a Web site, we could also give quick feedback to the person making the suggestion and publish overall project statistics that communicate what we’re doing. Who knows, we could even add blog capability—let people blog our process and progress. Get everybody involved. What do you guys think?
The team members seem to agree with this.
Steve: These ideas have the potential to really help us improve our efficiency in day-to-day operations. They’ll also help us meet the overall goals of the acquisition project, which of course is our “real” job.
People’s attitudes about change can make or break change efforts. Behavior change must be reinforced at all levels to be successful. It’s important to have executive support and a clear, consistent message from top leadership that is sustained over time and equally vital to have change supported by middle management and at the team and individual levels. Sometimes the mechanisms to reinforce changes in behavior already exist in an organization, and sometimes new approaches are required.
Steve: Obviously, we should not lose sight of the overall strategy, but I’m convinced we need to focus on small steps as we move along. The short-term win approach has a lot of appeal for me. I think the internal Web site we talked about can help us do this. What we’re trying to do is to say, “Stop and look around. If you see a problem or bottleneck, report it. Let’s tackle it and solve it.” We need to make sure this message gets out.
I’ll also talk to my boss and Matt Vauban about using the quarterly awards ceremony to highlight everybody’s improvement suggestions. Maybe we can get some coverage in the monthly employee newsletter, too.
Team Member 3: What about us? Some of us are supervisors, and we need to set an example in our daily work as well as get the word to employees about how to use the new system.
Steve: Okay, I’ll talk to corporate training and see if we can get some help from them on putting some stuff in our curriculum as part of our tactical project training. Let’s see—training about the new Web site, “low-hanging fruit” for process improvement, and awareness of change management.
Organizational training is one of the process areas from the overall CMMI framework that is likely to be mature in most medium-sized to large organizations. Corporate human relations departments usually have at least a rudimentary approach to planning and managing training activities. But execution of the plans is another story, especially if training is centrally funded. There are always more requirements than resources for training, and it seems to be one of the first areas affected when budgets are cut. Isn’t it ironic that most organizations claim that their people are their most important asset, and yet employee development often is one of the first things cut during a budget crisis?
Steve catches himself thinking back to the generic practices from the CMMI framework he and Rosa discussed.
Web site = resources = generic practice 2.3
Training = generic practice 2.5
Involve senior management = stakeholders = generic practice 2.7
“Scary!” he thinks. “I’m starting to apply the model just like Rosa said!”
Steve shares this revelation with the team. They discuss these ideas and pledge to identify and communicate short-term wins along the way. At the end of the meeting, they parcel out actions, set target dates, and agree to review progress at next week’s team meeting.
Many medium-sized and large organizations have well-established programs to manage and track training activity. As you begin an improvement program, it’s important to link to these efforts to ensure that the right training is provided at the right time to the personnel who are implementing changes at the project and organizational levels. Folding improvement requirements into existing infrastructure leverages scarce resources and ensures that change training is aligned with overall organizational training.
In addition to strategic training needs, organizational training addresses training requirements that are common across projects and support groups. These groups have the primary responsibility for identifying and addressing their specific training needs. The organization’s training staff is responsible only for addressing common cross-project and support group training needs—for example, training in work environments common to multiple projects.
In some cases, however, your organization’s training staff may address the additional training needs of projects and support groups, as negotiated with them, within the context of the training resources available and your training priorities. You must manage this activity over time to ensure that employees are receiving current training when refresher classes are needed, and to ensure that you account for employee turnover by training employees who are new to the effort.
Most organizations evaluate or test their training. Often, the employee receiving the training can provide feedback on its effectiveness, and the employee’s manager or team leader can also assess the effectiveness of the training in aligning with and meeting organizational goals. It’s important for those engaged in the management of process change to review these documents, assess the effectiveness of the training effort in meeting overall goals, and make any needed corrections.
The CMMI-ACQ provides specific recommendations on how to develop the skills and knowledge of people so that they can perform their roles effectively and efficiently (see Table 5-7). You identify the training required to develop the skills and the knowledge necessary to perform enterprise activities. After the needs are identified, you develop a training program to address them.
Table 5-7. Organizational Training Goal 1: Practices and Tips
CMMI-ACQ Process Area: Organizational Training | ||
1. Goal: A training capability that supports the organization’s management and technical roles is established and maintained. | ||
Practices | Tips | |
1.1 | Establish and maintain the strategic training needs of the organization. |
|
1.2 | Determine which training needs are the responsibility of the organization and which will be left to the individual project or support group. | |
1.3 | Establish and maintain an organizational training tactical plan. | |
1.4 | Establish and maintain training capability to address organizational training needs. | |
Effective training requires assessment of needs, planning, instructional design, and appropriate training media (e.g., workbooks, computer software) as well as development of a repository of training process data. As an organizational process, the main components of training include a managed training development program, documented plans, personnel who have appropriate mastery of specific disciplines and other areas of knowledge, and mechanisms for measuring the program’s effectiveness.
The organization identifies the needed training (Table 5-7, practice 1.1). Strategic training must address long-term objectives by filling significant knowledge gaps, introducing new technologies, or implementing major changes in behavior. Identification of training needs may also address some training needs of suppliers, especially in those process elements that define supplier interfaces and expectations.
In addition to strategic training needs, organizational training addresses training requirements that are common across projects and support groups (Table 5-7, practice 1.2). Based on the training needs, you develop a tactical plan for organizational training. The goal of this plan is to deliver the training that is the responsibility of the organization and is necessary for individuals to perform their roles effectively (Table 5-7, practices 1.3 and 1.4). This plan addresses the near-term execution of training and is adjusted periodically in response to changes (e.g., in needs or resources) and to evaluations of its effectiveness.
Many factors may affect the selection of training approaches, including audience-specific knowledge, costs and schedule, work environment, and so on. To select an approach, you must consider how to provide skills and knowledge in the most effective way possible given the constraints.
Training should be planned and scheduled (see Table 5-8, practice 2.1). You should provide training that has a direct bearing on the expectations of work performance. Therefore, optimal training occurs in a timely manner with regard to imminent job performance expectations. These expectations often include training in the use of specialized tools and in procedures that are new to the individual who will use the tools and perform the procedures.
Table 5-8. Organizational Training Goal 2: Practices and Tips
CMMI-ACQ Process Area: Organizational Training | ||
2. Goal: Training necessary for individuals to perform their roles effectively is provided. | ||
Practices | Tips | |
2.1 | Deliver the training following the tactical organizational training plan. |
|
2.2 | Establish and maintain records of the organizational training. | |
2.3 | Assess the effectiveness of the organization’s training program. | |
Keep records of all personnel who successfully complete (or fail) each training course or other approved training activity (Table 5-8, practice 2.2). Training records may be part of a skills matrix developed by the training organization to provide a summary of the experience and education of staff, as well as training sponsored by the organization.
In addition, a process should exist to determine the effectiveness of training (Table 5-8, practice 2.3). You can take measurements to assess the benefit of the training against the project’s and the organization’s objectives. You should pay particular attention to the need for various training methods, such as training teams as integral work units. When used, performance objectives should be shared with course participants and should be unambiguous, observable, and verifiable. The results of the training effectiveness assessment should be used to improve training materials.
Outsourcing creates significant organizational change. Failure to address this change is a risk factor for both you and the supplier. Organizations often do not realize the cost reduction and productivity improvements that they projected because they ignore the impacts of change on their own organization.
A key feature of organizational change activities is communication—with employees, system users, and management. Workshops are a mechanism that you can use effectively to make individuals aware of the process improvement project. Workshops are also a good way for people to work together to achieve common goals. Other effective techniques are to use early adopters as key influencers in the change and to offer incentives, such as recognition and rewards, that are tied directly to performance. Whatever approaches you use to implement organizational change, they require the same level of planning as any other program.
Any organizational change activities for the supplier should be built into the supplier agreement, and the agreement should clarify the ownership of tasks and deliverables, scope, and resources.
Recent research into change management has shown consistently that a key factor in the success or failure of a change effort is executive sponsorship. Senior leadership must set a course and deliver a consistent message over time to keep an organization’s change efforts on track.
Early one day, Matt Vauban’s secretary calls Steve to request an urgent meeting. When Steve is shown into Matt’s office, Steve’s boss is already there.
Matt: Steve, please sit down. I asked your boss to join us this morning because I have some concerns about the project you’re working on. You know how interested I am in your acquisition project. I’ve seen your draft project plan for managing the outsourcing effort, and it seems that you have that pretty well under control so far. But I’m concerned that we don’t have a plan for managing the changes that adopting the CMMI-ACQ will bring to the organization as a whole.
Matt pauses to let this sink in, and then he continues.
Matt: If I look at what companies like Toyota have accomplished, it’s not because they have put in place fixed-price contracts and challenging pricing targets. I’ve been reading the literature. It turns out that Toyota invests in their suppliers and develops those relationships over a long period of time. Their focus is on a quality product. They have a quality culture that gets everyone involved, from the employee in the front office to the supplier who develops a component for the technology solution. This quality focus gives them opportunities to eliminate waste and opportunities to innovate.
Steve: Yes, I’ve read something about that, too.
Matt: Steve, here’s the thing. Your project has the potential to change our organizational culture in some fundamental ways. I need to be convinced that we’ve thought through all the implications. Can you do some research and get back to us with an approach for change management?
Steve pauses for a moment to collect his thoughts.
Steve: Sure, Matt, I’d be glad to. But as far as Toyota, keep in mind that they’ve been building this culture for many years, and working on their supplier relationships to make it all work.
We’ve looked at the cultural alignment between us and our bidding suppliers, and we’ve reviewed some of the things you’re referencing—trust, long-term relationships, mutual well-being, discipline, continuous improvement, learning. These things don’t happen overnight, and they don’t happen just because an agreement gets signed. But on the other hand, just because we’re not a Toyota doesn’t mean we can’t begin to demonstrate the leadership behavior to work with our suppliers more effectively.
Matt: I want to make sure we’ve done our homework before we get into this too deeply.
Steve: Sure, and I’ll get you some research. But don’t forget we have process experts in house, like Rosa Gonzales. I’ve been meeting with her. Plus, we’re not jumping into it with both feet. We’re starting with processes we already do that will be easy to document. Our team has also been looking at ways to bring in our suppliers to help us shape this from day one, and use incentives and energize employees and managers to adopt a process improvement mentality.
I’ll meet with Rosa and Paula and put something together for you. How about if we get back to you in a week or two with some ideas?
Matt: Thanks, Steve. See my secretary on your way out to schedule us for an hour on, say, Wednesday afternoon in three weeks.
As Steve leaves the office, he thinks about what has just happened. He’s encouraged that Matt is engaged with the project, because everything he’s read about change management and CMMI adoption concludes with the admonition that senior leadership engagement is an essential ingredient to a successful project. Matt is certainly engaged. Now Steve must make the most of the opportunity Matt has presented and meet the challenge of addressing Matt’s concerns and putting together a change management plan. Steve’s first stop is to see his boss. Steve wants to make sure his boss is on board with what Steve has been asked to do.
Steve’s boss: Come on in, Steve! Matt must have been thinking in the shower again.
This is a shared joke among Steve’s colleagues. Matt once admitted in a staff meeting that he often got his best ideas while taking his morning shower.
Steve: The way he started out talking about “concerns” brought me up short. But it turned out okay. I’m glad he’s engaged!
Steve’s boss: Yes, I know you told me about the need for senior leadership in this effort. But why does it always have to be first thing Monday morning? Just kidding!
I was glad you answered the way you did. You know Matt puts a lot of stock in what Rosa says, and Paula is our internal customer. If they’ve bought into it, you’ll have a much better chance of getting the boss’s approval.
Steve: Thanks. That’s what I was thinking, too.
Steve’s boss: I know you don’t have much time between now and our next meeting with Matt. How about showing me what you’ve got first thing next week?
Steve: Sounds good. See you then.
Steve is under the gun. He has only a very small window of opportunity to put together a change management plan. Luckily, both Paula and Rosa are available mid-morning. They all get together in a small conference room with plenty of whiteboard space. Steve tells them about the meeting with Matt. Rosa walks over to the whiteboard and draws a diagram (see Figure 5-4).
Figure 5-4. Technology Adoption Life Cycle
Rosa: This represents the life cycle of technology adoption. It’s nothing new. It’s based on research done in the 1950s by a professor at Iowa State named Everett Rogers [http://en.wikipedia.org/wiki/Everett_Rogers]. The change management experts say that you need to focus on early adopters and then build toward early majority acceptance. Paula, I think you might be classified as an early adopter of CMMI-ACQ!
Paula: Well, that’s all well and good, but what does it get us?
Tip
Endorsement from early adopters in line or functional positions is a key to accelerating improvement efforts.
Rosa: Like Aretha Franklin said, “R-E-S-P-E-C-T.” If we want to use CMMI-ACQ throughout the company, then for openers, we need two things: senior management support, which it seems we already have, and credibility from someone that people respect.
With your leadership, Paula, other divisions will see that we’re making a difference. Sure, I’m supposedly the process improvement “guru,” and Steve’s the acquisition project manager, but we don’t have the kind of credibility you have. You’re a manager from a functional area. You do real work. That’s why early adopters are an important part of leading the change.
Paula: I never thought of myself in that role. But I do believe that this is the way we should go, and I’ll be glad to do what I can to get the word out.
Steve: This is good. We’ll be including a change management approach in our project plan for the acquisition. And we’ll have a communication plan supported by metrics to get the word out about what our goals are and how well we’re meeting them.
Rosa: There is another piece to this puzzle. Another researcher, Geoffrey Moore, says the most difficult aspect of technology adoption is “crossing the chasm” between early adopters and early majority. Having Paula’s support is really important. But we also need to support the effort through a “product perspective.” It’s a marketing term. It means supporting the effort with a holistic approach to meet the needs of the customer.
Rosa pulls a chart out of her briefcase and shows it to the others (see Figure 5-5).
Figure 5-5. Whole product concept
Rosa: So Paula’s division is the customer of the outsourced services. The entire effort needs to be supported like any other product. That will help bridge the gap between Paula, our early adopter, and the early majority groups in our organization.
Steve reiterates that his plan already includes many of these topics.
Steve: But I wasn’t looking at this from the perspective of accelerating acceptance of the CMMI-ACQ approach. It’s just common sense to try to support the product.
Paula: You’re right, Steve. But letting people know that you’re taking a product support approach to the acquisition project will help others feel more comfortable. In fact, that’s one of the reasons we’re adopting the CMMI-ACQ. It takes a life-cycle approach to acquisition.
Steve: Taking a whole product approach also means that we can’t do this alone. We need to involve our supplier and make them an integral part of continuous improvement. Let’s put together a meeting with our new suppliers to talk about some of the aspects of partnering that we want to emulate, and start building that culture.
Tip
Taking a whole product approach can help bridge the gap between early adopters and the next level of acceptance: the early majority.
Rosa and Paula nod in agreement. Paula says that George Taylor and Kristin Wells, from the supplier organization, should be a part of the meeting, and Paula agrees to ask them to host it.
The supplier meeting is convened the next day, and it quickly becomes an idea-generating session. Steve has a suggestion.
Steve: We need to work together as a learning organization. I mean we need to set up sessions where we focus on initiatives together, maybe even initiatives outside of the regular work activities, and bring in some of the other suppliers as well—sort of a think tank.
George Taylor: All of us together?
Steve: That’s right. That way, we can take some specific challenges from our day-to-day work and come up with solutions. This would give everyone a chance to work together and do things that we could immediately implement. We’ve already begun this process in-house with my acquisition team. I think it’s important to make this a collaboration among all of us.
George: Well, how much time are you thinking this would take?
Steve: That’s a good question, George. We can decide that together. I want to make sure that this is not just a meeting where we bring in leadership at the end of the day and everyone goes home and forgets about what we talked about. So I’ve been thinking about ways that we can make this well worth everybody’s time.
I hate this cliché, but it’s really true: Every challenge is an opportunity. We need to proactively capture the opportunities so that we can use them and improve what we’re doing. To some extent, this goes back to what Kristin was talking about earlier. If I look at a problem as a problem and don’t look at it from the standpoint of continuous improvement, I just have a problem, and I handle it, and nobody learns anything. But if we start talking about issues, challenges, and problems (big, medium, and small) from an improvement point of view, then we look at the problem differently. We can try to determine why it’s happening, especially if we believe there’s a strong possibility it might happen again. We can begin to live and breathe continuous improvement and support it as a way of life. If we can all problem-solve, then we can all continuously improve.
Steve pauses and then continues.
Steve: Now, this means a culture shift for all of us, and we know that won’t happen overnight. But let’s look for some situations that we could use to demonstrate to management how this might work, and examples of how it’s critical to the success of our organization and our suppliers.
The dialog continues for some time. Eventually, the team puts together the prioritized list per the original instructions for the workshop. The list looks like this:
Set targets for specific quality improvements.
Set up mentoring relationships between new staff and existing staff.
Set up a simple decision matrix to evaluate the impact of any problem, including symptoms and root causes.
Set up a process for a “Plan-Do-Check-Act” cycle, and begin to make it visible. Reward individuals for demonstrating these behaviors. Evaluate monthly and overall at the end of six months.
And the list goes on ...
Tip
Use common process improvement initiatives to encourage the partnership between acquirer and supplier.
Steve and the team also decide to invite Matt for an interim “temperature check” at the end of the meeting. They want to let Matt know were they’re headed before Steve formally briefs him at the scheduled change management meeting. Matt is brought into the session and listens to the report from the team. Then he takes center stage.
Matt: I want to commend you all for spending this time and working together as an integrated team to set some direction on how we can take our organization to the next level. Many of the items you’re focusing on are areas that we as a management team have discussed as well.
Although we’re all concerned about how we manage the business from a cost perspective, we also need to be mindful of managing from a quality perspective first. Now, don’t get me wrong. Don’t think you can wave the “quality” flag in my face and I’ll immediately give you whatever you ask for. I’m not convinced that you have to spend big bucks to eliminate waste and improve quality. That’s where the creativity and transformational opportunities lie.
I’m in full support of the output of this workshop, your priorities, and I want a team meeting scheduled in three months to determine how much progress we’ve made. Steve, please make sure the meeting is on my calendar.
Matt asks Steve to take the lead in putting in place activities to foster collaboration, with the goal of continuous improvement for the integrated team. Those items should become a critical part of continuous improvement going forward.
As continuous improvement takes hold, data becomes increasingly important for managing projects and the organization. An important characteristic of high-maturity organizations is their ability to base decision making on data. At the organizational level, data is used to select which process changes to deploy and then track their performance. Of course, this capability must be built over time. One successful method is to use pilot projects to test changes and begin to build an organizational database that supports analysis and future change deployments.
Matt and Rosa are talking about this one day while waiting for a meeting to start.
Matt: In the company I used to work for, they were big on pilot projects. One year, we picked two projects and tried them out separately. Once we were done with the piloting and those six process areas, we were able to sit down and ask, “What were the common activities they did? What seemed to work best for the so-and-so division? How did these people over there do configuration management with their suppliers?” Things like that. Then we began to nudge out, for example, a process description and templates that seemed to work best from that pilot and began to get those into other projects as they came out. These served as lessons learned and experience under our belt, in terms of what works and what doesn’t work. That’s kind of the way I think we’re going to do it here as well.
Rosa: Who did you choose for a pilot?
Matt: The project that was the most open to new approaches. Of the two projects, one of them was particularly open to trying new things; they wanted to do the pilot as soon as they heard about it. The other project, we talked to the director of that group and there was a new project coming on-board, kind of newbies—a lot of new people—so we said, “Hey, here’s a chance for us to get going in the planning part, right off the bat.” So that’s why that group was chosen.
Both were major initiatives, and so they got a lot of visibility, which was good and bad. But at least with a lot of visibility, they got the resources they wanted and were in the thick of it. That’s the main thing—to be in the thick of it. I think one of the most important things we learned is that the people go through a cycle of team formation with these pilots.
Rosa: You mean the good old “storm-norm-perform”?
Matt: Yes, small group dynamics, teaming stuff. When a group is first put together, it goes through stages of development as a group, just like an individual person goes through infancy, childhood, adolescence, and adulthood. With groups, it’s “form, storm, norm, perform, and adjourn.” They need to form up and understand their task, and then they go through a stage where they “storm”—voice and resolve contending approaches or viewpoints. Then they settle down to setting group norms, and then they perform their tasks. Then when they complete their task, they adjourn.
Rosa: Yes, I’ve seen that dynamic in groups I’ve worked with, too.
Matt: We also found that it went faster if we had more face-to-face meetings. One of our teams was split across two locations. We had a videoconference every week, and we tried to meet face to face at least every month or six weeks, but we were so busy we couldn’t always do it. So when we did meet, we seemed to go through these stages each time. The longer we went between face-to-face meetings, the more time we spent storming before we could get to norming and performing, even in a single, two-day meeting. Go figure.
Rosa: That’s very interesting. I’ve been thinking about managing our pilot kick-offs with trained facilitators. This sounds like a good thing to look at. Team leaders need to understand what the pilot teams are going through, and help them through it!
One last thing. How did you go from pilot to wider rollout?
Matt: Well, like I said, Rosa, we tried to figure out what worked and what didn’t across the pilots.
After you’ve determined which improvements to deploy across the organization, it follows that the next step is to plan, manage, and deploy them. The CMMI-ACQ suggests that this be done in successive cycles of improvement that are managed and measured. In this way, the organization can build on what it has learned from previous improvement cycles.
This is where the real fun begins.
Steve and Rosa are chatting in the hallway after the staff meeting.
Steve: You know, Rosa, we’ve talked a lot about how to get things going—what to do, what not to do, and so on. I’m really looking forward to just getting started. I guess I’m at the point where I need to dig in and get my hands dirty and try a few things.
Rosa: Why, Steve, I didn’t know you engineers got your hands dirty! I thought you left that to the mechanics. But you’re right. At some point, it’s just time to quit talking about it and jump into the pool. And you know what? I think the anxiety about something is usually much worse than actually going through it.
Steve: Well, I wouldn’t say I was anxious exactly.
Rosa: Steve, don’t go misunderstanding me again. I think we’re saying the same thing. You can only plan and anticipate so much. At some point, the only way to advance to the next level is to get started. I hope you’ll have fun doing it, too. I know you’ll be successful. After all, you have me as your process adviser!
But seriously, after all this planning I think we’ll find it very satisfying to get started and begin to see some results, some data that we can use to track progress. I know that’s the real fun of it for me, to begin to see progress. And then to think about rolling out the next wave of change.
Steve: I couldn’t agree more, Rosa. I think it’ll be fun to really make a difference in the way we do business around here, too. And with all this talk of data and analysis, I think I’m having a positive influence on you—you sound more like an engineer every day and not just a “process geek.”
They both laugh at this as they head down the hall.
The CMMI-ACQ provides specific recommendations on how to select and deploy incremental and innovative improvements that measurably improve your organization’s processes and technologies. The improvements support the organization’s quality and process performance objectives as derived from its business objectives (see Table 5-9).
Table 5-9. Organizational Innovation and Deployment Goal 1: Practices and Tips
CMMI-ACQ Process Area: Organizational Innovation and Deployment | ||
1. Goal: Process and technology improvements that contribute to meeting quality and process performance objectives are selected. | ||
Practices | Tips | |
1.1 | Collect and analyze improvement proposals |
|
1.2 | Identify and analyze innovations. | |
1.3 | Pilot process and technology improvements to select which ones to implement. | |
1.4 | Select process and technology improvements for deployment across the organization. | |
You must continuously improve your processes and your alignment with your suppliers (Table 5-9, practice 1.1). You can look for opportunities to maximize throughput based on the identification of the most limiting resource and, as a result, create a more agile supply chain (e.g., improvement proposals that promote a supply chain that responds both quickly and cost effectively). Create a proposal for process and technology improvement to document your proposed incremental and innovative improvements to specific processes and technologies. Managers and staff, as well as customers, end users, and suppliers, can submit such proposals. Process and technology improvements can be implemented at the local level before being proposed for the organization.
One way to focus initial improvement efforts is to target process bottlenecks at the project level. It follows that a successful improvement activity that removes bottlenecks and improves throughput at the project level might be a candidate for wider application across the organization.
Your customers and suppliers are vital sources of innovative ideas. Interorganizational and organizational learning are therefore critical to actively identifying and analyzing innovations (Table 5-9, practice 1.2). Together with your suppliers, you can establish an innovation review program. This program might create time-boxed innovation solicitation, which is a well-communicated formal process for analysis and guaranteed response to innovative ideas proposed by customers, employees, and suppliers.
Pilots are performed to assess new and unproven major changes before they are broadly deployed, as appropriate (Table 5-9, practice 1.3). When you plan pilots, it is critical to define quantitative criteria to be used for evaluating pilot results. Reviewing and documenting the results usually involve the following tasks:
Deciding whether to terminate the pilot, replan and continue the pilot, or proceed with deploying the improvement
Updating the disposition of improvement proposals associated with the pilot
Identifying and documenting new improvement proposals as appropriate
Identifying and documenting lessons learned and problems encountered during the pilot
You select process and technology improvements for deployment across the organization based on quantifiable criteria derived from the organization’s quality and process performance objectives (Table 5-9, practice 1.4).
You and your suppliers may share the costs and benefits of improvements (Table 5-10, practices 2.1–2.3). You can increase the incentive for suppliers to participate in improvement efforts across the supply chain by allowing suppliers to appropriate all the value derived from a contributed improvement in the short term (e.g., 6 to 18 months). Over time the supplier might be expected to share a proportion of those savings with you (for example, through cost reductions). Therefore, your plan for deploying improvements might include openly sharing most process know-how with your suppliers.
Table 5-10. Organizational Innovation and Deployment Goal 2: Practices and Tips
CMMI-ACQ Process Area: Organizational Innovation and Deployment | ||
2. Goal: Measurable improvements to the organization’s processes and technologies are continually and systematically deployed. | ||
Practices | Tips | |
2.1 | Establish and maintain plans for deploying the selected process and technology improvements. |
|
2.2 | Manage the deployment of the selected process and technology improvements. | |
2.3 | Measure the effects of the deployed process and technology improvements. | |
Any process-related knowledge that you or one of your suppliers possesses is viewed as accessible to virtually any other supplier in your supply chain (perhaps with the exception of a direct competitor). In this case, you need to establish rules and norms that prevent suppliers from accessing your knowledge unless they first explicitly agree to openly share knowledge with other suppliers of yours. For example, you have the ability to impose economic sanctions (such as withdrawal of business) on suppliers that violate the rules.
Accelerating, or even initiating, a process improvement program within an organization can seem like an overwhelming undertaking. Keeping “order amid change” while simultaneously keeping “change amid order” is a challenge that is best faced wearing the armor of proven best practices.
However, merely imitating a successful organization isn’t sufficient for affecting long-term, sustainable processes. In fact, you can get into trouble if you imitate without first considering the native processes and practices that have grown within your organization out of necessity. Often, creating processes in an ivory tower and mandating from on high that they be followed only strengthens a culture’s resolve to maintain the status quo. Instead, organizations should focus on maintaining process stability while gradually introducing small, incremental changes. And these incremental changes shouldn’t just be “good ideas” that someone thought up in the shower that morning. Instead, they should be based on the organization’s actual performance data and other metrics.
Most likely, your organization has already put in place some processes that allow it to operate within the boundaries of acquisition budgets, schedules, internal policies, and external mandates—that is, within the boundaries some of the time. By concentrating first on improving existing processes and then keeping up that momentum, you can execute acquisition projects and programs more effectively and efficiently. Process improvement can result in long-term benefits that will enhance your overall management of acquisition projects and ultimately the organization as a whole. Not to mention that you will gain the benefit of better fit and quality of deliverables after they’re deployed in the user community.
For all these reasons, you must treat a process improvement initiative as you would any other project, with milestones, metrics, program reviews, decision points, and so on. It should be planned and managed rigorously and should have appropriate resources. Applying the project planning practices from the CMMI-ACQ to the improvement project helps coordinate the work while allowing people to become familiar with the model. The executive team and management must do their part to support the work by clearly and consistently communicating the goals of the effort and the progress it’s making. Senior leadership should also endorse, encourage, and fund training to further develop the capabilities of their staffs.
When you begin a process improvement journey, it’s critical that you determine two things: where you stand in applying existing processes, and the destination you would like to reach. Taking a good, hard look at what you do well and where you stumble is certainly a start. Performing an in-house assessment is a confidential, unobtrusive, and less expensive way to gauge your organization’s current process maturity. Keep in mind, however, that people in an organization tend to rate their performance higher than an external, objective appraisal team would, especially in an organization that’s somewhat unfamiliar with process improvement or maturity models. There is plenty of room to interpret the questions, and when faced with questions about an unfamiliar subject, people usually just make their best guess.
The old saying “Hindsight is 20/20” is heard often, and with good reason. Analyzing historical data—or a lack thereof—can reveal facts about a project’s performance and provide clues about the level of adherence to existing processes. Tracing through past documentation reveals the paths that an organization has already traveled. The road ahead, however, can become confused, with off-ramps, roundabouts, and dead ends. Improvement efforts that start small, on a single project or program, are usually more successful in navigating, making adjustments, and then staying the course than are efforts to make big changes quickly.
After groups of process improvement scouts have found and documented the way, other projects and programs can follow that map. Leverage these artifacts to gradually build a process asset library, keeping in mind that clear, concise, objective statements that communicate improvement goals are much more usable than volumes of detailed “shelfware” that is too cumbersome to be used in daily practice.
The early adopters of process improvement efforts can pave the way for change by eliminating redundancy and waste in existing, well-known processes. Begin by focusing on foundational processes—those processes and practices that just make good project management sense. Root out the processes that don’t add value, and eliminate or streamline them. Pick working processes and tailor them to work optimally. Also identify strengths and opportunities, leverage their associated processes for quick payback, and use them to build momentum.
Techniques such as S.W.O.T (strengths, weaknesses, opportunities, and threats) can provide simple ways for you to identify a project’s weaknesses and threats. They also give you opportunities to pick low-hanging fruit by identifying and eliminating activities that don’t add much value to the overall process.
Use a simple mechanism to track process improvements and suggestions—for example, a Web site—and then reward early adopters for their short-term innovations. These practices encourage people to offer more improvement suggestions. Rewards don’t have to be formal or elaborate; they can be as simple and immediate as a gift certificate to a nearby restaurant or store. This type of approach catalyzes a new culture of collaboration and ownership, and it weakens barriers to change. Such barriers include the cynics in an organization, the chasm between early adopters and the early majority, and a “shoot the messenger” mentality. After suggestions for improvement are gathered, test them by piloting a controlled number of changes on a small project. In this way, you will gain an opportunity to polish and fine-tune the process with minimal disruption before it is widely implemented.
It may seem counterintuitive, but process improvement work can apply equally to a project that is in execution as to a new acquisition. It’s not necessary to wait until the “perfect time” or “perfect project” comes along; the perfect time is now, and the perfect project is the one you’re working on. Don’t get rattled if things don’t go smoothly at first or if there are a few false starts. It’s unrealistic to expect high-maturity performance right away, but that should not stop you from laying the foundation through managing and measuring process performance.
It’s vital for suppliers to participate in process improvement projects; they are stakeholders in the outcome. A shared responsibility for improving common processes curbs the “throw it over the wall” approach. Not only are the individual organizations’ processes strengthened, but also the relationships themselves grow stronger.
Identifying touch points—those parts of the overall process where acquirers and suppliers interact or intersect—is the key to identifying opportunities for collaboration and improvement. For example, one touch point during the solicitation and source selection phase of the acquisition life cycle is the RFI process. You issue a request for information to determine whether the capabilities to fulfill your needs exist in the industry. Other areas, such as contracting, configuration, change, and risk management, are often ripe with shared processes that can be standardized for the mutual benefit of you and your suppliers.
Using techniques such as alpha contracting to mutually delineate the scope of the requirements and define the deliverables can foster partnering and a sense of cooperation, and it can result in more efficient processes. The contract should spell out the scope of the shared process improvement activities to avoid misunderstandings and unplanned costs that may arise after the supplier begins executing the contract. And, as always, the key to successful collaboration is close communication—early and often.
During phases of the life cycle when processes aren’t shared and are instead being executed in parallel—for example, when the supplier is developing the technology—it is important for you to retain and exercise certain responsibilities, such as contract oversight. While you’re focusing on strengthening touch points and monitoring and improving individual projects and programs, don’t lose sight of the big picture: the health of the organization as a whole.
Along the way, don’t forget to have fun. Process improvement is hard work that requires individuals, teams, and middle and senior managers to wrestle with difficult problems, such as changing the culture and behavior of people and groups. But by collecting appropriate data and sharing it across the organization to determine, deploy, and measure successive cycles of improvement, you can make a tremendous difference in employee morale, customer satisfaction, and the organization’s bottom line. This should be satisfying and fun! Let’s get started!