The success of any project depends on delighting the customer, and that requires understanding the customer. Poor understanding of customer intentions—needs, expectations, and constraints—accounts for most project failures. This chapter highlights the vital importance of eliciting high-level requirements and maintaining the relationship between these and your business goals (see hidden truth number 3, “Maintain acquirer core competencies,” in Chapter 1).
We focus first on developing requirements, explaining how to successfully develop customer requirements and contractual requirements to guide the supplier’s work. The first step in developing good customer requirements is to elicit customer needs. We cover this important practice in depth by focusing on how to clarify the value of the technology solution for the customer through requirements, why it’s important to involve the customer early, and how to manage the gaps that naturally occur between stakeholders. You will learn that there is no substitute for direct interaction with the customer.
These interactions take a spiral pattern of repeated steps and increasing mutual understanding. You build a relationship in which each party continually increases its realization of what each can contribute. The process begins with the germ of an idea—a few words or a sketch—and eventually matures into a fully developed, operational technology solution.
The first step is to present the idea to the prospective customer immediately. Promote the idea. Help the customer understand what you have in mind. With truly novel solutions to problems, the customer may initially have difficulty seeing what you are offering. The second step is to listen to the customers’ views carefully, thoroughly, and in enough detail and context that you can understand what is really being described. The third step is to develop or modify the product or service in creative response to what you’ve heard from the customer. Then you return for further rounds of promotion, customer feedback, and development.
We then turn our attention to writing contractual requirements by describing how to capture minimum, accurate requirements and translate these into practical design constraints for the supplier. In this process, you must be cognizant of the conflicting goals between suppliers and acquirers and often between different suppliers (see hidden truth number 4, “Understand conflicting goals between suppliers and between suppliers and acquirers,” in Chapter 1). Acquirers want to obtain 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 you and with other suppliers.
Certain factors—such as lower costs versus higher profit margins, and fast delivery versus low deployment costs—may cause conflicts between you and the supplier as well as among multiple suppliers. We cover your role in designing the technology solution and in managing requirements throughout the project to discuss remedies for conflicting goals between various stakeholders and to achieve value-added technology solutions.
The essence of engineering successful solutions is to understand which solutions will add value for your customer. Eliciting needs goes beyond the initial collecting of requirements to proactively identifying additional requirements not explicitly provided by the stakeholders. You consult relevant stakeholders representing all phases of the product’s life cycle in the intended environment and ask them to describe business as well as technical functions. In this way, needs for all product-related life-cycle processes are considered concurrently with the concepts of the products you seek to acquire.
Frequently, the needs or requirements of stakeholders such as customers, end users, and suppliers are poorly identified or conflicting. Because you need to clearly identify and understand the stakeholders’ intentions throughout the project life cycle, you use an iterative process. You involve the relevant stakeholders to communicate their needs, expectations, and constraints and to help resolve conflicts. For that, successful project teams engage the customers from the beginning and proactively deal with the sometimes conflicting viewpoints of different stakeholders.
All projects begin with the customer, and you need a deep understanding of the customer’s business model (or mission) and processes. Matt Vauban, an executive in our fictitious acquisition organization, ponders this seemingly simple statement as he looks out his office window to the other side of the river. Then he turns to Steve Reiter, the project manager for the project, which is aimed at improving the company’s acquisition processes.
Matt: Steve, we always have to keep our business model in mind. We can’t afford to buy into some new technology just to make us feel good and look better. When I listen to our CEO, I get a clear message: We need to carefully look at everything we’re doing as a business and eliminate activities and technologies that don’t add value.
Also meeting with Matt and Steve is Paula Ressel, the internal customer for our acquisition project.
Paula: You’re right, Matt. I don’t think we’ve done that very well.
Steve: I agree. Whenever we invest money in the future, we better have a promising business model of what the future will look like.
This exchange is similar to an anecdote that John Marano Jr., now CEO and president of the start-up Vascular Insights, told nearly a decade ago:
The company laboratory invents a device with a wire frame and cocking spring on a nice piece of wood. When the wire frame is cocked, a small disturbance causes the frame to slap onto the wood with a great deal of force. The device is taken to a customer with the plea, “I don’t know what to use this device for, but if you tell me, I’ll be happy to sell it to you.” A highly negative customer response is common. On the other hand, if discussions with a customer result in, “I need a better mousetrap,” it is much easier to invent and sell a wire frame with a spring on a nice piece of wood.
Undertaking a development effort with a true understanding of customer requirements leads to easier and more frequent success.
Although it’s crucial to satisfy the customer, this satisfaction must emanate from a specific business need; this need may leverage new technology and create new products, but it must always add to the bottom line.
George Taylor, an executive from the supplier hired for this project, joins the meeting. Matt continues the discussion.
Matt: You can almost always develop a system to solve a business problem, but the cost might be horrendous. The question is, Is it okay with the customer? We go back to them and say, “I know you have these problems. However, for these reasons it will cost this much money. Are you willing to live with the current situation, or are we going to move forward and add this functionality?” We have to be honest about how much money we’re willing to spend to resolve a specific business problem.
You need deep organizational and business process knowledge to build value-added solutions. Yet gaining access to this knowledge is one of the most critical problems in acquiring technology solutions. For many project teams, the required breadth of skill and experience for engineering large, complex systems is a scarce attribute. One business-savvy technology leader lamented,
I ask projects to show me the business model that implementing this system will enable. The response I get is, “That’s probably something that needs to be created.” And you then wonder, “How many tens of millions of dollars have we spent developing a system to go global where we don’t have a global business model that my business partners can look at and agree with?” How can we build a system if we haven’t agreed to the business model? I don’t get that.
An organization might be tempted to bring in additional resources from suppliers to attempt to quickly fill this gap. Paula doesn’t buy that approach.
Paula: We’ve had limited success in using suppliers’ requirements analysts. They tend to be entry-level people, so there is a lot of turnover. When we go from project to project, even with the same supplier, rarely do we get the same requirements team assigned. We often get a person who needs to get up to speed, and that can be painful. They may understand technical best practices or they may have some helpful industry best practice knowledge, but they tend to lack business process knowledge.
Matt: How do you mitigate this risk?
Paula: We provide our own requirements team to support the supplier from a coaching and mentoring standpoint, and we leverage the supplier’s technical knowledge and best practices.
To focus on delivering value when buying and implementing technology throughout an organization, Matt, a seasoned executive, calls for a new role for acquirers.
Matt: It’s helpful for us to see ourselves as technology brokers. I’m not alone in this viewpoint. Senior executives in several companies like ours have publicly said this. I measure everybody who works for me on business transformation—not technology transformation, not the technical elegance of a solution.
Steve: Being an engineer by training, I find it sometimes hard for techies not to fall in love with the elegance of their designs.
Matt: I know, Steve. But we’re measured on achieving six sigma-type improvements, on world-class quality, efficiency, and effectiveness. Every dollar that goes into technology must benefit the business and our customers. It’s a different mentality. The technology broker’s only job is to transform the business—to get business results.
Key individuals in an acquisition organization must step up to the challenge of functioning as businesspeople first and then technologists. They must learn not only to use the language of the customer’s business but also to think like the business—understand business issues and propose business solutions. By combining deep business savvy with keen technology insight, acquisition organizations can more effectively conceive, develop, and support ideas for improving organizational performance, as Steve describes.
Steve: I think the key to any project is involving the right people who have business knowledge. It’s important that the project team understands the system delivery and acquisition management process, but that’s probably 25 percent. It’s more about somebody that the customer will respect when they talk to them. When you have someone who comes in and talks to the business in their own language, the team instantly gets respect.
George: When I’ve worked to gather requirements either for or with an acquisition organization, finding the right people to gather requirements is a challenge. We tend to look for what you might call “Sherpas” and “Yodas.” Remember Star Wars? You know Yoda, the Jedi master?
Everyone smiles and nods.
George: Well, of course Yoda is the wisest and most powerful Jedi of his time. That’s who we need—somebody who has the most knowledge and experience, somebody who has a really good context of the work that’s going on in their organization.
Someone in the back of the room is heard to say, “Yes, but talk funny Yoda does,” and everyone laughs. George continues the analogy.
George: Then you have the Sherpas—you know, the guys who guide the mountain climbers in the Himalayas. They’re the experts, they know the territory, they have endurance and resilience. Sherpas have all the effective job aids, and they often point you to best practices for actually getting the work done.
Tip
Identify and engage those individuals who have deep business knowledge and are well respected by their peers.
Before the integrated project team starts interviewing customers to elicit their requirements, it needs to conduct due diligence to find the Sherpas and Yodas. The team also needs to keep its eyes and ears open to identify potential Sherpas and Yodas during requirements gathering sessions.
Even if you have well-understood as-is and to-be business models and processes, it’s critical to have ongoing communication with stakeholders, especially the customer. Matt wants to review this issue with Steve.
Matt: How do you establish effective communication with other business functions? We need to make sure they don’t think we’re out there developing fancy technology solutions and wasting scarce resources instead of delivering value.
Steve: To get everybody on the same page, we use what we call a “bill of process.” This is a way to document a business process and help us maintain a common language with the business. It’s kind of like a bill of materials, which manufacturers use to describe a product in terms of its assemblies, subassemblies, and basic parts.
Matt: A bill of materials?
Steve: Let me explain. A BOM hierarchically decomposes a product until it reaches some constituent part or module that is out of the scope of the BOM. So we took the business processes and broke them down globally into subprocesses and activities. We augmented that with flow diagrams that show relationships and who is responsible for what.
Steve laughs.
Steve: As we went through this exercise some people discovered processes they didn’t know they had in their own areas.
Tip
Regularly benchmark your business model and processes against your competition and best-in-class organizations.
Methods like decomposing business processes and maintaining accurate process descriptions are ingredients for achieving common processes that are, in turn, the foundation for consistent execution of work. Matt reiterates this point from a global perspective.
Matt: Today, people focus much more on standardized processes and globalization—the ability to develop, manufacture, sell, and distribute products anywhere in the world at the lowest price. If you’re expanding into new regions or new product lines, you have to leverage common processes to keep your costs down and drive efficiency into every part of your business. The best product with the lowest cost structure wins.
Steve: Yes, the world is getting flatter every day.
Matt: And to survive, you have to do all this through seamless expansion or contraction. If you disrupt your business doing this, your competitors will eat you for breakfast.
Steve: In fact, focusing on value is why we’re looking outside ourselves in the first place.
Matt: We do frequent competitive analyses of business processes and the application of IT. We have numbers that go back more than a decade. Our business process leaders and my staff have process reviews with our CEO every year. Every process officer and information officer has to present a competitive assessment—where they are in their business processes relative to their competition and versus the theoretical limit of a particular business process or technology.
The joint leadership of business functions and the acquisition organization—in other words, the shared governance—is at the heart of effectively harmonizing business processes and technology solutions and thereby enabling the acquisition organization to add value to the endeavor. Steve illustrates.
Steve: The way global projects used to work was we built it at our headquarters and then called it “global” and deployed it everywhere else. But on this project we made a concerted effort to define the global requirements and the global process as a group. The initial phase wasn’t so much IT-related; it was more like defining how they currently did work and then defining what the new business process would be. To achieve this we put together a steering committee with equal representation from each region. So instead of having a heavy influence from headquarters, we were very conscious of the number of people from each region and created a team that represented IT and business equally.
Various techniques are available to interact with customers and stakeholders.
Paula: We use a variety of techniques to gather requirements. It depends on the type of project and the type of stakeholder. We like to give everybody a way to get heard. Sometimes this is easier said than done in a workshop environment. We do use workshops quite a bit, along with interviews or brainstorming. We don’t use questionnaires very much. They tend to be more impersonal and used for data collection. It’s often hard to interpret what’s written on a piece of paper, and the return rates tend to be very poor. Interactive sessions are much better.
In virtually all projects, you need to adopt a mix of requirements gathering techniques. This flexibility is even more important in an outsourced environment. Suppliers need to be involved early, and the combination of techniques must compensate for the additional handoffs from you to the supplier and, in many cases, from the supplier’s account manager or on-site team to a (perhaps offshore) development center.
The environment you select is an important aspect of eliciting requirements.
Paula: If you’re interviewing people to gather requirements, the best place is in the work environment. Working directly in the users’ environment is critical to our success.
Steve: We like to use a supplier team together with folks from our organization who understand the business process inside-out. They ask questions like, “How do you do this task or that activity?” while sitting next to the users or customers. The information we get that way is priceless.
Paula: How do you record the info?
Steve: Videotape. It’s extremely helpful. It’s really interesting when you look at these videos later and notice all those “job aids” people use that you completely missed during the interview—for instance, sticky notes on their computers with a list of quick commands and passwords. People don’t mention these things, because they’re so used to them they forget they’re even there.
Steve laughs as he remembers.
Steve: Sometimes when they tell you about a task or a sequence it sounds trivial. Then when you watch the video later you realize that they’ve described a very involved process. For instance, they might have to log on to three systems simultaneously to perform a seemingly simple task. They use a myriad of tools around their desk to work around a broken process, but they don’t realize the complexity anymore because the process has become second nature.
Sometimes observations are useful for eliciting needs. In conducting an observation, project teams watch individuals for an extended time and produce detailed records of work practices. The rationale for these studies is that actual work practices differ from prescribed practices as documented in procedures, policies, and handbooks. You can partially uncover these processes by studying videotapes, as Steve mentions. Observations, however, are a more thorough investigation to discover tacit requirements. Steve recalls the use of observation on a recent project.
Steve: We did visits of two to four weeks at each site, just as fact finding. We sat with the users to understand what they did. We did their job with them.
Tip
Instead of relying only on people’s stories about how work is performed, observe how work gets done.
Matt: Looks like you immersed yourself in the users’ work environment and business process.
Steve: Exactly. And we discussed with them how they perform a particular activity and really focused on getting to know the people and building that team. So everybody in every region felt part of the project. They didn’t always feel they needed it, because everybody thinks their own process is good enough. But they were proud of what they did, they showed it, and we understood it.
Another approach is to install a camera to videotape a work environment to quietly observe what’s going on. In this way, you can record work patterns in an unobtrusive way.
Observations provide additional insight into how practitioners perform their activities. They emphasize the importance of social interaction rather than data, data structure, or processing. By analyzing social interactions, you gain a better understanding of what people do and how or why they do it. Analysis of recordings and results from field studies reveal the practices through which information is communicated and tasks accomplished. Even apparently individual tasks such as reading, writing, or typing into a computer are embedded in interactions with others and are designed in relation to others’ activities.
However, records from observations are inherently unstructured. For example, observation records contain significant duplication, and the collected information ranges from specific observations of particular activities to anecdotes and war stories told by customers and users. With this kind of information, there is seldom a clear and simple correspondence between an observational record and a requirements document, model, or prototype. To bridge this gap, it is critical to move the customer and users from “How do I perform a particular process or function?” to “Why am I performing this process or function?”
Steve: People get so tied up in their day-to-day tasks, sometimes they can’t step back and understand why they’re doing a particular step. When we’re analyzing the business process to identify technology opportunities, it’s important to move away from the actual task, such as entering the data into a specific spreadsheet, and focus on why they’re doing that step.
Matt: How do you do that?
Steve: We try to get the process into flowcharts or process maps. This lets us break the process into subsets and get agreement on the individual components. Everyone thinks that their own job is very complex and no one else can do it. In fact, after you break it into pieces you can identify the few complex pieces and focus on them.
After stakeholder intentions have been made explicit, they must be prioritized for effective realization as a technology solution.
Paula: We basically had 16 high-level requirements, and then we asked the team to prioritize them based on their business value. We took a vote of all the stakeholders to get a forced ranking. We wanted to understand what was more important so we’d be ready to work through issues as they came up.
Prioritized requirements drive the process of successful project teams. Customers and users establish priorities for requirements, and this allows the project team to decide which requirements to investigate when and to what degree of detail.
To specify prioritized requirements, you need to take into account that requirements fall into several groups. In the 1980s, Noriaki Kano discovered that some requirements are not one-dimensional, where customer satisfaction is simply proportional to how functional the technology solution is (Center for Quality Management Journal, vol. 2, no. 4, 1993). In the so-called Kano diagram shown in Figure 3-1, the line going through the origin at 45 degrees depicts the situation in which customer satisfaction is simply proportional to how functional the technology solution is: the situation in which the customer is more satisfied (up) with a more fully functional technology solution (right), and less satisfied (down) with a less functional technology solution (left).
Often we can distinguish between “must-be” and “attractive” requirements. The must-be curve in Figure 3-1 indicates aspects with which the customer is more dissatisfied when the technology solution is less functional; but the customer’s satisfaction never rises above neutral no matter how functional the technology solution becomes. For instance, having a lack of security in an online banking system causes the customer to be dissatisfied; having airtight security, however, doesn’t raise the level of satisfaction. Good security is expected. It is a must-have requirement.
The curve labeled “Attractive” indicates areas in which the customer is more satisfied when the technology solution is more functional but is not dissatisfied when the technology solution is less functional. For instance, a customer may be more satisfied when word processing software can automatically hide menu items that haven’t been used for a while, but may not be dissatisfied if this feature isn’t available.
Understanding the Kano diagram has important implications for the way you specify solutions. Matt emphasizes this point.
Matt: I would much rather focus on solving the problems of my business customers than worry about some of the run-of-the-mill, technology-driven requirements. I want to focus on the business issue and be able to come back to the customer and say, “You want to go with some of these, and I want to put them together in record time.”
The CMMI-ACQ provides specific practices for eliciting customer needs, expectations, and constraints to obtain customer requirements that constitute an understanding of what will satisfy stakeholders (see Table 3-1).
Table 3-1. Acquisition Requirements Development Goal 1: Practices and Tips
CMMI-ACQ Process Area: Acquisition Requirements Development | ||
1. Goal: Stakeholder needs, expectations, constraints, and interfaces are collected and translated into customer requirements. | ||
Practices | Tips | |
1.1 | Elicit stakeholder needs, expectations, constraints, and interfaces for all phases of the product life cycle. |
|
1.2 | Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. |
|
The intentions of stakeholders such as customers and users are the basis for determining requirements. The stakeholders’ needs, expectations, constraints, interfaces, operational concepts, and product concepts are analyzed, harmonized, refined, and elaborated for translation into a set of customer requirements.
Eliciting needs, however, goes beyond collecting requirements from stakeholders to proactively identifying additional requirements not explicitly stated (Table 3-1, practice 1.1). Various techniques are available to elicit needs from current and potential customers and other stakeholders. For example, the following tools are all useful in eliciting needs:
Questionnaires, interviews, and operational scenarios obtained from end users
Technology demonstrations, operational walkthroughs, and end user task analysis
Prototypes and models
Observation of existing products, environments, and workflow patterns
Quality function deployment (QFD), which employs a series of matrices to translate qualitative customer requirements into quantitative technical requirements
The customer typically describes requirements as capabilities expressed in broad operational terms concerned with achieving a desired effect under specified standards and regulations (Table 3-1, practice 1.2). The various inputs from the customer and other stakeholders must be aligned with your strategy. As you document the customer requirements, you must obtain any missing information and resolve any conflicts (e.g., customer requirements that exist as an output of another project’s activities, such as a previous project that delivered the initial capability).
Here are examples of considerations you should keep in mind for expressing customer requirements:
Key characteristics (attributes) of the desired capability, with appropriate parameters and measures
Obstacles to overcome to achieve the capability
Competitive gap between existing and desired capability
The customer’s requirements establish the basis for what an acquisition must deliver, why the technology solution is needed, and how it must function to be of value to the acquirer. Making customer requirements explicit early in the acquisition process reduces the need for later redesign, rebuilding, and retesting.
For you as an acquirer, simply defining customer requirements isn’t enough. Customer requirements must be clearly and concisely translated into a set of supplier agreements that will guide the supplier in developing or configuring a technology solution that fits its intended use. In other words, you further specify the customer requirements so that they can guide the supplier’s technical work, considering other constraining factors such as safety and regulatory requirements.
In addition, you augment your customer requirements with technical specifications to ensure that the technology solution will fit well into the intended environment.
All this results in so-called contractual requirements: precise requirements contained or referenced by the supplier agreement that serve as the baseline for controlling the acquisition’s scope. In other words, subsequent changes to these requirements are permitted only upon formal approval and, in many cases, necessitate a change in the supplier agreement. In addition, contractual requirements provide a realistic basis for estimating project parameters such as cost and schedule and can be used as a reference point from which to measure the performance of the solution. Contractual requirements included in the RFP form the basis for evaluating alternative solutions and support negotiations with the potential suppliers.
Sound easy enough? Not quite. The dilemma faced by every acquirer is how to best translate customer requirements into contractual requirements. Time and again, acquirers and suppliers alike find it exceedingly difficult to arrive at an accurate, minimal set of contractual requirements.
Paula: Writing contractual requirements is hard. It gets easier if you focus on communicating and documenting those aspects of the solution that most clearly demand attention and seem most likely to create problems.
Requirements that are already common knowledge communicate little new information to a project team. This suggests that acquirers want to be particularly good at communicating a limited number of nonobvious or counterintuitive requirements. The contractual requirements should therefore focus on communicating the significant differentiators and avoid arbitrary requirements that make the technology solution do more than necessary to accomplish its purpose.
Unfortunately, many acquisition organizations and suppliers consider it desirable to create a highly detailed specification of contractual requirements. There is a long tradition in software engineering of making the specification document the sole body of knowledge about the solution. Many people think the only good specification is a highly detailed or “complete” one. Often we hear, “If only you had written a more detailed specification of the requirements, you wouldn’t be having these problems.” In other words, this myth is at the heart of the belief that you can eliminate risk by including more detail, if not mathematical precision, in specifying technology solutions.
Steve highlights an important lesson he has learned: In some cases, overly detailed standard templates used to document requirements can lead project managers to the conclusion that more detailed specifications are better.
Steve: A standard work product of our process is a requirements document that can be several hundred pages long. It has all the system requirements that are already well known to the supplier and the traceability data that is relevant only to the project team. It also has a lot of white space. This document was just indigestible.
Matt: What happened?
Steve: The supplier sent us a note: “Please don’t subject me to such torture.”
Everyone at the table laughs, and then Steve continues quoting the harried supplier.
Steve: “The requirements we need are in here somewhere, but I can’t find them. I shouldn’t have to read 300 pages to figure out the 30 functions that are critical to your business process.” The sad part was that virtually every project was using this format. So it took us a while to turn off the spigot. We organized an improvement workshop to change the template so that we only present relevant requirements to the supplier.
Steve smiles and continues.
Steve: We even applied the same approach to communicate requirements to our customer. During the workshop we found that one group had a custom-coded query tool that went into their requirements database and pulled out only the specific requirements that a customer would be interested in and formatted them into an output that was more readable than the standard template. We now use this tool to do the same for our suppliers.
A razor-sharp focus on the significant differentiators will result in a successful exchange with customers. In contrast, a full definition of all requirements can do more harm than good. Each requirement is a constraint for the supplier and can complicate the design task. These constraints can be arbitrary and can result in compromising a significant customer differentiator. In reality, a specification that contains too many constraints only draws the attention of the project team away from the things that really need to be optimized.
Surprisingly, it is much harder to produce an accurate, minimum specification than it is to create a detailed one. This situation is the perfect manifestation of something Blaise Pascal wrote: “I apologize for the length of this letter, but I didn’t have time to make it shorter.” It’s easy to create detailed specifications because, in many cases, we can simply copy every feature offered by the technology solution in use or by available technology solutions in the marketplace. In contrast, to arrive at an accurate minimum specification, you need to make choices—such as what to focus on and at what level of granularity—and to do that, you must know which requirements are truly important to the customer. This takes a much more profound knowledge of the customer. Paula confirms this observation.
Paula: It totally depends on whether the project manager is just a technology guru or whether he is, for instance, a business process expert as well as a great technologist. That combination of skills is hard to find. Some of the project managers are very deep into the business. They can tell you not only the key differentiators of what they’re changing in the application to improve the business, but also what the application does and how it fits into the business process. Other project managers just understand basic requirements. It could be an application that makes doughnuts versus compiling insurance reports. Their attitude is, “Give me the requirements and let’s code and deliver.” What we’re trying to evolve to is a state where a project manager is not only a great technologist but also has a feel for the business and understands what we’re trying to achieve as a business.
Matt: That’s right. Ideally, a project manager needs to understand why a customer should buy the technology solution we’re offering. In other words, what is the value proposition of this project?
Paula: Often people don’t understand the business process, and then they have a hard time answering these questions—expressing the significant differentiators. Engineers try to invent the perfect solution rather than a solution that will work based on the business strategy we have or the business reality we’re faced with. So rather than the perfect set of requirements down to the nth decimal point, I want a set of requirements that meets my needs within my business reality. Don’t give me a perfect solution, but give me a solution I can afford. We have a huge chasm between technical purists and the business realities we face.
The bottom line is that a project manager should be able to explain the significant differentiators in a compelling way. In many cases, the time span of an elevator ride (say, 30 seconds) should be enough time to get these differentiators across to someone. Many executives—just like venture capitalists—judge the quality of a project on the basis of the quality of its “elevator pitch.”
Tip
Quantify the market and competitive position for the significant characteristics of your technology solution.
You should document the advantages and disadvantages of each significant differentiator—those requirements that identify a solution as adding high value for the acquirer. Emphasize the distinctive features by highlighting the differences between what competitors currently have in use or on the market and what will be delivered by the project team. In addition, you should be aware of any patents, trade secrets, or other proprietary features, as well as any opportunities for the logical extension of the solution in use or the development of related IT products or services.
The project team can then quantify the significant differentiators as a way of quantifying the value of the opportunity to solve a customer problem. This allows acquirers to answer the question, How good is the idea in satisfying a customer need compared with how that need is satisfied today? Each differentiator has a quantitatively defined goal, and that allows the project team to quantitatively track progress toward achieving the goals over time. Additionally, the values of the same differentiators are established for any known competitive process or product and the best that is theoretically or practically achievable. The latter value is also a measure of the difficulty of the project objective.
Functional requirements traditionally dominate the quest for significant differentiators, but you cannot ignore nonfunctional requirements, or quality attributes, which are concerned with things like usability, reliability, safety, security, and performance. These may be significant differentiators for the customer.
Nonfunctional requirements stem from organizational policies, budget constraints, standardized processes, and external factors such as safety and security regulations. They define the behavioral characteristics or physical attributes of the technology solution—for example, “The software must respond to the user’s request within five seconds of a card being inserted in the ATM.” Nonfunctional requirements such as portability also relate to, for instance, the source code of software.
Frequently, nonfunctional requirements are mutually conflicting, at least initially. Required response time may be contradicted by, for instance, security and safety requirements. The process you use to arrive at a trade-off of these conflicts depends on the level of importance attached to the requirements and the consequences of the changes on other requirements and your goals.
Tip
Specify how the technology solution fits in your environment, from legal and performance requirements to security requirements.
You often see an overemphasis on functional requirements when the supplier has a dominant role in engineering solutions. When suppliers drive the process, they specify requirements from their point of view. Typically, suppliers formalize the functions of the technology solution to translate them directly into code and hardware. Requirements then address aspects of functionality, interface, and structure, insofar as they are important to the supplier but not necessarily to the customer. In other words, requirements discovery for the supplier revolves around the premise that the supplier has already selected the “right” solution and its functions simply need to be mapped to the customer’s and acquisition organization’s needs.
However, acquisition organizations must choose technology solutions with nonfunctional requirements in mind. Nonfunctional requirements address things such as country-specific regulations, skill level of the end users, and ways the product will be used. In many instances, nonfunctional requirements determine functional requirements and can be the deciding criteria for a technology solution. As the project team develops the specification, nonfunctional requirements are also likely to become functional ones for some part of the technology solution. For example, a reliability requirement can be translated into a function for error reporting.
Tip
Identify common (standard) requirements for your technology solutions, and make them available to all projects.
Often, many functional and nonfunctional requirements of one technology solution turn out to be the same for your other technology solutions. This in turn means that any new technology solution must account for those common or standard requirements. When standard requirements are documented and shared across projects, they allow a project team to stay focused on the significant differentiators, in part because they don’t allow the team to succumb to the “clean slate” myth.
When you’re engineering a technology solution, the clean slate myth postulates that project teams do not need to consider existing technology solutions and business processes that are in use. By throwing away these “troublesome” assets and building new technology solutions from scratch, organizations expect to find less expensive and more effective solutions. In practice, however, this situation rarely occurs, because very few technology solutions are built from scratch. Instead, many projects extend operational solutions. Thus, the project team must understand any deployed technology solutions, which usually integrate components from multiple suppliers.
Matt: How can we get to a state where our projects consistently acquire technology solutions that fully address the significant differentiators and satisfy all other requirements necessary to operate the technology solution in the intended environment?
Paula: We need to write requirements up front and make them available to the project team before the project starts. This gives us standard requirements that every project can use.
Acquirers and suppliers hear this straightforward answer time and again. Can it be that the solution to this problem has been right here all these years?
Paula: If you don’t start with standard requirements, every project manager looks at the customer requirements and delivers precisely those requirements. Unfortunately, often this solution won’t be extensible or won’t operate well with other solutions in our business processes.
Standard requirements are a key ingredient for advancing the project’s focus on what matters: the significant differentiators required to deliver the needed capabilities to the customer. In addition to the supplier agreement containing the core terms and conditions, service level agreements, and pricing, this allows you to standardize requirements for all acquisition projects (see Figure 3-2). Making clearly defined, concise requirements available to projects up front reduces project start-up time and improves your consistency in implementing common requirements across the organization.
What goes into standard requirements?
Matt: In virtually any organization, you have different layers of management decisions with different reach—some global, some local—as well as policies. We want our projects to remember these decisions and policies when they specify a solution.
Steve: Why not just reference decisions and policies in the contracts?
Matt: We went down that path and found that it results in missed requirements. Projects would focus on the more prominent functional requirements rather than going through the published decisions and policies to translate them into requirements. Since we want projects to focus on the significant differentiators, why not translate the decisions and policies into standard requirements and associated test cases one time and then reuse them many times on every project in the corporation? The idea was to start simple with standard requirements—for instance, basic security, operational, and data management requirements. And we gradually added the more sophisticated stuff, let’s say testing and architecture requirements. The standard requirements are an open-book test for the suppliers—no surprises for them. The suppliers will get used to the standard requirements over time, and they will become a standard way of doing business.
Predefining those requirements that matter across all projects or across the organization, making them visible to the acquisition organization and to the supplier, is a win-win situation for everyone involved.
Steve: This is a great idea. It avoids the situation where the project blindly refers to a set of standards or includes a laundry list of standards in a contract. These projects eventually find out that half the standards have no value. They’re outdated, or they don’t work with the given technology. Projects get in trouble that way. We want to be very cautious about people not listing reams and reams of standards just because they can. We want people to think about standards and explicitly say what part of the standard applies and whether the standard needs to be tailored for the application. We try to get people to think about that.
You need to carefully weigh your options before elevating a requirement to a standard requirement. Matt recalls an attempt to standardize the functionality of supporting different languages.
Matt: I remember a proposal that contained all the different systems and what languages they would use. For the Swiss group, we went through the proposal and checkmarked English, French, and German wherever appropriate. Then I called the originator of the request and said, “Look, you got English, French, and German in all the right places.” I’m sure the originator—a global IT architecture director—was thinking, ”Great, we did something good.” Then through a business partner I sent the originator a follow-up message: “Remember that Swiss French and Canadian French are different.” Then we waited a day or two and sent another message: “Don’t forget that we need to use English, French, and German together in some instances rather than assuming that those are exclusive choices.”
Well, c’est la vie (“such is life”). Acquirers must carefully choose between establishing a standard requirement that, on one hand, specifies that systems need to support multiple languages concurrently and, on the other hand, requires systems to support one language. In Matt’s example, such a requirement would force customers to add a translator function to the standard solution to support their business units in French, German, and English.
Steve: We carefully design standard requirements so that they don’t overconstrain projects. For each standard requirement, you have to decide to what degree you specify it, based on the risk; otherwise, we run the risk of turning a $25,000 project into a $1,000,000 project.
The CMMI-ACQ provides specific recommendations for deriving more detailed and precise sets of requirements, called contractual requirements, from customer requirements (see Table 3-2). Contractual requirements are included in the solicitation package for potential suppliers and eventually in the supplier agreement.
Table 3-2. Acquisition Requirements Development Goal 2: Practices and Tips
CMMI-ACQ Process Area: Acquisition Requirements Development | ||
2. Goal: Customer requirements are refined and elaborated to develop contractual requirements. | ||
Practices | Tips | |
2.1 | Establish and maintain contractual requirements, which are based on the stakeholder requirements. |
|
2.2 | Allocate the requirements for each supplier deliverable. |
|
Contractual requirements arise from constraints, from consideration of issues implied but not explicitly stated in the customer requirements baseline, and from factors introduced by the design constraints and the supplier’s capabilities (Table 3-2, practice 2.1). In other words, contractual requirements express customer requirements in technical terms that can be used to make design decisions. In addition to technical requirements (e.g., requirements specifying interfaces with other products or applications, functional requirements and their validation, and verification requirements such as product acceptance criteria), contractual requirements cover nontechnical stakeholder needs, expectations, and constraints.
Examples of considerations for nontechnical requirements include the following:
Frequency and format of supplier reviews
Standard measures and service levels for the technology solution
Supplier reports and other communications
Availability of support to meet levels of business processes or product performance
Warranty of products provided by the supplier
Logistics support that sustains both short- and long-term readiness
Minimum total life-cycle cost to own and operate (i.e., minimum total ownership cost)
Maintenance concepts that optimize readiness while drawing on both acquirer and supplier sources
Data management and configuration management that facilitate cost-effective product support throughout the product’s use by the acquirer
The level of detail of contractual requirements is based on the acquisition strategy and project characteristics.
The contractual requirements are allocated to supplier deliverables (Table 3-2, practice 2.2). When multiple suppliers are developing the technology solution, different products or product components may be allocated to different suppliers. In addition, you may allocate technical requirements to third-party products that must be used by the supplier (e.g., commercial off-the-shelf products).
As an acquirer of technology solutions, you must make sure that all your solutions fit together, but you must also remember that you do not build these solutions yourself. Because many acquirers grew up as part of an insourced organization or have worked for a technology supplier, their first reaction, as acquirers of technology solutions, is to spell out all the gory technical detail and overly constrain the solution. Steve answers the question, “What’s wrong with this picture?”
Steve: Well, you won’t leverage the technical capabilities of your suppliers, for one thing. What’s worse, you lose your focus on laying down realistic design constraints so that everything fits in your landscape of stakeholders, business processes, and technology solutions. I had to work hard on myself and with my team to transition to the mind-set of my new role as an architect for an acquirer. It made it easier to know that we weren’t alone out there.
Steve laughs as he recalls one incident.
Steve: One of my team members brought in a reference from a Roman architect, Marcus Vitruvius, who figured this out in the context of building design back in the day. We’re talking about 80–70 B.C. This guy claimed that well-designed buildings exhibited three virtues: firmness, commodity, and delight. If you’re an architect, you start with commodity and delight, what we’d call the look-and-feel end of the problem. The prime contractor and suppliers, on the other hand, they’re more concerned with the firmness: economy, safety, constructability. If you look at modern building practice, this is pretty much the division of labor among the architect, the builder (or prime contractor), and the individual laborers or suppliers.
As the design of technology solutions continues to mature, perhaps we will see a similar evolution in an environment that includes acquirers of technology solutions that have architects on staff. Perhaps someday there will be firms specializing in technology architecture that vie for work by demonstrating originality, elegance, and affordability in their architectures but are not responsible for implementing or configuring the architectures. To support this journey, the next two sections cover the practices you apply to develop design constraints and to verify the designs of the supplier.
Design constraints are a type of technical requirement. They express the qualities and performance points that are critical to the success of the product or service in the operational environment. Design constraints can include standards and design rules governing development and configuration of technology solutions, such as cost per component, the required database, the required type of application servers, and criteria for interfaces. The latter are often associated with safety, security, durability, and mission-critical characteristics.
Tip
Define the core of the solution first, and then gradually add connections to other solutions and the environment.
Why is it difficult to find the right balance between leveraging the supplier’s ability to deliver cutting-edge technology solutions and your desire for seamless, flawless technology integration and use? Steve contemplates this challenge.
Steve: As an acquirer of technology solutions, you’re given a problem in the real world and it’s typically really messy. When you develop design constraints you initially spend your time cutting yourself off from connections—trying to simplify things, trying to make sense out of often conflicting requirements. You eventually say, “Well, let’s assume it’s a sphere,” and you start adding connections, and first-, second-, third-, and fourth-order effects, to come up with a viable set of design constraints.
I’m not talking about a trivial system. You’re creating a technology solution that has significant economic value, that involves some degree of integration with other systems, interplay between software and hardware. It’s only when you start adding these other approximations that you start seeing what goes on—how tough it will be to either configure or develop a new solution or application thereof. You start to realize how big it is, and you either get scared and you don’t do anything—that happens to a large number of projects—or you’re naïve and proceed.
Matt: Well, you can’t get scared into doing nothing. You won’t get paid.
Everyone laughs.
Steve: In our team, we remind ourselves to think about Thomas Edison, who created the light bulb because he didn’t realize he couldn’t. Common wisdom thought it was impossible. So Edison went ahead and did it anyway.
You codify the design intent in the form of design constraints. Design constraints drive the design processes of the supplier and are your means for judging the supplier’s feedback on the current state of the design. You must stay focused to determine the design constraints that matter, use those constraints to drive the design, and then analyze the design to determine whether the constraints were met (or could be met).
Paula: A lot of effort goes into arriving at design constraints that are unambiguous and easy to understand. Without this clarity it’s excruciating to verify designs.
The design verification process is usually repeated several times until a workable design is achieved. The decisions that result in the design constraints must be made manifest and visible throughout the life cycle of the system.
Paula: There are always trade-offs. I mean you have to keep your options open. Most architects or designers would love to develop these technically elegant, complicated systems that are intriguing and professionally groundbreaking—but very expensive. I have to remind my project teams, including the suppliers, that we’re here to add value to the business, we’re here to enable our businesses to grow and move forward and deliver within the agreed-upon schedule. So that has to be the top priority for us. And when we look at it, my teams are also responsible for keeping our cost down, meeting the cost design constraint so to speak. So one of the things we have institutionalized is taking a hard look at cost.
Steve: How do you do that?
Paula: We ask questions like, “What will this design constraint do to my operational cost going forward?” Most of the time, this question stomps the project team, because they’re focused on the development cost and don’t consider the maintenance cost, which often is higher. We roll up our sleeves and work with the team to get a design that won’t add any operational cost and meets the return on investment long-term. In doing this, we take a hard line against suboptimization. We obliterate any fine-tuning of an individual technology solution, if it doesn’t optimize the set of technology solutions that support a particular business process or the organization overall.
Tip
Judge a solution’s elegance by its value to the business, and not by how technically sophisticated or professionally intriguing it is.
For example, you must carefully analyze the implications for maintenance when you use off-the-shelf or nondevelopmental items (for example, COTS products, government off-the-shelf products, and open source software). Consider the compatibility of the proposed technology solution with future releases of COTS products, and assess known defects in reused or off-the-shelf products and the status of their resolution.
Tip
Take into account the total cost impact of a design constraint for a technology solution before levying it on the supplier.
Tip
Always look for ways to optimize the business process before constraining the technology solution.
Your principal choice is often a trade-off between efficiency and flexibility. The goal is to avoid premature commitment to a particular technology solution—that is, to not make a binding decision before all the required information is known. Often, the decision is made in favor of an efficiency that is not worth the cost. Steve emphasizes this point.
Steve: Nine out of ten times, the customer will say we need to make our systems more flexible, because we need to be making changes to either business rules or processes or something on a weekly basis, bimonthly basis, and so on. So it’s critical to figure out what things in the system don’t change very often, what things should be allowed to change often, and how we establish design constraints that provide parameters for the supplier to meet these objectives.
Establishing practical design constraints takes work.
Steve: Some of the first systems we built had pretty sloppy constraints and were too aggressive. The key is to make sure the constraints you give the suppliers are real. You can’t just throw a bunch of design constraints over the wall to suppliers down the street, let alone if your supplier is in China or India and you’re on the other side of the globe. With outsourcing, you’re entering into a close partnership that will require ongoing interaction, supervision, and quality control.
It’s important to have clear criteria for addressing design issues for the life of the product in the operational environment. Such criteria tend to focus on provisions for more easily inserting new technologies or the ability to better exploit commercial products. Examples include criteria related to open design or open architecture concepts for the alternatives being evaluated. To make this happen requires close partnership between acquirer and supplier.
Matt: The notion of handoff has become obsolete. We’re engaged with suppliers from the beginning, and we work very closely with them throughout the delivery process.
However, he adds a word of caution.
Matt: It’s hard work to get from a handoff-based environment to a thought-process-based environment. So it’s really about taking ownership of the technology solution from beginning to end and making sure suppliers are bringing in the right skills to make it all work. It’s like taking accountability for the whole solution even though they may not own some things. It requires a supplier to take the responsibility of making sure all the right things are done to have the appropriate level of engagement and oversight around a third party doing work for the same project.
Tip
Identify design constraints that apply to all technology solutions that enable a business process.
Designing a technology solution is an iterative process.
Steve: Everybody involved in designing technology solutions has to recognize that there’s constant evolution. After that prototype or next system is out there, customers start realizing all the additional benefits and then start adding more things on your plate. That’s a good thing. The problem with many projects at this stage is that they’re only looking at solving their immediate problem and don’t account for the fact that their solutions will be part of a whole landscape of technology solutions. They’re not looking at what are or could be common business processes and their solutions holistically. You need to create a solid to-be picture and thoroughly understand that your project is one puzzle piece in a system of systems.
Matt: The question is, of course, how do you get that comprehensive view of a process and what should be common so that you can try to build one solution once? If we do that, we have more money to spend on meeting more business needs. And then the customer would look at something and say, “Well, it took you nine months to put this solution in place, and you’re telling me I can’t get this change in for another six months?” You’ll try to explain—but it’s based on priority. You’ll have no way to accelerate your solutions engineering, because you don’t have the ability to apply solutions or at least pieces of your solutions to different business problems. It’s very important that you extract as many of the critical design constraints early on, preferably as implemented in the first increment or version of your solution.
To achieve high levels of reuse and interoperability in technology solutions, you typically establish common design constraints for products or product families that can be deployed in one or more domains. Common design constraints (also called reference architectures or product line architectures) provide a proven bundling of products, applications, and configurations. They give you a base for creating technology solutions that use design constraints reliably and cost-effectively. For example, some acquirers encapsulate functionality in the form of services that can be leveraged by multiple, if not all, technology solutions. Common design constraints are then organized in the form of service-oriented architectures.
To make all this happen, even large, global suppliers often use supplemental third-party resources, and suppliers may subcontract with one another, depending on areas of expertise and available business opportunities.
Kristin Wells: There are many suppliers in the world of acquired technology solutions. We may compete one day and partner the next.
Engagement models are varied and complex. Some companies require only a set of high-level standards and outsource everything else; others outsource a specific portion of the design, such as a high-level architecture or physical design. Up-front planning and realistic constraints help you avoid unnecessary iterations when you build the system. To minimize rework, some suppliers have a well-defined flow to verify the acquirer’s technology standards, standard requirements, and constraint quality.
Matt: You’re right, Kristin—there are many suppliers out there. That’s why the governance of the technical design is so important for us as an acquirer of technology solutions. You have to stay within common design constraints, such as standards first of all, and those standards have to be current and they have to be rigorously enforced.
Steve: I couldn’t agree more. All this makes a difference. It’s easy to say this doesn’t matter and let our supplier run off and do what they want and we just accept what they do. The problem is when you do that, you don’t get any synergy from system to system, from one project to the next. You die the death of a thousand cuts. We finish one system and we’re all happy about it. Then we start another project, only to realize that we have to go back to the drawing board and don’t have any money.
We can avoid this scenario. We just have to define early on what the common constraints are for the project and the supplier. And then we have to put our foot down and hold firm in our discussions with the suppliers.
Matt: How does that usually go?
Steve: Well, you always have one project or supplier that says, “For what I’m doing, software X is better.” Then another project or supplier says, “I can increase performance if I use software Y.” You always have this tension back and forth where there is no piece of software that’s better for everybody, there is no data model that’s better for everybody. But there is a single piece of software or a single data model that falls into a strategic category that is better for the acquisition organization as a whole.
Apparently this topic has hit a nerve. Steve continues passionately.
Steve: Let me just tell you about this one project we’re working on. It’s a broad project across all groups. The supplier has a real difficult time understanding why we wanted to use a certain server from one supplier as a common design constraint for all our application servers, why we wanted to use a particular Web server from another supplier, and why we wanted to use one type of database. There were reasons why those common design constraints where picked across the organization. Performance, reliability, availability—the whole nine yards. We took all this into account. We have one set of hardware—different sizing, but one hardware platform that we actually run our software on. Every Web application is targeting that common design constraint.
Matt: I’m with you so far.
Steve: So the supplier came back and said, “We support the application server and the Web server, but not the mix-and-match approach your design constraints require. As a matter of fact, our product most likely won’t even work in this configuration.” We actually had to tell the project team of the supplier, “Look, we wrote in the contract you signed that you have to fully implement our design constraints and support our target environment.” The problem was that nobody on the supplier team had bothered to analyze the common design constraints.
The best way to avoid such a situation is to include suppliers in the creation of common design constraints as appropriate, and thoroughly educate them on the intent of the constraints.
Matt: Now my architecture group invites the supplier’s chief architects to be part of the technical discussion when we debate the best way to build common design constraints. They are essentially considered part of my staff. So we’re all in it together. It doesn’t make sense for them to have a myopic view of what they’re delivering.
However, simply compiling a list of technology standards as your common design constraints isn’t enough to effectively guide the design of technology solutions.
Matt: We used to say to a supplier, “Here are the technology standards we use”—in most cases, a list of standard products. And a supplier will come in and, for instance, say, “I’m going to use this standard from a work flow standpoint, and that one from an integration standpoint. And these other two standards over here, we’re going to plug in together.” We would all walk away happy, expecting a perfect solution to arrive at our doorstep. Then when the suppliers are configuring or developing the solution, they’re convinced that’s all the effort they really need to put into meeting our design constraints. As long as the technology standards are met one at a time they would say, “Oh, that’s an acquirer-approved implementation.”
But when you look at it from a total solutions viewpoint, you have to go back to the requirements and figure out, “Okay, with all these standards fitted together in a particular way, are we looking at a proposed solution that is beneficial to us?” So you have to dive into what is happening at different layers of the proposed solution. What are the performance expectations across the solution? What is its total cost of ownership? It isn’t enough to simply stay within a list of standard products. You have to come up with an integrated set of common design constraints.
Providing a list of technology standards is a good start in helping suppliers understand the technical constraints that are important to you. However, it leaves the question of how to mix and match your technology standards to arrive at an appropriate technology solution.
Steve: A list of technology standards is only a first step, because the standards can be mixed and matched many different ways. So as an integrated set of design constraints, we hand a reference or product line architecture to the supplier that defines a set of technology standards—for instance, standardized IT applications, infrastructure elements, and implementation and support methods—for a particular business process. This creates a mapping from the business process to the technology architecture, and that’s critical for reducing technological uncertainties by standardizing on common design constraints. These get the project and supplier on track to understanding what the solution should look like.
Getting common design constraints right is a learning process in and of itself.
Matt: On one hand, you have to be incredibly firm in establishing and enforcing what will be identical across technology solutions in the intended environment. You have to communicate both internally and externally: “Now that’s fixed. If you don’t agree with that, then that’s your prerogative. This is how we will run the business.” On the other hand, you have to make it very clear what other parts are up for discussion. You have to say, “Within this reference architecture, in this area down here, you have an option.” You can say, for instance, “If performance is required, then you’re allowed to use these types of interoperable capabilities versus Web services.” That’s a discussion that is captured in the common design constraints.
Steve: Part of the learning in getting the design constraints right is to neither overspecify nor underspecify. For example, let’s say a supplier embeds a certain database, which isn’t our preferred database, in their standard solution. This database is completely encapsulated in the solution. In this case, we never have to interface with this database directly. Our common design constraint would allow for that. We would let the supplier use a database of their choosing because we follow a “black box” approach for system components we don’t own and that we don’t directly interface with.
But let’s say we’re hiring a supplier to develop a system that we will own, and we intend to store the system’s data in a database shared by other technology solutions in the intended environment. In this case, we want to enforce a more stringent set of design constraints. For instance, the supplier will have to satisfy the common design constraint for databases.
Tip
Build alternative approaches or variations of design constraints into the reference architecture.
Tip
Carefully weigh the trade-offs of using packaged functionality or services with the impact of their failure on the business process.
Commercial off-the-shelf products are both a blessing and a curse for acquirers. Using COTS components in a true plug-and-play fashion can be exhilarating. However, COTS products make the world very complicated because COTS suppliers are not under the same time constraints as acquirers are—for instance, to upgrade a solution to keep pace with the changing business environment. And not all COTS suppliers can accommodate your desired time frame for upgrades and modifications. You must therefore look at common design constraints for COTS products that isolate those risks but still allow you to use COTS products effectively.
That’s why many organizations are attempting to isolate their technical environment from this downside of COTS products. For instance, some organizations have outsourced the care and feeding of these technology solutions to suppliers, paying for it as a service from a technology company or service provider. Unfortunately, this isn’t always possible. You might need certain functionality to gain a competitive advantage, and there’s only one supplier with 15 employees who can provide this solution. How many times have we heard this story? This scenario keeps acquirers up at night. Acquiring organizations mitigate this risk by protecting and minimizing the risk to the rest of the infrastructure. This practice becomes increasingly important every day as environments become more integrated than ever before.
Steve: People say, “You know, it’s great that we have moved into the distributed world—ubiquitous computing and all that.” I’m afraid the talent we have in place to manage those types of environments is not sufficient. What’s even harder is that given the unique design constraints that we settle on based on our business model, it is not something your employees can learn in college and come out after four years and know all the “gotchas” relevant to your environment. We have seriously accelerated our technical training to combat this trend.
Establishing common design constraints is not just a technology decision.
Matt: The leadership of an organization must decide together what systems must be common. For instance, if you’re a car company you might say, “We don’t care if you are in Canada or South Africa; you will order cars this way.” Now, from a Canadian perspective, I have to go to the standard vehicle order management system—that’s it. However, I have to handle French if that’s not covered in the standard system, so I have to funnel data through a translator—whatever I have to do locally to stay within that standard. Getting to this state is a bumpy journey, because when you first create a scorecard of your existing technology solutions against your common design constraints, most likely you’ll be faced with a plethora of red, if red is your color of choice for discrepancies.
Steve: It gets to where you can’t read the specs for all the red everywhere.
Matt: Sometimes it’s frustrating trying to figure out how you can close the gap and how you can get there fast enough. What a change in attitude and delivery speed if you stick with it. Instead of grappling with, “I only want to pay for the solution that works with my project,” you end up with an organization and a set of suppliers that sees the power of flexibility and drives to implement with more shared cost across processes and applications. The suppliers want to be successful, and they know they have to do certain things in order to integrate into this bigger environment they’re working on. You can’t just have your teams and the different suppliers doing things their way and at the end of the day be able to integrate into a larger organization.
The CMMI-ACQ provides specific recommendations on how to develop design constraints for the supplier’s technical solution that potentially satisfy an appropriate set of allocated requirements (see Table 3-3).
Table 3-3. Acquisition Technical Solution Goal 1: Practices and Tips
CMMI-ACQ Process Area: Acquisition Technical Solution | ||
1. Goal: Constraints for the technical solution are developed and satisfied by the supplier’s design. | ||
Practices | Tips | |
1.1 | Determine the design constraints for a technical solution. |
|
1.2 | Verify the design to ensure that the resulting product will perform as intended in the acquirer’s environment. |
|
Design constraints express the qualities and performance points that are critical to the success of the product in your operational environment (Table 3-3, practice 1.1). They may include standards and design rules governing the development of products and their interfaces. The criteria for interfaces are often associated with safety, security, durability, and mission-critical characteristics.
Tasks for identifying common design criteria may include the following:
Establishing the structural relations of products and rules regarding interfaces between products
Identifying external interfaces of the technology solution
Identifying common products and common interfaces for all technology solutions
Developing reference architectures or frameworks
Establishing design rules and authority for making decisions
Defining criteria for the physical deployment of software to hardware
Identifying major reuse approaches and sources, including legacy and COTS products
The CMMI-ACQ includes a collection of practices under the label “Decision Analysis and Resolution” to support acquirers that are using a formal evaluation process to analyze identified alternatives against established criteria. These practices cover how to establish guidelines to determine which issues should be formally evaluated and then apply a structured approach to determine a recommended solution.
A repeatable criteria-based decision-making process is especially important, both when you’re making the critical decisions that define and guide the acquisition process and later when you’re making critical decisions with the selected supplier. Establishing a formal process for decision-making gives you documentation of the decision rationale. Such documentation lets you revisit the criteria for decisions when you’re considering changes or technology insertion decisions that affect requirements or other critical project parameters. A formal process also supports the communication of decisions between you and the supplier.
You perform design verification (or technical review or architectural evaluation) throughout the project life cycle to gain confidence that the requirements are capable of guiding a development that results in a satisfactory technical solution (Table 3-3, practice 1.2). This practice should be integrated with risk management. Mature organizations typically perform design verification in a sophisticated way by using multiple techniques and broadening the verification to include other stakeholder needs and expectations.
Technology becomes more ubiquitous every day and is rapidly expanding into every facet of our lives. This means the early days of “green field” solutions, when you could begin totally anew, are virtually gone. It is somewhat analogous to how the frontier of the American West began to fill up around 1870. In the early days of the Wild West, a great deal of land was open to open-range livestock and for homesteading. There was little or no local law enforcement, and the military had a concentrated presence only at specific locations. It was common to witness shootings, where gunmen died “with their boots on.”
Matt picks up on this analogy.
Matt: In the technology space you still need Wyatt Earp, and there are still a lot of renegades out there who can get you in trouble.
Staying with the Western theme for a moment, we can’t resist replaying a scene from the movie Tombstone. As Wyatt Earp runs a card table in a crowded saloon, with an inebriated Doc Holliday standing by, a group of cowboys enters noisily, led by Curly Bill and Johnny Ringo. Introductions are made (so to speak), and Doc Holliday makes a comment about Ringo. Ringo pats his gun before addressing Holliday with the words, “Eventus stultorum magister” (“Fools must be taught by experience”). Doc Holliday gives Ringo a smile and responds, “In pace requiescat” (“May he rest in peace”). Tombstone Marshal Fred White defuses the scene: “Come on now. We don’t want any trouble in here. Not in any language.” Matt can relate to this scenario.
Matt: I’ve seen projects deployed where somebody says, “Oh, this just happened,” and the project manager doesn’t realize that this is a problem, and he mentions it to some folks, and eventually it goes all the way back to the architect. And the architect gets this look of horror on his face and says, “I never thought of that.” Those are absolutely the worst moments. That’s a system doomed to failure if it gets deployed.
How can you avoid a situation where the project has to “die” so that you can learn a valuable lesson, and the sheriff has to mitigate between acquirer and supplier?
The goodness of fit for a technology solution denotes the fulfillment of its requirements and the conformity of the solution with its specification. The easiest way to establish the goodness of fit is to know all the parameters of a solution. In the real world, this scenario is the least likely to occur.
Steve: What we mostly like are projects that don’t make any changes—projects that come up and say, “Well, we’re implementing this system and it has already been done. It works. It’s put together exactly the same.” But projects never work like that. There’s always some “secret sauce” that somebody adds.
Tip
Mandate and enforce standards for representing the technical design constraints and for the supplier’s design deliverables.
This is why technical reviews are critical. They formally establish the consistency of the proposed technology solution or between the technical design and its contractual requirements and design constraints. George Taylor, who represents our supplier, speaks to this.
George: Sophisticated acquirers mandate “drawing” standards that we have to deliver to for the technical design. There are no good drawing standards on the market for, let’s say, distributed systems, so the acquirer requires us to show them the technical design in their specific format, which typically is pretty descriptive.
Steve: We need to understand what our suppliers are doing. When we started to do this we found that our suppliers didn’t understand the implementations of their project decisions in the intended environment. For instance, they designed a single-threaded application for use in a distributed infrastructure. Suppliers didn’t understand why the code they wrote didn’t work in that environment. So when they had to actually draw it out as a technical design diagram following the standard notation, we would get into discussions with them. For instance, they would say, “I didn’t know I had to have a load-balancing application for this distributed system.” Clearly one of the benefits was that the supplier got educated through this process.
Technical reviews hold the supplier accountable for meeting the technical design constraints throughout the project. To be effective, such reviews involve, for instance, operations and maintenance personnel in addition to the integrated project team.
Tip
Contractually ensure that your prime supplier and its suppliers certify the technical design and the technology solution.
Steve: To get maximum benefit, all reviews need to be conducted the same way. You have to have clear entry criteria. We insist that the suppliers have done their homework before they show up for a review. The supplier’s technical design and the resulting technology solution must be peer-reviewed by the supplier and the involved subcontractors and product suppliers. We contractually mandate that the prime supplier goes out to the product vendors and says, “Hey, give me your best engineers to come in and ratify our technical design.” This also helps the supplier produce meaningful trade-off analyses to flush out performance versus flexibility versus availability versus all the other “-ilities.” Then they rank them and come up with scenarios and really drill into it and figure out, from a design and technology perspective, how all this fits together. If you don’t get the best people from your supplier engaged up front, you’ll pay for it when you fix your systems over and over again.
Matt: How do these reviews work, Steve?
Steve: We conduct early design reviews with lots of very intelligent people in the room, on the phone, on the other side of the globe smiling from the video screen. We noticed a tremendous spike in successful projects after we mandated that operations people be part of technical reviews. This stopped the historical disconnect between applications teams and operations groups. Anyway, all these folks are trying to guide the project and the suppliers to be successful. Our project teams and the suppliers that come through once will always remember their first technical review with us.
Steve laughs.
Steve: Once in a while, you get the naïve project and they’re bloodied every step of the way. These projects would get a rude shock when they go through the first review, because they get hit with the product standards and the other common design constraints. The project didn’t bother with that. They would say, “We picked the best solution.” This might be true if the system was running all by itself. You can count on the fact that they will have the right answers when they come through again.
George: I remember some of those. You have to make sure you and your team can clearly articulate what they have on paper. So you can pull in all the pretty diagrams from other projects or some Web site or whatever, but if you can’t communicate what the solution is and how it meets the need, you’re toast. I’d say the architecture really needs to be communicated on how it’s going to meet the requirements and how it fits in. If you can’t do that, the architecture’s not worth anything.
Tip
Involve your operations and maintenance personnel in the technical reviews throughout the project.
Staying on top of the evolving technical design is critical for any acquirer of technology solutions. Throughout the project you probe for how “real” the proposed design is; for instance, does it live up to your requirements for performance, scalability, and availability?
George: The acquirer sits down with the project team and says, “You’re proposing this technical design. Now show me how it will meet availability, how it’s going to meet scalability, performance, and flexibility.” They ask us to walk through some scenarios. Let’s say a transaction comes back 90 percent of the time within 5 seconds. We would show how that transaction flows through the different layers of design and put some approximate timings on what we think it is, based on experience and proof of concepts and other things like that. So, it’s really trying to tie back the nonfunctional requirements and showing evidence of meeting them.
Steve tends to apply the test of “reasonableness” with many suppliers.
Steve: I meet with the supplier and say, “I want to see the following performance and scalability graph,” and I draw the graph and tell them what the axis is, and explain what the general performance and scalability curve should look like. The expected performance of a technology solution increases first. The curve in the chart goes up. And then depending on the workload—such as number of users, number of transactions—the curve eventually turns over and then the performance comes, in most cases, to a grinding halt.
George: As a supplier, I have to say we hate it when that happens.
Steve: Yes, but it’s the nature of the beast. Suppliers tend to come in with performance and scalability graphs that show how the performance of the proposed solution increases. The charts basically tend to go up. And you say, “No, no, no. I want to see where the chart turns over and where it dies.” And the supplier says, “Oh, don’t worry about it, we’ll never get to that point.” So you insist: “Okay, but show me where that point is.” That’s a typical conversation that goes on in the technical review meetings with the supplier. We want to know what the practical and theoretical limits of the technology solution are.
Matt: Steve, can you give us an example?
Steve smiles.
Steve: Okay, let’s say a supplier—not George, somebody else—wants to demonstrate to you that a piece of software will work up to the currently anticipated 5000 users. So you have to ask, “Okay, are there any components in the system that will not work with up to 5000 users?” After a little bit of back and forth you might get the following response: “Well, there is this component that tends to top out at 200 users when certain conditions are true. Anyway, all you have to do is buy 25 servers and you’ll be fine.” Okay, that’s an answer I’ve heard—but is that a reasonable thing to do? You have to carefully look at the total cost of a solution. Otherwise you end up with a minimum initial investment and you lose your shirt in the long term. In the example I just gave, you would be stuck with an unreasonable number of servers that would tank even the most optimistic return on investment.
To get everybody in tune with the evolving technical design, acquirers typically conduct several design reviews. Projects are required to come in with key design goals and explain how the technical design maps back to requirements, what the operational costs associated with the alternatives are, and what the suggested trade-offs are to successfully implement the solution.
Steve: We have enough people review something that we rarely miss anything. When somebody does miss something, it’s a white-knuckle moment—it’s a horrible situation. It can get worse when senior management leans on you to turn this situation into a risk as opposed to an issue. I don’t know if you’re familiar with that little game. Instead of saying, “This is bad and we can’t let it go through,” somebody says, “Well, couldn’t it possibly work?” Yeah, with the wind blowing behind you 100 mph and if everybody is working on it like the pit crew of a Formula 1 team and you set up some extra monitoring and yadda, yadda, yadda.
Matt: I’ve been in on some of those discussions.
Steve: So we eventually get to a “yes,” but now you’ve set the precedent. You’ve triggered an avalanche, and suddenly you’re looking at a long list of risks and your issue log is cleaned out. These are the projects that turn into a death march, because eventually somebody forgets to close the loop on one of those “risks” and the project never solves the problem. Those projects are the ones that go into production and the performance turns out to be horrible. We’ve learned the hard way that it’s much better to bite the bullet early, but it can be a big cultural change to admit failure and do it quickly.
The reviews are not only for the acquirer team but also require the active participation of the supplier’s project team.
Steve: All the different suppliers are involved in the technical reviews. We make sure that everybody is there and participates. When I ask for technical approval, any supplier that has a problem in their area speaks up. And they will, because they need to protect themselves. The supplier is responsible for making sure the product works in the intended environment. If there’s an issue, the supplier has to fix it. This is much cheaper to do during design than in production—everybody knows that. These joint reviews and rigorous supplier agreements establish clear accountability.
For some new suppliers, this is a learning curve. When something goes wrong in production, we have to bring them back and say, “You signed off during this technical review that this would work. Your supplier architect was there to sign off. He was there to review—remember, we take attendance. He was there. He listened. He signed off, and you need to stand behind that decision.”
Tip
Actively involve suppliers in technical reviews, and record their approval of the proposed solutions.
With all the technical reviews and individual accountability, it is important to work hard to foster teamwork and constantly emphasize the fact that all parties are in this together.
Steve: When you put together the technical design, especially for a complex system, then it gets very testy and interesting. In the heat of the battle, there is a tendency for suppliers to want to point fingers at each other if, for example, a solution doesn’t go right. One of the biggest challenges we face is to make sure that there is no finger-pointing. We have very little tolerance for a supplier to come into, let’s say, a corrective action meeting and say, “Well, it was really the other supplier’s fault.” We really want to go in there with a team and say, “This is what went wrong, and this is how we will correct it as a team.”
It helps to have a pool of technical experts—for instance, IT architects—who evaluate many projects throughout the year. Project managers can leverage this knowledge to expedite technical reviews and the design of the technology solution overall.
George: A lot of times people come to the architecture team not for approval, but long before that, just to bounce ideas off the team. There’s only so much process guidance and design constraints that a project team can read. If we get a three-foot thick list of requirements, constraints, how-to, and lessons learned, then people can’t read it all. Even if they had enough time to read it all, they couldn’t comprehend it all. So they come to us and ask questions: “This is what I’m thinking about doing, here is my idea, here is what the business requirements are. What would you do?” “Oh, we would do this, this, and this.” They run off and come back three weeks later with their actual plan. This saves months and months of delay for a project team trying to get up to speed independently.
The CMMI-ACQ provides specific recommendations on how to verify the implementation to ensure that it meets allocated requirements and that the product is ready to be brought into your environment for further integration and user acceptance testing (see Table 3-4).
Table 3-4. Acquisition Technical Solution Goal 2: Practices and Tips
CMMI-ACQ Process Area: Acquisition Technical Solution | ||
2. Goal: Analyze and verify the development and implementation of the technical solution by supplier. | ||
Practices | Tips | |
2.1 | Verify the technical solution implementation by the supplier to ensure that contractual requirements continue to be met. |
|
2.2 | Analyze the product interface descriptions to ensure that they are complete and in alignment with the intended environment. |
|
The design implemented by the supplier includes development of product components, integration of the components, unit and integration testing of the product, and development of end user documentation. You verify the supplier’s implementation to ensure that it meets allocated requirements and that the product is ready to be brought into your environment for further integration and user acceptance testing.
You examine a technology solution to determine whether it is ready for production and whether the supplier has adequately planned production (Table 3-4, practice 2.1). The verification process also examines risk; the process determines whether production or preparations incur unacceptable risks that might breach the objectives of schedule, performance, cost, or other established criteria. You evaluate the full, production-configured product to determine whether it correctly and completely implements all contractual requirements. You also determine whether traceability exists between the final contractual requirements and the final production-configured product.
For this verification to be successful, you must determine that the requirements are fully met in the final production configuration and that production capability forms a satisfactory basis for proceeding into pilots or full production.
Rarely is an acquired product a stand-alone technology solution. Therefore, you must carefully analyze the descriptions of the product interface to ensure that they are complete and aligned with the intended environment (Table 3-4, practice 2.2). Here are typical criteria:
To specify technology solutions, requirements and design constraints typically need to be discovered incrementally. This practice gives you additional opportunities to improve the conceived solution. Engineering a solution is therefore an evolutionary activity that investigates what the stakeholders are concerned with, what is important, and what they’re trying to achieve. In other words, engineering continues in recurrent cycles of exploring the perceived problem and proposing, validating, and verifying improved specifications.
Most acquirers deliver technology solutions in a dynamic environment. This requires flexible requirements and pragmatic design constraints that can be clarified and changed as the project progresses. In other words, you must account for the learning of stakeholders and the negotiation of requirements and design constraints throughout the project. On most projects this causes the classic problems of rapidly fluctuating requirements and disjointed design constraints. Early on, some projects lament the lack of detailed design constraints to adequately express technical requirements, whereas others freeze their requirements prematurely and then face the wrath of unhappy customers who keep changing requirements and mistake acceptance meetings for prototyping sessions. The following sections propose some remedies and review practices to better practice agility.
Stakeholder feedback, especially from customers and users, plays a decisive role from the beginning to the end of successful projects.
Paula: It’s not always easy to get somebody to raise their hand and say, “I will take responsibility and champion this initiative.” The organization will say, “I want you to provide this capability,” but trying to get an individual to raise their hand and say, “I’m willing to drive this to successful conclusion” is more of a challenge. One of our big development rules states that the acquisition organization will stop a project if the business resources are not committed to support it. We need to make sure that the business champion is committed, that he or she is willing to drive that project if the business really wants it, and that we have the appropriate stakeholders that are willing to go down that path with us. If they don’t, then stay with the current process until the business is ready to redesign it. Without that, the project team will just end up chasing its tail.
Tip
Validate the business champion’s and customer’s commitment to the project. If there is no commitment, stop.
It’s critical to have ongoing face-to-face discussions with a representative number of customers and stakeholders from the earliest conceptual phase through final delivery. This is the only reliable way to establish, continuously modify, and validate the idea’s value proposition. Large numbers of contacts are not necessary, but it is important to hear the broad perspective of views within the affected business processes. For many projects, the number of customers and stakeholders is large, and it is important to make enough individual contacts to get a representative view of the customer requirements.
Matt adds a word of caution.
Matt: A lot of ideas come from smart individuals who mean well and want their business unit to succeed. They go over to the acquisition organization, tap on their shoulders, and say, “I need X.” No one ever asks these well-meaning individuals, “How does this help sell more products or deploy better capability in the field?” In addition to being good technologists, we need to ask why. We need to apply our limited technical wherewithal in the right places.
As a successful acquisition organization, you must identify your customers and keep them engaged throughout the project. In addition to having a project team that is well versed in the business process and technology, successful teams seem to identify a “partner” or a business liaison who keeps his eyes and ears open to help ensure the success of the project. This liaison—your Yoda, as discussed earlier in this chapter—knows the business or mission intimately, understands current requirements, and can anticipate future needs.
It’s difficult to maintain effective communication channels throughout the project. In particular, lengthy requirements documents hinder your communication with customers and suppliers, because they do not provide the interaction necessary to resolve misunderstandings about requirements. Rather, forging a common understanding of the proposed solution requires frequent interaction among stakeholders. Because documentation alone doesn’t provide sufficient communication, reviews are often the most effective channels.
Suppliers and acquirers seem to agree that communicating the requirements by using prototypes helps prevent misunderstandings, but to be successful you must do more. For instance, you must insist that all the involved parties have access to the latest deliverables, and you need to find ways to bridge language barriers and cultural differences across extended teams. It’s also important to avoid passing information through too many hands before it reaches the recipient. This is especially important for acquirers that work with offshore suppliers. This situation is often compounded if the supplier isn’t involved in requirements development.
Paula feels she has a best remedy for this situation.
Paula: Let’s host a validation workshop to walk through the requirements and ensure clear understanding, identify issues, and fill any gaps. The alternative to spending this time up front is to have the new supplier design and deliver a system without having an opportunity to clarify any issues. This means you end up with another problem, rather than a solution that eliminates the problem you started out with!
We often have stakeholders with a variety of backgrounds and different levels of expertise on our projects, and we need to leverage their knowledge and understanding of the business process. This can lead to conflicts among stakeholders. Both of these aspects of managing stakeholders are a challenge.
Stakeholders represent a diverse community, whether you are procuring or developing business application software or you are managing a program to deliver the next military fighter plane.
To increase the probability that the proposed solution will perform as intended in your environment, you validate requirements in frequent exchanges with the customer. Requirements validation should be integrated with risk management. Mature organizations typically validate requirements in a sophisticated way by using multiple techniques, and they broaden the basis of the validation to include other stakeholder needs and expectations. These organizations typically perform analyses, conduct simulations, or build prototypes to ensure that requirements satisfy stakeholder needs and expectations. Successful projects validate requirements with multiple stakeholders.
Paula: The intent behind our review process is to get commitment from all the stakeholders. We conduct functional requirements reviews with the customers and users, as well as with the technical team. We also hold frequent review meetings about the nonfunctional requirements or quality attributes. These meetings involve the business customer—we definitely focus on a deep dive with our technology people to get the input and feedback from our architecture team, operational team, suppliers, and security team. To streamline things, we highlight those requirements most pertinent to their area of expertise. That type of “involved” review process with all stakeholders helps us end up with a solid agreement on the right requirements.
Successful projects also involve stakeholders who have a variety of technical knowledge about the business process, including operational specialists like security experts as well as maintenance suppliers. Including all these stakeholders creates an environment of early and open communication. It also ensures that the project team members, users, and customers pool their knowledge and help validate all ideas.
Steve: Team building is so important. It focuses on getting the business team to really get involved. Successful team building can make the difference between the business champion and users being your enemies or your allies—and a positive voice out to the customer. Before, when we started to build the trust relationship with our customer, there would be a lot of “You don’t understand” from the customer, as well as “You can’t make this work!” In these initial sessions, I would talk to my customer, and my business champion would say to me, “We’ve been with you for three hours, and you still don’t understand.”
Everyone around the table groans.
Steve: I’m happy to say that this relationship has changed dramatically. Today the business person is saying to the end user, “We just spent three hours with Steve Reiter and his team, so why can’t you explain what you’re doing?” The business champion has become more of a spokesperson and has taken ownership of the project. That’s a key part of our success.
Even within a tightly knit group of stakeholders, however, the stakeholders establish different priorities and attach different importance to the requirements. For example, one group of stakeholders may emphasize the economic aspects of a problem (will we make money in the future?). Another stakeholder may be concerned about status and responsibility (will the software give managers more control?). Still others may worry about job satisfaction (will we get the opportunity for personal development?).
How can stakeholders cope with these differences? If you take into account these different and potentially conflicting views, you avoid a narrow frame of reference and help build an appropriate picture of the problem. Comparing different viewpoints helps you investigate the advantages and limitations of different solutions. In an outsourced environment, the consolidation of different viewpoints becomes the specification of the solution that is captured in an RFP and eventually in the contract that is executed by the supplier. Of course, it isn’t easy to resolve conflicting stakeholder viewpoints.
Paula: You have different layers of stakeholders and different regional or local groups, and there is definitely a certain amount of turf protection and politics.
Matt: One thing we tend to overlook is how much time it takes to get everybody on the same page. If our deadlines don’t leave us adequate time to align stakeholders, projects increase their risk of failure.
Paula: That’s right, Matt. One other thing. My team tries to take the input and feedback from all stakeholders without judgment—more from a brainstorming standpoint—and make it visible so that we can talk through the pros and cons. We then try to make the business responsible for resolving a lot of the inconsistencies. Where we have seen problems in the past is when the technology team is trying to meet the needs of multiple stakeholders that don’t agree.
In this case, it’s particularly important to have a governance structure in place, perhaps in the form of a steering committee in which the business and acquisition organizations are represented. This body can intervene and bring those issues to resolution.
However, pushing for a unified set of requirements, seeking a common solution where there is none, can be detrimental to a project or program.
Kristin: Sometimes there is simply no common solution that will work across areas. The requirements are so different that I can’t get an optimal system that does all of them. For example, in one of our government contracts the Air Force and the Navy are both looking at air superiority in their airspace. There are some very basic capabilities that are common between them. For instance, they might want planes that have two engines, radar, carry this type of payload, are supersonic or subsonic, and so on. So somebody might conclude, “A fighter plane is a fighter plane.” Well, it’s not, because the environment that the Air Force deals with is very different than what the Navy deals with. The biggest difference is that the Navy lands on aircraft carriers, which is a moving airbase.
Matt: Sounds like a classic dilemma.
Kristin: That’s right. We have a program called Joint Strike Fighter. The pain of this program is that it has tried to incorporate everybody’s needs. This makes the price tag for each airplane a lot higher when you’re trying to satisfy a set of disparate requirements. Overall, logic says, “Yeah, it’s cheaper than buying two types of airplanes. I pay 1.5 times the price of a single airplane if I can do the job of two.” So it will be interesting to see how the Joint Strike Fighter performs in the field in different environments.
The proof is in the final result. Projects must be extremely careful when combining disparate requirements into a single solution. Such an approach not only may represent a formidable engineering challenge but also might easily end up as a financial disaster.
As if understanding stakeholders’ viewpoints isn’t difficult enough, their viewpoints frequently change as the process of engineering a solution evolves. Careful project teams continuously validate their concepts with the stakeholders and involve them throughout the project.
Steve: It’s kind of funny. On one of the main points of a global systems project, the North American group wasn’t willing to budge on something where we thought Europe really had the best practice. So we agreed to create a regional solution for North America and a regional solution for Europe. Halfway through the project, North America realized that the European method was better, and we ended up redoing the system and bringing it together as a global, common solution.
Sometimes you find yourself in a variant of this situation caused by organizational inertia.
Steve: Part of this is driven by organizational culture. You have projects that start but never finish. Based on their knowledge and experience, people find themselves in situations where they conclude that this will not come together. So let’s not talk about the difficult pieces of the problem because this project will never finish. It’s not until people see something—maybe a prototype—that they realize this solution might have some validity. This happens quite a bit with big projects.
While exploring how projects “mind the gap” between stakeholder communications, acquirers often encounter a situation dubbed “the elephant in the room.” The gray fellow is an idiom for a problem that obviously exists but is ignored for the convenience of one or more stakeholders. According to Wikipedia, it derives its symbolic meaning from the fact that an elephant would indeed be conspicuous and remarkable in a small room; thus the idiom also implies a value judgment that the issue should be discussed openly. Steve tells us how he has survived several encounters with the elephant.
Steve: We agreed with our organization in Mexico that they would start using the common global system to allocate their actual spending to their acquisition programs. During development of this financial system, we discussed how they allocated their actual spending and everybody felt this was a shoo-in—smooth sailing, no problems expected, since their processes matched how the common system was used in other parts of the company. But then after we deployed the system in Mexico, nothing was allocated to the acquisition programs. So we went back and said, “What’s wrong? It looks like all your actual spending has been allocated to a financial holding account rather than to individual acquisition programs.” And they said, “Well, it always goes into a holding account first. You don’t need to worry about that.”
That’s when I realized I was staring right at the elephant. They were using the system consistently but with a twist. Everything was parked in a holding account until month end, which caused interim reports to come up blank. Nobody discussed during development that they parked funds in this holding account rather than directly allocating it to acquisition programs. So nobody did anything about it.
Tip
To represent requirements, develop prototypes together with complementary models such as business process flows.
There are some gaps in stakeholder interactions that cannot be resolved by communication alone. Customers and users often do not know what they need until they see it. Multiple representations of requirements (e.g., prototypes, simulations, models, scenarios, and storyboards) have proven extremely beneficial for identifying issues and exposing unstated needs and customer requirements. Steve couldn’t agree more.
Steve: We had all the requirements written down in a Microsoft Word document. This was mostly because that’s what we were told to do. However, the primary value was in the working models and the prototypes that we used in the sessions with the customer. It was more important that they saw a prototype compared to reading a requirements document. If it wasn’t for the interactive sessions that we had with them, they wouldn’t have signed off on the documents.
A few times we actually had to go back to the requirements document, and they would say, “Well, this is not what we decided in the meeting.” And we would say, “Well this is how it is written.” But then we would realize that how it was written was not how we actually did the prototype. So we agreed to use the prototype as the source of truth.
The use of prototypes early in the project increases the likelihood that customers, suppliers, and the acquisition team will have a better understanding of the real stakeholder needs. Thus, prototyping increases the useful functionality provided by the technology solution at delivery. The prototype needs to be based on a thorough understanding of the business processes. Paula illustrates this.
Paula: We do a lot of process modeling and prototyping to show how the process would be enabled by the proposed solution. We instruct the supplier to build some pieces so that the customer can see and understand what we’re talking about. Frequently, we work with our hosting supplier to stand up one of the COTS packages we’re considering and then use the COTS package as part of our prototype. With the help of the supplier, we build some of the computer screens and apply some of the business rules.
Steve: Can you give us an example?
Paula: Sure. My most recent project was a financial system. In our prototype we just did a small number of relevant transactions. We didn’t create a lot of the fancy logic. But we let the customers and users see how they would input, for instance, their forecast, how they would then report back the variances and forecasts versus actuals. When we first presented our ideas to the customers we used business process flows and a simple slide show, but when we went to get sign off on the requirements we included this prototype.
Steve is also enthusiastic about prototyping.
Steve: Customers love prototypes. It also strengthens our communication with the suppliers. For instance, there can be major disconnects between the supplier’s on-site team and their offshore development center. In many cases, we now give the supplier a prototype along with the requirements document. This has tremendously improved communication and reduced the amount of rework. In this case, it’s true that a picture is worth a thousand words.
Matt: I understand you’ve taken this a step further. Tell us about that.
Steve: Well, it works so well that we’ve contracted with a supplier to establish an integrated prototyping environment that contains prototypes of all our technology solutions and associated scenarios of their application to a particular business process. So now we can show our customers not only the technology per se, but more importantly illustrate how it fits into the context of the business process.
Matt: So it’s like having a library of prototypes.
Steve: That’s right. And it has changed the way we work. Since the prototypes allow us much better communication with the business customer, we can adjust to a shared governance structure between the technology group and the business. We use this new structure to prioritize the requirements in the best interest of a business process overall, and not just for a particular project or single stakeholder. All this was enabled by this tight link between groups of prototypes and their associated business processes.
Tip
To prioritize requirements for a technology solution, establish a collection of prototypes that optimize the entire business process.
Walkthroughs also encourage discussion of the functions and behavior of a technology solution. Walkthroughs present a series of scenarios that might occur during the use of the product and that make explicit some stakeholder intentions. Typically, operational scenarios are derived from business process descriptions and operational concepts.
Paula: We start out with the business process and derive customer requirements, which are really the value proposition—the stakeholder intentions—and then we walk through user scenarios. We work with the customers and users. They tend to say, “Let’s take a particular business process or subprocess and start talking about how a user might be working with the business process to achieve a goal.” What are all the scenarios and challenges that we can come up with to help us build and elaborate those with prototypes and wireframes so that the stakeholders see multiple views of requirements? We try not to go back to the business with just a requirements document but with prototypes, wireframes, summary business requirements, and rules. That way, we create an overall process on how we might document each of their different processes.
Tip
Jointly with the customer, develop and walk through scenarios that demonstrate how the technology solution will be used.
As solution decisions are made and more detailed requirements are developed, you refine the prototypes and scenarios. Requirements also evolve to facilitate the validation of the technology solutions delivered by the supplier.
Scenarios can represent historical records of executing software or a thought experiment of executing a proposed system. Intuit’s innovative gathering of scenarios highlights this point. Intuit’s “Follow Me Home” program started when software designers realized that testing in the usability laboratories could not accurately reflect the experiences of users who tried to install and use the software in their own environments. Customer surveys were not timely enough or detailed enough to expose potential problems. So staff from Intuit went to local stores and asked software buyers for permission to observe them as they first tried to use it. Watching people in their own homes with their own computers revealed subtle problems, such as the user who was confused by the “Register” item on the main menu, thinking that it had something to do with the product-registration card (De Young 1996, p. 263).
As you create and use prototypes and scenarios, engage in intensive dialog with your customers. This practice ensures that customers contribute to the requirements, and that immediately affects the technology solution. Scenarios serve as a means of discussing alternative solutions, grounding discussions and negotiations in real examples, and supporting trade-offs among design alternatives. Misunderstandings between stakeholders become apparent, and through prototypes the supplier’s understanding of the problem to be solved can be validated quickly. Scenarios serve as a common basis for communication to help resolve such misunderstandings.
Equally important, validating requirements via a scenario lets stakeholders detect missing functionality, overspecification, errors, or unintended side effects. Teams frequently use prototypes or mock-ups to enact scenarios. This allows for a hands-on experience of the proposed system, making it easier for stakeholders to discover problems and suggest how the specification can be improved. Prototypes and mock-ups are therefore popular methods for validating requirements. When done correctly, both techniques are cost-effective. When done poorly, however, they can be expensive and sometimes even disastrous in misguiding stakeholder expectations.
The CMMI-ACQ provides specific recommendations on how to perform analyses to determine candidate requirements for product concepts that will satisfy stakeholder needs, expectations, and constraints. It also covers recommendations on how to validate requirements to increase the probability that the resulting product will perform as intended in your environment (see Table 3-5).
Table 3-5. Acquisition Requirements Development Goal 3: Practices and Tips
CMMI-ACQ Process Area: Acquisition Requirements Development | ||
3. Goal: The requirements are analyzed and validated. | ||
Practices | Tips | |
3.1 | Establish and maintain operational concepts and associated scenarios. |
|
3.2 | Analyze requirements to ensure that they are necessary and sufficient. |
|
3.3 | Analyze requirements to balance stakeholder needs and constraints. |
|
3.4 | Validate requirements to ensure that the resulting product will perform as intended in the user’s environment using multiple techniques as appropriate. | |
Operational concepts provide an overall description of the way in which the technology solution is intended to be used or operated, deployed, supported, and disposed of (Table 3-5, practice 3.1). For that, you take design constraints explicitly into account. In contrast, a scenario is a sequence of events that might occur during the use of the acquired product that makes explicit some stakeholder intentions.
As contractual requirements are defined, their relationship to customer requirements must be understood. In light of the operational concept and scenarios, the contractual requirements are analyzed to determine whether they are necessary and sufficient to meet the customer requirements (Table 3-5, practice 3.2). The analyzed requirements then provide the basis for more detailed and precise requirements throughout the project life cycle. You also need to determine which key requirements will be used to track technical progress. For instance, the weight of a product or the size of a software code base may be monitored throughout development to assess its risk.
Stakeholder needs and constraints can address cost, schedule, performance, functionality, reusable components, maintainability, or risk. Acquirers use proven models, simulations, and prototyping to analyze and balance stakeholder needs and constraints (Table 3-5, practice 3.3). You also perform a risk assessment on the requirements and design constraints and examine product life-cycle concepts for effects that requirements might have on risks.
You analyze the requirements to determine the risk that the resulting technology solution will not perform appropriately in its intended environment (Table 3-5, practice 3.4). For that, you explore the adequacy and completeness of requirements by developing product representations (e.g., prototypes, simulations, models, scenarios, and storyboards) and obtain feedback about them from relevant stakeholders. To gain adequate insight into how the technology solution progresses and to ensure that it meets customer expectations, you assess the technology solution as it is developed by the supplier in the context of the validation environment to identify issues and expose unstated needs and customer requirements.
The many sentences beginning with “After the requirements are frozen ...” embody a favorite myth of many acquirers and their contracting officers. Although the thought of “frozen” requirements is comforting, in reality this state never comes true, at least not for most technology solutions. In fact, many people argue that change is an inherent property of any technology project. Discovering requirements for a technology solution is a process of learning, communication, and negotiation. To specify technology solutions successfully, then, you must discover the requirements progressively. Stakeholders have an interest in transforming a situation from what it is to something they like better. They progressively relate a situation to technological artifacts as perceived solutions. Their understanding of the current situation serves as a springboard to a new cycle of improvement.
Tip
To maximize the value of the resulting technology solution, contractually allow for changing requirements.
This necessary learning is one reason for the cyclic characteristic of technology projects. Acquisition projects are in a constant dialog with the customer to generate requirements and negotiate design constraints, which in turn generate new possibilities for the customer and other stakeholders. As customers learn more about the desired capabilities and better understand their application, they envision many features they wish they had included in the original requirements.
Many customers and suppliers therefore argue that requirements should not be frozen while they learn about the application domain or the capabilities of the proposed solution. In other words, you should not formalize requirements any faster than you can reduce the rate of uncertainty about technical decisions.
However, this leaves the unresolved issue of finding an economical balance between supporting changes in requirements and delivering operational solutions. Such a balance is of utmost importance; otherwise, last-minute changes to the specification will keep delaying the deployment of the technology solution.
Stakeholders constantly struggle with getting the requirements right and getting them stable. Change may come from various sources, causing significant uncertainty in a project because of conflicting and missing information. For example, the enabled business processes often change, thus requiring the original specification to change, before even the best supplier can deliver the solution. Hence, it seems virtually impossible to produce defect-free specifications before building the technology solution or, at minimum, a prototype.
Paula: One side of it is, “We didn’t do a good job up front, and our requirements baseline was bad.” That’s the risk of rushing through the requirements gathering—you end up with a highly inaccurate specification up front, and you end up in change control hell. And then you also have to cope with business change. In a project I’m working on right now, we just got a new business champion. That’s very painful. From a project perspective it’s not something I can really control, as much as we try to manage as best as we can. We have to be very diligent in how we manage change and traceability.
Tip
Allow for different viewpoints of different stakeholders involved in different phases of the project.
No stakeholder can come up with a complete list of requirements at the start of requirements gathering. Rather, they evolve during the project as stakeholders increase their understanding. Moreover, requirements emerge from new stakeholders who were not originally consulted. The people consulted at some stage in the process may change jobs and thus are no longer available for consultation.
If a specification fails to integrate these changes, it becomes obsolete. It hinders people’s communication and learning process and leads to inferior software. In other words, a static specification prohibits stakeholders from formulating their insights to improve the proposed solution.
Tip
Negotiate with the customer and the supplier the deadline for stakeholders to change requirements.
The central question is this: How much of the specification do you need before the supplier can start the design and you and the supplier can establish the supplier agreement? In terms of the specification, some people would say you can never get it complete no matter how hard you try. But then the question is this: How can you tell that the specification is good enough?
Steve: You stop working on the initial requirements when you run out of time. That’s it—we had to have this system up by the end of the year. So the business customer has to trust that you understand the problem to be solved. What we said to the business champion was, “We get the gist of the overall problem. We guarantee you as we build it, we will iterate. We will not hold you to every word that was said in the initial requirements session.” That was the thing. They had to trust that we were not going to come back and say, “You signed the requirements specification, and see? On line two on page seven, it says that we’ll do it that way and now you’re stuck with it.” We were very clear to them that the process will be iterative. They’re completely open to making changes, and we will just go through it and prioritize based on business value.
By starting without a complete specification you can overlap requirements discovery and the supplier’s development of the technology solution, reducing everyone’s overall time to delivery. Such a reduction is not free. It leaves you vulnerable to expensive rework, because the supplier may have completed detailed design work that changes later in the process. Thus, you face a trade-off between delivery speed and delivery expenses.
Tip
When the cost of potential rework is lower than the cost of reduced cycle time, overlap your specification with the supplier’s design and development activities.
When the cost of potential rework is lower than the cost of increased cycle time, you should overlap your specification with the supplier’s design and development activities. Steve is convinced that this is the way to go.
Steve: We struggled when we had contracts that forced us into a waterfall methodology. Everything was strictly sequential, locked in through firm fixed-price contracts. You were forced to get to a low level of detail in the plan so that the vendor could make a qualified bid. This caused analysis paralysis and a lot of angst. Sometimes you had to make decisions that you knew you were stuck with, even though you knew you’d want to change them when the supplier actually built the system or the business actually started to see the solution.
So you find yourself in a catch-22. To survive, some of us got together and decided to trick the system.
Steve laughs.
Steve: Well, sometimes you have to ask for forgiveness later, and in this case the workaround became the new way of doing things. So we decided to break our projects into smaller chunks. For instance, one of my projects turned into nine projects, one of Paula’s ended up as five projects, and so on. We then used the related projects to institute a progressive freeze of the requirements.
Matt: A progressive freeze? How does that work?
Steve: We defined a schedule for freezing different requirements. For example, we might decide to freeze the number of screens in the financial services application 30 days after the start of the project, but we might determine some of its more detailed attributes—such as color, width, position on the screen—90 days later. The point is, we don’t have to freeze all requirements at the same time. We can freeze them in increments, depending on when the information is needed. So we were still able to use firm fixed-price contracts for the smaller projects, and we learned more about our requirements faster, delivered workable solutions more rapidly, and made everybody happy along the way. How’s that for a workaround?
Tip
Stay engaged with the supplier’s design team as requirements are translated into detailed design decisions.
Stakeholders iteratively negotiate trade-offs between requested functions, the capabilities of the technology, the delivery schedule, and cost. In the case of conflicting requirements, an effective technique is to prioritize them and include as many as possible in the contractual requirements in order of importance. Even so, it’s difficult to achieve a consensus on the requirements among the stakeholders that have to accept and abide by the rankings. Even after priorities are negotiated, it’s hard to maintain consensus without strong leadership to oversee adherence to priorities. In addition to shifting priorities, Steve identifies two other reasons for fluctuating requirements.
Steve: We’re often faced with a loosely integrated technical design. Requirements occasionally fluctuate because the technical designs for different components aren’t tightly coordinated. In making a detailed design decision, suppliers often make incorrect assumptions about how we intend a contractual requirement to be met. A requirement then becomes unstable across different components of the design. Without tight coordination of design decisions, inconsistencies become apparent only at integration time.
And then there’s the “creeping elegance” syndrome, or what some people call “gold-plating.” Suppliers go beyond the contractual requirements by adding features we haven’t requested. This also destabilizes the requirements. Often project managers recognize the impact of this on schedule and performance, but only after resources have been expended unnecessarily or when schedules have slipped irreversibly.
The CMMI-ACQ provides specific recommendations on how to manage the requirements of a technology solution and how to identify inconsistencies between the project’s requirements and the plans and work products (see Table 3-6).
Table 3-6. Requirements Management Goal 1: Practices and Tips
CMMI-ACQ Process Area: Requirements Management | ||
1. Goal: Requirements are managed, and inconsistencies with project plans and work products are identified. | ||
Practices | Tips | |
1.1 | Develop an understanding with the requirements providers on the meaning of the requirements. |
|
1.2 | Obtain commitment to the requirements from the project participants. | |
1.3 | Manage changes to the requirements as they evolve during the project. | |
1.4 | Maintain bidirectional traceability among the requirements and work products. | |
1.5 | Identify inconsistencies between the requirements and the project plans and work products. | |
To avoid requirements creep, you establish criteria to designate appropriate channels or official sources of requirements. When a project receives requirements from an approved requirements provider, you review the requirements with the source to resolve issues and prevent misunderstanding before the requirements are incorporated into the project’s plans (Table 3-6, practice 1.1).
The project maintains a current and approved set of requirements over the life of the project. This typically includes directly managing changes to customer and contractual requirements developed by the acquirer and oversight of the supplier’s requirements management process (Table 3-6, practices 1.2 and 1.3). Changes to requirements may lead to changes in supplier agreements; these changes need to be agreed upon between the project and the supplier after appropriate negotiations. To effectively analyze the impact of the changes, you must know the source of each requirement and document the rationale for any change. The project manager, however, may want to track appropriate measures of requirements volatility to judge whether new or revised controls are necessary.
When the requirements are managed well, traceability can be established from the source requirement to its lower-level requirements and from the lower-level requirements back to their source (Table 3-6, practice 1.4). Such bidirectional traceability helps you determine whether all source requirements have been completely addressed and whether all lower-level requirements can be traced to a valid source. As the acquirer, you trace the contractual requirements to the customer requirements; the supplier maintains comprehensive bidirectional traceability to the requirements defined in the supplier agreement, and you verify that traceability.
You also need to identify inconsistencies between the requirements and the project plans and work products, if any, and initiate corrective action to fix them (Table 3-6, practice 1.5). Your corrective actions can also result in changes to project plans and supplier agreements.
The single hardest part of building systems, software, and technology solutions is deciding what to build to address the stakeholders’ needs. Getting the requirements right may be the most important and difficult part of a project. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later (Frederick P. Brooks Jr., The Mythical Man-Month, Addison-Wesley, 1995).
The requirements development effort comprises three information-gathering components:
Gathering qualitative information through a continuous dialog with prospective stakeholders
Getting quantitative information about stakeholders’ business processes or operations, requirements, and competitive attributes to set the value of the opportunity, determine its size, and estimate the eventual rate of penetration and final level of acceptance into the business
Addressing communication, distribution, and support strategies
The interactions between acquirers and stakeholders should form a spiral pattern of repeated steps and increasing mutual understanding. Through this iterative process, a relationship evolves in which each party continually increases its realization of what the other party has to offer. Engineering a solution begins with understanding the stakeholder’s needs, expectations, and constraints for building the system, software, or technology solution.
The stakeholders’ main focus, and therefore also that of the acquirer, is acquiring a solution that adds value to stakeholders’ business or operations. The idea for this solution may start by being described in a few words or in a hand-drawn sketch, long before it matures into a fully developed product concept.
It is critical to foster an ongoing dialog with customers and stakeholders from the earliest phase of the acquisition life cycle through final delivery of a product. Clear communication and mutual understanding are the only reliable ways to establish requirements, continuously modify concepts, and verify the value of the deliverable. For many projects the number of customers and stakeholders is large, and it is vital to interact with a representative critical mass to form an accurate view of the requirements.
Your first step in developing your acquisition requirements is to present the idea to the prospective customer and promote it by helping the customer understand it and see how it will add value to the business or operations. With truly groundbreaking solutions to complex problems, the customer may initially have difficulty envisioning what you have to offer. Documents, diagrams, models, and prototypes are all ways to help stakeholders understand what the proposed idea will look like. By showing them something concrete, you ground discussions in reality and can begin to talk about what works and what needs to change in very specific terms. This is an opportunity for stakeholders to identify needs or requirements that may have been misunderstood or misinterpreted and reconcile those differences.
The second step in requirements development is for you to listen to the customer’s perspective, carefully and in enough detail and context to understand the real needs that the stakeholders communicate through their words and actions. For this step, you can employ a combination of techniques to make these interactions successful and productive. By conducting brainstorming sessions, workshops, moderated focus groups, interviews, and observations, you can draw requirements out of the stakeholders, perhaps even requirements that they haven’t thought of. All these techniques are important tools. It may also be beneficial for you to use a “formatted tool for hearing,” such as quality function deployment, to ensure that the customers’ views are documented and thoughtfully translated into terms that you, the stakeholders, and the suppliers can understand.
The third step in requirements gathering is to creatively modify or develop the idea to reflect a deeper understanding of requirements that fulfill stakeholders’ needs. The spiral continues as you return to the stakeholders with further rounds of communication and development. As the process continues, the stakeholders’ requirements become more refined and eventually you can translate them into documented customer requirements that are accurate, high-level, and easy to digest.
It’s widely believed that a more detailed specification is better, but that is a myth. This myth is often perpetuated by project and program managers who feel obligated or are even mandated to use highly detailed standard templates for documenting specifications. Instead, the requirements should be accurate, minimal, and understandable. Remember that each requirement represents a constraint and a risk for the customer. The requirements must focus on the significant differentiators—the specific foundational characteristics that enable the system to achieve its purpose.
To maintain focus on significant differentiators, you, the customer, and the supplier must make choices about which requirements meet these criteria. This process of sorting and quantifying the criticality of a requirement—determining whether it is a must-be or an attractive requirement—is the first step in prioritizing customer requirements. Prioritizing is a tricky task, especially when you’re evaluating nonfunctional requirements like reliability, scalability, safety, security, and performance, which often seem to conflict with other requirements. Standard requirements—such as those specifying architecture, data management, basic security, operational details, and testing—reflect the policies that projects adhere to across the organization. Clearly, developing acquisition requirements is more than just a balancing act; it’s a balancing act that takes place on a tightrope, and one misstep can have disastrous results.
After the significant differentiators and standard requirements have been established, they’re translated from customer requirements into contractual requirements. The contractual requirements specify the criteria that suppliers must meet to build a successful deliverable—one that is of high quality, within budget, and delivered on time. To ensure that contractual requirements leverage the supplier’s capabilities, it is important to develop design constraints that must be satisfied by the supplier’s design. Design constraints express the qualities and performance points that are critical to the success of the product in the acquirer’s operational environment. They document the interfaces, product reuse, use of COTS components, criteria for evaluating the supplier’s design, and criteria for screening and selecting possible alternative solutions.
Verifying the supplier’s design to determine goodness of fit with the requirements is a critical, ongoing activity. You must ensure not only that the requirements have been met as promised but also that the design has not been “enhanced” to include features that were not requested. These features, which are said to “creep” into a system, add unnecessary complexity and potential risk. In determining goodness of fit, technical reviews are key practices for acquirers as well as suppliers. Reviews formally evaluate the consistency of the proposed technical design or the consistency between the technical design and its contractual requirements and design constraints.
Stakeholders and acquirers constantly struggle with two opposing forces: getting the requirements right and getting them stable. To support these goals, you use prototypes, models, and walkthroughs to encourage discussion of the system’s functions and behavior and help keep the communication channels alive.
Like strands in a double helix, the requirements are continuously analyzed, validated, and adjusted as the technical design spirals in parallel. To keep these strands from becoming disconnected and frayed, you must continue fostering and mediating relationships with and between customers and suppliers; at the same time, you bear the responsibility of ensuring that the delivered solution will not only operate but also meet expectations in the deployed environment. Technical development involves addressing the project’s technological uncertainties, and it can easily wander astray if it becomes isolated from customer needs. Development should be based on stakeholder targets for the system or service, including its cost, plus the specific plans and actions to achieve those targets.
In this chapter, we focused primarily on how to elicit requirements from stakeholders, translate them into contractual requirements, and validate that the supplier starts on the right path. In Chapter 4, we examine the acquirer-supplier relationship in more depth by discussing how to apply integrated project management, use configuration management, establish the right metrics, and, finally, live with the technology solution.