There are three main aspects of a project that tend to be in regular tension with one another: quality, schedule, cost. Typically, project management is about managing the tension that arises as focus and prioritization shift between these three elements.

Many times, organizations are forced to decide between pushing schedules, reducing costs, spending more on resources, and maintaining quality throughout the life of a product’s development. As a part of a product development lifecycle, requirements play a very important role in attempting to reduce or at least mitigate the tension between these areas.

Know What You’re Developing, and Why

Quality is, of course, a highly significant aspect of any product development effort. For many organizations, quality is paramount — especially in the case of highly-regulated industries like medical devices or automobiles, where quality concerns essentially amount to safety risks.

To ensure quality, you need to know what you are developing and why. And then, what are the requirements that meet those needs? In other words, a product should be defined to a meaningful degree before development begins. The distinction and order of “why” and “how” before “what” is a key element of requirements management.

This certainly does not mean that the product must be fully defined and agreed upon before any development happens. However, there should be enough definition to demonstrate that stakeholders agree on the needs and the high-level requirements meeting those needs, including acceptance criteria.

This is where a single source system becomes crucial, allowing cross-functional visibility to facilitate feedback and reviews to reduce the time and work between definition and development.

Requirements and Quality Assurance

Requirements are used to define the qualities of a system, features, or subsystem that meet actual user needs. A dedicated requirements management platform, like Jama Connect, helps ensure that development activities trace to actual needs and builds confidence that those needs are being addressed through gap analysis.

A gap in coverage happens when a need has been identified, but the engineering response to that need has not been provided. We often see this when higher level requirements don’t relate to anything, such as when an epic might be lacking stories.

Another aspect of improving quality is getting the right people involved at the right time. More eyes can sometimes be a hindrance to speed, but having people show up late to a discussion is usually worse. It’s important to make sure that not only the correct people are involved, but that the process for collaboration and reviews is clearly defined and well supported with a purpose-built solution, like Jama Connect.

Lastly, a discussion about quality would be incomplete without verification and validation (V&V). When writing requirements, it’s important to remember that the ability for a requirement to be verified is a key quality of a good requirement.

Typically, verification will happen against each requirement and is established by acceptance criteria determined while defining requirements. Validation, on the other hand, is concerned with whether or not you built the right product.

Through verification, you may determine that the product or feature works, but validation is focused on answering whether you actually met the need you set out to fulfill.

When considering the decisions and trade-offs made around quality, especially in relation to cost and schedule, having verification and validation activities closely tied into requirements definition can bring quality discussions closer to the front-end of an effort and avoid impacts of finding issues late in the lifecycle. Having a live and actionable trace matrix is essential in supporting this, especially where a product’s quality is non-negotiable.

Staying on Schedule Requires Visibility and Tracking

Schedules are mostly concerned with timelines and meeting time-based delivery of the product or its features.

In order to manage a project, the approach needs to be determined and then the infrastructure put in place to support that approach. From a product definition standpoint, the requirements may need to be organized in a way that makes sense for decomposition and capturing the granularity needed to properly define and align the product and teams. From there, development teams will collect those requirements into backlogs of work and manage the development of activities using a preferred methodology.

A quick way to build efficiency into this process, regardless of the methodologies implemented, is to manage at the level of discrete, individual items and move away from documents.

In terms of releasing pressure on the schedule, the idea is that instead of gating development and work based on large documents, manage the state of individual requirements, moving them independently through definition, acceptance and into development. Of course, logical groupings of requirements will necessitate some structure, but just identifying that appropriate organization will minimize the collection size and improve speed.

An obvious detriment to the schedule is people working on the wrong things. This can happen when teams do not have visibility into how what they are working on connects to the larger product definition.

To avoid this, consider the trace to a defined need as part of the approval and criteria for adding requirements into the backlog. Working on requirements lacking this trace runs the risk of working on the wrong thing. Of course, as you get into development cycles, new work may be discovered that helps facilitate and enable development, but this should be considered as potential scope creep.

Lastly, when it comes to schedule, it’s important that teams are tracking their work. You’ll likely be asking different questions at different phases of the effort. The important thing is that you clearly identify what you need to track to ensure progress and minimize issues that might fall through the cracks.

Once you know what you need to track, then you need to capture that data. In Jama Connect, as an example, you can track the state of requirements across the workflow, from draft through approval, which helps determine progress and find roadblocks. At a minimum, you’ll want to consider tracking the status of testing as well. That information is not the only key to the schedule but is also very important when assessing quality.

Avoid Rework by Defining, Agreeing, and then Developing

From a project management standpoint, the key metric related to cost is typically actuals again budget, where we’d take a baseline of the estimated cost and compare it to the actual cost to date. However, the cost is about more than money spent against the budget. It is also concerned with the cost of missed opportunities or lost market share.

One of the most expensive occurrences in product development is rework. Rework happens when teams get through some development activities only to find that they didn’t build the right thing or that the user needs are not actually fulfilled by what was developed.

To avoid or at least reduce rework, teams must define, agree, and then develop. The more teams can align around what it is you’re actually building and just how that thing will be verified, the better-aligned development activities will be. Additionally, as requirements are generated, verification should be defined at each level of abstraction.

Another way that teams can avoid cost and potentially positively impact their schedule is to reduce the time that teams are waiting to begin activities. This tends to happen when visibility across a development lifecycle is low and access to information is limited.

Using a single source system, like Jama Connect, and providing individual requirement status allows teams to start acting on information as it’s available and ready. As an example, if requirements are accessible and their status is visible, quality teams who handle V&V activities can begin their planning and verification activities much earlier than if they were waiting for documents to be released.

Change is another aspect of cost that’s often overlooked. Change is inevitable as we learn new information and get feedback throughout the product lifecycle. However, the cost of change can be mitigated by identifying and evaluating the impact of that change across the product. Change to a single requirement could impact definition and verification across multiple degrees of separation. Using trace, costs can be avoided by identifying and communicating these impacts early, even before applying the change.

Inform and Justify Decisions to Understand Impacts

In order to balance the three elements of project management discussed here, consider decisions that are being made and the tradeoffs determined during the lifecycle of your product development effort. In most cases, the decisions are working to balance quality, schedule, and cost.

The key to project management is being able to inform decision-making, justify these decisions, and understand the impacts. Properly managing your requirements can inform these decisions by being able to track requirements by their individual state, assess the trace for impacts and gaps, and ensure visibility and communication across teams.

Want to learn more about successfully managing every project? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.