CHAPTER 2. Gathering and Analyzing Requirements
The reason most organizations don’t end up with a satisfying configuration management process is that they don’t begin by identifying the needs that must be satisfied. It is important to define the criteria for success explicitly.
Everyone has a different understanding of what configuration management can do, and expectations generally are high. Each stakeholder group believes they know what configuration management should do for them, but very seldom are these expectations and assumptions clearly documented, or even consistently understood, within the group. This chapter describes how to corral all of your organization’s visions and hopes for configuration management and wrangle them into a solid set of requirements that are achievable and realistic.
It is important to understand at the outset that requirements management techniques are not dependent on the subject matter of the requirements. This chapter provides some general information about requirements management and systems engineering along with describing specific experiences in gathering and analyzing configuration management requirements. If requirements management is a strength for your organization and these techniques are second nature to every project, you can just skim this chapter quickly to gather the bits that are important for configuration management. On the other hand, if you are unfamiliar with the cycle of eliciting, documenting, prioritizing, and sizing requirements, read carefully. Better yet, get a requirements management expert to join your project team. The only proven way to control the cost and quality of your overall configuration management effort is to define good requirements up front and put them under strict change control throughout the project.
Gathering
Requirements management generally falls into two areas: what you do before you have requirements, and what you do after you have them. This first section describes how to distill configuration management requirements out of all the expectations and hopes that might be swirling around. This process of gathering all the wishes of all the stakeholders is critical because until everything is put on the table, there is no way to really understand what the end goal of configuration management should be for your organization.
Figure 2.1 shows the gathering part of the requirements cycle. I call this “gathering” because the purpose is to initiate communication with as many stakeholders as possible and to clarify that communication enough to document specific needs for the project. Although many textbooks on requirements management discount the dreams and hopes of your stakeholders, experience shows that many requirements can be lost if you discount dreams and hopes too soon.
Figure 2.1. Requirements are distilled from stakeholder dreams.
Eventually, though, you must start to focus on those dreams and hopes and get to specific wishes and expectations. The difference here is one of practicality. Although a stakeholder might dream of a configuration management system that automatically detects and documents every new business application installed on every server, even the most optimistic wouldn’t expect that kind of system to grow where the organization is still struggling just to catalog all of the available servers. The horizontal lines in Figure 2.1 indicate filters that must be applied to get to the next step. Only the practical dreams and hopes will be expressed as wishes and expectations.
This first filter is where a strong project sponsor comes into play. The sponsor needs to judge what is and is not going to be practical for the project. This difference between practical and impractical is often measured in degrees of desire, the amounts of effort to be expended, and the general size of the project that the sponsor desires. All these factors will help determine which dreams and hopes are worth pursuing.
After all the wishes and expectations have been put on the table, the second filter is measurability. Those expectations that cannot be measured cannot be fulfilled. Only the wishes and expectations that can be put into concrete, measurable terms will become requirements. This isn’t to say that the other expectations and wishes aren’t important—they should be saved and used in presentations as descriptions of the benefits of your project. These “soft” benefits, where you can fairly claim them, will help greatly with stakeholder concurrence at various decision check points along your project path. Never discount what a stakeholder expects—just don’t promise to deliver on it by putting it into your requirements document.
Finally, not all of the requirements are going to be fulfilled in your project scope. Funding is the filter which determines which requirements actually get built. Although all requirements are practical and measurable, not all are important enough to be funded in your project. This final filter, analyzing requirements, is the subject of the second half of this chapter.
The Need for Requirements
The need for good requirements should be obvious. Without a vision of where the project is headed, it’s likely to go nowhere. It is critical to have clear, specific, measurable, and documented statements about what the configuration management process and the Configuration Management Database (CMDB) should do.
Without good requirements, the implementation team will not know when they’ve finished their work. Instead, they will continue implementing until they feel their work is “good enough.” Of course, the opinion of what is enough will be different between the implementation team and the test team, and there will be inevitable debates about whether what was implemented really completes the needed tasks.
If you don’t have good requirements, validation of the final work product becomes a long, difficult negotiation session with users telling you that it isn’t correct, and you saying that it is exactly what you intended. Testing should always be based on whether requirements have been met or not. Without adequate or measurable requirements, testing is simply an opinion poll indicating whether the test team likes what they see. Testing normally results in a set of defects, where a defect is defined as an area in which requirements are not met. Without requirements, the test team has no basis on which to raise defects. This results either in no defects being raised at all, negating the purpose of testing, or in defects being endlessly debated between the implementation team and the test team.
Without good requirements, the project manager will have to make up tasks in the project plan. A good plan should be based on meeting stated requirements, and fulfillment of each requirement should be documented as a deliverable in the plan. If there are no requirements, you’ll most likely end up with a project plan to produce project-oriented deliverables such as communications plans and test results, but without concrete tasks to actually implement configuration management.
Good requirements will serve as a project measuring stick throughout all the stages, and as we see later in this chapter, serve as a boundary between what gets into the first release and what can wait until later releases. If someone asks you to start building a configuration management process, organization, or tool without good requirements, it’s time to educate him or find another project to work on.
We had a major customer, where we were pressed for time and needed to get a configuration management plan put together to meet a contractual deadline. We talked briefly to the central office team who had been thinking about configuration management, but completely ignored the people out in the business units and geographical regions of the customer. We didn’t even document what we heard from central office in the form of requirements.
Of course, the results were predictable. We struggled to figure out what might be of value. We debated about whether things would really satisfy the customer. We produced what we thought might be wanted. We produced the document describing exactly what would be in the CMDB in great detail, and then spent the next 12 months defending and rationalizing it! In the end, the customer decided we should start over and take a more careful, requirements-based approach.
The lesson learned is that by not taking the time to document requirements up front, we ended up needing much more time to accomplish our task, and even then it didn’t meet the customer’s needs.
So we know we need requirements, but what kind do we need? We need statements that are clear, unambiguous, and pertinent. Hopefully you’ve learned clear and unambiguous language from your English teacher. A requirement that states “Present a screen to the user” is unclear and ambiguous. A much better wording is “The system shall render an HTML page containing form A7.” Clarity is normally gained through adding more descriptive words. Never use words like page, field, table, column, box, picture, or icon without additional text to say what these should look like, what they should contain, and how they should be defined. Remove ambiguity by choosing words more carefully. Avoid words such as some, much, many, often, and about in your requirements, and replace them with exact numbers.
Pertinent is just as important—each requirement must apply to configuration management. You’ll be amazed at how easy it is to start specifying requirements for change management, incident management, or any of a number of other disciplines. Although all process disciplines within the IT Infrastructure Library (ITIL) framework clearly integrate with one another, you must doggedly insist that configuration management not try to accomplish more than it is capable. Be on your guard especially for requirements that sound like they fit, but fundamentally deal with another process area.
For example, “The CMDB shall relate each incident record to one or more configuration items.” That almost sounds like a configuration management requirement, but look more closely. Can the CMDB relate anything to anything? How would that work? In reality, when an incident record is recorded is the perfect time to find out which configuration item (CI) is broken and record the relationship between the CI and the incident. That specific instance in time happens as part of the incident management process, and the service desk agent recording the incident is using an incident management tool. This can’t be a requirement against the configuration management process or tool because they won’t even be in play at the time. Be careful to insist that all of your requirements actually can be filled by the process or tool you’re putting in place.
Where to Look
So where do you go to get good requirements? The best place to start is where you are. Most likely you are involved in building configuration management because of your role in the enterprise. Look at your job description. If it says anything about configuration management, those are probably some requirements. Look at the problems that you, your team, and your organization are experiencing because you don’t have good configuration data. Those problems are a great place to look for a description of what’s needed. Attend some incident management meetings—document what you learn about how configuration data could help, being careful to get only configuration management requirements. Do the same with meetings regarding change approvals, capacity planning, or service levels. In each of these disciplines, you’re likely to discover some way in which configuration management data could help. In addition to these formal meetings, you also want to talk to people both inside your organization and in other organizations who are implementing ITIL. All these areas will help you when looking for requirements.
Certainly you’ll want to schedule time with your stakeholders. Anyone who has a dream, hope, wish, or expectation of configuration management is a stakeholder, and the more of them you can listen to, the better you’ll be able to compile a complete picture of what will satisfy your organization. Be sure to consider those stakeholders outside of information technology (IT). Although you may need to educate them a bit about what configuration management is and why you’re interested in it, you’ll often find the fresh perspective they can bring worth the effort of seeking them out. Also don’t get bound to a single geography. If your organization spans the world, you should talk to people all across the world and not just in your home country. In this exploratory stage of requirements gathering, you will most likely get a much better education about how your organization thinks, and not just about configuration management. Any time spent seeking out your stakeholders will be returned threefold in time saved getting your project approved and keeping it moving forward when obstacles arise.
Beyond talking to people, you can also look at documents for clues to the requirements. Is there a configuration management process description somewhere? It probably has a lot of requirements in it. Descriptions of related processes can also be sources for good requirements. Look up configuration management tools and read the descriptions of the features they support. Which of those features are requirements for your tool set? By all means read the ITIL volume on service support. You’ll find some general guidelines there for what the configuration management process should be, and those guidelines can be distilled into requirements for your organization. If you have been handed any project description or scope documentation for the configuration management project, those would be excellent sources of requirements. While you’re between appointments with all your stakeholders, take the time to read all the documents you can find.
The key thing to remember is that when looking for requirements, it is impossible to cast your net too broadly. Every corner you fail to examine has the potential to unleash a project-crippling surprise later. Every person you fail to ask will come in at the eleventh hour with a completely new thought that needs to be implemented. Remember that the filters defined in Figure 2.1 and explained earlier will help center these discussions and provide actual requirements. Skipping directly to the easy requirements without considering some of the less obvious sources will leave you with an incomplete picture of the project.
Techniques for Eliciting Requirements
Just as there are many places to look for requirements, there are many ways to find requirements after you get to those places. The techniques you use are critical to getting key business people to open up and share their dreams, which is the only way your project will be able to satisfy them. There is little more frustrating than meeting all of the stated requirements, only to find out that you “missed the mark.” This can happen too easily if you ask the wrong questions or use the wrong techniques. The following sections describe some techniques that will help you avoid this trap.
Requirements Workshops
One important technique for getting a solid set of requirements is to hold a requirements workshop. The purpose of the workshop technique is to bring together people so that they can share their ideas on what configuration management should become. The format and participation in the workshop will be dictated by what your organization typically supports, but the following paragraphs will give you some of the techniques that have proven effective in large projects.
Most of the success of a workshop approach to requirements gathering is dependant on getting the right participation. Ideally you’d like to have every stakeholder for the project, but that usually isn’t practical because of the number of stakeholders and other demands on their time. The most important participants in a requirements workshop are the project sponsor, the requirements analyst, and anyone who is known as the greatest skeptic in your organization. The first two are obvious choices, but it has been proven repeatedly that workshops are more effective if you include the skeptic as well. Maybe you have someone who has been particularly vocal that configuration management will never work. Perhaps you know of someone who believes the task is just too big. Those are exactly the points of view you need in the workshop because they provide the best grounding in reality for the dreams and hopes of the optimists.
Along with those three roles, you should seek as much diversity as possible in your workshop participants. If your company is international, make sure that each country, or at least each geographic region, is represented. By all means seek participants from outside the IT organization. It is often these “business” people who have the clearest ideas of what IT projects should accomplish, and usually these same business people will make the final evaluation of your project’s success.
Also invite people from different levels in the organization structure. A workshop with all executives will be out of touch with what can truly be accomplished, whereas recommendations from a group with no managers at all will not be as easy to sell come funding time.
Workshops are always more effective if they can be conducted face to face. The travel costs for a well-run workshop are saved in labor later in the project as clear requirements make implementation, testing, and deployment much easier. The typical requirements workshop should be two or three days. If the participants are new to configuration management, you may need a bit more time and be able to combine the requirements gathering with some good education for your stakeholders. If this is part of your plan, make sure to leave time and have the appropriate expert supply the education. The workshop should also include one or two people designated to take notes and capture requirements.
The agenda for the workshop should be based on a breakdown of the scope of your overall configuration management effort. If you’re starting at ground zero, that means part of the workshop should focus on the process, part on data sources, part on tools, and part on identifying the people who will benefit and exactly how they will get those benefits. For example, your agenda might start with a high-level view of the configuration management process from the ITIL service support book, followed by an open discussion on which pieces need more definition for your organization—that would result in a list of process requirements. The next item on the agenda might be a discussion of the kinds of decisions people would like to be able to make with more data. That could lead to some interesting requirements on both data sources and users of the data. The workshop should include discussion of the roles that are expected to be played, and where those roles will fit within your organization. Organizational requirements and labor requirements often are ignored, but this is a mistake. Remember that the purpose of the workshop is to cast a broad net and get as many ideas about what needs to be accomplished as you possibly can.
In very large, global enterprises, a modified form of workshop can be useful. We call this a road show approach. In this approach, you make a world tour to the various locations where concentrations of stakeholders can be found, and conduct basically the same workshop at each location. At each stop on the tour you present the current state of thinking, including the cumulative knowledge from previous meetings, and then solicit feedback that can be used to shape the thinking. This global approach allows a much wider group to participate in face-to-face meeting formats while incurring travel expenses for only a small team of core people. One of the most fatal mistakes in gathering requirements is to ask everyone at the “home office” what they need while completely ignoring the 90 percent of the stakeholders who don’t work at corporate headquarters. The format of the road show needs to be adapted to review the results obtained from previous stops on the tour, but for large organizations this type of workshop will get the best possible results without having one large free-for-all session.
Storyboarding
Storyboarding is another technique that can be useful for getting people to talk about their wishes and expectations. This involves having one of the team members create a set of scenarios, or storyboards, describing potential ways in which configuration management information could be gathered, used, reported, or some other aspect. For example, you might prepare a storyboard describing a typical change event in your organization. The general outline of the storyboard might look like this:
- A change is proposed by the server administrator to add memory to the CashFlow server.
- The change is sent to the architecture team, who evaluates it against standards found in the CMDB.
- The architecture team approves the technology behind the change and forwards the record to the Change Approval Board (CAB) for business direction.
- The CAB checks in the CMDB for other servers that already have additional capacity. Finding one, they ask whether CashPro could be moved to a different server.
- The server administrator checks the configuration of the other server and finds that it doesn’t have enough memory.
- The CAB approves the proposed change.
Storyboards do not have to describe in detail the existing procedures or even the new procedures. They simply need to cover enough ground so that they can generate conversation about the requirements. This kind of a “straw man” approach often helps people explain their own expectations more clearly than a simple discussion. Experience shows that people more readily criticize an existing concept than create a brand new concept.
After the storyboards are in place, you can either send them around in email for discussion or use them as the basis for workshop type sessions. Regardless of the format, it is important to let everyone know that your purpose is not to make the storyboard perfect, but to generate discussion and capture requirements for the configuration management project. You can use the tendency to want to improve the storyboards, however, by evolving naturally from the raw storyboards to the more refined format of use cases.
Interviews
In some cases, one or more senior leaders in your organization might intimidate others in a workshop format. Rather than turning a workshop into an interview with one lead speaker and many spectators, it is sometimes better to schedule individual interviews with people whose position and personality make this a better approach. Direct interviews also can be useful when key stakeholders are too busy to attend a workshop or comment on a package of storyboards.
The interview takes no less preparation than the workshop and should cover many of the same topics. When using interviews in conjunction with workshops, always include workshop results as part of the agenda for the interviews. The ideas generated by the many might spark the thoughts of the interviewee and lead to more productive discussions. Unfortunately, because the interview has only one person generating ideas, it is likely to provide less quantity of requirements than a workshop. On the other hand, because the interviewee is likely to be in a higher leadership position, the requirements probably will be more important than those generated at a group workshop.
The disadvantage with interviews is that communication of the results is not as easy as those for workshops. After a workshop, all the participants know the results immediately and most likely will begin talking about them to their peers and their management team. After an interview, you simply have a set of notes and need to work hard to get the ideas generated out to others. It is quite possible that a single idea heard only in an interview doesn’t represent the wishes of the organization at all. In fact, many times I’ve had ideas from one interview directly conflict with ideas from a separate interview. In this case, it is even more important to get the notes out for review to determine which ideas should be turned into legitimate requirements.
Whether you use a workshop, a road show, storyboards, or individual interviews, one of the most important techniques in soliciting requirements is to loop back and make sure you’ve accurately and completely captured what you heard. Certainly this involves documenting the requirements (more on that in a moment), but more importantly it involves reviewing the documents with the original sources. There is nothing quite as satisfying as being understood. Accurately capturing and playing back the requirements you hear will go a long way toward building your support base among the stakeholders. On the flip side, there is nothing quite as alienating as being misquoted and left feeling misunderstood. Always take time to put the requirements in writing and validate that you captured them accurately.
How to Document Requirements
At first glance, it might seem from the previous discussion that requirements are simply meeting notes. I’ve left the impression that by listening to lots of conversations and keeping careful notes, you will have created a workable set of requirements. It is now time to correct that misconception. To really be usable and helpful, requirements should be documented more carefully than just as a set of notes. This section describes some of the best practices in documenting requirements and helps you to move from notes to a set of specific requirements on which you can build a project.
Levels and Categories
A simple list of requirements, starting from the first thing you hear and ending with the last thing someone asks for, is probably the most inefficient way to document your requirements. You need a way to organize information that will be helpful in managing the requirements later. Most requirements systems feature at least some notion of levels and some idea of categories. Levels indicate the degree of specificity of a requirement, and categories are used to group requirements along architectural lines. The following sections deal with requirement levels and categories.
Level indicates the degree of generality or specificity of a requirement. Business requirements typically are at the highest level and express general needs about what the business functions of configuration management will be. A business requirement might say “Each update to the CMDB must be traceable to a specific request for change.” This is general in several ways: it defines a policy statement, it leaves the notion of “traceable” open to further definition, and it allows for many different implementations through either processes or tools. This concept of business level requirements generates much confusion because it seems to violate the earlier rule that requirements should be unambiguous. In reality, however, there is a difference between a requirement that is general and one which is ambiguous. An ambiguous requirement can be interpreted in different specific ways, whereas a general requirement doesn’t provide details but also doesn’t suggest multiple interpretations. The distinction isn’t all that important in practice because business requirements are always made more specific by requirements at lower levels.
The next level of requirements is typically the “system” level, where most of the overall details of the total configuration management project are defined. These requirements should be more specific than the business requirements and will necessarily be more numerous. System requirements normally are defined at a level of detail that allows the implementation team to fulfill them in some verifiable way. Adding to the earlier example, here is a system requirement that would be at a lower level than the business requirement: “When a user attempts to update a configuration item from the Update screen, the system shall read the value of the RFC field. If the value is not valid in the systemRFC table, the system shall respond with a message indicating that updates are not allowed without a valid RFC.” This requirement is clearly at a lower level of detail than the business requirement that spawned it, but it is also a direct result of something the business requirement asks for. It is important that requirements at a lower level be directly traceable to higher level requirements.
In documenting system requirements, you might decide that one or more pieces of the overall architecture need to be defined at a still lower level of detail. This can lead to the third level of requirements, often called component requirements. Not every project will have component requirements, and even when you choose to use component requirements, not every component will require them. Component requirements are most often useful for components that must interface with people or tools outside of your configuration management team. User interfaces and external tool integration points are examples of situations that frequently require component level requirements.
Now that we understand requirement levels, categories are much simpler. When speaking of requirements, the best practice is to split categories along architectural lines. If your project will involve building a complete configuration management solution from nothing, your architectural categories might include process requirements, tool requirements, organization requirements, and data requirements. If, on the other hand, your job is to develop the next release of a configuration management tool, the categories might be user interface, database, external interfaces, and reporting. The essential thing is that you define a set of categories that will make sense to everyone working on the project. After the requirements are organized by categories, the implementation project plan, the testing cycle, and even deployment can be organized along the same lines. This kind of architecture-driven project helps to ensure that no tasks are missed and all requirements are fully implemented, tested, and deployed.
Documentation Techniques
There are a couple of special purpose requirements documentation techniques that deserve special attention. The first is called use cases. Use cases essentially are sequential descriptions of how something is supposed to work. They describe how a person or tool (called the actor) relates to the thing being built. Use cases are especially good for describing transaction- or workflow-oriented requirements because they help everyone understand the flow and sequencing better than a simple list of system or component requirements. Many volumes are written about using the use case technique in documenting requirements, but the basic steps are fairly simple:
- Document who the actor is.
- Describe the normal or typical set of steps that happen in order.
- Think about any deviations from the normal steps, and document those paths.
- Go back and flesh out the use case with enough text to make it a useful requirement set.
The other special technique that can be used to document requirements is a prototype. Especially in the case of defining web pages or other user interface elements of the configuration tools, you can often start with a “low fidelity” prototype, which is no more than a few slides put together in a presentation. Where your project team has the skills, you can go further to a “high fidelity” prototype by actually using rapid prototyping tools. The process of building a prototype, getting feedback, modifying the prototype, and repeating until all the stakeholders are satisfied is a great way to document exactly what the interface is supposed to look like. In this case, it really is true that the picture is worth a thousand words.
When to Stop Gathering Requirements
All this focus on gathering requirements might make it seem that you are never going to actually implement configuration management. In reality, the requirement process can take several weeks to several months, depending on the maturity of thinking around configuration management in your enterprise. If your stakeholders know about configuration management and understand what the project should accomplish in principle, you will get to the end of requirements relatively quickly. They probably already know what they want, and your mission simply will be to capture it on paper and move on to the analysis phase.
In some cases, however, the requirements gathering process must be combined with an education process. In this situation, the best thing you can do is to get together whatever experts you have to help you prepare completely. Workshops, storyboard sessions, and interviews that you conduct will need to be much more basic to start out. In some cases you may need to have an initial session to establish the subject matter in people’s minds, and then a follow-up session where you can actually gather requirements. In the questions you ask and the categories you choose, you are teaching the organization to have a common vocabulary and a consistent idea of what configuration management is and does. If that is your situation, don’t be afraid to let the requirements gathering stage go on for several months.
But how do you know when you are finished with requirements? That is actually a rather difficult question. The simplest answer is that when you’ve asked everyone you can think of and none of them have new ideas, you’re finished getting requirements. But we all know that someone who ran out of ideas yesterday might think of something new tomorrow. Requirements can’t be a boundless process. If the requirements gathering phase lasts too long, your stakeholders will get the impression that your project will take too long to return significant value, and may even decide that there are higher priorities than endless requirements gathering. On the other hand, if you cut off the requirements gathering too soon, you run the risk of significant stakeholders feeling their voice wasn’t heard and thus withholding support from the project. A delicate balance is clearly required.
The best practice is to gather the requirements by level, and let each level mature appropriately. This means that you first gather the business requirements and steadfastly refuse to talk about lower-level details until everyone believes they have exhausted all the general requirements. Make sure to include reporting, administration of tools, data sources, procedures, organizational roles, and everything else mentioned in this book to cover the entire waterfront. When you’re convinced that you’ve achieved the full breadth of coverage and have all the business requirements documented, go through a few reviews. First, review with the project team and see whether any new ideas emerge. Then review with your project sponsors—the people who are funding your project and making key decisions about whether to go on. Finally, review with the widest possible list of interested and affected stakeholders. At each stage of the review, look for new requirements. This isn’t the time for rewording or redefining the existing requirements—that comes in the analysis phase. By the time you’ve concluded those three reviews, you should have a fairly mature set of business requirements and everyone will be more than ready to dig in at a lower level.
Next, define the system requirements category by category. Decide at this stage whether you need component requirements or not, but don’t start defining them until you’ve finished with all the requirements that apply at the system level. Again, go through a series of reviews, although the reviews might need to be split into multiple meetings to accommodate the larger number of requirements anticipated at this level. The lower-level requirements will dictate that more people from the implementation teams are involved to really understand whether the requirements are unambiguous enough to be directly implemented. The review process lets the system requirements mature, and as they do, people will decide they have no further system-level requirements to add. Repeat the process again for each set of component requirements you want to define. Eventually you’ll get the feeling of a solid, completed set of requirements. This is admittedly more art than science, but it does become easier with practice.
Gathering and documenting requirements is a lot like making popcorn in the microwave. You start simply with setting up things. Pretty soon things are popping along nicely, and before you know it requirements are springing up everywhere. But after a bit, the pace slows and not many new requirements are popping. With enough experience, you’ll learn to let the last ideas mature without waiting too long and burning the popcorn.
Analyzing
Congratulations! By now you’re the proud owner of at least a couple articulate, well-written requirements documents. That’s great work. The next step is to turn those documented requirements into a configuration management organization running a configuration management process to collect and manage configuration management data. The best way to do that is to spend some time in requirements analysis.
Analysis can conjure a picture of endless studies conducted by countless committees. That isn’t at all what is intended here. Requirements analysis is simply the act of deciding the right order to approach things and breaking large endeavors into smaller projects to demonstrate small steps toward the overall goal. This section describes several techniques that will enable you to clearly understand how to build a workable configuration management service, whether in one single project or as part of a multiyear program.
Requirements Prioritization
When people document requirements, they tend to end up with lists of individual functions that have various degrees of importance to the organization. The first thing you want to do is organize the requirements by importance. This is called requirements prioritization, and is the first stage of analysis.
To allocate requirements to different priorities, you need to define what the different values can be. Some like to use “low,” “medium,” and “high.” Others choose “deferred,” “optional,” and “required,” or perhaps “possible,” “important,” “critical,” and “vital.” The labels you choose to use are not nearly as important as the policies behind using those labels. If this is a new step to you, and you are unable to find any requirements that have been prioritized in your organization before, do everyone a favor and take time to document the policy around choosing different priorities. It sounds trivial, but having a consistent way to decide between a high priority and a medium priority will save your project and future projects hours of time in haggling and debating. If clear policies already exist for your organization, then simply review the policy to make sure it fits the context of your requirements.
The next issue is to decide who gets to specify the priorities. Sometimes a “one person, one vote” approach works well. If you feel there may be significant conflicts in the priorities of different groups, you might want to establish a more sophisticated weighting system allowing more powerful groups a stronger voice in the prioritization. The team that doesn’t need a vote is the implementation team—they will get their say in the next phase of analysis when they specify how difficult the requirements will be to implement.
Requirements should be prioritized by levels, starting with business requirements. After all the business requirements have been prioritized, next prioritize all the system requirements that relate to each business requirement. For example, suppose you have business requirements A, B, and C. Business requirement A has system requirements a and b; requirement B has system requirements c, d, and e; and requirement C has system requirements f, g, h, i, and j. Once you’ve determined that A and C are high priority and B is medium priority, then determine which of a and b is the highest priority and which of f through j is highest priority. This seems obvious, but it is surprising how often people spend time prioritizing dozens or even hundreds of detailed system requirements without ever realizing that the business requirement is low priority and probably will not get implemented in the coming project.
A common problem is that everything seems a high priority. You may end up with 5 percent low priority requirements, 15 percent medium priority, and 80 percent high priority. This can happen if you have weak or nonexistent policies for choosing priorities. If you find your requirements analysis taking this direction, you simply insist that instead of several priority categories, you use a strict numerical ranking. Take the entire highest priority category and rank them from the most urgent to the least urgent. This enforces the idea that some requirements have a higher priority than others.
A second issue that can arise is that people will be hesitant to use the lowest priority category because they believe this is equivalent to making a decision that the requirement won’t be fulfilled. This isn’t so, because prioritization is only the first part of the analysis phase. Many times smaller requirements at a lower priority will get implemented before larger requirements at a higher priority. Just because a requirement gets assigned to a lower priority does not mean it won’t get built into your configuration management project.
Sizing the Requirements
Knowing the priority of the requirements gives you half the information you need to properly scope your configuration management project. The other half of the equation is an estimate on how long it will take to fulfill each requirement. This estimate is referred to as the size of a requirement. When you know the size and priority of each requirement, you can assemble these pieces together into a coherent plan to meet the most important requirements in the shortest time possible while expending the least amount of resources possible.
In order to assign the correct size to each requirement, you need to turn over the requirements to the team responsible for implementing them. For tools requirements, this might be a development or customization team. For process requirements, this is most likely a process engineer. For organization requirements, you might need an HR specialist who can estimate how long it will take to find people to fill the roles indicated in the requirements. At this early stage, these estimates are not commitments to specific days in a project schedule, but indicators of the level of effort that will be needed for each requirement.
Ask the teams doing these estimates to provide only a rough order of magnitude at this point. Remember that some of the requirements being estimated will not be implemented in the first release, or possibly not at all, so you don’t want someone spending hours getting to a very accurate estimate of how long it will take to implement. A rough guess is all you want during requirements analysis phase, and a more detailed estimate will come during project planning.
Be sure to get the estimates back in consistent units. Most often this means asking everyone to estimate the number of days required to fulfill the requirements they are sizing. To provide estimates as a number of hours is probably too fine grained, but going to weeks or months will end up having too many requirements with exactly the same size. If days of effort will be difficult or expensive to estimate, you can also choose to start by categorizing the requirements into tiny, small, medium, large, and extra large. Should too many requirements fall into the same sizing category (such as all of them are medium), you can do more specific sizing on just those requirements.
If your organization is not accustomed to providing estimates, it would be best to document some policies in this area as well. For example, if a developer is providing an estimate for writing a bit of code, should they also include hours for testing that code? Or will you get a separate testing estimate from someone else? Should hours be included in the estimates for reviews of the work products, such as code reviews and document reviews? Making the wrong assumptions about what should be included in the size of a requirement will result in an inflated or deflated size when compared to other estimates. Simple policy statements help to avoid these kinds of inconsistencies and mistakes in sizing requirements. Those mistakes will lie hidden until the actual project execution uncovers them and pays for them with the realization that the schedule will slip or more work could have been done in the time allotted.
Deriving Additional Requirements
Many times in the course of analyzing requirements, the experts will discover that something is unclear or missed entirely. This happens most frequently in the estimation phase, where deep subject matter experts are looking at the requirements more critically. This isn’t a problem, but it definitely should be addressed when found. When something appears unclear, or additional details need to be decided, the best way to handle this is by adding more requirements, called derived requirements. Rather than springing from workshops or interviews, they come from the implementation team and serve to fill in any gaps in the original requirements documents.
Rather than simply slipping them in, these requirements should be integrated into the requirements documents through a controlled change process. The stakeholders who helped to define and prioritize the requirements should get a chance to review the proposed new requirements before they are adopted officially into the documents. This prevents an implementation team from “gold plating” the requirements and thus delivering capabilities that actually are not needed. The change can be proposed by the expert finding the omission, and a small core group of stakeholders can quickly review and determine whether to add more detail.
Most often these requirements that are derived later will have the same priority and category as the requirement originally being examined. As an example, suppose you find a system requirement stating “The CMDB shall store a name for every configuration item.” Our customization team is estimating the amount of time it will take to make our tool satisfy this requirement when they realize that they will need to know how many characters a name can be, whether the name should allow mixed case, and if any special characters like underscores and hyphens can be part of a name. The team leader proposes an additional requirement that says “The name of a configuration item shall be no more than 40 characters long, and shall be made of upper- and lowercase letters and numerals, but no other characters.” The priority and category of the new requirement would be the same as the original requirement, and the two should be linked to indicate that one cannot be done without the other. An alternative is to change the wording of the original requirement, in essence making it more specific and measurable.
The process of deriving additional requirements can happen throughout the analysis cycle. The more eyes you have on the requirements, the greater likelihood that these kinds of insertions will occur—this is a good thing. Remember that the purpose of analyzing the requirements is to decide what will eventually get built by the configuration management project. Greater clarity in analysis now will always lead to less cost in implementation later.
Gaps occasionally are found even after the analysis phase has been completed and the requirements are agreed to. When additional requirements are necessary after the start of the project, they should be introduced through a carefully controlled change process which makes sure that everyone is informed of the change. Major shifts, such as adding additional business requirements, need to be reviewed with your project sponsor because they will most likely impact the project schedule and budget, whereas minor changes to the content of system or component requirements usually can be handled by the project team directly during implementation. Either way, the stakeholders should be made aware of the changes, no matter how subtle.
Gaining Project Approval
The central goal of requirements analysis is to produce an exact project scope that can get funded so you can move forward. Looking back at this chapter, you’ll realize you have quite a bit of information that can help you put together a recommended scope. You have notes from workshops and interviews, many of which will put context around what your stakeholders feel are the important groups of requirements. You have the reviewed requirements documents, consisting of a full set of everything that could possibly be done by your project. Most importantly, you have assigned a priority and a size to each requirement, and through the set of reviews you have confidence that you haven’t missed anything.
Using the information you’ve gathered, you now undertake the creative exercise of finding the right project scope. You’ve been given general outlines by your sponsor, but now you are going to get precise about exactly which business, system, and component requirements you will implement. More importantly, you’re going to decide which requirements you will not be implementing in the first configuration management project. Whether you’re developing a tool or implementing an entire service, you should always begin with the idea that there will be a second release. That is, always assume that you cannot implement all requirements in a single, monolithic project and that follow-up projects will be needed to completely fill all of the organization’s needs.
Many people like to set the scope based on a given set of resources over a specified period of time. In other words, how much can my implementation team of six people accomplish given a four-month project life? Using that scheme, you can simply look down the list of requirements by priority, putting in the highest priority ones that fit in the number of effort days allotted. When you have all the highest priority requirements in that will fit, look across the next highest priority set and see if any are small enough to still fit inside the box. Following this method will get you to a project that fits your predetermined criteria.
Other organizations prefer to work along functional lines. Here you look at your requirements lists by category, and which architectural function has been determined as the highest priority overall. After you’ve identified the highest priority functional set, you then include all the requirements needed to fully implement that function. Often you’ll find that you need to include requirements from other categories to truly implement the high priority function.
Whichever method you choose to assemble a “good” project, you will probably have some juggling to do. The more familiar you are with the requirement set, the better you’ll be able to do this juggling.
As an example, you might have documented a requirement for graphic visualization of relationships between configuration items. In the system requirements, you explored exactly what was needed and found that you need the ability to search for a single CI, and then show that CI at the center of a radial diagram with the various relationships in a circle around the single CI. This is a common requirement, and one that can be accomplished by several of the leading tools. In your organization, this requirement has been prioritized with a medium priority, and the estimate to fulfill the requirement has come back at 22 days of effort. At the same time, you have a requirement to produce essentially the same information in a list format, which has come back as a high priority but will take 30 days of effort.
You could choose to include neither requirement in your proposed scope, which would clearly make for a lower cost project with a shorter implementation time, but this would reduce the overall function provided to a level that might not be acceptable. You could choose to do both requirements, but at a higher cost in terms of resources and/or schedule. Or you could choose just one or the other presentation formats, citing the rationale that they really provide the same information. Using a decision-making process like this, the team should assemble an overall project scope, determining exactly which requirements will hold together to produce the right balance of function versus cost.
While the proposed scope is being assembled, don’t forget to document the rationale used to put it together. That rationale will help in selling the proposal to all of your stakeholders. Many of the questions that your stakeholders will have will already be covered because the team has considered and responded to them in assembling the project proposal. If you assembled the project using time and resource constraints, be sure to tell everyone what those constraints are. If you selected a set of functionality as the highest priority, document why those functions were chosen and how each requirement contributes to those functions. Logical and well-documented rationale will make the proposal much stronger than a simple list of requirements.
On one project, the approval of the scope came at a very bad time for me. Rather than travel to meet with the sponsor face to face, I settled for a conference call that I could squeeze into my schedule. The call seemed to go well, with the sponsor replying “OK” and “Yes” at all the appropriate points, so I thought the scope must have hit the mark. We went on to organize the project plan and start executing the project. Only later did we learn that I had missed some reports that our sponsor thought were the most crucial part of configuration management. Two months into the project, the sponsor introduced five new business requirements, essentially changing the entire shape of the project. This cost several hundred hours in reworking the plan, the budget, and even the design.
The moral of the story is that whenever possible, you should insist on a face-to-face meeting with your sponsor, and directly ask whether he or she is completely happy with the project.
After you’ve put together your specific list of requirements to be implemented and the rationale for why you’ve chosen those and excluded others, you’re ready to see your sponsor. This is a critical meeting for the entire implementation of configuration management. The sponsor certainly saw some value to the project to even let you go this far, but here is where your sponsor and key decision maker will measure your proposal against his or her own expectations. If your proposal disappoints those expectations, you’ll have long, difficult climb to get each subsequent part of the project supported and approved. On the other hand, if your sponsor believes you’re being too ambitious and doesn’t really believe you can accomplish everything you’ve promised, you’re going to suffer more scrutiny at each checkpoint. It is vital at this point that you get frank feedback on the proposed scope. If the scope isn’t satisfactory, ask for an opportunity to correct it and come back. There is nothing that can sabotage your implementation quite as thoroughly as a sponsor who seems to agree with the scope, but isn’t quite satisfied with it.
When the project scope has been defined by a set of solid requirements that have already been reviewed by the stakeholders and approved by the sponsor, you’ve built the strongest possible base for implementing configuration management.