change management Archives

Tag Archive for: change management

This image portrays a video blog series, with this topic being on Software Defined Vehicle development

In this blog, we will preview a section from our video, “Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development” – Click HERE to watch it in its entirety.

Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development

Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.

We are excited to introduce Florian Rohde, an expert in electrification, variant management, software defined vehicles, continuous integration and validation, and AI in automotive development. With more than 20 years of experience in the automotive industry, Florian has worked with companies large and small, from Siemens to NIO to Tesla Motors.

In this episode, we discuss:

- Challenges in software defined vehicle development
- Variant and configuration management in SVDs – and which companies are excelling
- Balancing documentation, complexity, and speed

Below is a preview of our interview. Click HERE to watch it in its entirety.

The following is an abbreviated transcript of our webinar.

Kenzie Jonsson: Welcome to our Expert Perspectives series where we showcase insights from leading experts in complex product systems and software development, covering industries from medical device to aerospace and defense. We feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today I’m excited to welcome Florian Rohde, an expert in electrification, variant management, software-defined vehicles, continuous integration and validation, and AI in the automotive industry. With more than 20 years of experience in the automotive industry, Florian has worked with companies small and large, from Siemens to NIO, to Tesla Motors. Without further ado, I’d like to welcome Florian Rohde, who will be speaking with Matt Mickle, Jama Software’s very own director of automotive and semiconductor solutions.

Matt Mickle: Thanks, Kenzie. So my name is Matt Mickle. I run our solution development for automotive and semiconductor at Jama Connect. I’ve been with the company at Jama for about 11 years and worked as a consultant for most of that time. And now my team handles most of the consulting and development of solutions for automotive and semiconductor. And I live out in Europe, in Amsterdam. Came over here to help start up our European headquarters. And I’m joined today by Florian Rohde

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Automotive

Florian Rohde: Absolutely. Thanks, Matt. So I’m in the automotive industry for about 20 years. I started as an intern at Bosch, and then I started as a junior test engineer at a company called Siemens VDO, which then was incorporated into Continental. Back in the day, we were building electric power steering systems. So highly safety critical components in your car. So I got grounded into functional safety right from the beginning. I spent about seven, eight years at that company, both in Germany and in Romania. And then in 2012, I joined a startup called Tesla Motors, and that is bringing the interesting parts to our discussions here, I guess.

So in 2012, Tesla had about 2,000 employees worldwide. I was the first member and the founder of a team for vehicle software validation. So every software release, every software functionality on the vehicle level went through my signature for about six years. I counted over 700 releases in that time to the end customer and way more software that went through our test systems in that time. And after six years there at Tesla, I was one year at NIO as a director of integration of smart components. And starting 2019, actually, I became a consultant advisor all around SDV, software-defined vehicles, and basically trying to facilitate the communication between what you can call the old world and the new world. So the new players on the market and established 100-year-old OEMs because I speak both languages. I’ve been in both worlds. So I’m helping both sides, helping the new players really to understand regulatory things and scaling and things like that and helping the established players really to understand the role of software in today’s and tomorrow’s vehicles.

Mickle: Well, I know that when we started to talk about having this chat, one of the things that you’d mentioned is that you’re hearing quite often in the industry about challenges, especially as people are trying to shift into this modern way of working with software-defined vehicles. There’s still a lot of challenges around variant handling and configuration management. You have some strong background in handling some of those things, especially while you worked at Tesla. How would you say that your approach had to change when you started to think in a more software-defined vehicles perspective when it comes to variant management?

Rohde: Yeah. I think in general, there’s a lot of challenges. Variant management is one of them. But I think let’s focus on that for the purpose of this talk. Let’s not focus on engineering culture or software skill sets and so on. That’s, for sure, other topics we can talk about. But today, let’s talk about variant management, configuration management, etc. So on one hand, I see gigantic numbers of configurations out there when you look at legacy OEMs. And somebody told me just Ford F-150 numbers, they were like hundreds of thousands or even higher than that. So on one hand, you see the companies struggling with the variety of variants actually of their product. But then on the other hand, you also see R&D teams struggling with those variants, both in how to handle them on the development side of things, but even more so on the testing side of things, especially… So I’m a test engineer, originally. And for test engineers, additional variants are usually a nightmare because it just means basically one-on-one growth of your testing efforts.

