Jama Connect^® Features in Five: Change Management

Learn how you can supercharge your systems development process! In this blog series, we’re pulling back the curtains to give you a look at a few of Jama Connect’s powerful features… in under five minutes.

In this Features in Five session, Máté Hársing, Solutions Architect at Jama Software, explores the Change Management capabilities in Jama Connect, showing how regulated industries can streamline their compliance and efficiency across the product lifecycle.

VIDEO TRANSCRIPT

Máté Hársing: Hi, I’m Máté Hársing, Solutions Architect at Jama Software. Welcome to this Features in Five video on Change Management with Jama Connect. If you’ve ever worked in a regulated industry like MedTech, you know that change is inevitable, whether it’s from updated standards, customer feedback or internal improvements, where every change must be documented, assessed, and validated, because in our industry, changes can literally be life-critical. Without the right tools, managing change quickly turns into a mess, email threads, disconnected spreadsheets, and siloed tools. That leads to missed impacts, compliance risks, and wasted time.

Jama Connect helps bring order to that chaos with structured change management, and it doesn’t stop at development. After a product is approved, field feedback, manufacturing updates, or regulatory changes also need to be reviewed and connected to related items. Without a system in place, tracking those changes through email or spreadsheets risks letting things slip through the cracks.

So what goes wrong without Jama Connect? Teams can’t easily see what’s impacted by a change. Requirements, test cases, and risks live in separate tools. Manual versioning makes it hard to track who changed what and why. Unverified changes can lead to audit issues or delays. Here is how Jama Connect helps. During development, Live Traceability™, Versioning, and the Suspect Link tool help teams stay aligned and act fast. Impact Analysis and Version comparison give clarity before making a change. For released products, formal change requests pull in all affected items, and reviews in the review center bring visibility, collaboration, and confident decision-making.

RELATED: Jama Connect for Medical Device & Life Sciences Development Datasheet

Hársing: Here is a Trace View of our device’s system requirements. You can see everything it touches, subsystem requirement verifications, and associated risks. Now, we will simulate a change to this system requirement. Once the change is made, the suspect tool automatically flags impacted items downstream, letting us know that in this case, this particular version of the verification case no longer covers the updated requirement and has to be updated. This is what we call reactive change management. Switching to Impact Analysis, we can preview all linked items before implementing the change so our engineering and quality teams can assess the ripple effect and plan accordingly. This is known as proactive change management. It helps us assess the complete cost of a change across as many degrees of separation as our item’s traceability has, as well as providing filters to focus on specific domains, such as verifications in this case, drowning out the noise of any other items we don’t want to see for the time being.

Next, we will use the compare versions view to see what changed. Clearly marked, easy to digest, with intuitive red line/green line differentiation. This is especially helpful during design reviews or when responding to auditors. You’ll notice there is a comprehensive audit trail captured here, who changed what, when and why, so that we can create complete accountability in Jama Connect. And here’s how we handle the change to an approved product. We create a change request item, pull in related artifacts using an easily predefined filter, and send everything through a review. All stakeholders can review the changes in context, see the differences, and provide feedback, ensuring the change is well-documented and fully assessed. The change request can be finalized while we see all the related items and can make sure all the necessary changes in the scope of the change request have been implemented.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Hársing: Jama Connect supports seamless change management across the full product lifecycle, from controlled updates during development to formal change requests for approved products, ensuring traceability, visibility, and compliance every step of the way. Thank you for watching this demonstration of change management in Jama Connect. If you would like to learn more about how Jama Connect can optimize your product development processes, please visit our website at jamasoftware.com.

To view more Jama Connect Features in Five topics, visit:
Jama Connect Features in Five Video Series

Best Practices for Change Impact Analysis

Impact analysis is a key aspect of responsible requirements management. It provides an accurate understanding of the implications of a proposed change, which helps the teams make informed business decisions about which proposals to approve.

The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change.

Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise.  In product development surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis.

RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond

Impact Analysis Procedure

Impact analysis has three aspects:

1. Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels.
2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.

Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. On complex projects with thousands of artifacts, to manually determine what and who is affected by a change is time-consuming and error-prone. Alternatively, you could adopt a product development solution like Jama Connect, which includes built-in functionality for end-to-end traceability and impact analysis, and automatically highlights the items and people that are impacted when a change occurs.

