Compliance & Regulation Archives

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.

This is part one of a two-part series. Part two is available here.

FDA Inspection

FDA inspections can be daunting, especially for an organization that is expecting its first one. In part one of a two-blog series, here are five best practices to prepare your organization for success:

1: Understand why the FDA will perform an inspection

The first step in preparing for a successful FDA inspection is understanding why your facility and Quality System (QS) are being inspected. Whether it’s a pre-approval inspection, a biennial audit, or for‑cause, knowing where the FDA will be focusing will help you focus on how to prepare.

2: Learn what an FDA Investigation is like

Another key understanding is that an FDA inspection is not just another audit. The inspection is not the same as an ISO 13485 certification audit, internal audit, or supplier audit. While not all FDA investigators are identical, in general, FDA inspections are much more rigorous and intense in nature.

Thus, educating yourself and your organization on what to expect during an FDA inspection is important. Many resources are available at the FDA’s website, including guides for medical device manufacturers and their Quality System Inspection Technique (QSIT). Another aspect to know is an inspection will assess compliance to 21 CFR 820 (the Quality System), as well as other parts, including 803 (MDR), 821 (Tracking), 806 (Corrections and Removals), and 807 (Registration and Listing).

3: Identify Subject Matter Experts (SMEs) for processes and devices

Identify subject matter experts (SMEs) for QS processes and devices. These individuals should be knowledgeable with the subject matter, as well as able to communicate well with the investigator. While your organization’s records should speak for themselves, having an individual who can guide an investigator as necessary makes the inspection run more smoothly and efficiently.

4: Perform an assessment and address gaps

For an organization preparing for its first FDA inspection, review your Quality System procedures and records, with increased attention to the areas relevant to the anticipated focus of the inspection.

Many organizations also design their Quality Systems for ISO 13485 compliance, and while ISO 13485 and the FDA Quality Systems Regulations (QSR) are similar, there are some differences. Note, the FDA has indicated that harmonizing and modernizing the Quality System Regulation (QSR) with ISO 13485 is an active initiative. Until then, ensure your Quality System covers all aspects required by the FDA. One available tool that maps the FDA 21 CFR to ISO 13485:2016 is AAMI TIR102:2019.

Also audit your recent Quality Systems records for 2 reasons, 1) identify any issues for compliance to your organization’s procedures, and 2) familiarize yourself with any issues so they can be reviewed clearly by the SME if those topics come up in the investigation. Use a reputable auditor that is familiar with FDA inspections and how investigators are trained. Involve your SMEs so they are prepared as well.

Records to review include those associated with the particular device of focus. For example, in a Pre-Market Approval (PMA) inspection, ensure an SME can walk an investigator through the Design History File of the device to demonstrate the design controls were adequately met. Before the FDA arrives is a good time to ensure that there is evidence that all design inputs are verified and all user needs and all intended uses have been validated.

Ensure that your firm is registered and that your device listings are up to date.

5: Perform mock inspection(s)

Mock inspections serve a number of purposes when preparing for an FDA inspection. They allow individuals that may be involved, including SMEs, an opportunity to practice, can identify areas of concern that can be addressed before the FDA arrives, and give your organization an opportunity to practice the logistics of hosting an FDA inspection.

Again, use an experienced auditor familiar with FDA inspections and the mindset of FDA investigators.

As with any large endeavor, preparation is key. These best practices provide you with the path and resources to educate and prepare your organization for an FDA inspection.

Visit part two of this blog series for best practices and tips regarding the logistics of running a smooth and efficient inspection.

Tag Archive for: Compliance & Regulation