So there is a problem that needs to be solved and it’s on two sides. It’s one, how do you solve that problem in your product itself? And the other thing is, how do you solve that problem in your tool chain? So things like what you’re doing on the requirement side of things, specification, and so on. Let’s look at the product for now. So Tesla had a different approach to this problem. They actually made themselves agnostic to the variety of variants. What does that mean? That means they developed their product software first and they were designing the software in a way that it can handle pretty much an endless amount of variance. Of course, and we can talk about that, there’s challenges to the validation of things. There’s challenges to how you handle software updates. There’s challenges how you handle releases. But we had a pretty good process in place to do so. But the alpha and omega of the whole thing is that there’s a system in place that allows the software to handle the variance without being handcuffed to some process from the past.

RELATED: Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls

Mickle: Okay. So a lot of the challenges that I hear, and maybe some of what you hear, is especially around the alignment of the software with the hardware in terms of releases, considering those are evolving at different paces. So since the software is evolving so fast and handling multiple configurations, how do you account for that with what you’re doing with either tooling or the product?

Rohde: Right. So I think there’s a consensus in industry by now that the hardware has to be able to accommodate new software features over time. Or in other words, it has to be designed for a little more than it originally offers at start of production. There’s still a lot of hesitance around legacy carmakers because it’s a financial discussion, right? So I don’t think from technical point of view, anybody would disagree that the hardware should be overdesigned by, let’s say, 20% so the software can start evolving over time and creating new cool stuff. But it’s always a question how you actually finance that.

The good news here is that actually, hardware and compute power becomes more reasonable in pricing. So we’re not talking about dollars per bytes in memory anymore. We started talking about dollars per gigabytes, right? So we can actually make that happen a little easier. But obviously, there’s a strong legacy of hardware driving the timelines, and then the software goes on the hardware to make the functionality work as designed and then go into the car as a component. So now in the next generation of cars, you hear a lot the term of decoupling. So you’re decoupling software from hardware. What does that actually mean? That means that on the technical side of things, you have to find ways to have your software actually handling the car’s compute resource and not as a conglomerate of several separate ECUs. So we’re talking about zonal architecture at one point in the future, we’re talking about high compute power architecture, HPCs.

But on the other hand, it also means organizationally and structurally. So when I go back and look at the Tesla example, Tesla has one software that runs on all their cars. And the cars are, for sure, not all the same hardware. As a matter of fact, I like to sparkle that in here right now because a lot of people think Tesla holds the variance low, but that’s not the case. Yes, they have only four or five models in the field, five actually by now. But they actually perform some sort of a facelift statistically every week. So while in a traditional car-making you wait for about three to four years before you put in a flurry of hardware changes, and in between, the car stays more or less unchanged. What we experience at Tesla is that every week, there’s some new hardware going into the car. So there’s some new costs down available. There’s something better available. There’s some replacement parts available. It goes in right next week. And that means that you have thousands and thousands of different variants of Teslas driving out there, even though from the outside, they all look the same.

So what we did is we decoupled the software in a way that it’s “smart enough” to handle all these variants. So the way that works is there’s a package and that package of software contains all different options and variants, and it also contains the information who is allowed to play with who, so what variant is allowed to play with what variant of the other car component and so on based on our validation and release process.

But in general, in a very simplified way, the car knows what it is, and that’s already a huge difference to a lot of legacy carmakers. So the car has a digital information about its components in hardware and in software and in mechanics. And based on that information, it receives the software package and it builds its own personalized update out of that. And it’s talking to the components and updates the components with the right versions based on the information it has. This information is on the other hand also mirrored up into what they call the mothership, so the server area. So that information is available in real-time, and I’d like to talk about that a little bit because I think it’s extremely valuable, for example, for the validation and release process to set your priorities.