RELATED: When Evaluating Product Development Software Tools, Not All Cloud is Equal

Whichever route you take, understanding the impact enables teams to quickly and accurately respond to change requests. The team can be responsive while maintaining control over the scope and customer expectations.

Lastly, impact analysis is essential on projects where quality and safety are an issue such as in healthcare, automotive, and aerospace projects. In these situations, it’s critical to understand the specific set of requirements and features that need to be retested after a change is implemented.

Steps in a typical impact analysis process look like this:

1. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
2. Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
3. Estimate the impact of the proposed change on the project’s schedule and cost.
4. Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
5. Report the impact analysis results to all stakeholders so that they can use the information to help them decide whether to approve or reject the change request.

In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand.

Money Down the Drain

What can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request?

Imagine two developers on your team estimate that it will take four weeks to add an enhancement to one of your product lines. The customer approves the estimate, and the developers set to work. After two months, the enhancement is only about half done and the customer loses patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.”

In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, you waste several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.

Learn how a requirements management solution eliminates many of the budget-draining headaches of product development in Karl Wiegers’ paper, “Getting the Most from a Requirements Management Tool.”

RELATED: A Guide to Good Systems Engineering Best Practices: The Basics and Beyond

Editor’s Note: This section was added to this blog post on 4/08/2025. It was written with assistance from AI and reviewed and updated by McKenzie Jonsson.

The Importance of Traceability in Change Impact Analysis

Effective change impact analysis is not just about identifying affected requirements, tests, and risks—it’s about doing so with confidence, speed, and accuracy. This is where traceability becomes critical.

Traceability is the ability to track and document the lineage and history of requirements throughout the development process. It ensures that every requirement, test case, design element, and risk assessment is connected in a structured way, providing full visibility into all dependencies in the full process. When a change in one element is introduced, whether in response to evolving customer needs, regulatory updates, or system modifications, traceability enables teams to easily assess the impact of that change on all related artifacts.

How Traceability Enhances Change Impact Analysis

The truth is, the two go hand in in, really. Traceability supports change impact analysis in many ways, including:

1. Identifies Downstream and Upstream Effects
   Changes in one part of a system can have cascading effects on related requirements, tests, and risk assessments. With end-to-end traceability, teams can immediately see what is impacted and take proactive steps to mitigate risks.
2. Reduces Rework and Late-Stage Surprises
   Without traceability, overlooked dependencies often result in late-stage failures, expensive rework, or compliance gaps. A traceability-enabled approach to change impact analysis allows teams to plan changes with greater precision, minimizing unexpected disruptions.
3. Strengthens Compliance and Audit Readiness
   Many industries, from medical devices to automotive and aerospace, require stringent documentation of changes and their impact. Traceability ensures that organizations can quickly generate reports that demonstrate compliance with regulatory requirements.
4. Enhances Collaboration Across Teams
   By maintaining a single source of truth, traceability tools ensure that stakeholders across engineering, quality, and compliance teams stay aligned. This reduces miscommunication and streamlines decision-making.

RELATED: Traceable Agile™ – Speed AND Quality Are Possible for Software Factories in Safety-critical Industries

Leveraging Traceability Tools for Smarter Change Management

Manual impact analysis is time consuming and error prone. Modern requirements management platforms like Jama Connect^® provide real-time traceability (Live Traceability™), allowing teams to visualize relationships between artifacts and perform change impact analysis efficiently. These tools help teams:

• Instantly generate trace reports to understand how a change affects the system.
• Perform gap analysis to ensure all impacted areas are accounted for.
• Automate notifications to relevant stakeholders when changes occur.

By integrating robust traceability into change impact analysis, organizations can reduce risk, accelerate development cycles, and maintain compliance with confidence —ensuring that every change is made with clarity and precision.

Let’s say an organization is developing a medical device and must change some of its requirements along the way – something that happens all the time. By conducting an impact analysis of this requirement and its dependencies, the product development team could accomplish all of the following:

• Determine the ripple effects of the change: How will it affect higher-level requirements upstream and links downstream? Are there are any conflicts to resolve? Proper impact analysis answers these questions and in turn reduces the risk of unexpected consequences requiring costly remediation later on in the lifecycle.
• Connect people, not just requirements: The impact analysis process should go beyond flagging at-risk upstream and downstream items. It should also reveal who is affected by changes, plus notify those team members about the necessary next steps. This is where live traceability and real-time collaboration in one platform really matter.
• Assess what is required going forward: Impact analysis is ultimately about gaining visibility into the future – almost like a crystal ball – and acting accordingly. In addition to showing potential risks to existing requirements, it can also identify new requirements and test cases that may be needed for keeping the project on track.

Teams may perform impact analysis using multiple tools. A dedicated requirements management platform, with integrated risk management and end-to-end traceability, is ideal for fully mapping out the effects of changes and identifying subsequent action items, along with the personnel responsible for them.  When manual tools are used, data gets kept in silos which can create misalignment, poor visibility, and difficulty to assess the impact of change.

Replacing those manual workflows, which often revolve around software like Microsoft Word and Excel, is crucial for optimizing impact analysis. That’s because informed analysis requires accurate traceability, something made much easier with a proactive and automated platform that serves as a single source of truth at every stage of product development. In this way, requirements management software addresses the biggest roadblocks to effective impact analysis.

Overcoming the Obstacles en Route to Better Impact Analysis

From the rapid pace of innovation in industries like medical device development and automotive manufacturing, to the need to coordinate increasingly distributed and remote engineering teams, there is no shortage of possible challenges when building a complex, modern product. When it comes to impact analysis in particular, the three primary issues include:

1. Manual Traceability

Impact analysis isn’t possible without effective traceability. But with so many evolving requirements to keep track of, accurately tracing everything can be difficult without truly scalable and automated tools.

To see why, consider a hypothetical case in which a critical requirement needs an immediate change. The time constraints mean all upstream and downstream effects must be quickly accounted for, with requirements and other artifacts (like test cases) properly traced forward and/or backward as needed.

But doing so is difficult when working with nothing more than a traditional traceability matrix  housed in Excel or Word. The amount of manual work required could result in something being missed due to human error and a lack of comprehensive traceability within the matrix itself. The team might not realize they’ve overlooked missing coverage until it’s too late.

Solution: Live traceability provides straightforward navigation of upstream and downstream relationships, along with automatic identification of risky links. It also updates items in real time so that team members are always looking at the most accurate assessment of test coverage.

2. Inefficient Modes of Collaboration

Email-oriented collaboration only compounds the above problem. When lengthy, complex documents – which might not even be up to date – are emailed between teams, confusion, and delay are almost inevitable.

Simply staying current with any changes to project requirements can mean searching through your crowded inbox and trying to reconcile various attachments. Is “RequirementsDoc_v2FINAL” really the final version, or is there something more recent circulating under a different name?

In order to effectively conduct impact analysis, everyone tied to the requirements needs to be notified in real-time when changes are made and provide their input. Centralizing this information creates a more systematic way for change management and enables accountability within the organization on how decisions are made past and present.

Solution: Instead of email, use a real-time platform with instant notifications and the ability to pull in internal and external collaborators as needed. On such a platform, everyone is looking at the same data, which helps expedite review and approvals.

3. Rework and Opportunity Costs

Impact analysis is supposed to reduce risk by letting you see how specific changes will play out and empowering you to take any corrective action as early as possible. But when impact analysis is built upon manual processes and limited traceability, it can do the opposite and actually make projects riskier.

For example, extensive rework may be required to ensure that all requirements are met. This work represents a major opportunity cost, as the time sunk into correcting process-related problems could have gone into more strategic initiatives.

However, teams can avoid getting bogged down in rework by upgrading their impact analysis and traceability tools. Leaving static documents behind for an automated platform with real-time collaboration built-in is both reliable and helps to ensure product quality.

Solution: Invest in a platform that enables proactive, rather than reactive, requirements management. Features like live traceability that connect requirements to tests make it easier to handle changes as they happen and avoid costlier actions later on.

Fueling the Engine for Superior Impact Analysis

A modern requirements management platform enables streamlined impact analysis while bringing teams closer together to work in real-time, even if they’re physically distributed. As a result, analyzing upstream and downstream relationships becomes more practical, as does the overall development of high-quality products within budget and on time.

