Tag Archive for: Product Development & Management

Product Team

A product team and an engineering team could be viewed as two sides of the same product development coin. So, ask yourself, “Who only uses half a coin?” It’d be like using just one side of your brain.

In a perfect product development world, communications are seamless, specifications are clear, and product and engineering teams work without friction. Except, we live in the real world where life is messy, responsibilities overlap, specifications change, and the way teams interact can introduce friction.

In the rush of product development, it’s important to establish boundaries for each team while also working as a unit and develop processes to head off trouble before it begins. This only gets more complicated with bigger and more technical projects.

The Product Team

Before the first line of code is written, someone needs to own the product and fully understand what’s being built and why.

It’s the product team that should understand the why, inside and out. From ideas that turn into research that guides specifications to conversations with customers, the product team is lining up the rubber ducks in neat little rows so engineers can focus on the technical problems. What do the ducks look like? How do they sound when squeezed? And what do users want?

Product teams tend to dream big, but they must also manage expectations and align goals with those of the overall business. That’s why it’s a good idea to get an engineering lead involved early in the planning process to build cross-team cohesion.

For example, if you’re building the next great blogging platform, maybe your commenting mechanism is the “killer feature” and the engineering team needs to focus on issues like authentication and moderation tools. How much of the apple can we bite off at a time? Such questions circle back to product team responsibilities like the business goals and strategy. Prioritization is the byproduct of open talks between teams to determine what is needed and what can be delivered on time.

It’s also worth noting that tension between teams is a natural and healthy aspect of working cross-functionally. Each team has its own set of internal goals, but those must align with overall strategic goals for the company (or product).

The product manager serves as the CEO for whatever is being built. If he or she asks for the moon, there must also be the understanding of the challenges that await.

We’ve probably all been in a meeting where something ambitious is proposed and the engineering team rolls their eyes, thinking, “If we could build that we’d all be zillionaires.” The balance here is one of awareness.

Technical teams need to be just as ambitious as their product counterparts, and that means understanding a little bit of each other’s worlds to know what’s feasible and what will cause deadlines to crash.

https://resources.jamasoftware.com/blog/a-guide-to-good-systems-engineering-practices-the-basics-and-beyond

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

The Engineering Team

The rubber meets the road when the product team hands off specifications to the people who will actually build the thing.

Engineering is the technical team of developers and managers who write the code and create the front end, so the clearer the guidance they get upfront, the better. That doesn’t mean micromanaging from the product team, but it does mean regular check-ins to increase buy-in, build cohesion, and avoid surprises.

Going back to our blogging platform example, let’s say there are some whiz-bang features on the front end that will dazzle users. A product manager might tell engineering to focus on those features. If the product team has done its job, the tech leads can accurately inform them how long it will take to implement the features.

However, they could just as easily warn the product team that there are backend issues to tackle to enable those frontend goodies. There’s no way to have one without the other, and this is another area where the tension comes in, as timelines might have to be readjusted.

When teams understand that they’re on the same side, everyone can take a step back to see the full map and make sure they’re headed to the same destination. It’s also where teams who understand each other excel.

Product must comprehend the engineering team’s needs, and engineering must grasp the importance of the product planning that came before. Maybe it’s a matter of a few sprints to see where the marquee feature is in a week. Or perhaps a lower-priority feature that really puts a kink in the line just needs to be delayed.

Either way, the only solution is to drop the egos and hash things out in realistic terms. Again, if product has done the job, both teams should be like looking at the release like a big X on a treasure map and walking there together.

RELATED: The Complete Guide to the Systems Engineering Body of Knowledge (SEBoK)

One Team

If all of this sounds familiar, you’re not alone. Everyone in these teams is working under a number of different dynamics.

It could be that product feels it has defined everything so thoroughly that the engineering team can take the ball to the goal after a simple handoff. Of course, that is rarely the case.

More likely, there’s a stream of reviews to comb through and see how things are advancing (which, if you’re using the right solutions, can be handled faster and with less meetings) while moving the goalposts when one side reports a change in the variables.

So, what do you do? Learn to function as one team while respecting each other’s territory. After all, you’re all headed to the same goal. Even if your organization compartmentalizes each side, find a way to cross the streams. For many, the move from Waterfall development to Agile created a more efficient, functional model for developers, and a variation on that theme can serve you here as well.