So let’s say I only have time to do one combination. So I would like to reach most people with my release today. Of course, I’ll do the next combination tomorrow and the day after. But today, I have only time for one and I want to reach the most people. So I can go and I can actually look what combinations are out there that are relevant for this release and I can prioritize my validation on that. Actually, at one point, we went so far that we even took time zones into consideration that we say, “We can validate all of this large area of the fleet, but hey, that will be midnight or 1 AM by the time they get it. So they will not install it for another eight hours or something like this. So let’s focus somewhere else.” So all this information is making it extremely powerful to manage your priorities and both in research… Sorry. And both in development and in validation.

CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development

Impact analysis is the assessment of the implications of changes, in the specific context of product development. It is integral to requirements management, as it offers insights into dependencies and gaps in coverage, which help inform decisions about the product’s lifecycle.

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

As part of our ongoing series of Ask Jama webinars, covering customer questions and best practices, we recently held a webinar addressing release management options in Jama Connect.

In the webinar, Ryan Moore, a Jama Connect expert and a consultant from our Professional Services team, discusses options for managing releases within Jama Connect. The following concepts were covered:

Leveraging Jama Connect’s release field
Re-use and synchronization
Branching vs. mainline approaches

We heard from our customers afterward that this webinar was informative and insightful, and we wanted to make sure that you didn’t miss out on this great content. Below you can see a transcript of the webinar, and view the full webinar recording.

The Full Demonstration of Release Management Options in Jama Connect

Transcript: Release Management Options in Jama Connect

Thank you all for taking the time out of your busy schedules to join us for the session about change management options in Jama Connect. Before we get started, I’d like to start off by clarifying a few key concepts as they pertain to requirements management, and really how they fit in within the scope of Jama Connect. I’ll also be including some use cases for each of the concepts we walk through today to help provide a bit of a bigger picture. And then we’ll go into a live demonstration within the tool. Through my experience with different organizations and various industries, I find that people tend to use a lot of different terminology and nomenclature that may pertain to any one subject, whether you’re discussing what you consider a specific version, or what’s the difference between a product versus a project, or how you define your user roles. This is no different when you’re approaching the concept of how you define releases. So, it’s important for us to clarify it.

A release to one person may be considered the final distribution of a product, where it’s officially available to the public or active in the field. Software teams, on the other hand, may think of release in terms of code or hardware. Other teams may consider manufacturing distribution in their framing releases. For our considerations today, let’s consider a release a grouping of requirements and corresponding tests that represent a product at a specific point in time. This could be a requirement set that’s specific to a product version, such as version 2.0 or version 3.0, where it could be included as part of a blanket, summer or fall release. So, regardless of what your organization is going to be using for requirements and tests, you could be using stakeholder requirements, market, user requirements, system versus subsystem, functional versus non-functional, design requirements or input requirements, verifications, validations, or calling new test cases. These are the types of artifacts that we’re going to be considering as a part of a release.

Baselines

Now let’s define baselines. Baselines are a very important aspect of Release Management and within Jama Connect as well. They provide clear cut lines in the sand. Baselining within Jama Connect can really be considered the ability to capture a snapshot of any grouping of items that you choose within a project at any given point in time. Let’s elaborate on some of the more common use cases for baselines. Baselines provide the ability to take full snapshots of artifacts. By taking baselines at release milestones, we’re able to make comparisons down the road using Jama Connect’s baseline comparison reports, which are exportable. They also provide detailed information and nuanced changes quickly and easily. Just a couple of clicks of a button, we can pull up these reports. The baseline reports will provide you a full list of any modified, deleted, or added items between baselines. So, it gives you the information that you need to be able to make quick comparisons. You can also use them to compare to the current state of the project. We can use baseline to compare between two baselines, or we can select a baseline that we captured prior and compare it to the current state of the project as well.

Additionally, you can also use Jama Connect’s baselines to actually roll back items, so you can roll back to prior baselines. Since baselines can be captured at the time of release, that also means you’ll have the ability to revert back to prior releases. So, lots of different power and what you can do in leveraging the baselines. As I mentioned, they are also easily exportable if you need it to export out and place into a quality management system (QMS) or another type of document control. And as a final caveat, we want to keep in mind that baselines, they’re static bits of information. They’re not going to be able to be leveraged to fork projects on a different path or branch them, if you will. Today we’ll through the concept of branching via reuse and synchronization during the presentation today.

Reusing and Synchronization

