Great business analysts are grown, not simply trained.
The job includes many soft skills that are more people-oriented than technical. An organization’s BAs likely will come from diverse backgrounds, which could include the business side, the IT side, and subject matter experts. Whatever their backgrounds, new BAs will have gaps in their experience, knowledge, and skill sets because of the unique bridging and communication-centric nature of this vital project role. This article looks at some of the skills and knowledge issues associated with business analysts who come to the job from various previous positions.
Anyone pursuing a career as a BA should study an inventory of relevant knowledge, such as the Business Analysis Body of Knowledge developed by the International Institute of Business Analysis (www.theiiba.org). I’ve developed a suggested business analyst job description (available from www.processimpact.com/goodies.shtml). All BAs should determine the job knowledge and skills that pertain to their situation, identify their own knowledge gaps, and actively seek the information that will let them do a first-rate job. Classroom training, eLearning courses, self-training, coaching, and practice will all be useful methods for bridging the gaps. New BAs also can benefit from mentoring from those who have more experience, perhaps in the form of an apprenticeship.
The Former User
Many corporate IT departments employ business analysts who migrated into that role following a career as an end user of business applications. These individuals have a solid understanding of the business and the work environment, and they easily can gain the trust of their former colleagues. They speak the user’s language. They know the existing systems and business processes.
On the downside, former users who are now in the BA role often have little understanding about software development and how to communicate with technical people. If they are not familiar with various analysis modeling techniques, they likely will express all requirements information in natural-language textual form. They might not appreciate the importance of specifying how the system should handle exception conditions, which is how you make a software application robust. Users who become BAs will need to learn more about the technical side of software development so they can represent information in the most appropriate forms for their multiple audiences.
Some former users believe that their understanding of what is needed is better than that of the current users, so they don’t solicit or respect input from those who will be using the new system. Recent users can be stuck in the here-and-now of the current ways of working, such that they don’t see opportunities to improve business processes with the help of a new information system. It’s also easy for a former user to fall into the trap of thinking of requirements strictly from a user interface perspective. Focusing on solution ideas can impose unnecessary design constraints from the outset and often fails to solve the real problem.
Despite these shortcomings, moving from a user position to a BA role can be a meaningful career option. The senior manager of a medical devices division in a large company once told me that he had a problem. “Two years ago I hired three medical technologists into my division to represent our customers’ needs,” he said. “They’ve done a great job, but they are no longer current in medical technology, so they can’t speak accurately for what our customers need today. What is a reasonable career path for them now?”
This manager’s former medical technologists might be ready to move into a BA role. Although they aren’t up on the latest happenings in the hospital laboratory, they can still communicate effectively with other med techs. Spending two years in a product development environment gave them a good appreciation for how product development works. They might need some additional training in requirements-writing techniques, but these employees have accumulated experience that could make them valuable analysts.
The Former Developer
Project managers who lack a dedicated BA often expect developers to fill the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development. The stereotypical geek isn’t the most socially adroit of human beings. A few developers have little patience with users, considering them a necessary evil to be dealt with quickly so the developer can hustle back to the real job of cutting interesting code. Of course, many developers recognize the criticality of the requirements process and are willing to work as analysts when necessary. Those who enjoy collaborating with customers to understand the needs that drive software development are good candidates to specialize in business analysis.
The developer-turned-analyst might need to learn more about the business domain. Developers can easily lapse into technical thinking and jargon, focusing on the software to be built instead of the users’ needs. Former developers also will benefit from training and mentoring in the soft skills that the best analysts master, such as effective listening, negotiation, and facilitation.
The Subject Matter Expert
In his book Effective Requirements Practices (Addison-Wesley, 2001), Ralph Young recommends having the BA be an application domain or subject matter expert, as opposed to being a typical user. As Young puts it, “SMEs can determine whether the requirements are reasonable, how they extend the existing system, how the proposed architecture should be designed, and impacts on users, among other areas.” Some product-development organizations hire expert users of their products with extensive domain experience into their companies to serve either as BAs or as user representatives.
One risk here is that the BA who is a domain expert might specify the system’s requirements to suit his own preferences, rather than addressing the needs of diverse user classes. SMEs sometimes strive for a high-end, all-inclusive system, when in fact a less comprehensive solution might well meet the needs of most users. It often works better to have a BA from the development team work with the SME, who then serves as a key user representative (product champion).
The Project Manager
These days I hear a lot of discussion juxtaposing the business analyst and project manager roles. There seems to be an expectation that the same people readily can perform both roles on a project, or that there is significant overlap between the roles. I don’t see it that way. I think both project management and business analysis are challenging tasks with their own bodies of knowledge. Certainly, there is some commonality in applicable soft skills and personality characteristics, such as the ability to foster collaboration and negotiation among stakeholders who might have conflicting interests. Activities like scoping and prioritization are also common to both roles. But there are some significant differences.
A project manager who takes on a BA role will likely need to learn more about how to ask the right kinds of questions of user representatives to elicit a robust set of requirements. He’ll also need to learn how to represent that requirements knowledge in various forms, including well-crafted natural language requirement statements and graphical models. Conversely, a BA who picks up project management tasks may need to learn about estimation, planning risk management, resource allocation, and metrics. While a close partnership between a project manager and a business analyst is important to project success, anyone who is thrust from one role into the other should identify and fill crucial gaps in his knowledge and skills.
I believe that people can become good BAs regardless of their background, provided they have the right personality for the job and an appropriate combination of skills, knowledge, and experience. It doesn’t happen simply by decree or by desire, though. All novice BAs need to be honest about the gaps in their background so they can ramp up to full effectiveness quickly.
The first article in this series described the critical role of the business analyst in bridging the communication gap between business and IT, understanding project scope, and asking meaningful questions during requirements elicitation. This concluding article continues by exploring several additional contributions that BAs make to a software project.
Prioritize Early and Often
Requirements development is an iterative and incremental process, proceeding from fuzzy notions to detailed specifications a layer at a time. If you’re facilitating an elicitation workshop, keep the discussion focused on the right level of abstraction for that day’s objectives. Don’t let the participants get bogged down in excessive detail or premature system design. It can be valuable to sketch out possible user interface screens or build prototypes to clarify requirements. However, diving deeply into design too early can lead to a system that fails to meet the user’s actual needs.
It’s discouraging to realize at crunch time that everything the team has left to do is essential, while they’ve already implemented some features that weren’t really that important. BAs must work with customers to define the priorities for requested product features, so the team can build the most critical functionality in the early iterations. Your job as a BA includes facilitating negotiation between the various stakeholders to ensure that the team makes sensible priority decisions.
Early in the project, identify the various user classes that might contribute requirements. You’ll need to understand which user classes are favored, which (if any) are disfavored, and which groups of users won’t have input to the product’s requirements. The favored user classes typically take precedence if you encounter conflicts in the requirements or priorities presented by different user classes.
Next, work with appropriate representatives of each user class to identify their major use cases. Performing a first-cut prioritization on the use cases will help you determine which ones to explore in detail early on. The top priority use cases are those that are the most important (capabilities the users really need) and the most urgent (capabilities the users need right away). The users might elect to implement only core portions of certain use cases in the initial release or iteration, leaving enhancements for later. Alternatively, they might opt to initially implement the full functionality of a small set of use cases. Understanding the logical dependencies among the requirements will let you determine whether some high-priority requirements should be delayed. Sometimes architectural constraints demand that certain functionality be implemented first.
Create a Collaborative Environment
Software development sometimes is characterized by strained relationships among developers, users, managers, and marketing. The parties may not trust each other’s motivations or appreciate each other’s needs and constraints. In reality, though, the producers and customers of a software product share some common objectives. For information systems development, all parties work for the same company and benefit from improvements to the corporate bottom line. For commercial products, developers and marketing should strive to meet the purchasing customers’ needs, so they will buy more products and rave to their friends. And contract developers should try to make the client happy to get repeat business. A win/win outcome means customers are delighted with the product, the developing organization is happy with the business outcomes, and the development team members are proud of the good work they did.
Achieving a win/win outcome requires honesty. Sharing all relevant information among the stakeholders and telling the truth without blame or judgment promotes free and informed choices. Such a ideal environment isn’t always achievable. In fact, none of my suggestions are likely to work if you’re dealing with truly unreasonable people.
Defining business requirements early in the project will clarify the prospective benefits for both customers and the developing organization. The participants also need to be honest about functionality costs and project constraints. If you think the customer’s cost or schedule expectations are unrealistic, say so and explain your reasoning. Considering the costs will help the stakeholders make sensible business decisions to achieve the maximum value within the existing resource, time, and technology constraints.
It’s not unusual for a BA to solicit input from users only to hear, “I don’t have time to talk to you. You should know what I need.” However, software success is most likely when the BA can forge a collaborative relationship with key stakeholder representatives. Users might hesitate to participate in requirements exploration until they know exactly what you expect from them. Tell your customer collaborators what you need from them so they know why their input is so vital. A vision and scope document will help you identify the right users to talk to and will give them a clear understanding of what the project is trying to achieve.
Insufficient user involvement is well established as a leading cause of software project failure. Point this out to users or managers who don’t want to spend time on requirements discussions. Remind your customers of problems they’ve experienced on previous projects that you can trace back to inadequate user involvement. You can’t afford to keep rebuilding or discarding systems that don’t measure up because the user needs weren’t sufficiently understood. If customers won’t commit to reaching a shared understanding of their requirements, the development organization might be better off avoiding the project. Otherwise, the outcome might well be lose/lose.
Hone Your Skills
The business analyst provides the essential function of bridging the understanding and perspective gap that lies between customers and developers. A competent BA must combine communication, facilitation and interpersonal skills with some technical and business domain knowledge. Even a dynamite programmer or a system-savvy user needs suitable preparation before serving as a BA. The following capabilities are particularly important:
- Facilitation techniques, to lead elicitation workshops.
- Interviewing techniques, to talk with individuals and groups about their needs.
- Listening skills, to understand what people say and to detect what they might be hesitant to say.
- Writing skills, to communicate information effectively to users, managers and technical staff.
- Organizational skills, to make sense of the vast array of information gathered during elicitation and analysis.
- Interpersonal skills, to help negotiate priorities and resolve conflicts among project stakeholders; domain knowledge, to have credibility with user representatives and converse effectively with them.
- Modeling skills, to represent requirements information in graphical forms that augment natural language text.
An effective BA has a rich toolkit of tolls and techniques at his fingertips and knows when—and when not—to apply each. My book Software Requirements, Second Edition (Microsoft Press, 2003) describes more than 40 requirements engineering “good practices.”
There’s no substitute for experience, though. One of my consulting clients discovered that they could inspect requirements specifications written by experienced BAs twice as fast as those written by novices because they contained fewer defects. In contrast, another organization asked each developer to write the requirements for the system components for which he was responsible. The result was specifications having wildly divergent styles, organization, and quality. This made it hard for developers to review and use each other’s specifications. A third organization appointed as BAs several developers for whom English was not their native language, while yet another expected its users to write up their own requirements. It’s hard enough to write good requirements when you do it for a living, let alone if you do it just once in a while or in a language in which you aren’t completely proficient.
Requirements for a software product aren’t just lying around waiting for someone wearing a hat labeled “BA” to collect them. At best, requirements exist in the minds of users, visionaries, and developers, from which they must be gently extracted and massaged into a usable form. A talented BA can guide the process to help users understand what they really need to meet their business needs and help developers satisfy those needs. Few project roles are more difficult than that of the business analyst. Few are more critical.
Software managers sometimes assume that every talented programmer is also proficient at interviewing customers and writing requirements, without any training, resources, or coaching. This isn't a reasonable assumption. Like testing, estimation, and project management, requirements engineering has its own skill set and body of knowledge. Unfortunately, computer science curricula often emphasize programming-related knowledge over other software life cycle activities. Self-study and on-the-job learning often neglect softer skills such as those needed in requirements engineering, unless you’re specifically studying in pursuit of a professional business analyst certification.
The role of the business analyst is critical to a software project. Many organizations expect developers or project managers to handle this vital function on their own. And even if a project team does include dedicated analysts, their skills might not be up to the task. Too often, I meet BAs who have had little training in how to perform their job and who have few books or tools available to help them. BAs who come from a user background may lack technical understanding, while those who migrated from the IT world might not understand the user’s business domain and terminology. A BA provides a specialized capability that can make the difference between a project that succeeds and one that struggles. In this two-part series, I describe several characteristics and practices of successful business analysts.
Bridge the Communication Gap
The BA is a communication middleman, bridging the gap between vague customer notions and clear specifications. The BA must first understand the user’s real needs and then define a set of functional requirements and quality goals that allow developers to build and testers to verify the system. To be an effective BA, become proficient in all forms of communication, including listening, speaking, and writing. As you interact with executive project sponsors, marketing, and user representatives, understand their objectives for the proposed system and their concerns about the business and the application. Use the vocabulary of the application domain, rather than forcing your customers to understand computer jargon.
Take the time to learn about your customer collaborators and understand how they prefer to communicate. Watch for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal filter of understanding on what you hear the customers say. Keep one of my axioms of software development—and life, for that matter—in mind: The customer is not always right, but the customer always has a point. You must understand and respect those points, so they can be appropriately addressed in the product.
Try to understand the users’ implicit expectations about the system’s characteristics, such as performance, usability, efficiency, and reliability. Companies sometimes make products that fully meet the functional needs, only to discover that users hate it because it doesn’t work like they expect. When users declare that the system must be “user-friendly,” they have a mental image of what that means to them. As a BA, your job is to understand the intent behind each such expectation, so you can translate something vague and subjective like “user-friendly” into goals the developer can satisfy. One technique is to ask users what would constitute unacceptable performance, usability, or reliability.
Requirements development should lead to an understanding, shared by the various stakeholders, of the system that will address the customer’s problem. The BA is responsible for writing requirements that clearly express this shared understanding. Writing documents that customer representatives can understand and verify, while unambiguously conveying precise functional and nonfunctional requirements to the developers, is a tightrope walk. A single requirements specification might not meet both needs.
In requirements discussions, users often bring up fragments of functionality (“I need to be able to sort the list alphabetically”), quality characteristics (“this system has to be a lot more reliable than the old one”), or solution ideas (“then I select the state where I want to send the package from a drop-down list”). Don’t discard these bits of information because they convey part of what the user has in mind. However, I prefer to focus the early requirements discussions on the tasks users need to accomplish with the system: their use case. This helps you understand why the functionality or characteristics they describe are important. An understanding of user goals leads to the necessary functional requirements, which then leads to detailed user interface design.
Because use cases describe a user view of the system, users should understand them. However, use cases alone rarely convey enough detail to developers. One important BA task is to derive from each use case the specific functional requirements that, when implemented, will let users perform the tasks described in the use case. This means you must be able to communicate effectively in both directions: with users (the task view) and with developers (the technical view). To make sure you’ve been understood, have user representatives, developers and testers review your documents.
Color Inside the Lines
Begin your exploration of a new system’s requirements by defining the ultimate vision of what the product or application will be and do. Talk with the funding sponsor, marketing manager, or product visionary early on to define the project’s business objectives. This information helps you answer this critical question whenever someone suggests a new product feature: “Is this feature in scope?”
Teams rarely implement the ultimate solution in one pass. Instead, define the scope of the first release or iteration as a subset of the final product. Describe a growth path from the initial release toward realizing the ultimate vision through a series of staged releases or iterations. Also, document any known limitations or functionality that you don’t intend to build but which some stakeholder might expect to find. Expectation management is an important strategy.
Ask Revealing Questions
When working as a BA, you’ll need to actively facilitate discussions with users to pull out information that might otherwise go unstated. Ask questions to identify possible alternative ways a user might want to perform some task and to surface related tasks that the user representatives didn’t mention initially. If a user says “the default should be …”, he’s probably describing the normal flow for a use case. The phrase “but I should also have the option to …” suggests an alternative flow for that use case.
Users naturally focus on the system’s normal, expected behaviors. However, developers write much code to handle exceptions, so you should also search for possible error conditions that could arise and decide how the system should respond. If you don’t describe exceptions during requirements elicitation, either the developers will make their best guess at how to handle them, or the system will simply fail when a user hits the error condition. It’s a safe bet that system crashes aren’t in the user’s plans.
A BA isn’t just a scribe, recording whatever customers say they want. A creative BA can suggest ideas and alternatives to users during elicitation. When users truly can’t express what they need, watch them work and suggest ways to automate appropriate portions of the job. BAs can often think out of the box that limits the creativity of people who are too close to the problem being solved. Be careful to avoid gold-plating, adding extra functionality that just seems cool or somehow desirable. An effective BA must be able to think at multiple levels of abstraction. You should be able to generalize from a specific need expressed by one user to define a set of related needs that will satisfy many members of that individual’s user class.
Part 2 of this series will look at some of the other habits that help skilled BAs contribute to building great systems, including prioritizing requirements and creating a collaborative environment.
This article continues the exploration of requirements-related metrics that I began in Part 1, which looked at measuring product size and requirements quality.
Requirements Status
Track the status of each requirement over time to monitor overall project status, perhaps defining a requirement attribute to store this information. Status tracking can help you avoid the pervasive “ninety percent done” problem of software project tracking. Each requirement will have one of the following statuses at any time.
- Proposed (someone suggested it)
- Approved (it was allocated to a baseline)
- Implemented (the code was designed, written, and unit tested)
- Verified (the requirement passed its tests after integration into the product)
- Deferred (the requirement will be implemented in a future release)
- Deleted (you decided not to implement it at all)
- Rejected (the idea was never approved)
Other status options are possible, of course. Some organizations use a status of “Reviewed” because they want to confirm that a requirement is of high quality before allocating it to a baseline. Other organizations use “Delivered to Customer” to indicate that a requirement has actually been released.
When you ask a developer how he is coming along, he might say, “Of the eighty-seven requirements allocated to this subsystem, sixty-one of them are verified, nine are implemented but not yet verified, and seventeen aren’t yet completely implemented.” There's a good chance that not all these requirements are the same size, will consume the same amount of implementation effort, or will deliver the same customer value. If I were a project manager, though, I’d feel that we had a good handle on the size of that subsystem and how close we were to completion. This is far more informative than, “I’m about ninety percent done. Lookin’ good!”
Requests for Changes
Much of requirements management involves handling requirement additions, modifications, and deletions. Therefore, track the status and impact of your requirements change requests. The data you collect should let your team answer questions such as the following:
- How many change requests were submitted in a given time period?
- How many of these requests are open, and how many are closed?
- How many requests were approved, and how many were rejected?
- How much effort did the team spend implementing each approved change?
- How long have the requests been open on average?
- On average, how many individual requirements or other artifacts are affected by each submitted change request?
Monitor how many changes are incorporated throughout development after you baselined the requirements for a specific release. Note that a single change request potentially can affect multiple requirements of different levels and types (user requirements, functional requirements, nonfunctional requirements). To calculate requirements volatility over a given time period, divide the number of changes by the total number of requirements at the beginning of the period (for example, at the time a baseline was defined):
The intent is not to try to eliminate requirements volatility. There are often good reasons to change requirements. However, we need to ensure that the project can manage the degree of requirements changes and still meet its commitments. Changes become more expensive as the product nears completion, and a sustained high level of approved change requests makes it difficult to know when you can ship the product. Most projects should become more resistant to making changes as development progresses, meaning the trend of accepted changes should approach zero as you near the planned completion date for a given release. An iterative development approach gives the team multiple opportunities to incorporate changes into subsequent iterations, while still keeping each iteration on schedule.
If you receive many change requests, that suggests that elicitation overlooked many requirements or that new ideas keep coming in as the project drags along month after month. Record where the change requests come from: marketing, users, sales, management, developers, and so on. The change request origins will tell you who to work with to reduce the number of overlooked, modified, and misunderstood requirements.
Change requests that remain unresolved for a long time suggest that your change management process isn’t working well. I once visited a company where a manager wryly admitted that they had enhancement requests that were several years old and still pending. This team should allocate certain of their open requests to specific planned maintenance releases and convert other long-term deferred change requests to a status of rejected. This would help the project manager focus the team’s energy on the most important and most urgent items in the change backlog.
Effort
Finally, I recommend that you record the time your team spends on requirements engineering activities. These activities include both requirements development (getting and writing good requirements) and requirements management (dealing with change, tracking status, recording traceability data, and so on).
I’m frequently asked how much time and effort a project should allocate to these functions. The answer depends enormously on the type and size of project, the developing team and organization, and the application domain. If you track your own team’s investment in these critical project activities, you can better estimate how much effort to plan for future projects.
Suppose that on one previous project, your team expended ten percent of its effort on requirements activities. In retrospect, you conclude that the requirements were too poorly defined and the project would have benefited from additional investment in developing quality requirements. The next time your team tackles a similar project, the project manager would be wise to allocate more than ten percent of the total project effort to the requirements work.
As you accumulate data, correlate the project development effort with some measure of product size. The documented requirements should give you an indication of size. You could correlate effort with the count of individually testable requirements, use case points, function points, or something else that is proportional to product size. As Figure 1 illustrates, such correlations provide a measure of your development team’s productivity, which will help you estimate and scope individual release contents. If you collect some product size data and track the corresponding implementation effort, you’ll be in a better position to create meaningful estimates for similar projects in the future.
Figure 1. Correlating requirements size with project effort gives a measure of team productivity. Each point represents a separate project.
Some people are afraid that launching a software measurement effort will consume too much time, time they feel should be spent doing “real work.” My experience, though, is that a sensible and focused metrics program doesn’t take much time or effort at all. It’s mostly a matter of developing a simple infrastructure for collecting and analyzing the data, and getting team members in the habit of recording some key bits of data about their work. Once you’ve developed a measurement culture in your organization, you’ll be surprised how much you can learn from the data.
Disciplined software organizations collect a focused set of metrics about each of their projects. These metrics provide insight into the size of the product; the effort, time, and money that the project or individual tasks consumed; the project status; and the product’s quality. Because requirements are an essential project component, you should measure several aspects of your requirements engineering activities. This two-part series, adapted from my book More about Software Requirements, describes several meaningful metrics related to requirements activities on your projects.
Product Size
The most fundamental metric is the number of requirements in a body of work. Your project might represent requirements by using a mix of use cases, functional requirements, user stories, feature descriptions, event-response tables, and analysis models. However, the team ultimately implements functional requirements, descriptions of how the system should behave under specific conditions.
Begin your requirements measurement by simply counting the individual functional requirements that are allocated to the baseline for a given product release or development iteration. If different team members can’t count the requirements and get the same answer, you have to wonder what other sorts of ambiguities and misunderstandings they’ll experience. Knowing how many requirements are going into a release will help you judge how the team is progressing toward completion because you can monitor the backlog of work remaining to be done. If you don’t know how many requirements you need to work on, how will you know when you’re done?
Of course, not all functional requirements will consume the same implementation and testing effort. If you’re going to count functional requirements as an indicator of system size, your analysts will need to write them at a consistent level of granularity. One guideline is to decompose high-level requirements until the child requirements are all individually testable. That is, a tester can design a few logically related tests to verify whether a requirement was correctly implemented. Count the total number of child requirements, because those are what developers will implement and testers will test. Alternative requirements sizing techniques include use case points and story points. All of these methods involve estimating the relative effort to implement a defined chunk of functionality.
Functional requirements aren’t the whole story, of course. Stringent nonfunctional requirements can consume considerable design and implementation effort. Some functionality is derived from specified nonfunctional requirements, such as security requirements, so those would be incorporated appropriately into the functional requirement size estimate. But not all nonfunctional requirements will be reflected in this size estimate. Be sure to consider the impact of nonfunctional requirements upon your effort estimate. Consider the following situations:
- If the user must have multiple ways to access specific functions to improve usability, it will take more development effort than if only one access mechanism is needed.
- Imposed design and implementation constraints, such as multiple external interfaces to achieve compatibility with an existing operating environment, can lead to a lot of interface work even though you aren’t providing additional new product functionality.
- Strict performance requirements might demand extensive algorithm and database design work to optimize response times.
- Rigorous availability and reliability requirements can imply significant work to build in failover and data recovery mechanisms, as well as having implications for the system architecture you select.
You’ll also find it informative to track the growth in requirements as a function of time, no matter what requirements size metric you use. One of my clients found that their projects typically grew in size by about twenty-five percent before delivery. Amazingly, they also ran about twenty-five percent over the planned schedule on most of their projects. Coincidence? I think not.
Requirements Quality
Consider collecting some data regarding the quality of your requirements. Inspections of requirements specifications are a good source of this information. Count the requirements defects you discover and classify them into various categories: missing requirements, erroneous requirements, unnecessary requirements, incompleteness, ambiguities, and so forth. Use defect type frequencies and root-cause analysis to tune up your requirements processes so the team makes fewer of these types of errors in the future. For instance, if you find that missing requirements are a common problem, your elicitation approaches need some adjustments. Perhaps your business analysts aren’t asking enough questions or the right questions, or maybe you need to engage more appropriate user representatives in the requirements development process.
If the team members don’t think they have time to inspect all their requirements documentation, try inspecting a sample of just a few pages. Then calculate the average defect density—the number of defects found per specification page—for the sample. Assuming that the sample was representative of the entire document (a big assumption), you can multiply the number of uninspected pages by this defect density to estimate the number of undiscovered defects that could still lurk in the specification. Less experienced inspectors might discover only, say, half the defects that actually are present, so use this estimated number of undiscovered defects as a lower bound. Inspection sampling can let you assess the document’s quality so that you can determine whether it’s cost effective to inspect the rest of the requirements specification. The answer will almost certainly be yes.
Also, keep records of requirements defects that are identified after the requirements are baselined, such as requirements-related problems discovered during design, coding, and testing. These represent errors that leaked through your quality control filters during requirements development. Calculate the percentage of the total number of requirements errors that the team caught at the requirements stage. Removing requirements defects early is far cheaper than correcting them after the team has already designed, coded, and tested the wrong requirements.
Two informative metrics to calculate from inspection data are efficiency and effectiveness. Efficiency refers to the average number of defects discovered per labor hour of inspection effort. Effectiveness refers to the percentage of the defects originally present in a work product that was discovered by inspection. Effectiveness will tell you how well your inspections (or other requirements quality techniques) are working. Efficiency will tell you what it costs you, on average, to discover a defect through inspection. You can compare that cost with the cost of dealing with requirements defects found later in the project or after delivery to judge whether improving the quality of your requirements is cost effective.
The second article in this series will address metrics related to requirements status, change requests, and the effort expended on requirements development and management activities.
In the previous two articles in this series I have shared some “cosmic truths” about requirements concepts in general and about how requirements affect the project stakeholders. This closing article in the series, adapted from my book More about Software Requirements, presents four more universal truths regarding requirements specifications.
Cosmic Truth #7: The first question a business analyst should ask about a proposed new requirement is, “Is this requirement in scope?”
Anyone who’s been in IT for long has worked on a project that has suffered from scope creep. It is normal and often beneficial for requirements to grow over the course of a project. Scope creep, though, refers to the uncontrolled and continuous increase in requirements that makes it impossible to deliver a product on schedule.
To control scope creep, the project stakeholders must first agree on a scope definition, a boundary between the desired capabilities that lie within the scope for a given product release and those that do not. Then, whenever some stakeholder proposes a new functional requirement, feature, or use case, the BA can ask, “Is this in scope?” To help answer this question, some project teams write their scope definition on a large piece of cardstock, laminate it, and bring it to their requirements elicitation discussions.
If a specific requirement is deemed out of scope one week, in scope the next, then out of scope again later, the project’s scope boundary is not clearly defined. And that’s an open invitation to scope creep.
Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialog.
Even an excellent requirements specification won’t contain every bit of information that developers and testers need to do their jobs. There will always be tacit knowledge that the stakeholders assume—rightly or wrongly—that other participants already know, along with the explicit knowledge that must be documented in the requirements specification. BAs and developers will always need to talk with knowledgeable users and subject matter experts to refine details, clarify ambiguities, and fill in the blanks. This is the rationale behind having some key customers, such as product champions, work intimately with the BA and developers throughout the project. The person performing the role of BA (even if this is one of the developers) should coordinate these discussions to make sure that all the participants reach the same understanding so the pieces all fit together properly. A written specification is still valuable and necessary, though. A documented record of what stakeholders agreed to at a point in time—a “group memory”—is more reliable than human memories.
You need to include more detail in the requirements specifications if you aren’t going to have opportunities for frequent conversations with user representatives and other decision makers. A good example of this is when you’re outsourcing the implementation of a requirements specification your team created. Expect to spend considerable time on review cycles to clarify and agree on what the requirements mean. Also expect delays in getting questions answered and decisions made, which can slow down the entire project.
This very issue was a major contributing factor in a lawsuit I know of between a software package vendor and a customer. The vendor allowed no time in the schedule for review following some requirements elicitation workshops, planning to begin construction immediately. Months later, numerous key requirements issues had not yet been resolved and the project status didn’t remotely resemble the project plan.
Cosmic Truth #9: The requirements might be vague, but the product will be specific.
Specifying requirements precisely is hard! You’re inventing something new, and no one is exactly sure what the product should be and do. People sometimes are comfortable with vague requirements. Customers might like them because it means they can redefine those requirements later on to mean whatever they want them to mean. Developers sometimes favor vague requirements because they allow the developers to build whatever they want to build. This is all great fun, but it doesn’t lead to high-quality software.
Ultimately, you are building only one product, and someone needs to decide just what that product will be. If customers and BAs don’t make the decisions, the developers will be forced to. This is a sign that the key stakeholders are abdicating their responsibility to make requirements-level decisions, leaving those decisions to people who might know far less about the problem or the business.
Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping. A valuable adjunct to simply specifying each requirement is to define fit criteria that a user or tester could employ to judge whether the requirement was implemented correctly and as intended. Attempting to write such fit criteria will quickly reveal whether a requirement is stated precisely enough to be verifiable. See Suzanne Robertson and James Robertson, Mastering the Requirements Process, Second Edition (Addison-Wesley, 2006) for more information about fit criteria.
Cosmic Truth #10: You’re never going to have perfect requirements.
Requirements are rarely finished or complete. There is no way to know for certain that you haven’t overlooked some requirement, and there will always be some requirements that the BA won’t feel are necessary to record. Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities.
Striving for perfection can lead to analysis paralysis. Analysis paralysis, in turn, can have a backlash effect. Stakeholders who have been burned once by a project that got mired in requirements issues sometimes are reluctant to invest in requirements development at all on their next project. This is an even quicker path to failure.
You don’t succeed in business by writing a perfect specification. From a pragmatic perspective, strive to develop a set of requirements that are good enough to allow the team to proceed with design, construction, and testing at an acceptable level of risk. The risk is the threat of having to do expensive and unnecessary rework. Have team members who will need to base their own work on the requirements review them to judge whether they provide a suitably solid foundation for that subsequent work. Keep this practical goal of “good enough” in mind as you pursue your quest for quality requirements.
996Z5SDQNRAX
This is the part 2 of an article on how to achieve successul process improvement programs. These keys are based on my own experience plus interviews that I conducted with industry analysts and consultants. I hope these help you have achieve a success with your process improvement efforts.
6. Create a process map for the current and ideal state
Many business processes today are in a sad state. Processes are fragmented across isolated functional departments. Processes are plagued by numerous organizational handoffs. Handoffs are the source of non-value added work, causing delays, errors and inflexibility. These handoffs result in
- People involved in the process not understanding the whole process from end to end.
- Process or sub-processes are invisible, unmeasured, and unmanaged.
- No one has accountability or management responsibility for end-to-end results.
- Different business units or departments view each other with suspicion.
Process mapping is a method for thoroughly understanding a business process. Process maps are used to gain an understanding of the current situation (“As Is”) and for documenting the ideal state (“To Be”). Activities discovered through process mapping reveal linkages among organizational resources and the products and services that are produced and delivered to customers. The process map should provide a detailed picture of the business process to facilitate meaningful improvements. Process maps provide a key tool for analyzing performance issues and for understanding the voice of the customer and supplier relationships.
7. Benchmark the current process
Organizations engage in benchmarking to understand how they are performing against other organizations. Comparisons may be with peers in like or similar industries or against world class organizations in other industries or other size organizations. The use of benchmarking provides a sense of urgency to change and find new ways to improve business processes.
To reduce costs, increase revenues, speed delivery, or increase customer satisfaction, companies must apply benchmark data to their processes. Benchmarking should be closely linked to organizational value propositions, core values, strategies, goals, objectives, tactics, and actions. Benchmarking can help an organization achieve operational excellence.
Enfocus Solutions Inc. strongly believes that benchmarking is an excellent tool that business analysts can use to improve business processes. Benchmarking is included as part of Enfocus Requirement Suite™ enterprise subscription.
8. Build knowledge management into the process
APQC, a best practice research organization, recently conducted a study on knowledge management. The study showed that to maximize the benefits of knowledge management, organizations must not only implement tools and approaches for knowledge sharing, but also embed those tools and approaches in the flow of employees’ daily routines. Employees should view locating and sharing knowledge as part of the way they work, not as separate add-on activities. That is, for knowledge management to be effective, it is must be integrated part of a business process.
A knowledge management focus is the next logical step for organizations to garner all the intellectual capital and institutional memory that resides in an organization. Knowledge management is finding the right information for the right people at the right time. Enterprises compete based on knowledge capital. Knowledge in business strategy, operations, and processes coupled with the skills and experience of knowledge-based workers enables organizations to better serve customers and be competitive. Knowledge management should be considered in all process improvement projects.
9. Many problems can be solved without IT support
Many managers and BPM teams still believe that buying the latest IT system, is the ‘magic bullet’ that will instantly solve all of their problems. However, it should be noted that often a well-designed business process supported with a simple and inexpensive automation, is much more effective than a business processes supported by large expensive enterprise systems.
It is important to keep in mind that successful business process improvement can be accomplished without any IT at all. For example, focusing on the items below can make a considerable difference in process efficiency.
- Reducing the number of hand-offs between people or organizational units.
- Eliminating waste.
- Removing non-value add activities.
- Using a less expensive resources to undertake an activity.
- Tackling the root cause of errors , for example providing forms that are easier for customers to complete, which cuts down on the number of incorrectly completed forms being received).
- Creating procedures to ensure that all staff do things consistently.
10. Get organizational buy-in
Without organizational buy-in, business process improvement projects are nearly always doomed to failure. Simply imposing a new way of working onto a business area seldom works and often results in extreme resistance from employees. This resistance often makes it very difficult for the project team to implement a new process, and usually results in people pretending that things have changed, while continuing to work in the same way they always have.
Proper organizational involvement is one of the big keys to successful business process improvement. Doing the following will significantly increase your chances of success:
- Asking workers for their opinions, and for their ideas for improvement (see number 4 above)
- Explaining to staff why things need to change (consider showing them benchmarking data).
- Being very open, and responding honestly to questions and concerns.
- Continuing to keep staff informed throughout the project.
- Having staff participate on the business process improvement project team.
I hope you have found these tips helpful. Please provide comments and sugestions of your own experience below.
The first article in this series presented three “cosmic truths,” realities about requirements that I’ve discovered to apply to virtually all software projects. This article continues with three more such insights, focusing on requirements and the project stakeholders.
Cosmic Truth #4: The interests of all the project stakeholders intersect in the requirements process.
Consultant Tim Lister once defined project success as “meeting the set of all requirements and constraints held as expectations by key stakeholders.” A stakeholder is an individual or group who is actively involved in the project, who is affected by the project, or who can influence its outcome. Figure 1 identifies some typical software project stakeholders. Certain stakeholders are internal to the project team, such as the project manager, business analysts, developers, and testers. Other stakeholders are external, including customers who select, specify, or fund products; users who employ the systems; compliance certifiers; auditors; and marketing, sales, and support groups. The business analyst performs a central communication role, being responsible for interacting with all these stakeholders. Further, the BA is responsible for seeing that the system being defined will be fit for use by all customers, perhaps working with a system architect to achieve this goal.
Figure 1.Some typical software project stakeholders.
Identify your key stakeholder groups at the beginning of the project. Then determine which individuals will best represent the interests of each group. You can count on stakeholders having conflicting interests that must be reconciled. They can’t all have veto power over each other. You need to identify early on the decision makers who will resolve these conflicts, and these decision makers must determine what their decision-making process will be. As my friend Chris, a seasoned project manager, points out, “I have found that there is usually one primary decision maker on a project, oftentimes the key sponsor within the organization. I don’t rest until I have identified that person, and then I make sure he is always aware of the project’s progress.”
Cosmic Truth #5: Customer involvement is the most critical contributor to software quality.
Various studies have confirmed that inadequate customer involvement is a leading cause of the failure of software projects. Customers often claim they can’t spend time working on requirements. However, customers who aren’t happy because the delivered product missed the mark always find plenty of time to point out the problems. The development team is going to get the customer input it needs eventually. It’s a lot cheaper—and a lot less painful—to get that input early on, rather than after the project ostensibly is done.
Customer involvement requires more than holding a workshop or two early in the project. Ongoing engagement by suitably empowered and enthusiastic customer representatives is a critical success factor for software development. Following are some good practices for engaging customers in requirements development (see my book Software Requirements, 2nd Edition for more information about these practices):
Identify user classes. Customers are a subset of stakeholders, and users are a subset of customers. You can further subdivide your user community into multiple user classes that have largely distinct needs. Unrepresented user classes are likely to be disappointed with the project outcome.
Select product champions. You need to determine who will serve as the literal voice of the customer for each user class. I call these people product champions. Ideally, product champions are actual users who represent their user-class peers. In some cases, though, you might have limited access to actual users, so you need to employ surrogates to speak for certain user classes to the best of their ability. Such surrogates might be subject matter experts or marketing personnel. When developers are forced into the position of trying to identify user needs, they often don’t do a great job.
Build prototypes. Prototypes provide opportunities for user representatives to interact with a simulation or portion of the ultimate system. Prototypes are far more tangible than written requirements specifications and easier for users to relate to. However, prototypes aren’t a substitute for documenting the detailed requirements. You also have to watch out for the risk that users who evaluate prototypes will conclude that the system is almost done and press the development team to release the prototype as a delivered product. This is usually a disaster.
Agree on customer rights and responsibilities. People who must work together rarely discuss the nature of their collaboration. The BA should negotiate with the customer representatives early in the project to agree on the responsibilities each party has with respect to the requirements process. An agreed-upon collaboration strategy is a strong contributor to the participants’ mutual success.
Cosmic Truth #6: The customer is not always right, but the customer always has a point.
It’s popular in some circles to do whatever any customer demands, claiming “The customer is always right.” Of course, the customer is not always right! We all know this. Sometimes customers are in a bad mood, uninformed, or unreasonable. If you receive conflicting input from multiple customers, which one of those customers is “always right”? It’s a silly philosophy.
The customer might not always be right, but the BA needs to understand and respect whatever point each customer is trying to make through his request for certain product features or attributes. The BA must be alert for situations in which the customer could be in the wrong. Rather than simply promising anything a customer requests, strive to understand the rationale behind the customer’s thinking and negotiate an acceptable outcome. Following are some examples of situations in which a customer might not be right:
- Presenting solutions in the guise of requirements.
- Failing to prioritize requirements or expecting the loudest voice to get top priority.
- Not communicating business rules and other constraints, or trying to get around them.
- Expecting a new software system to drive business process changes.
- Not supplying appropriate representative users to participate in requirements elicitation.
- Failing to make timely decisions when a BA or developer needs an issue resolved.
- Not accepting the need for tradeoffs in both functional and nonfunctional requirements.
- Demanding impossible commitments.
- Not accepting the cost of change.
The final article in this series will present four additional cosmic truths dealing with requirements specifications.
This is the first part of an article for creating a successful process improvement program.These keys are based on my own experience plus interviews that I conducted with industry analysts and consultants. I hope these help you have achieve a success with your process improvement efforts.
1. Choose the right business area to improve
Although every part a business will probably benefit from a business process improvement project, some processes will return much bigger benefits than others. However, it is very important that the first area chosen has the potential to return big benefits. Many successful BPI projects have been considered failures, simply because the return on investment wasn’t large.
Choosing a large complex area for the first project is not a good idea and significantly increases the risk of failure. There is high probability that your team will run out of energy and money before the project is complete. It is very important that you to learn to walk before you run.
By carefully selecting the first BPI project, you should be able to realize big benefits quickly. The attention this attracts will create momentum to tackle further BPI projects.
- Choose a high profile business process with potential for quick and large gains
- Don not choose a business process that is plagued with political problems
- Do not choose a process that is too large or complex
- Choose an area with a willing and able process owner
2. Start with a problem statement, vision, objectives and scope
Business process improvement should be treated as a project and not a routine daily activity. Organizations that treat BPI as something that their already over-stretched staff should simply fit in around their normal daily activities are not successful and nothing worthwhile actually results.
Starting with a well-written clearly defined problem statement, vision, and project scope ensures that the project team and stakeholders have a common understanding of what is expected. BPI needs to be set up as a project with the following attributes:
- A problem statement
- A clear, measurable set of objectives such as “reduce customer complaints by 10%” or “reduce processing time by 2 days.”
- A clearly defined scope.
- A clear plan of who is responsible for delivering what, by when.
- Properly allocated resources – (people and money).
3. Use a Process Classification Framework
Today’s global companies face an unprecedented amount of change. Technology has blurred the lines between business segments, allowing ambitious companies to enter new industries with game-changing offers. And in the wake of the recent recession, emerging-market multinationals have gained strength, market share, and sophistication, presenting an increasing threat to incumbent players. However, recent advances in business process management (BPM) software, tools, approaches, and process reference models have made these goals more achievable. These changes have allowed organizations to become more responsive and improve core business processes as conditions change, using standardized, industry- and function-specific best practices.
For business process improvement, frameworks and reference models help support process analysis, design, and modeling activities. Starting with a process framework or reference model can significantly accelerate these activities, providing analysis professionals with a strong foundation on which to build. A framework helps organizations in three key areas: benchmarking, content management, and business process definition. The cost of not using a process framework is the additional time it takes the process design team to develop their own process model and obtain process consensus from the project stakeholders.
There are a number of process reference models available, including: Accenture, APQC’s Process Classification Framework (PCF), SAP, Supply Chain Council, the Telecommunications Management Forum, and the Value Chain Group. The Process Classification Framework (PCF) developed by APQC in 1992, is a widely used business tool. This open source framework is commonly referenced in business books, incorporated into numerous consulting methodologies for process improvement and re-engineering, and has been translated into many languages, including Japanese, Chinese, Spanish, Polish, and Portuguese.
Benchmarking and process measurement activities are generally too costly to undertake without the use of a process framework or reference model. Using a process framework or reference model as a common language reduces the effort required for benchmarking activities. Internally, organizations need a common way to describe the work they do so that it can be consistently and repeatedly measured. Externally, organizations normalize their internal processes against the process framework or reference model, and depend on the objective, standard definitions in the framework to enable the comparison of processes across organizational boundaries.
Content management activities rely on common taxonomies. Using a process framework or reference model as the basis for a content management taxonomy helps knowledge managers quickly build consensus among various stakeholders, even when the structure of the reference model doesn’t precisely map to existing enterprise process models. The process framework or reference model acts as an interface between the way the content is organized and the way work is performed. Business analysts and process improvement teams should seriously consider using a process classification framework.
4. Use Agile methods
The best way to mange a business process improvement project is to apply agile development methods. Break the project into small iterations that are of fixed duration (2-4 weeks) of time. Tangible deliverables should be produced as part of each iteration. The work performed in each iteration should be prioritized and the project team should focus their efforts on high priority items first. Retrospectives should be conducted at the end of each iteration to capture lessons learned and to make improvements for the next iteration.
5. Get ideas and input from both workers and managers
Often BPI projects gather a lot of managers into a room. A facilitator draws various process maps on whiteboards; and miraculously coming up with the new process. This just doesn’t work in practice. Manager workshops have their place, but they are often best used at the start of a BPI project, in order to get a high level view of a business processes and to scope out the project, and later in the project to work through a detailed model of the existing processes and to identify and agree on improvements. Other techniques such as interviews, observations, modeling, simulation, and benchmarking will most likely be needed to achieve the objectives
It is simply a bad idea for BPI projects to elicit input and ideas from only managers. Managers play a role in a business process improvement project, but the really key people are the people that do the work. This is because the workers actually carry out the business processes on a day-to-day basis and know where the problems and workarounds are. They often have good ideas for improving existing processes. Listening to them keeps them involved and makes implementation much easier. Managers often have a view of the business processes that does not actually reflect reality.
BPM project team members should observe workers going about their normal activities. Relying on people simply telling you what they do, often results in big chunks of a process being missed. Often people only discuss the ‘sunny day scenario’ when everything goes right. The biggest improvements are often associated with removing or reducing error handling activities and eliminating workarounds. Once a detailed model of the existing process has been prepared, it should also be reviewed with the workers to identify improvements. Workers often have excellent ideas for process improvement and getting their buy-in is essential.
With rare exception, today’s managers in most organizations spend most of their time reacting to problems or critical situations; this is often referred to as crisis management. BPM projects should spend considerable effort working with managers to determine what information managers require to manage the process and help them get out of crisis management and on to effectively managing operations.
BPM projects should ensure they have a thorough understanding of the process operates, what information is required to manage and monitor the process, and then determine the best method to provide the information in a timely manner to enable managers to move from reactive to proactive management and ultimately to predictive management. These changes will greatly enhance management maturity and provide the organization with a long-term continuous and sustainable increase in productivity.
I hope you have found these tips helpful. Please provide comments and sugestions of your own experience below.
As every consultant knows, the correct answer to nearly any question regarding software is “It depends.” I realize that’s not a very satisfying answer, but this isn’t just a consultant’s cop-out—it’s true. The best advice for how to proceed in a given situation depends on the nature of the project, its constraints, the culture of the organization and team, the business environment, and other factors.
That said, having worked with many organizations, I’ve made some observations about software requirements that really do seem to be universally applicable. In this series of three articles (adapted from my book More about Software Requirements) I present some of these “cosmic truths” and their implications for the practicing business analyst.
Cosmic Truth #1: If you don’t get the requirements right, it doesn’t matter how well you execute the rest of the project.
Requirements serve as the foundation for all the project work that follows. I don’t mean the initial software requirements specification you come up with early in the project, but rather the full set of requirements knowledge that is developed incrementally during the course of the project.
The purpose of a software development project is to build a product that provides value to a particular set of customers. Requirements development attempts to determine the mix of product capabilities and characteristics that will best deliver this customer value. This understanding evolves over time as customers provide feedback on the early work and refine their expectations and needs. If this set of expectations isn’t adequately explored and crafted into a set of product features and attributes, the chance of satisfying customer needs is slim.
Requirements validation is one of the vital subcomponents of requirements development, along with elicitation, analysis, and specification. Validation involves demonstrating that the specified requirements will meet customer needs. One useful technique for validating requirements is to work with suitable customer representatives to develop user acceptance criteria. These criteria define how customers determine whether they’re willing to pay for the product or to begin using it to do their work. User acceptance criteria typically stipulate that the product allows the users to properly perform their most significant tasks, handles the common error conditions, and offers an acceptable level of quality. User acceptance criteria aren’t a substitute for thorough system testing. They do, however, provide a necessary perspective to determine whether the requirements are indeed right.
Cosmic Truth #2: Requirements development is a discovery and invention process, not just a collection process.
People often talk about “gathering requirements.” This phrase suggests that the requirements are just lying around waiting to be picked like flowers or to be sucked out of the users’ brains by the BA. I prefer the term requirements elicitation to requirements gathering. Elicitation includes some discovery and some invention, as well as recording those bits of requirements information that customer representatives offer to the BA. Elicitation demands iteration. The participants in an elicitation discussion won’t think of everything they’ll need up front, and their thinking will change as the project continues. Requirements development is an exploratory activity.
A business analyst is not simply a scribe who records what customers say. The BA is an investigator who asks questions that stimulate the customers’ thinking, seeking to uncover hidden information and generate new ideas. It’s fine for a BA to propose requirements that might meet customer needs, provided the customers agree that those requirements add value before they go into the product. A BA might ask customers, “Would it be helpful if the system could do <whatever idea he has>?” The customer might reply, “No, that wouldn’t do much for us.” Alternatively, the customer might reply, “You could do that? Wow, that would be great! We didn’t even think to ask for that feature, but it would save our users a lot of time.”
This creativity is part of the value the BA adds to the requirements conversation. Just be careful that BAs and developers don’t attempt to define a product from the bottom up through suggested product features. It’s better to base the requirements on an understanding of stakeholder goals and a broad definition of success.
Cosmic Truth #3: Change happens.
It’s inevitable that requirements will change. Business needs evolve, new users or markets are identified, business rules and government regulations are updated, and operating environments change over time. In addition, the business need becomes clearer as the key stakeholders become better educated about what their true needs are.
The objective of a change control process is not to inhibit change. Rather, the objective is to manage change to ensure that the project incorporates the right changes for the right reasons. You need to anticipate and accommodate changes to produce the minimum disruption and cost to the project and its stakeholders. However, excessive churning of the requirements after they’ve been agreed upon suggests that elicitation was incomplete or ineffective—or that agreement was premature.
To help make change happen, establish a change control process. You can download an example of such a process from http://www.processimpact.com/goodies.shtml. When I helped to implement a change control process in an Internet development group at Kodak, the team members properly viewed it as a useful structure, not as a barrier. The group found this process invaluable for dealing with its mammoth backlog of change requests.
Every project team also needs to determine who will evaluate requested changes and decide to approve or reject them. This group is typically called the change (or configuration) control board, or CCB. A CCB should write a charter that defines its composition, scope of authority, operating procedures and decision-making process. A template for such a charter also is available at http://www.processimpact.com/goodies.shtml.
Nearly every software project becomes larger than originally anticipated, so expect your requirements to grow over time. According to consultant Capers Jones, requirements growth typically averages one to three percent per month during design and coding. This can have a significant impact on a long-term project. To accommodate some expected growth, build contingency buffers—also known as management reserve—into your project schedules. These buffers will keep your commitments from being thrown into disarray with the first change that comes along.
I once spoke with a manager on a five-year project regarding requirements growth. I pointed out that, at an average growth rate of two percent per month, his project was likely to be more than double the originally estimated size by the end of the planned sixty-month schedule. The manager agreed that this was plausible. When I asked if his plans anticipated this growth potential, he gave the answer I expected: No. I was highly skeptical that this project will be completed without enormous cost and schedule overruns.
When you know that requirements are uncertain and likely to change, use an incremental or iterative development life cycle. Don’t attempt to get all the requirements “right” up front and freeze them. Instead, specify and baseline the first set of requirements based on what is known at the time. A baseline is a statement about the state of the requirements at a specific point in time: “We believe that these requirements will meet a defined set of customer needs and are a suitable foundation for proceeding with design and construction.” Then, implement that fraction of the product, get some customer feedback, and move on the next slice of functionality. This is the intent behind agile development methodologies, the spiral model, iterative prototyping, evolutionary delivery, and other incremental approaches to software development.
Finally, recognize that change always has a price. It is never free. Even the act of considering a proposed change and then rejecting it consumes effort. Software people need to educate their project stakeholders so they understand that, sure, we can make that change you just requested, and here’s what it’s going to cost. Then the stakeholders can make appropriate business decisions about which desired changes should be incorporated and at what time.
Speaking of which, the next article in this series will present several cosmic truths about requirements and project stakeholders.
996Z5SDQNRAX