More specifically, the right solution will be an engine for better impact analysis, propelling key advantages throughout product development, including:

• Automatic identification of suspect links: If a requirement is modified, the platform will automatically flag its downstream links as “suspect” so that team members can review them before proceeding with development.
• Easier relationship navigation: Users can efficiently navigate upstream and downstream relationships. A visual schematic lets team members save time in finding missing coverage and make sure that they’re not overlooking anything.
• Enhanced collaboration: Team members get notified about relevant changes and can be pulled in right away to respond, on a shared platform offering a single source of truth. This real-time setup is much more efficient than relying on email alone.

Want to learn more about how Jama Connect can improve your impact analysis? Set up a free trial today to get started.

GET STARTED

Changing how your teams work is hard.  In my previous post, I covered the first three of my learnings in my time as a Strategic Customer Success Manager at Jama.  I’m now going to fill you in on how to approach communicating about Jama to your various stakeholders.

We all know we need to communicate, but communicating about change needs to be thought through.  It’s not enough to post a broad scale notification on the company’s intranet and hope that readers can “right-size” this information and accurately apply it’s meaning to their roles.  Do everyone a solid and think through the various categories of people who need to be brought up to speed and spoon feed them only the information they need to digest.

To do this correctly, this needs to be done in advance – then actually executed. I say this because once the process of rolling the tool out begins, things get muddy and you will forget to notify folks in the way you’d envisioned.  Think about each group of people you’re communicating with.  In my experience there are several groups:  leadership, those creating requirements, stakeholders, etc.  Some of these people will be defined by Jama license type, some will not.  Tell them what they want to know.  For example, how you communicate with your leadership will be different from somebody who will be simply reviewing and chiming in on requirements.  Below is an example of what I’m talking about.

Communication Plan

Another wrinkle of the communications plan is to think through the cultural norms and politics at play in your organization.  Actually think about the order of communications and who needs to know what and when.   Are there influencers you need to hit one on one?  Perhaps there is a member of the team part of the old guard who needs to be spoon fed information.  Don’t fight it – account for it and assure they get the information they need in a way they can digest it.  And don’t forget about external resources – partners and consultants that are helping you bring your products to market.

The last important thing I’d like to share with you about this is to share your wins widely.  Make your improvements and advancements in your process public knowledge!   Even small improvements in your process can have dramatic results over the long haul, so talk it up.  And not just in your team meetings and stand-ups either – be sure leadership is aware their investment is starting to bear fruit.  Not only will this garner goodwill with your management, but it will encourage further adoption and help silence latent naysayers.

I am a Strategic Customer Success Manager at Jama. I have watched many customers implement Jama Connect and learned a few things along the way.

One of the biggest AHA! moments I’ve had so far is that the lift the organization makes to change human behavior around how they do their work is much heavier than the tasks associated with training people how to use Jama Connect. Learning how to use Jama Connect is actually the easy part! The real challenge is successfully going through the change management exercise.

Humans hate change. Why? Because it’s hard! Repaving the roads in our brains around our daily activities is hard mental work and when the work we’re doing is on a delivery timeline – or heaven forbid, behind – reverting to the evil we know can be astonishingly tempting. As an organization going through change that involves the lifeblood of your organization – your products – you need to accept this undeniable fact and embrace strategies that address that head-on. I’ll be sharing the first of my learnings with you in this post; another follow-on post with additional thoughts will be posted in the next several days.

Communicate why the change is necessary to the entire organization
Make sure everyone wallows in the pain of the current state and understands why the new state is better and critical to the longevity of the organization. Paint a vision of it. Talk about how the changes are important to everyone, not just the product organization. Why? Because there will be hiccups along the way and everyone needs to be bought in and understand the value of going through the challenges and work associated with the change. In my experience, if you don’t, they won’t.

Accept change will be disruptive to the business
Your investment in thorough planning will minimize the amount of disruption, but no amount of planning will make it seem like nothing is going on. That’s OK. Plan for that disruption in your timelines of possible. The exercise of shaking things up provides the rare opportunity to look at what you’re doing with a critical eye and make changes deemed unthinkable before. The good news is that this change is actually what you needed, the trick is to not develop amnesia around it!