First, create a great set of fundamentals with your product team by bringing in engineers as early in the planning stages as possible. Ask what’s feasible and go to lunch and dream about unlimited budgets. Integrate the engineering team as best you can, because their insight will save squabbling down the road. Then create specifications that are realistic.

Next, empower each side of the table with respect. Product may want the moon tomorrow and engineering will explain how much lift is needed to get there, so friction is inevitable. In the big picture though, both sides are arguing for the same goal, so keep that front-of-mind and allow room for either side to concede territory as needed. Conflict is normal and necessary, but if one side is utterly powerless and is continuously overrun, the “team” notion falls apart and the idea of collaboration breaks down.

If both teams are aligned, truly listening and making necessary adjustments, there’s no reason even large, complex projects can’t be finished on time and on budget. It takes work, especially if an organization is averse to cross-functional teamwork.

The payoff, though, is happier, more productive teams who share in the product’s success. It’s up to both sides to come to the table ready to cooperate.

Does that mean having certain boundaries? Yes! It’s unlikely the engineering team has done the market research to say whether a feature is desired by users. And it’s equally unlikely that the product team will accept a major delay for technical implementation if it was in the original specification.

Each side has a job to do, but the key is understanding that everyone is marching under the same umbrella in the end. That’s why it’s important to play the role you’re in while listening and accepting the experience and knowledge of the entire team.


preparing for fda inspection

FDA Inspection

Intro

In Part One of this two-blog series, I shared 5 best practices to prepare your organization for FDA inspection success. Inspections by the FDA can lead to regulatory action and consequences such as warning letters, recalls, and consent decrees. Thus, you want to put your best foot forward to demonstrate the compliance of your Quality Management System (QMS). In this Part 2, we’ll focus on the logistics for running a smooth and efficient inspection.

1: Tone and philosophy

First and foremost, everyone interacting with the FDA should be truthful, professional, and courteous. While this may seem like common sense, it is worthwhile to emphasize. The FDA is there to protect the public good by finding the evidence that your Quality Management System is compliant, so convey that you are there to help them in that goal.

RELATED POST: Complying with FDA Design Control Requirements Using Requirements Management Principles

2: Typical Roles

In its aim to demonstrate compliance to FDA regulations, an organization is balancing 3 things: 1) Providing the investigator with requested documents, information, and subject matter experts (SMEs) in a timely manner; 2) Understanding what topics the investigator may request go to next and prepare accordingly; and 3) Keeping a record of what the investigator has examined.

To that end, here are roles to have during an inspection.

  • Host – Serves as the primary interface with the investigator. This role is typically best served by your Head of Quality, as that individual understands the organization’s QMS and understands the FDA approach. If there is more than one investigator, there should be one host per investigator.
  • Scribe – Takes notes on conversations with the investigator and what the investigator is examining throughout the inspection. Like the host, assign one scribe per investigator. Folks great at listening and typing quickly make for great scribes.
  • Back Room lead – This person runs the Back Room, coordinating all the requests coming in, sending requests to the front room, and prepping SMEs. Even more importantly, this person is monitoring what is happening in the front room, anticipating areas of inquiry, and preparing accordingly.
  • Doc Control – Whether your organization is paper based, 100% with electronic records, or a hybrid, Doc Control is key to retrieving those records in a timely manner and keeping track of what has been presented and reviewed by the investigator.
  • Tech Reviewers – These folks inspect records before they head into the Front Room to ensure it’s the right document and noticing any issues that the host should be aware of before they are presented to the investigator.
  • Runners – Individuals who can retrieve information and SMEs as needed.

3: Set up a Front Room and Back Room

Typically a conference room, the Front Room is where activities with the investigator(s) are centralized. Aside from the investigator, Individuals are limited the bulk of the time to the host, scribe, and SME’s.

The Back Room is where document, information, and SME preparation occurs. A large conference room works best, not too far from the Front Room.

RELATED POST: The Rapid Rise of Digital Health Technology: Challenges and Keys to Success

4: Communicating between the Front Room and Back Room

Determine how information between the Front Room and Back Room will be shared. This includes document and information requests, as well as the conversations that are occurring. One way that works is a web-conference call (no audio or video) in which the scribe shares a document in which they are typing in live. This shared screen is then projected in the Back Room.