What is reuse and synchronization? Reuse and synchronization within Jama Connect can be considered as two advanced concepts. They both have very beneficial use cases and unique purposes. For that reason, I’ve included separate definitions. But you can also use them together and the outcome is going to be a lot of time saving and powerful use cases for you. Consider the concepts of reuse. In practice and in defining reuse is really to simply copy items in Jama Connect from one location to another, or it can be within the same project or across separate Jama Connect projects. Synchronization can be considered an additional step on top of reuse that allows you to maintain connections between those copied or reused items. Synchronization really adds an additional layer of monitoring between your artifacts to track differences or changes between them, and also provides you the ability to push and pull information between those synchronized items. Synchronization really leverages the concept of global IDs within Jama Connect. And those are the shared IDs between reused and synchronized artifacts that are going to help you bridge those items and maintain the connection between them.

Let’s walk through a few use cases for reuse and synchronization to help you better frame the use cases here and how it’s applicable and practical in use. Major releases to a large product. These could be small or large modifications to variants or existing product lines that you have. Staged releases of an evolving product is a second use case. And that may be used to leverage over time on a rolling schedule. For example, if you release a beta product, where you’ll be refining towards a final version and working as you go. Recent synchronization allows for version comparisons. As I mentioned before, Jama Connect’s synchronization allows you to generate a comparison view to easily identify differences between synchronized items. Also allows for “maintenance” updates to release projects. And synchronization allows you to separate Jama Connect projects into different maintenance workspaces, if you will, and easily push changes back into one main major release project. It also allows for changes to be “pushed” between releases.

In the same vein, and we’re talking about these projects that we’re leveraging for releases, you can use the synchronization to push changes back and forth between those projects. It allows for change control to the product. So, synchronization pushes, and this is very important, are never automatic. It’s always going to be a manual process, so you have to have ownership of that. What that means is that users always dictate when the changes are being made. Once again, this is a very important aspect to remember when considering using synchronization. You need to develop a regular cadence to determine who and when the changes are going to be pushed and pulled between synchronized artifacts or items. Then lastly, you’re able to use reuse and synchronization to create branches or forks from the original project. If needed, this concept of branching allows you to really work on multiple releases in parallel.

Release Management Options

Let’s talk about releases and in terms of the different types of releases that organizations may be working on as they go through the product development cycle. When we talk in terms of releases, we have two different methodologies that we’ll outline today and their differences. Linear versus parallel releases. We have linear on the left-hand side here and parallels on the right-hand side here. As you can see, linear releases are sequential or one after the other. They’re never going to be worked on simultaneously. Alternatively, parallel releases on the right-hand side, as you might expect by the name, parallel, they’re going to be worked on in tandem or side by side. So, you can be working on multiple releases in tandem.

“How are requirements impacted by these two approaches?” you might be thinking. In linear release management requirement, typically, we’ll have one singular definition at any given time. If I’m working in parallel, however, I may have the same requirement that spanned across two or three different releases. And that definition could easily change depending on the need of that release, or if I’m working in Release V2.0 versus Release 3.0. We might have a different need to alter the definition of that requirement. Since it’s summertime, let’s take a sunscreen for example. If I’m working on sunscreen products, it has different options SPF 15, SPF 30, and SPF 50. And we’re working on these simultaneously because we’re needing to roll them out on a similar timeline, where we have a similar roadmap for them. There may be same requirement in SPF 15 as there is in SPF 50 to include a very specific ingredient that helps block out the sun. But in SPF 15, we may need less of that depending on the strength versus needing more in SPF 50.

Let’s talk about the suggested approaches in Jama Connect for linear versus parallel. For the specific Jama Connect features and how they pertain to each release, Jama Connect’s release field is going to be the suggested method for the linear approach. The reason being is that the release field is going to allow you to make items a part of only one release at a time. So, the release field in Jama Connect doesn’t allow you to tag items in more than one release at a time. From a configuration standpoint, that means that the release field does need to be added to each item type that we’ll be using to label items as part of releases. That can be easily done by accessing your Jama Connect Admin section, navigating to the item types and then going to the fields. And if you don’t already have a release field as part of the item, you can easily add that there. In linear releases, you’re going to be leveraging baselines within one project to capture the state of the artifacts at the time of release.