Don’t get deterred
There’s a natural, human resistance to perceived roadblocks and barriers. Sometimes these are used to demonstrate failure of the project. Don’t buy it. Change fatigue will probably set-in. Things won’t happen perfectly. Stakeholders only partially involved in the success of the project will resist changing how they work. Timelines may slip and second thoughts will start swirling. Don’t let natural challenges inherent in any broad scale change derail seeing yourself and your teams in a better place.

Follow up with Change Management, Part 2.

Impact analysis is a key aspect of responsible requirements management. It provides accurate understanding of the implications of a proposed change, which helps the team make informed business decisions about which proposals to approve. The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change. Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise. Software surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes how the impact analysis activities might work.

Impact Analysis Procedure

The chairperson of the change control board will typically ask a knowledgeable developer to perform the impact analysis for a specific change proposal. Impact analysis has three aspects:

1. Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels, as when a system that runs daily requires more than 24 hours to complete a single execution.
2. Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
3. Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.

Figure 1 presents a checklist of questions designed to help the impact analyst understand the implications of accepting a proposed change. (You can download the checklists and templates described in this article from http://www.processimpact.com/goodies.shtml.) The checklist in Figure 2 contains prompting questions to help identify all of the software elements that the change might affect. Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. As you gain experience using these checklists, modify them to suit your own projects.

Figure 1. Checklist of possible implications of a proposed change.

Figure 2. Checklist of possible software elements affected by a proposed change.

Following is a simple procedure for evaluating the impact of a proposed requirement change. Many estimation problems arise because the estimator doesn’t think of all the work required to complete an activity. Therefore, this impact analysis approach emphasizes comprehensive task identification. For substantial changes, use a small team—not just one developer—to do the analysis and effort estimation to avoid overlooking important tasks.

1. Work through the checklist in Figure 1.
2. Work through the checklist in Figure 2, using available traceability information. Some requirements management tools include an impact analysis report that follows traceability links and finds the system elements that depend on the requirements affected by a change proposal.
3. Use the worksheet in Figure 3 to estimate the effort required for the anticipated tasks. Most change requests will require only a portion of the tasks on the worksheet, but some could involve additional tasks.
4. Total the effort estimates.
5. Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
6. Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
7. Estimate the impact of the proposed change on the project’s schedule and cost.
8. Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
9. Report the impact analysis results to the CCB so that they can use the information to help them decide whether to approve or reject the change request.

In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand. To improve your ability to estimate the impacts of future changes, compare the actual effort needed to implement each change with the estimated effort. Understand the reasons for any differences, and modify the impact estimation checklists and worksheet accordingly.

Figure 3. Estimating effort for a requirement change.

Money Down the Drain

Here’s a true story about what can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request. Two developers at the A. Datum Corporation estimated that it would take four weeks to add an enhancement to one of their information systems. The customer approved the estimate, and the developers set to work. After two months, the enhancement was only about half done and the customer lost patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.” In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, the A. Datum Corporation wasted several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.

Impact Analysis Report Template

Figure 4 suggests a template for reporting the results from analyzing the potential impact of each requirement change. Using a standard template makes it easier for the CCB members to find the information they need to make good decisions. The people who will implement the change will need the analysis details and the effort planning worksheet, but the CCB needs only the summary of analysis results. As with all templates, try it and then adjust it to meet your project needs.

Figure 4. Impact analysis report template.

Requirements change is a reality for all software projects, but disciplined change-management practices can reduce the disruption that changes can cause. Improved requirements elicitation techniques can reduce the number of requirements changes, and effective requirements management will improve your ability to deliver on project commitments.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.

Because the available tools, vendors, and features frequently change, I won’t provide specific tool recommendations here. Instead, I’ll provide some general guidance about how to effectively incorporate such tools into your software development process and how to use the tool’s reporting capabilities to get a handle on the project’s change activity. Look for the following features in a tool to support your requirements change activities:

• Lets you define the data items included in a change request.
• Lets you define a state-transition model for the change-request life cycle.
• Enforces the state-transition model so that only authorized users can make the permitted status changes.
• Records the date of every status change and the identity of the person who made it.
• Lets you define who receives automatic email notification when an originator submits a new request or when a request’s status is updated.
• Produces both standard and custom reports and charts.

Some commercial requirements management tools have a simple change-proposal system built in. These systems can link a proposed change to a specific requirement so that the individual responsible for each requirement is notified by email whenever someone submits a pertinent change request.

Tooling Up a Process

When I worked in a Web development team for a large corporation, one of our first process improvements was to implement a change control process to manage our huge backlog of change requests. We began with a process similar to the one described in the previous article in this series on change control. We piloted it for a few weeks by using paper forms while I evaluated several issue-tracking tools. During the pilot process we found several ways to improve the process. We also discovered several additional data items that should be included in the change requests. We selected a highly configurable issue-tracking tool and tailored it to match our process.

The team used this process and tool to handle requirements changes in systems under development, defect reports and suggested enhancements in production systems, updates to Web site content, and requests for new development projects. Change control was one of our most successful process improvement initiatives. Our process and tool really helped this extremely busy team manage its dynamic backlog of requests effectively.

Status Overkill

It’s easy for people to get carried away with all the options they have available with a change control tool. I saw a good example of this once when I was visiting a client site. That very day, someone was configuring the team’s new change control tool. He was planning to set up no fewer than fifteen unique statuses for change requests. While I can imagine that these statuses all made some sense, the fact is that no one is going to use them all in practice. Some of them were transient statuses, through which a change request might pass just briefly on its way from one status to another. In reality, no one is going to update the contents of the change-request database frequently enough for these short-lived status changes to be useful.

Be sure to take a pragmatic approach to the tools and processes you use. If the process and tool are overly complex and do not add evident value to the organization, team members will find ways to bypass the process or revert to handling things manually instead of through the tool. This undermines the effort and gives the whole concept of process a bad reputation.

Measuring Change Activity

Software measurements provide insights into your projects, products, and processes that are more accurate than subjective impressions or vague recollections of what happened in the past. The measurements you select should be motivated by the questions you or your managers are trying to answer and the goals you’re trying to achieve. Measuring change activity is a way to assess the stability of the requirements. It also reveals opportunities for process improvement that might lead to fewer change requests in the future. Consider tracking the following aspects of your requirements change activity:

• The number of change requests received, currently open, and closed.
• The cumulative number of changes made, including added, deleted, and modified requirements (You can also express this as a percentage of the total number of requirements in the baseline.)
• The number of change requests that originated from each source.
• The number of changes proposed and made in each requirement since it was baselined.
• The total effort devoted to processing and implementing change requests.
• The number of cycles through the change process that it took to correctly implement each approved change (Sometimes changes are implemented improperly or cause other errors that need to be corrected.)

You don’t necessarily need to monitor your requirements change activities to this degree. As with all software metrics activities, understand your goals and how you’ll use the data before you decide what to measure. Start with simple measurements to begin establishing a measurement culture in your organization and to collect the key data you need to manage your projects effectively. As you gain experience, make your measurements as sophisticated as necessary to help your projects succeed.

Figure 1 illustrates a way to track the number of requirements changes your project experiences during development. This chart tracks the rate at which requests for new requirement changes arrive. You can track the number of approved change requests similarly. Don’t count changes made before baselining; you know the requirements are still evolving prior to establishing the baseline. Once you’ve baselined the requirements, though, all proposed changes should follow your change control process. At that point you should also begin to track the frequency of change (also called requirements volatility) that Figure 1 illustrates. This change-frequency chart should trend toward zero as the project approaches its ship date. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments. It probably also indicates that the original baselined requirements were incomplete, suggesting that improving your requirements elicitation practices might be a good idea.

Figure 1. Sample chart of requirements change activity.

A project manager who’s concerned that frequent changes might prevent the project from finishing on schedule can gain further insight by tracking the requirements change origins. Figure 2 shows a way to represent the number of change requests that came from different sources. The project manager could discuss a chart like this with the marketing manager and point out that marketing has requested the most requirements changes. This might lead to a fruitful discussion about what actions the team could take to reduce the number of post-baselining changes received from marketing in the future. Using data as a starting point for such discussions is more constructive than holding a confrontational meeting stimulated by frustration.

Figure 2. Sample chart of requirements change origins.

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.  Karl Wiegers is an independent consultant and not an employee of Jama.  He can be reached at http://www.processimpact.com.  Enjoy these free requirements management resources.