Direct chat channels between the scribe and Back Room Lead are also helpful to communicate information the Host should be aware of, like any delays in document retrieval, etc.

5: Documents/Request Management

Determine how documents and request management will occur. There will be time periods when requests are coming fast and furiously. Whether through a spreadsheet or database, it is important to keep track of what has been requested, when it has been presented to the investigator, and returning any hard copy records after the investigator is through with them.

Providing the investigator with the requests in a timely manner demonstrates that your organization’s QMS is under control and has nothing to hide.  Keeping a file of everything the investigator has reviewed is key if there is any action taken by the FDA that requires formal response by your organization. It is vital to know what was specifically reviewed so it can be referenced and referred to as necessary to inform those responses.

Closing

Your organization has worked hard to build and run its Quality Management System and prepare for an FDA inspection. Implement these tips to run an efficient inspection and demonstrate your compliance to FDA regulations.

READ MORE


requirements traceability

Derived requirements traceability is a form of requirements management focused on tracing requirements that aren’t explicitly defined in higher-level requirements, but which are necessary for meeting them and for making the overall system work as expected. In derived requirements traceability, teams will document the dependencies and logical links between these lower-level requirements and other system elements.

Derived Requirements, Explained

For example, let’s say a hypothetical automotive system has a higher-level requirement stating that it must be capable of traveling at very high speeds. A derived requirement in this case might say that the system also needs to be lightweight. While this requirement is not defined by the project stakeholders, satisfying it is essential to the engineering process of the entire system. If the end result is not light enough, the original requirement for fast travel won’t be met, either.

Another way to look at it: Derived requirements are decomposed from other requirements, including business and stakeholder requirements. Adequately tracing them serves several general purposes:

  • It facilitates impact analysis, by helping identify all the work products that might need modification before implementing a proposed change.
  • It follows the life of a requirement, both forward and backward in relation to customer needs, and from origin through implementation.
  • It creates a roadmap, showing at which points each requirement or business rule was implemented.
  • It simplifies the packaging up of requirements baselines, which are snapshots of approved requirements assigned to product releases at points in time.
  • It helps meet certain medical regulatory requirements, such as the design controls under FDA CFR 21 820.30 for aligning device design inputs and outputs.

In practice, proper derived requirements traceability will involve cataloging all of the connections between derived requirements and other types of requirements, plus business rules, architecture and design components, source code modules, test cases, help files, and documentation. This process ensures that the product in question is ultimately maintainable, compliant, and tightly aligned with customer expectations.

Enabling Traceability as Part of Requirements Management

For sufficient derived requirements traceability, each requirement must have a unique and persistent label that allows for unambiguous tracking throughout the project. A centralized, modern requirements management solution is preferable to numerous discrete requirements documents for this purpose.

Not only does such a management tool provide one convenient place for collecting feedback and collaborating in real time on reviews and approvals, but it also supports live traceability of upstream and downstream relationships, with clear visibility into the impact of changes on all levels of requirements as well as test coverage. Accordingly, project teams can set up four distinct types of traceability links for their derived requirements.

Four types of requirements traceability

Figure 1. Four types of requirements traceability.

RELATED: Vave Health Migrates to Jama Connect® to Accelerate Development and FDA Clearance

The Four Types of Derived Requirements Traceability

1. Forward to Requirements

When customer needs evolve, requirements may have to be adjusted in response. By making these adjustments, project teams can keep pace with changes in customers priorities, introductions of new business rules, and modifications of existing rules, among other events.

2. Backward From Requirements

Tracking backward from requirements can provide clarity into the origin of each derived requirement. For instance, a requirements management tool could show the link between the derived requirement, the requirement it came from, and the customer use case being addressed.

3. Forward From Requirements

Once derived requirements begin flowing into downstream deliverables during product development, it’s possible to draw trace relationships between requirements and their corresponding elements. This type of link provides assurance that every requirement is satisfied by a particular component.

4. Backward to Requirements

Finally, this type of link allows for visibility into why certain features were created. Consider how most applications include lines of code that don’t directly relate to stakeholder requirements. Even so, it is important to know why a software engineer wrote that code in the first place.