Parallel releases on the right-hand side, reuse and synchronization really enable you to work simultaneously across multiple projects. And these projects will be release specific projects. Each project will maintain the scope of a unique release. Parallel release approaches. There are a few different variations that you may choose from when using parallel approaches. If you need to work in parallel, you have to roll out multiple releases simultaneously. You have two suggested approaches here, two key concepts that we’ll cover. A branching approach and a mainline approach. The branching approach, which is really aptly named for a visual image of branches stretching out from the base of a tree, requires you to leverage Jama Connect’s project duplication with synchronization. So, we’ll be copying projects. We’ll also be synchronizing the items within the project in the process of creating that project copy. Your various release projects will be branched off of your original release project. So, if we’re looking at our graphic here, our one would be the original release project, the first release, and then we could branch off into other various releases. So, we’ve branched off to R2, and then we have two branches that come off of R2, R2.1 and R3. And you can see that these are copies of R2 labeled here.

The mainline approach, however, dictates that you use one centralized project for the current state of affairs or the most recent release. Projects are created for unique releases and specific elements may be picked and chosen off of the mainline project to be selected for reuse and synchronization into your specific release projects. This method allows you to pick and choose, as I said, which specific elements are impacted by a release and strategically copy them into the appropriate release project. The resulting project off of your main project may be thought of as a unique release-specific workspace. You’ll manage all your release- specific work in the outlier projects and then push changes back into the mainline via synchronization once you’ve finalized your release.

Once again, Jama Connect’s baselines are going to be leveraged once releases are pushed back into the main project to capture release milestones. So, we have our release-specific projects R1, R2, and R3. And we have our mainline project that houses all of the aggregate information. So, we are able to push and pull back and forth between these. Key capabilities in Jama Connect for each release management approach. If we’re looking at linear releases using that release field and also leveraging baselines. So, two main concepts there for the linear, and that’s the one after the other. We’re not working in tandem or in parallel. For parallel, we talked about the branching in the mainline approaches. Branching will really be leveraging the project duplication, reuse and synchronization. Whereas mainline, we’re looking at reuse, synchronization, and baselines.

Now that we’ve walked through all that, let’s hop into the tool itself and give you a quick demonstration of how to use the release field, how to branch projects, and what the mainline approach looks like as well.

To learn more about how to optimize team collaboration for streamlined product development processes, download our new eBook

DOWNLOAD NOW

EDITOR’S NOTE: This post on requirements was originally published here, by Medium, and this article was adapted from Software Requirements, Third Edition, by Karl Wiegers and Joy Beatty. If you’re interested in software requirements management, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.

Creating a Culture that Respects Requirements

The leader of a corporate requirements organization once posed a question. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?”

In another organization, a business analyst experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked me.

These questions exemplify the challenges that can arise when trying to engage business analysts, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that she’ll get what she needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as the typical business analyst is.

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary.

Get Buy-In for a New Process

It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

It’s possible the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. Those experiences would leave anyone feeling frustrated.

Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.

If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves.

Quantify the Costs of Requirement Problems

Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive — and expensive — course corrections.

Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to recognize that, without solid requirements, failure is highly likely.

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity.

Get Input from Developers, QA, and Testers

You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.

Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.

Management Needs to Lead the Charge

Management plays a dominant role in shaping an organization’s culture. The leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Yes, project-specific and localized grassroots efforts are important. But without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire.

Behaviors — not pronouncements —are evidence of a commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.

Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.

Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results. Everyone wins when they work together toward a common objective.

To learn more on the topic of requirements management, we’ve curated some of our best resources for you here.

SEE MORE RESOURCES

At a conference I attended recently, I listened to teams discuss the challenges they faced in deploying software in their organizations. The consensus was that the software is easy; the people are hard. That is to say, getting up to speed with a new software solution itself is relatively easy compared to getting people to change their behavior and successfully adopt new software.

ROI Requires that Teams Actually Use the Solution

One of the speakers said something that really stuck with me. This person said, “There is no return on investment without adoption, and there is no adoption without user acceptance.” And while that may seem obvious, many times the end user of the software is forgotten. Other priorities — like budget, schedule, and various agendas — put a lot of pressure on the deployment plan. The human aspect, as important as it is, gets lost.

Gaining Acceptance Later in the Implementation Will Cost You

When implementing a new solution, it’s imperative that you get your team on board from the get-go – and not just for the purpose of keeping them happy. Just as it’s more costly to identify inaccurate requirements late in the product delivery lifecycle, the same principle holds true for user acceptance. Resistance from users identified late is always going to be more costly than adoption issues identified and addressed early.

While implementing a new solution may be a top–down decision, it’s important to remember that the users are the ones who will need to adapt to the change. The primary impacted stakeholders (i.e. the end–users) will be more receptive to a major change if they are participating in the process, rather than being told that they must adopt a new tool. 

Change is difficult, and without a full understanding of the benefits of a new solution, teams may feel frustrated or resistant. One way to preemptively combat resistance is by identifying long- and short-term goals for each team member and encouraging users to be involved in the implementation process.

The Key to User Adoption is People

Having worked in professional services for over a decade, I have come to see just how valuable it is to understand the people side of deployments. In my years as a business analyst, I’ve seen from the inside just how difficult it can be to get people on board with new solutions, particularly those that also come with process changes, and how to make those changes stick.

My interest in this topic goes even deeper. A few years ago, I completed a master’s program in psychology where I studied human behavior and why people do or do not change. I’ve found that what I learned during my study of psychology has translated quite well to the consulting world.

In this post I won’t be able to outline the perfect adoption plan for your organization; this would be futile as no two companies have the same needs or challenges. But I will discuss the approach we recommend when planning for a solution rollout that maximizes adoption.

If You’re Taking a Trip, Bring the Whole Team Along

I’m going to start with an analogy:

Let’s say you’ve pretty much determined that everyone on your team could benefit from a vacation. You’ve even heard people say so. You’ve had some good conversations about what people want and need, and with that knowledge you pick out a destination that’s going to recharge everyone.

Next, you have to figure out what kind of transportation you’re going to use to get everyone to the identified location. You’ve gone online and talked to some others about what kind of vehicle works best for teams like yours.

So, with the information you have, you go ahead and buy the perfect car for this trip. It has all the things you need.

In case you haven’t figured out how the pieces of my analogy fit into the rollout of a new solution, here it is:

The people are those who would benefit from a new process and solution to meet their business objectives
The “destination” is that ultimate goal, where the benefits are realized
The “car” is the new software solution that gets you to that ultimate goal

But here’s something you have to consider before you embark on this journey: You have to figure out where everyone lives, what kind of baggage they’re bringing with them, and how you’re going to organize picking them all up so you can all be in the car at the same time, happily enjoying the journey to your destination. More on that in a bit.

Key Factors in Planning a Successful Software Deployment

If you’ve ever actually planned an out-of-town experience with coworkers (or family, for that matter), you know it’s impossible to make everyone happy all the time. Introducing a new way of working to your teams can be even more difficult. Why?

Before I answer that, remember that these are the main things to keep top-of-mind when planning a successful deployment:

Bringing new teams into a new solution, with new processes, is not simply a functional or technical issue; it is a people-centric change.
Benefits that require that people adopt the solution inherently require that those people change behavior.
The longer adoption problems go unaddressed the more difficult and expensive they are to address.

New data for 2019 reveals the growing gap between product complexity and requirements management. Find out more by downloading our report.

Design Your Approach Based on the Specific Needs of Your Team

Change is hard – especially when people are involved. You can put up your pie chart or line graph with anticipated benefits and have everyone nodding their heads in agreement, and you can find the perfect “car” to get you there. But you cannot assume that pointing at that amazing vacation spot on a map or showing off your awesome new vehicle will translate to motivation and acceptance for the people who must be on board in the end.

Of course, some will be on board immediately, so make sure you identify those people and train them to evangelize for the effort. These advocates are a great asset as you complete your rollout to the rest of the organization. Successful organizations often pair these early adopters with new users to help them get up to speed with the new process.  

Others may need more attention, and you must pay careful attention to their fears and objections and speak to them early and often.

Consider the Delta Between Where Your Team is Today and Where You Want to Be

You must consider the maturity of your organization and teams. Of course, it doesn’t have anything to do with the emotional maturity of the individuals (though that could come into play), but the maturity of their processes and toolset and how they’re accustomed to getting their work done today. In my experience as a consultant, I find that team maturity ranges widely, especially when it comes to requirements management processes and supporting tools.

Knowing where teams are — or their level of maturity — is important for a number of reasons, not least of which is anticipating resistance. Think about the person who is currently using a Word doc that they keep somewhere on their laptop to manage the requirements for a really complex product. This might be considered a pretty basic level of maturity.

Now, before bringing this person into a new solution, it is important to think about the degree of change being asked of this person. What does a single-source collaborative system feel like to a person coming from Word files on their computer? What resistance can you anticipate and what will be your approach? Again, communication early and often is going to be key to getting this person on board with a new solution.

Learn more about best practices for change impact analysis by reading our blog post.

Engage with People to Counteract Resistance

When change is introduced, the initial reaction from most is to resist. This isn’t necessarily a bad thing, as not all change is good. But if you don’t address resistance, it can lead to rigidity, causing teams to dig their heels in and get stuck.

When you are bringing on a new team into your deployment effort, don’t just set up training on how to use the tool. You’ll want to engage with your people at a personal level so you can uncover their anxieties and address them. You’ll need to anticipate their questions and welcome their concerns. When you know their concerns, you can address them; it’s the concerns you don’t know about that can manifest very late and cause problems for the whole deployment.

For example: Consider a person who has yet to log into the software even a month after deployment. What did we not know about this person that let them slip through the cracks? A quick way to find out is to simply ask them.

Remember that unanswered questions today turn into resistance tomorrow. Provide opportunities for people to voice their questions early so you can address them. Consider establishing clear channels for communication with users.

Explore product development strategies for systems engineers by downloading our whitepaper.

Adopt a Change Management Model to Give Your Project Structure

There are many change management models out there, and I recommend researching these until you find one that make sense for the size of your company, its culture, and your strategic goals. I personally like the ADKAR model from Prosci.

The five parts of this specific change management model fit well with how we’ve been discussing bringing on teams to improve adoption:

Awareness of the need for change.
Desire to participate and support the change.
Knowledge on how to change.
Ability to implement required skills and behaviors.
Reinforcement to sustain the change.

We’ve also seen great success from teams who have read this book: “Change Management: The People Side of Change,” by Jeffrey M. Hiatt and Timothy J. Creasey.

A good change management model, like ADKAR, will help you consider the approach you want to take as you get started on your deployment plan. You’ll want to think about:

How you will build awareness, not just of new processes and solutions, but also why you’re taking on this initiative and what you hope it will do for your organization.
How you will communicate the benefits of using the solution, particularly the “what’s in it for me” for each individual or each team.
How you will build knowledge about how the solution works, relative to the current tool, and how to get the most of it.
How will you ensure people gain the ability to use the solution with the proper training for their position, in a style that will help them feel empowered and not burdened through the learning curve.
What kind of reinforcements you can use to ensure that the process change sticks and the initiative’s objectives are met.

These are just a few examples of how to use the ADKAR model but the key is to engage with this line of thinking early and be open to adjusting as you learn more.

To learn more, watch our webinar to learn about other best practices for implementing new technologies.

With our machines and appliances talking back and people working side by side with robots, the times they are a changing. Business has to be transformed to meet the demands of a future that requires a new way of doing things, and new tools to help them get their faster. Robert T. Wanderwerf of KPMG puts it this way, “We are living in interesting times, with multiple transformation triggers all present at the same time, all equally intense.” He points to a tipping point in globalization, a major slowdown in Western economies, significant shifts in technology and energy costs, and the challenges of regulatory compliance. “When four or five significant drivers are changing at the same time, the business environment becomes highly complex.”

Growing Business Transformation:

Business perceive the signs. In a study by Forbes of 900 corporations, 93 percent said they were involved in major business transformations. They are re-designing internal processes and structures, re-aligning their business models. Some view the transformation as a wholesale turnaround. Others limit themselves to transforming specific processes, functions or areas.

The questions for many businesses are,

How necessary is a major transformation?
Will a surgical, limited repositioning be enough?
Do we need to transform our organization before we can adequately transform our business?

The Devil in Execution:

Most companies get the vision correct, but the devil is in the execution of major transformation. More than half the companies who undertake this mission fail to achieve the desired business result. Companies often underestimate the kinds of operating model refinements needed to actualize the plan across all their staff, technologies, data management and risk management components. Executives have to stop being complacent based on current revenue streams. The transformation must be continuous process–not a fast and final fix. It must start before it becomes an emergency surgery. Customers need solutions that integrate products and services. Business transformation must align the company with its customer’s projected needs.

The Transformation Charter:

The core team should draft a transformation charter around which the actual transformation process can be anchored. The charter will push your company past the common malaise that delays many such projects, especially when they are about the future. The typical transformation charter includes 10 important elements. It is critical that the transformation team has to buy into them in order for change to happen.

Name of the initiative. Giving the initiative a name for internal purposes and for wider broadcast inside and outside the company, to gain greater by-in.
Purpose or aim of the transformation. Specify the case for change and the “burning platform” you are contending with.
Transformation strategy and approach. Specify the projected participation of each staff member taking part in the transformation. (What responsibilities, what activities?) Activities and responsibilities listed should add-up to solutions.
Scope. what is in and what is out? It’s important that the team agree on what changes fall within the scope of the transformation, and what does not.
Roles and accountability. Specify the certain roles n the transformation and name the people who are to fill them.
High-level timeline. The transformation should map in time as a project, as a guide to the initiative planners. The timeline should account for budget, member availability, and the like.
Budget. Needed resources should be set aside for the transformation project. Committed resources should be accounted for.
Communication strategy. For the transformation to be successful, the plans and progress should be transparent. The rules about communication should be specific.
Initiative governance. Who will make the decisions and how will the decisions be communicated? Who will run the meetings and how should they be run?
Risk management adjustments. Transformation carries its own kind of risk. There must be a plan for a method of coping with potential risks and a survival plan adjusted around the transformation.

Transformation is an evolution and it doesn’t happen overnight. It takes careful planning, continuous review and iteration of those plans, transparency and visibility throughout the organization and a certain amount of calculated risk. By having the right tools and processes in place to help you navigate you can reach that future faster.

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

Audience	Responsibilities	Interests and Concerns	What do they need to know?	Communications Methods
Business Analysts Product Owners	Define requirements in Jama Execute user stories	Define high quality requirements quickly Understand how best to leverage Jama to capture requirements Obtain high quality requirements to build software Have all of the information needed to build a story available in one place Understand how best to leverage Jama integration to support development process Ensuring stakeholders and dev teams are bought in to the new process – don’t want resistance to change to increase workload (e.g. business not willing to use Review Center, so stories have to be exported for review) Don’t want to have to spend time in additional tools to get context for scope	Maintain momentum of use of new process – ensure teams can execute independently following new approach Provide support to help teams navigate through challenging issues Keep community abreast of key technical events (upgrades, enhancements, etc) Improve individuals’ skills to allow them to become coaches themselves to develop competency in their peers – coach the coach Affirm value	Team meetings Intranet posts Stand-ups Individual reach outs All hands meetings
Leaders and Management	Managing portfolios with multiple projects Planning and funding products and projects Reporting on progress and delivery of their products and projects to the organization	Achieving higher ROIs Delivering more business value faster Reducing costs of development and delivery Maintaining team satisfaction Very little time to meet or read e-mails Need high-level, executive style overviews (don’t want all the details)	Investment in change is working Products are getting out the door faster Number of released defects are decreasing Rework is decreasing	Intranet posts Individual reach outs Emails highlighting ROI improvements
Stakeholders and Requirement Reviewers	Review requirements and provide feedback	Don’t understand why they need to change how they provide requirement feedback	How to work with the new process and tool Affirm value of new process and tool	Team meetings Intranet posts Stand-ups Individual reach outs All hands meetings

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.

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.

Read the Cosmic Truths about Software Requirements, Part 1.

Read the Cosmic Truths about Software Requirements, Part 2.

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.

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.