A model is a representation of a complex entity or process. It can describe the details of a larger object, or it can be a schematic description of a system. A model can capture phenomena so that they can be analyzed and studied.
The value of a model is in its abstractions, and through these abstractions it simplifies what may be a complex reality. It is important, then, to be able to take a model, along with all its associated abstractions, and compare it to reality. In this way, you can use the model pragmatically to study phenomena and validate hypotheses. In the case of capability maturity models, you can compare your organization’s acquisition processes to the standard model and determine how your practices differ from the model. You can also determine what you need to do in order to achieve a complete, executable, repeatable set of acquisition processes.
Many people find it difficult to apply CMMI (Capability Maturity Model Integration) efficiently and effectively in practice. The challenge of using CMMI, or any model, is in its interpretation. With CMMI you first define a process area, goal, or practice, and then you determine how to align these model components with processes, goals, and practices in your own acquisition environment. This book is written for those who are interested in improving their practices for acquiring technology solutions. If you have embarked on applying a model like CMMI to improve your project execution and organizational performance, you may be challenged because your organization still behaves like a developer of technology solutions rather than an acquirer.
It is not our intent to walk you though the CMMI for Acquisition (CMMI-ACQ) and explain what each goal, process, and practice might mean. (See the Appendix for a summary of the initial draft of CMMI-ACQ.) Rather, this book is intended to be a practical guide that gives you insights in applying the CMMI-ACQ. We describe the key areas of focus for an acquirer and address some of the challenges you will surely face.
CMMI is a collection of best practices that helps organizations improve their processes. It was initially developed by a team from industry, the U.S. government, and the Software Engineering Institute (SEI). CMMI is designed for application to process improvement in the development of products and services, covering the entire product life cycle from conceptualization through maintenance and disposal.
Following the success of the CMMI for development organizations, the group identified the need for a CMMI model to address the acquisition environment. This need was reinforced and gained further attention because of similar needs expressed by General Motors (GM), which acquires information technology (IT) solutions. In accord with GM’s strategy, GM projects first develop requirements and design constraints and then oversee multiple suppliers, which develop IT solutions to be deployed in GM’s business units. This approach parallels the acquisition processes used in many government organizations.
In both government and industry, acquirers must take overall accountability for solution delivery, allowing the supplier to perform the tasks necessary to develop and maintain the solution. Unfortunately, many organizations have not invested in the resources that are needed to effectively manage acquisition projects. Often, acquirers disengage from the project after the supplier is hired. Then they discover, too late, that the project is not on schedule, the selected technology is not viable, and the project has failed.
An acquirer has a focused set of major objectives. To deliver the requirements of the ultimate IT users and the acquisition sponsors, the acquirer must maintain relationships with them. In addition, the acquirer defines the needed scope and execution direction to deliver the technology solution through its relationship with the supplier (via the supplier agreement) and the acquirer’s own supplier management activities. The acquirer owns the project, executes overall project management, and is accountable for delivering solutions.
You will find many maturity models, standards, methodologies, and guidelines that can help your organization improve the way it does business. However, most of these approaches focus on a specific part of the organization and do not offer a systemic approach to the problems that most organizations face. By focusing on improving one area of a business, these models unfortunately have perpetuated the stovepipes and barriers that exist in organizations.
The CMMI-ACQ contains 16 core process areas that cover project management, process management, and support processes. In addition, six process areas unique to acquisitions are included. These six process areas address unique acquisition practices, including development of solicitation and supplier agreements, acquisition management, development of acquisition requirements, development and verification of design constraints for technical solutions, acquisition validation, and acquisition verification.
The practices in all process areas focus on the activities of acquirers. Those activities include supplier sourcing, developing and awarding contracts (supplier agreements), and managing acquisition of solutions that include products and services. Supplier activities are not addressed in this document.
For suppliers, CMMI for Development (CMMI-DEV) can be treated as a reference model for developing technological solutions and products and services.
When your activities are focused either on the acquirer or on the interaction with the supplier, practices that are essential for executing acquisition processes are performed differently or with differing roles. These differences are apparent in monitoring, directing, or overseeing a supplier, which occur after you have selected a supplier or authorized a supplier to begin work.
To bridge the gap between the CMMI-ACQ and its practical application, this book includes five characters who appear throughout the book. They are members of two fictitious acquirer and supplier organizations. Each chapter includes stories that engage these characters as they work through important areas of focus. The chapters are ordered to roughly reflect a project life cycle, and the stories describe the insights, pitfalls, and tips and tricks we’ve gathered over the past decade from commercial and government organizations that outsource work, as well as the suppliers that provide technology to these organizations.
We begin with the early phase of the acquisition life cycle—acquisition planning—and then proceed through subsequent phases as the acquisition project progresses. Along the way, you will meet the characters who make up the integrated team using outsourcing to work on a series of projects. The discussions are mainly focused on the acquirer.
This chapter introduces the characters and describes how the book is structured. Chapter 2, Getting Started, discusses how to formulate an acquisition strategy and align it with the organization’s goals. That chapter presents a framework for acquiring solutions and describes outsourcing activities, with a focus on acquisition planning, writing requests for proposals (RFPs), handling supplier responses, conducting negotiation, creating standard contracts, and collaborating with suppliers.
Chapter 3, Engineering Solutions, explains how to get requirements right. It also shows how you translate requirements into practical design constraints that can be documented or referenced in the supplier agreement so that the supplier can produce value-added technology solutions. Chapter 4, Delivering Solutions, outlines how to execute projects that include integrated project plans, standards for measurement, uncertainty and risk, transition to operations, and maintenance and support.
Chapter 5, Accelerating Acquisition Improvement, describes how to continuously improve acquisition processes and become a catalyst for cultural change within an organization. The appendix, Overview of CMMI-ACQ, presents the six key process areas that are specific to acquisition organizations as well as the process areas common to all CMMI models. All these processes areas are vital to an acquirer’s success.
The characters that appear throughout this book are named Matt Vauban, Steve Reiter, George Taylor, Kristin Wells, and Paula Ressel. We created these character descriptions to capture the generic characteristics of individuals who typically apply CMMI-ACQ within an organization to improve the processes of their outsourcing engagements with suppliers.
As the story begins, Matt, a senior executive, has just been given what could be one of the most significant assignments of his career, from both a growth perspective and a career enhancement perspective. He has been asked by the executive board to salvage an outsourcing engagement that has not been successful for the organization. The first order of business is to assemble the acquisition team. Matt starts with a key position, the lead project manager. He is fortunate to have Steve Reiter, a superior candidate, in the organization. The only challenge is to persuade Steve that this is a viable initiative that can be turned around.
Matt also knows that he needs to have the best of the supplier’s staff on board to make this partnership work. The organization has made it clear to the supplier that only their best, most qualified individuals will be acceptable if the engagement is to be salvaged. The supplier pulls its best troubleshooting individuals, Kristin Wells and George Taylor, for the project. Matt and Steve join forces to make sure that Kristin and George have the “right stuff.” And finally, Matt needs to recruit a solid customer representative, and he finds that person in Paula Ressel.
As Matt drives to work, he sees the sun rising over Lake Michigan in the distance. He reflects on his career—where he’s been and where he’s going. Matt is the lead member of an elite team that has been hand-picked to troubleshoot a major assignment for his company: outsourcing a large portion of IT development to a group of suppliers. Matt has been preparing for this kind of opportunity his entire career. Right out of college, he worked as a programmer for a small software company. That was well before the dot-com boom. Even though he learned a great deal about developing software and he knew how many defects could be introduced when developers were tired and overworked, Matt found it difficult to survive on the unsatisfactory salary and the demanding hours. He soon realized that if he wanted to move up the corporate ladder in a high-tech organization on the management side of the house, he’d have to go back to school and get his MBA. The MBA was his ticket to bigger and better things, and Matt soon landed a job managing a development team and delivering software to the mass market.
Matt is a quiet guy who works and leads by example. If he asks a staff member to work beyond normal hours and spend time away from family, then he is right there with his sleeves rolled up, working alongside his staff to make sure that the job gets done and his employees go home.
As he turns the corner to drive into the parking lot, his only concern about his latest assignment is the team. Will he be in a position to assemble the “right” people so that he can get up to speed quickly to meet all the challenges? His boss has assured him that the composition of the team is the least of the challenges that lie ahead, but Matt knows that the team selection is key. He has scheduled interviews for the core team members, starting today.
Outsourcing has been attempted in this company in the recent past, an effort led by executives who had a short-term vision about cutting costs and a longer-term vision about using cost cutting to reach the next rung on the corporate ladder. Matt knows that he is walking into a highly visible situation. Others have failed or have conveniently moved on, and he doesn’t want to become a casualty of a program that carries the stigma of failure. He knows instinctively that he needs to go back to basics. What are the key processes to execute with suppliers? How can he mitigate risk that he can’t necessarily see or predict? Who will be his allies within the company? And how can he get his suppliers to a place where a true partnership is central to the development and deployment of systems using outsourcing?
Steve Reiter, a senior project manager, is Matt’s first interview of the day. Steve has just completed a project management assignment that he really enjoyed. The project had to do with building self-service capability for the human resources department. The capabilities that he was able to deliver to the organization were, in a word, awesome. Everyone—from the senior executive of human resources to Steve’s business counterparts in human resources—is congratulating Steve on a job well done, including requirements gathering, the design (which used a new Web technology), and a flawless launch. Steve has really showcased what a development team can do in a company.
Now Steve is between projects and looking for his next opportunity, and Matt hopes Steve will join him in this visible, high-potential initiative. Matt has already briefly explained to Steve what he is looking for: a strong project manager from within the company who will be vocal about and able to develop and implement key processes to partner with suppliers and effectively execute projects as an acquirer of technology solutions.
For his part, Steve is a six sigma black belt, experienced in process improvement, and he has 15 years of experience in project management. He knows he can take on this assignment, but he isn’t sure that it is necessarily career-enhancing or desirable. The feedback in the organization indicates that this outsourcing activity might be the beginning of the end for any internal development teams and will usher in a management model that could make his teams’ services obsolete. Steve doesn’t like the idea of working on an initiative that has the potential of putting others out of a job. He is also concerned about the various development teams that he has worked with in the company. Are they at risk, or is the verbalized official position that was communicated around outsourcing real—that individuals who are involved in development internally have been given other opportunities to become part of the new order? Steve wants to ask Matt this question at the interview today. And with their positive professional relationship in the past, he is sure that he will get an honest answer.
As Steve walks into Matt’s office, Matt congratulates him again on the success of the human resources project. After working with Matt on a number of initiatives, Steve knows that Matt’s praise is sincere, because Matt is very careful to reinforce positive feedback and give praise for exceptional achievements. As Matt sits down and invites Steve to sit in an adjacent chair, he begins to describe the purpose of the meeting and what he is looking for from Steve.
Matt: So, Steve, I asked you to come in today to talk very honestly about the new position I have open. I’m sure you want to know how it ties to our outsourcing model. I’d like to understand what you’ve heard about the company’s experiences with outsourcing to date—because our experience has not been stellar, as you know. I’d also like to understand how you think you can help us make the right changes to our working model with suppliers to make this outsourcing approach work.
Matt stops at this point to give Steve the floor and let him share what he has heard about the job, outsourcing, and any other topics that might be on his mind.
Steve: Well, to be honest, Matt, when you left me the voice mail inviting me to interview for this position, I have to say I had mixed feelings about it. I mean, there are rumors in the company that we’re going to replace all of our software architects and developers with management folks who know nothing about building software, and hiring a bunch of suppliers who understand technology but know nothing about our business.
Matt: Okay, that’s good to know. Please go on.
Steve: I’ve gotten mixed feedback about outsourcing. The suppliers like it because the contracts tend to be bigger, but the project managers who are trying to manage suppliers have run into some significant challenges. I know you’ve been asked to make this model work, but I’m concerned that success will be dependent on some serious efforts to define and implement the processes and practices that we need to perform versus what we are asking our suppliers to do. The last thing we all want to do is to duplicate work with the supplier or lose control over the technology work that we ask the suppliers to do. This is really a paradigm shift for how we need to work!
Matt wants to make sure that he is very direct in responding to Steve’s concerns.
Matt: Steve, as you know, management has every intention of repositioning staff and retraining for open positions if resources aren’t needed in the development area. I have personally seen this under way, and I feel comfortable that this direction will continue. But I also want to make it clear that our ability to use suppliers has a direct impact on the bottom line and will help keep the company competitive. So our work with suppliers is not a part of a model that we can try as an experiment, and then, if it fails or is just too hard, toss it aside and go back to the way things used to be. This is an approach to systems development that we really have to figure out. And I’m looking to talent like you to step up and make this work for our organization.
Steve nods in agreement and feels comfortable that his reservations about the job have been addressed.
Matt then poses his next question. It’s not only an interview question but also tests whether Steve has the “right stuff,” the right insight into the course corrections that will be necessary to make outsourcing work. Matt looks directly at Steve as he continues.
Matt: Well, I know you’ve spent a great deal of time as a scholar of process, and from a very practical perspective, you’ve used this knowledge to be very successful in bringing projects in on time, on budget, and with quality. I know you’re a black belt in six sigma and know a thing or two about process improvement. While I’m not as well versed as you in these areas, I have a general sense of what these two standards have done for us internally and how they have improved our processes through your hard work. The human resources project was just one example. So, if I asked you to apply your process knowledge to this outsourcing model, what would you focus on first, and how would you lead a supplier-acquirer team to develop functionality on time, within budget, and with quality?
Steve smiles.
Steve: Matt, when I got the call from you, the wheels started turning, and I did some research on this area. I think you knew I’d do that. So here’s what I think. I believe we moved to an outsourcing model without the necessary planning to make it work. This doesn’t mean we need to give up on the approach—I agree with you on that—but it does mean we have work to do. You know my favorite topics—process execution and process improvement. We need to identify the differences between an internal development process and an acquirer-supplier process, and we have to begin to develop everybody’s skills and experience so they learn the core competencies of successful acquirers. And we must have process improvement that is driven by business goals. As I did my research on outsourcing and the acquirer-supplier model, I was also trying to answer the question of how to define those acquirer skills and processes. I was hoping to find something in the industry that would help us jump-start the work so we avoid making the same mistakes again.
Steve begins to draw a diagram on a nearby whiteboard.
Steve: We have to start out with a strategy for acquisition, and it should drive everything else we do.
Steve writes “Acquisition Strategy” toward the top of the whiteboard.
Steve: The acquisition strategy defines the answer to our key business question: What do we need to purchase to deliver technical capabilities to our organization and customers?
Matt looks at Steve and begins to give him additional points and positive feedback.
Matt: I agree with you, Steve—this isn’t just about technology. It must tie the business needs and goals to what we do, and then allow us to tie consistent processes to the execution of that work. As we move from an internal development organization and add acquisition, one of our new core competencies must be to pragmatically manage the acquisition. We need to learn how to develop accurate, minimum customer and technical requirements and craft solid, practical supplier agreements. Also, we have to verify that the solution not only works but also delights our customers.
Steve nods, because he is sure that he and Matt are absolutely on the same page. When that kind of alignment happens in a discussion, the direction outlined validates that the work is not only achievable but even interesting. Steve continues.
Steve: Yes, we have to precisely focus our energy on developing the core competency necessary to be good acquirers. And let’s not forget that all our development work is rooted in a set of practices that all successful development organizations have to master, whether development happens internally with a development team or externally with suppliers.
Steve finishes his drawing on the whiteboard and contemplates it (see Figure 1-1).
Steve: It’s like a Maslow’s hierarchy for acquirers. If we forget to nurture the foundation practices, we trigger the need to readdress them. It’s just like we, as humans, can’t go too long without meeting our basic needs, like food and water. Let’s see. The foundation practices cover activities like project planning and management, configuration management, training, managing requirements, and managing risk. These practices are the foundation of our core competency. All three levels—acquisition strategy, core competency, and foundation practices—are interrelated and feed into each other. If there are problems in any area, they permeate the entire system—our organization.
Matt: So, let me just play this all back to you. I want to be clear about this initial thinking. We know that whether we do development internally or externally, the work is the work. Someone still has to manage the project, gather requirements, design and code, and test the code before it’s put into operation. Those are examples of the foundation practices in your pyramid picture. The difference in the acquirer-supplier model is around who performs the work and therefore how the work gets managed. Right?
Steve: Right. Let me draw another picture, because I think what you are describing looks something like this ...
Steve draws a simple diagram on the whiteboard (see Figure 1-2). It has two columns—one labeled “Acquirer” and the other “Supplier.” He draws several horizontal lines across the columns, each a different length.
Steve: Each of these lines represents a process area from CMMI. The different lengths of the different lines reflect how much work should be performed by the acquirer or by the supplier. All the CMMI process areas, all the collections of best practices, are represented here. None of the work is eliminated. It’s just allocated differently.
He then augments the drawing by adding a vital few process areas specific to an acquirer.
Steve: What it boils down to is the work to deliver a technology solution. I mean, you are right on target—the work is the work. And we need to be clear about who does what and how we can perform as acquirers with suppliers to deliver the best solutions to our customers.
Matt is pleased that this interview has turned into a working session. As far as he is concerned, the interview is over and he has hooked Steve into the job through a lively discussion about Steve’s ideas for solving this process challenge. He saw Steve’s excitement as he whiteboarded the various pieces of the acquirer-supplier puzzle. Matt is now convinced that outsourcing has a really good chance to be successful. He and Steve can make it work.
Matt continues his line of thinking.
Matt: So the answer to our question, as simple as it seems, is that there are standard processes and best practices that all acquirers must follow to deliver technology solutions that improve the bottom line and give stakeholders what they need. If we can clearly determine who does what and eliminate duplicate work, we can better leverage the capabilities of our suppliers and create a win-win situation for both us and our suppliers. And I think we also need to avoid a bureaucratic process that creates a “micromanage the supplier” mentality. If we as acquirers focus too much on the suppliers’ development work, we lose sight of the bigger picture—that we’re the ones aligning technology solutions with business needs and user needs and holding the supplier accountable, but not doing the supplier’s work. Our core competencies have to be things like strategy, requirements, program or project management, and supplier management. We have to figure out how to measure progress and enforce the delivery of value through effective processes as the supplier creates solutions to meet the specified requirements.
Steve nods in agreement.
Steve: That’s exactly it. And it’s feasible. During my research I found a new industry and government reference model for process improvement on the Software Engineering Institute’s Web site—the initial draft CMMI for Acquisition. This model reflects all our discussion today and more. The CMMI-ACQ gives us an industry standard to help us determine whether or not our current processes are working. And then we can accelerate our improvement effort around acquisition because we will have a preexisting structure. Also, using the CMMI-ACQ will bring us closer to our suppliers. They apply a different model of the CMMI, the CMMI for Development, to do their development work, but we’ll both be speaking the same process improvement language. For instance, the CMMI-ACQ clearly defines the touch points between acquirers and suppliers, effectively standardizing the acquirer-supplier interface for outsourcing transactions.
Matt is convinced that he has found the right person to lead the team in making acquisition work for the company, an individual who can help the organization move from an internal development model to a model that supports acquisition of technology solutions.
Steve and Matt are now feeding off of their mutual excitement about the potential for this project.
Matt: CMMI-ACQ addresses the key processes we need to focus on. Let’s figure out the really important things we need to do to make outsourcing work for us, and then we can explain to the CEO how CMMI-ACQ is going to help us become a world-class acquirer. I have a meeting today with Kristin Wells and George Taylor, and we can just continue this discussion with them. They’re the key supplier resources who have been newly assigned to our outsourcing initiatives by their company. The supplier says they’re two of their most seasoned people, and together they have a wealth of experience in supporting companies outsourcing the development of systems. I’d like you to be at this meeting this afternoon. I’d like your feedback as to whether you think Kristin and George have the right skill set and experience. Steve, can you plan to be in that meeting?
Steve: Absolutely.
Matt: So, I take it you’re willing to take on this assignment and work with me to ensure the company’s success?
Steve smiles and responds.
Steve: After I started whiteboarding the solution, you knew I made the commitment!
Kristin Wells is a seasoned executive who has moved up through her organization and has learned various aspects of the technology business through hands-on experience. She has actually performed many of the key jobs on a development team, so she is frequently called upon to troubleshoot an outsourced engagement that is “going into a ditch.” Not only does she have the skills, but also she has a keen analytical mind that helps her zero in on areas that can be immediately triaged to put a project back on track.
Kristin also has an extensive process background. She has successfully completed every software development course offered by the Institute of Electrical and Electronics Engineers (IEEE), although she has never pursued formal certification. As far as she is concerned, what matters is the knowledge and how it can be applied from a practical perspective. And, given the renewed emphasis on outsourcing, Kristin finds herself in high demand as outsourcing engagements have proliferated.
George Taylor is one of those guys who live, eat, sleep, and breathe process improvement. Long before the industry understood the importance of standardized processes, George led all the outsourcing development teams in his organization through a series of exercises to develop an engineering process that all of them could use interchangeably. This initiative resulted in an invitation from the SEI for George to review the initial version of the SEI’s software development process. He was thrilled to participate in that review, and he spent considerable time discussing aspects of development with his colleagues before he sent his feedback.
Now Kristin and George have just concluded a conference call with their company’s senior executive in charge of outsourcing. He made it clear that the meeting with Matt is critical to both companies, because their continued partnership is at stake. Kristin turns to George to prepare for the meeting with Matt.
Kristin: George, to make sure we don’t miss anything in our discussion with Matt, let’s outline the topics we want to touch on. I want to walk into the meeting this afternoon with both of our resumes in hand, so that Matt understands our backgrounds. I also want you to be prepared to discuss some of the troubleshooting you’ve done and the positive results. I want you to highlight your CMMI and ITIL [IT Infrastructure Library] experience as well. I’ll focus on my breadth of knowledge in managing projects of all sizes, from large government contracts to smaller, early Web technology projects. I’ll highlight what I believe has been an exemplary track record. Is there anything else we need to highlight?
George: No, but based on my experience in these kinds of situations where I have been asked to come in and fix a bad engagement, we really need to be prepared to answer just about any type of question—from a company-specific question to an industry question about outsourcing.
Matt invites Kristin, George, and Steve to sit around the small conference table in his office. He wants this to be an informal meeting, and he has erased the whiteboard with the pictures Steve drew earlier. Matt wants to use his mental notes from this morning to steer the conversation with the two supplier reps into a working session. It remains to be seen whether Kristin and George are up for the task.
Kristin starts the conversation by handing the two resumes to Matt.
Kristin: Matt, George and I are prepared to talk about our past experiences with outsourcing engagements that have gotten off track and what we have done specifically to get these initiatives righted. Or we can talk about our plans for your current outsourcing projects, or anything else you want to discuss. We had a conference call this morning with our executive in charge of all outsourcing engagements, and he wanted to assure you that we were recruited from other assignments within our company with the intent to do whatever it takes to make your outsourcing activities work. So we see this as a critical meeting for our company and our ongoing partnership.
Matt puts the resumes on the table and looks across the table at George and Kristin.
Matt: Your credentials preceded you, Kristin. If you weren’t qualified on paper, we would not even be having this conversation. What I really want to focus on are the next steps. We have a number of things to accomplish, and we also have some lessons learned from previous supplier engagements. Where should we start, and which of these lessons should we apply?
George is the first to respond.
George: I’ve spent the last two weeks gathering data about the current situation from team members in your company as well as in ours, and with this data I’ve put together a root cause analysis as a first step. My analysis has surfaced two key facts. First, there was not enough clarity around the roles and responsibilities between supplier team members and your company team members. This resulted in confusion, lack of consistent management across the projects, and redundant work.
Matt: Okay. Can you give me an example?
George: Sure. You had an architect assigned to the project who was very enthusiastic about the technology. So not only did he create a high-level design, but he decided to start coding some of the functionality and demonstrate it to the business customer. Well, of course coding is not in the architect’s job description, but, more important, all the functionality he coded was just for fun. Besides generating code that had to be rewritten, his demo changed the customer’s expectations. That expanded the requirements, resulting in a significant delay and a less-than-satisfied customer.
Matt: So it’s important that everyone understand their role.
George: That’s right. The other key fact I uncovered had to do with process. It wasn’t clear within the team who was supposed to execute what processes. As an example, some of the supplier team members were confused as to who should be doing detailed requirements for the project. Supplier team members waited for acquirer team members to complete the detailed requirements, when in fact it was a supplier responsibility to complete these based on the high-level business requirements. By the time our supplier lead finally realized what was happening and clarified the processes, we’d lost two weeks. To resolve these issues, I recommend that we quickly put together some team workshops, get the new teams together, and clarify the processes along with clearly defined roles and responsibilities. Then, with some expert project management skills, I believe we can execute and deliver to our commitments.
Steve speaks up.
Steve: George, are you a student of CMMI and process improvement?
George: Yes, I am. In fact, I’ve consulted with organizations to help them take their development groups to higher maturity and capability levels.
Steve: Sounds like you’ve been in the thick of CMMI for a while. Are you familiar with the CMMI-ACQ?
George: No, but I read something about it not too long ago. Isn’t that being worked on? I think by one of the Big Three auto companies, the Department of Defense, several government agencies, and the SEI?
Steve: That’s right. The initial draft of the model has been published, and I think we should use the CMMI-ACQ to help us accelerate these workshops and clarify what each of our groups on these joint teams needs to focus on. Matt, should I walk Kristin and George through our thought process from this morning?
Matt: Be my guest.
George and Kristin listen closely to Steve ’s descriptions of the CMMI-ACQ. Steve finishes the recap.
Steve: Let’s see how quickly we can get the teams together. We want to reestablish the process partnership within our outsourced project teams and use the acquisition model to help standardize our processes. I’ll ask my team to put together a slide documenting the division of work, and we can begin to reference this picture with the teams.
Kristin expands the discussion.
Kristin: It’s my understanding that in the past your company struggled with interpreting how the CMMI for Development applies to acquirers.
Steve: Yes, and the more we used it, the more we understood that it fell short of what we needed as acquirers. We needed a more extensive collection of best practices for acquiring technology solutions. Then I found the CMMI-ACQ on the SEI Web site, and I thought, “Bingo! Somebody else must have had the same thought.” The CMMI-ACQ has best practices that we can use right away.
Kristin: Can you give me an overview?
Steve: The CMMI-ACQ focuses on key acquirer activities—initiating and awarding supplier agreements, using a set of standard metrics to manage the acquisition of products and services, developing acceptance criteria, defining supplier deliverables, and so on. It’s different from the CMMI for Development model, which focuses on development activities, including the supplier’s activities to execute work.
Kristin: Makes sense. So, the CMMI for Development is the reference model that suppliers use for executing their systems engineering, hardware and design engineering, and software development work. In contrast, the CMMI-ACQ provides a road map for acquirers of the technology solutions that suppliers develop or configure.
Steve sets up a chart he has prepared for this meeting (see Figure 1-3).
Steve: Here are the six CMMI-ACQ process areas that are specific to acquirers. “Acquisition management” focuses on managing the supplier agreement—things like dispute resolution and change management. This includes managing payments and ongoing communications with suppliers. “Acquisition requirements development” defines processes for specifying measurable requirements that express customer value, which the supplier then translates into more specific, detailed requirements. “Acquisition technical solution” means you codify the role of the acquirer’s architecture group in terms of high-level technology direction, nonnegotiable technology standards, and architecture reviews. We use the processes in the “acquisition validation” and “acquisition verification” process areas to ensure that the product or service received from the supplier fulfills its intended use and meets architectural technology constraints. The “solicitation and supplier agreement development” process area defines practices for preparing a solicitation package, selecting a capable supplier, and establishing the supplier agreement.
Matt nods as Steve continues.
Steve: The CMMI-ACQ also addresses the foundation practices that any organization must excel at if it wants to be successful. These are common to all CMMI models. They cover project management, support process areas, and process management. For project management, we’re talking about planning, monitoring and control, and risk and requirements management, as well as measurement and analysis, configuration management, process and product quality assurance, causal analysis, and resolution. The foundation practices also cover activities that help us improve as an organization, not just project by project—organizational process definition, process performance, training, and innovation and deployment. These process areas essentially describe practices and capabilities that are our “required commodities.” Each process area amplifies the nuances that successful acquirers master to implement these common practices and capabilities.
Kristin: If you apply the acquisition best practices to your work, and if we apply those practices in the development model that reflect the work that we need to do as a supplier, then together we can improve our results and achieve greater customer satisfaction.
Matt glances across the table at George and Steve, who are nodding in agreement.
Matt: I think we just defined our direction.
Matt’s last hurdle in recruiting the key players on his team is to effectively engage Paula Ressel, the internal customer for this product. Matt knows that Paula is going to be a challenge. By reputation, she is a demanding individual. Part of this attitude has to do with her background. She is by training an accountant who was chosen early in her career as a high-potential employee. She has taken this designation to heart and has tried to be assertive and exacting in every assignment.
Her director feels that Paula is perfect for this assignment—to use outsourcing to develop some of the financial business intelligence functionality—because Paula is a voracious reader. She reads everything that comes across her desk. She isn’t shy about asking questions. She also has the uncanny ability to take the detail in any initiative and abstract it immediately to a high level, describing the salient deliverables and the overall business value. It is these two characteristics that Matt feels will be invaluable in keeping this integrated team moving forward and focused on the right things. Matt has arranged a luncheon meeting with Paula. He wants to make sure that she understands how he is going to proceed, and he wants to get her feedback from the business side of the company.
After describing for Paula some of the challenges uncovered in George and Kristin’s two-week analysis, Matt focuses the discussion on workshops, getting all the teams on the same page from a roles and processes perspective, and then keeping a tight rein on oversight and management. Matt is trying to raise Paula’s comfort level. He knows that the business intelligence functionality is directly tied to an important business case for the company. This functionality will be critical in the next 18 months to two years in giving the company information it needs to reposition its product line in an emerging global business. Paula asks the tough question that Matt anticipated.
Paula: How do you know you are making the right course corrections with outsourcing? How do you know that you’re doing all the right things?
Up to this point in the conversation, Matt has avoided any discussion about the SEI, CMMI, IEEE, and process improvement—concepts that he knows he will have to put in a business context for Paula.
Matt: Paula, we have pulled in the best resources from within our organization and also within the supplier’s ranks. We believe that we understand what went wrong, and it had to do with a lack of clarity around roles and processes. To make sure that we’re doing all the right things, we’re also going to leverage some important industry standards. One in particular has been just recently published in response to the large number of companies who are now looking to outsourcing as a way to accelerate the development of systems. This is a set of best practices that will allow us to verify that we are doing all the necessary things to acquire solutions. We will also talk to suppliers who support outsourcing, other companies who are using outsourcing, and make sure that we do not repeat the same mistakes they’ve made.
Paula has worked with Matt in the past and has a great deal of respect for him. It has been her experience that, if Matt says he is going to make something work, he will do everything possible to follow through.
Paula: Matt, I believe that you will do everything to make outsourcing work for us. Now, what is it that I can do to help you?
Matt: I want you to do what you do so well. Make sure that we cover the details, that we include all your requirements, and that we deliver what you need for business intelligence. My door is always open, and I want your feedback as we build this functionality with our supplier. Let’s schedule some brief checkpoint meetings so that we remain in alignment.
Paula agrees.
Matt has completed the work of building a team to work on improving the company’s acquisitions processes.
Matt spends the next week synthesizing the information he has gleaned from his team members. He also references discussions he has held with project managers who were involved in some of the challenging projects that were part of the initial outsourcing activity. He has been told by the chief information officer that he will be invited to the next meeting of the executive board to discuss plans for getting the outsourcing initiative back on track.
Based on the interviews, the discussions with suppliers, and his contacts within other companies that have instituted outsourcing, Matt feels confident that he can put together a presentation for the board that will resonate with board members and give them confidence that the company can move forward with this approach and be successful.
Matt has hit upon the idea to characterize the key insights he has gained as “hidden truths.” These are the main points about outsourcing that the company must understand and execute to be successful. Major analysis firms like Gartner and Forrester have echoed some of these concepts in their analyses, but no one has put together this list in exactly the way Matt intends to present it to the board.
The invitation comes from the CEO for Matt to appear at the next executive board meeting to discuss his plans for reversing the negative trends in using outsourcing to obtain technology solutions. The CEO wants to be convinced that the model can be workable, because the last thing that the executive board wants to do is to invest more funds with suppliers, with no guarantee that there will be any return on investment (ROI).
Matt begins his presentation to the board.
Matt: Now more than ever, organizations are increasingly becoming acquirers of technology solutions by obtaining development and maintenance services from suppliers and developing fewer technology solutions in-house. Like many other organizations, we have adopted a business strategy to improve our operational efficiencies by leveraging suppliers’ capabilities to deliver quality solutions rapidly, at lower cost, using the most appropriate technology.
Matt pauses, weighing his words carefully before he continues.
Matt: Acquisition of technology solutions is challenging, because we must still hold overall accountability for solution delivery, while allowing the supplier to perform the activities necessary to develop and maintain the solution. According to some folks, 20 to 25 percent of large outsourcing projects fail within two years, and 50 percent fail within five years. And that’s within the IT domain alone. A number of factors contribute to project failure: mismanagement, an inability to articulate customer needs, poor definition of requirements, inadequate processes for supplier selection and contracting, insufficient procedures for selecting technology, and uncontrolled changes to requirements. The onus for these disturbing statistics does not sit exclusively with the supplier, but also with us. Most project failures can be avoided if acquirers learn how to properly prepare for, engage with, and manage suppliers.
Matt glances around the room. He can tell that he has hit on points that matter to the board members.
Matt: We’ve learned a lot about buying technology solutions over the years. Thinking back, it took a lot of perseverance and the collective brain trust of all our customers, employees, suppliers, and partners to plainly see the hidden truths about acquiring technology solutions, and to decisively act on them. It boils down to six hidden truths.
Matt explains that successful acquisition organizations don’t engage in outsourcing without executive commitment.
Matt: To implement the policies, processes, and activities that will drive our outsourcing efforts, we must have continued support from you and all the other members of the executive team. Deciding to use an outsourcing model is a strategic decision, and it is made by the executives at the highest levels of the organization. After we make this kind of commitment, the executive team is key in giving the organization and its suppliers consistent messages about the strategy and its importance to the company. This will include positive encouragement to support specific team initiatives, along with recognition of the successes of our project team members as well as supplier team members.
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, Matt tells the board.
Matt: Acquirers and suppliers must acknowledge these costs and risks and mitigate them through ongoing collaboration. One of the most important aspects of this partnership is to make risks and issues visible and manage them together. We’ve decided to immediately institute joint project reviews that are focused on early identification of risk and to make our managers, from our company and the supplier, squarely accountable for resolving these risks in the shortest time possible. And these risks and their mitigation are an important aspect of all of our outsourced projects that we measure on an ongoing basis.
Matt introduces the third hidden truth: In an outsourcing model, the acquirer must maintain and execute certain core competencies. As an example, he cites the role of IT broker as a core competency for acquirers.
Matt: We must solicit these high-level requirements and must clearly articulate the relationship between them and our business goals. Suppliers are not necessarily in a position to understand our business strategies. We must also develop expertise in maintaining architecture and standards in order to manage our solution costs and to drive selected technologies forward. Competing technologies are proliferating, and that drives cost; as an acquirer, we must drive the overall technology vision for our organization. We are also responsible for developing specific acceptance criteria for the functionality that is built. For this, we can adopt formal activities like user acceptance testing. As contractually specified deliverables are created and presented to us, we must have clear and complete acceptance criteria to ensure that our defined requirements have been met and that the right technology has been delivered.
Organizations want to acquire solutions that benefit their bottom line and provide stakeholders with what they need. Suppliers want to fulfill their contracts, make a profit, and maintain their relationships with acquirers and with other suppliers.
Matt: Certain factors—such as lower costs versus higher profit margins, and fast delivery versus low deployment costs—may cause conflicts between the supplier and the acquirer, as well as among multiple suppliers. With all these different and occasionally conflicting goals in the mix, we must all agree on some balance to achieve success. We must build an environment of trust with our suppliers so that they can feel comfortable about sharing their ideas and work with us to leverage opportunities. If we approach them only from a cost-cutting perspective, we will miss the chance to jointly realize competitive opportunities that could make our relationship a true partnership and strengthen our company’s position in the marketplace.
Engaging in active outsourcing is one of the most difficult challenges for an organization that acquires rather than builds technology solutions, Matt explains.
Matt: We must manage our suppliers to achieve results and retain accountability for those results. We must plan, manage, motivate, and communicate with our suppliers but not participate in the detailed, technical development of the solution. This is why it’s so important for us to have the right acquirer processes that are aligned with supplier processes. We can avoid confusion, redundant work, and nonstandard technologies, and we can seamlessly work together to deliver to our internal customers. The CMMI-ACQ model of best practices will help us create the clarity needed about roles, responsibilities, and processes.
Matt tells the board that processes, contracts, requirements, products, and product components are all viable candidates for standardization.
Matt: 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. The more we leverage standard contracts and reuse requirements, exploit products like standard reporting software, and take advantage of common capabilities like access controls or data warehousing, the more efficient our outsourcing activities can become. Our suppliers will become familiar with these standard requirements and components and can build them into their proposals. This should help our suppliers to more effectively leverage their skilled staffs and reduce overall development costs. Over time it should also have an impact on the cost and quality of application maintenance.
Table 1-1 shows the hidden truths and their alignment with the CMMI-ACQ processes.
Table 1-1. The Six Hidden Truths
Hidden Truths | CMMI-ACQ Process Areas | Book Chapter |
|---|---|---|
|
| |
|
| |
|
| |
|
|
Next, Matt summarizes the hidden truths.
Matt: These six hidden truths are the foundation of what our organization needs to do to become a successful acquirer of technology. Revealing these hidden truths is the first step, but making them a reality is an even bigger challenge. Based on our analysis, we firmly believe that it’s critical for us to evolve our processes to make this happen. If we want to compete in a global marketplace, we need to get even more precise about what we focus on with technology, and how we bring together the right employees with the right suppliers to create the right technology solutions for our customers. We’ll need to invest in the human capabilities necessary to effectively manage projects in an acquisition environment. Our teams must be engaged throughout the project life cycle. We can’t afford any situations where the team disengages after the supplier is under contract. We can’t afford to discover too late that a project is not on schedule, deadlines cannot be met, the selected technology isn’t viable, and that the project has failed.
Matt concludes with the following remarks.
Matt: I am making a commitment to all of you today that we will work to effectively implement outsourcing for our company. I will come back on a quarterly basis and give you very detailed updates. In the interim, you will receive reports that will capture initiatives that are outsourced and their current status. Based on the commitment from our teams and the supplier teams, and the course corrections that we have identified, we believe that outsourcing can become an effective tool to deliver solutions to our organization. Any questions?
In each chapter that follows, Matt, Steve, Paula, Kristin, and George—as well as Rosa Gonzales, a new hire joining the team in Chapter 5—will set the context for the CMMI-ACQ process areas by sharing their struggles, experiences, and ideas. In highlighted boxes within the text, you’ll find tips to immediately direct you to some of the most important rules or tenets for improved acquisition practices. These tips include lessons learned, aspects of an acquisition that require special attention, or realities that may occur in your acquisition. We then explain the associated CMMI-ACQ elements as well as tie the tips to CMMI-ACQ process areas, goals, and practices.