While a full accounting of all four types is beyond the scope of this piece, let’s look at a more in-depth example of the fourth type. Suppose a tester discovers unexpected functionality with no corresponding requirement. It could indicate two divergent possibilities:

  • The underlying code might have been implemented to meet a legitimate implied (derived) requirement, which could then be added to the requirements specification.
  • Alternatively, it might simply be orphan code that no longer belongs in the current product.

Traceability links create clarity in such situations, shining a light on how the different pieces of a system all fit together. Conversely, test cases derived from – and traced back to – individual requirements offer a mechanism for detecting unimplemented requirements, because the tester won’t find the expected functionality.

Some possible requirements traceability links.

Figure 2. Some possible requirements traceability links.

There are many types of traceability relationships possible within a project, and not all of them will be needed on every project. However, there are good motivations for implementing derived requirements traceability, via a best-in-breed solution with flexibility that can be leveraged as needed for a given project.

RELATED: How Jama Connect® Helps Program Managers with DOD 5000 Adaptive Acquisition Framework

The Main Motivations for Derived Requirements Traceability

At a high level, traceability contributes to a more efficient product lifecycle and superior project management. More specific reasons for implementing it include:

Certification

Traceability data can support certification of safety-critical products, by demonstrating that all requirements were implemented.

Impact analysis

By tracing derived requirements, it’s less likely that something will be overlooked when determining the effects of changes to requirements.

Maintenance

Clear traceability simplifies maintenance, as changes (e.g., in response to updates to government regulations or corporate policies) can be performed with more confidence. A modern requirements management tool makes it easier to show where each applicable rule was addressed in requirements.

Project tracking

Traceability information offers an accurate record of the implementation status of planned functionality, with missing links indicating work products not yet created.

Reengineering

List functions in a legacy system set for replacement and use traceability data to record where they were addressed in the new system’s requirements and software components.

Reuse

With derived requirements traceability in place, it’s more practical to reuse product components by identifying packages of related requirements, designs, code, and tests.

Risk reduction

Documenting component interconnections reduces risk in the event that a key team member with essential knowledge about the system departs the project.

Testing

The links between requirements, tests, and code help indicate the likely locations of bugs when a test yields an unexpected result. Also, knowing which tests verify which requirements will save time by allowing for the elimination of redundant tests.

The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.


What is requirements traceability

Product complexity is growing at an exponential rate. As it does, requirements move between more and more departments and stakeholders throughout the course of the development process. Requirements traceability helps product teams overcome one of the biggest challenges they face with requirements management.

The number of decision points is higher than it’s ever been. Each decision needs to be made understanding the impact on the requirement itself and on the product overall. It is essential to maintain visibility into the activity taking place and to be able to tie it all together.

That’s where requirements traceability comes in. What follows is a look at the definition of requirements traceability, as well as its purpose, importance, and benefits. You’ll also find common challenges of requirements traceability, along with a few ideas to help you start overcoming those obstacles today.

Common challenges 

If all this sounds like traceability is too difficult, fear not. While there are some challenges to requirements traceability, there are also many templates and tools you can use to streamline the process (more on that below). For now, let’s tackle some of the challenges so you can see how they can be overcome.

Differing organizational viewpoints.

Not everyone has the same understanding of why and how traceability should be performed. Stakeholders in sponsor or management positions may only view requirements traceability from a standard or regulatory perspective. They see it as a “must-have” but may not understand the additional benefits of requirements traceability (as discussed above) in the way a project or systems engineer might.

One way to tackle this obstacle is to educate stakeholders on what can be achieved if end-to-end traceability is achieved. Share this article with everyone involved in your development process so they can have a basic understanding of why requirements traceability is an essential part of requirements management, beyond simply knowing they need it to cover their bases.

Organization-wide adoption.

There are a variety of reasons a company might be slow to adopt traceability. Training is one such example. As considered regarding stakeholders, not all teams or individuals working on a project know why traceability is so crucial, or they simply may not know how to execute proper traceability correctly. Additionally, some people may be worried that traceability data from their decision points could come back to bite them.

If this is a challenge for your organization, again, education is imperative. But even beyond that, you need to create a culture in which traceability is seen as an inherent part of the development process. Start by creating clear policies regarding how the organization manages traceability. Then develop a positive training program for all new and existing employees to complete. If you choose a requirements management tool, make sure it has a strong track record of being intuitive and easy to use software that adapts to your process—not the other way around.

Want the inside scoop? See what users are saying about Jama Connect
Cost of implementation.

Getting an entire development organization on the same page regarding requirements traceability, then ensuring proper execution, can be a costly endeavor. The time spent developing policies, conducting training, and creating/maintaining traceability data add up and can even make folks feel less productive. Additionally, you may choose to adopt a traceability tool to streamline your process, which means upfront costs will be higher than previous projects.

Overcoming this obstacle requires a mindset change. We urge you to consider the cost of doing nothing. Unproductive work time, lengthy time-to-market, rework, and defects are all extremely expensive symptoms of inadequate requirements traceability. Each of these carries a hefty price tag. For a look at exactly how much these complications could be costing your organization, check out the calculators on pages 9-11 in our Buyer’s Guide. While there are costs to implementing requirements traceability and management tools, the amount saved throughout the development process far outweighs the short-term investment.

Managing change.

When building complex products, change is inevitable. It is essential that team members know about the changes and scope their impact across the product development lifecycle. That means looking closely at any related system requirements, downstream requirements, and verification tests that may be affected.

Performing this activity can be cumbersome and time consuming with manual requirements traceability tools. And the associated risks are similar to doing nothing, simply because you cannot be sure you’ve accounted for everything when dealing with static documents and human error.

If you’ve experienced this setback in your organization, it may be time to explore automated requirements management tools that enable live traceability with living requirements.

Jama Connect’s Requirements Management Enables Live Traceability™ Across Your Development Process

Bridge engineering siloes across development, test, and risk activities. Provide end-to-end compliance, risk mitigation, and process improvement with our intuitive, award-winning requirements management platform. Learn more! 

Improper management tools.

Some development teams are still tracing requirement relationships using Word or Excel documents and collaborating via email. A Requirements Traceability Matrix is one example of a document that manually traces elements of requirements management including, business requirements, objectives, design elements, and test cases via a spreadsheet. Teams input the list of requirements and fill in the related data. The spreadsheet is static but is updated manually by the team throughout the development lifecycle.

There can be advantages to using a Requirements Traceability Matrix if you are developing a product that doesn’t have many requirements. And it is better than not tracing at all. You can even use a template to create a Requirements Traceability Matrix. However, if your product is complex, with many requirements, you’ll likely experience many of the challenges discussed above.

In the case of complex products, a Requirements Traceability Matrix does not have the functionality you’ll need to keep up with the pace of change and create a quality product in the timeframe required by stakeholders. Flexible requirements management tools like Jama Connect can even capture trace relationships across teams and toolsets, further enhancing the benefits of traceability.

Insufficient compliance framework.

Regulated industries need requirements management to demonstrate compliance with industry standards. There are specific ways reviewers and regulators must receive regulatory submissions. To pass an audit you must present proof of comprehensive traceability.

If comprehensive traceability wasn’t performed throughout your development process, a lot of time will be committed to gathering the necessary information after the fact. Even if traceability was meticulously maintained in Word or Excel, there will still be time spent compiling it into an acceptable format for regulatory submission. In the meantime, competitors that make traceability inherent to their process will be first to market.

Sound familiar? Luckily, there are tools that perform end-to-end traceability and come with frameworks aligned with industry standards. Requirements management tools like Jama Connect simplify the audit process with export templates, thus speeding up the compliance presentation process.

RELATED POST: Requirements Management Tools and Software

Templates and tools to streamline the requirements traceability process

There are numerous tools available to assist with the requirements traceability process. It’s important to assess your needs to know what is best for you.

Are you creating a straightforward product that doesn’t have functional safety or regulatory requirements? If so, a Requirements Traceability Matrix may suffice. Download this Requirements Traceability Matrix template to get started today.

Are you creating a multifaceted product with both software and hardware components? Will you be required to prove functional safety or regulatory compliance? In these cases, you’ll need a requirements management tool with bidirectional traceability and compliance templates you can easily export.

Here’s some additional recommended content on traceability you might find helpful:


What is Traceability?

What is traceability? In this blog, learn its definition and why it is crucial for product teams.

Product complexity is growing at an exponential rate. As it does, requirements move between more and more departments and stakeholders throughout the course of the development process. Requirements traceability helps product teams overcome one of the biggest challenges they face with requirements management.

The number of decision points is higher than it’s ever been. Each decision needs to be made understanding the impact on the requirement itself and on the product overall. It is essential to maintain visibility into the activity taking place and to be able to tie it all together.

That’s where requirements traceability comes in. What follows is a look at the definition of requirements traceability, as well as its purpose, importance, and benefits. You’ll also find its common challenges, along with a few ideas to help you start overcoming those obstacles today.

The Definition

Traceability (or requirements traceability) is the tracking of requirements throughout the product development lifecycle. It is a documented thread that provides forward and backward visibility into all activity surrounding each requirement (including design, development, testing, and support). Requirements traceability helps minimize the risk of negative outcomes and maximize productivity. Its benefits include greater team efficiency, easier regulatory compliance, and higher-quality products.

Complex Upstream and Downstream Requirements Traceability

What’s its Purpose and Importance?

Traceability enables product teams to associate a specific requirement with all the related project artifacts, as well as other requirements, both forward and backward, so that anyone can see how the activity relates to the requirement—and vice versa—at any point during development. This functionality, also called live traceability, fosters team collaboration and enables early detection of possible production risks.

Think of it this way: How important is it to have your products developed correctly in terms of definition, quality, and timing? Mission critical, right? That’s why requirements traceability is so critical.

Let’s take a look at some of the benefits of requirements traceability throughout the product development lifecycle. For example:

  • Simplifies project estimates
  • Enhances process visibility
  • Increases development efficiency
  • Improves impact analysis of change
  • Demonstrates verification and validation
  • Strengthens product quality
  • Proves compliance or functional safety

A single line of sight on a requirement, or a digital thread, is supremely important for application lifecycle management (ALM) and product lifecycle management (PLM). Both endure tight timelines and increasing numbers of requirements — including those from regulations, where compliance is non-negotiable.

Knowing the relationship between requirements, risk, tests, and so forth, is the difference between developing a compliant product on time and getting stuck in rework, delaying launches, and dealing with unhappy stakeholders. With requirements traceability, you don’t have to compromise on speed or quality.

The bottom line is that end-to-end traceability confirms you’re building the right thing and helps you prove compliance or functional safety. Without it, your development efficiency and product quality are in jeopardy.

Forward, backward, and bidirectional: The mechanics of creating a digital thread

To connect all the phases of the product development lifecycle, from customer needs through support, four distinct kinds of links must be used to thread the process end-to-end. This includes high-level requirements as well as derived requirements—those not specifically defined but necessary for meeting defined requirements or having the system work as expected. Derived requirements must also be adequately traced to reap the full benefits of live traceability.

RELATED POST: Building an Audit Trail Through Live Traceability

Forward

There are two kinds of forward traceability: forward to requirements and forward from requirements. They both trace from an upstream component to downstream artifacts. The difference is in where they begin.

Forward to requirements traces from customer need to requirements. This is important because customer needs can evolve over time. If they do, requirements may need to change as a result. Following this type of forward traceability enables teams to be informed of changes in priorities at any time throughout development.

Forward from requirements traces relationships between requirements and corresponding downstream artifacts, including test cases. This type of trace ensures that each requirement is not only satisfied but verified and validated.

Backward Trace

Backward

Like forward traceability, there are two kinds of backward traceability. This pair traces from an endpoint, or downstream work product, to upstream elements. The two types of backward traceability have differing starting points.

Backward from requirements gives insight on how a requirement came to be by linking the requirement to the customer use case it addresses. This enables teams to improve decision making by understanding the origin of a requirement.

Backward to requirements begins at performed work and traces to its requirement. It gives visibility into why specific items were created and how different pieces of a system fit together. Tracing in this way also allows testers to find gaps or missing requirements.

RELATED POST: Checklist: Selecting a Requirements Management Tool

Bidirectional

Bidirectional requirements traceability is the ability to perform both forward and backward traceability. Bidirectional traceability is optimal because it gives teams full visibility from requirements specifications through building, testing, changes, defects, and back again. Traceability of this caliber can only be achieved through automated requirements management tools, such as Jama Connect®.

Requirements Traceability Relationship Map

Here’s some additional recommended content on traceability you might find helpful: