Tag Archive for: product development

The popularity of Agile methodology, along with the increasing trend toward automation in software development, has pushed requirements management solutions to evolve. The misconception that Agile methodology doesn’t work in regulated industries is outdated, but regulated industries have, justifiably enough, specific expectations of their requirements management (RM) solutions, and those expectations continue to drive change in the market.

A recent report from Forrester Research, “Now Tech: Agile Requirements Management Tools, Q2 2018,” outlines the state of the market for Agile RM solutions and lays out the questions customers should ask when selecting the right requirements solution for their space.

Why invest in requirements management?

According to Forrester, it’s not just highly regulated industries and organizations involved in complex product development that can benefit from a requirements solution.

In spite of the “a coalition of Agile aficionados arguing that it’s unnecessary to formally collect and manage requirements,” the report suggests that best-in-class RM solutions can significantly improve product design and delivery for Agile development teams: “In the face of increasing regulations, connected products for the internet of things (IoT), and scaling Agile practices, AD&D [application development and delivery] leaders long for something to bring traceability and auditability to their processes without sacrificing speed.”

Why do you need traceability?

The right RM solution enhances development transparency through traceability. Traceability is a roadmap that shows you where in the product development lifecycle each requirement or business rule was implemented. With traceability, teams are better-equipped to perform impact analysis – i.e., to assess the consequences of proposed changes. This is crucial in complex product development, where simple changes can have far-reaching impacts, and it’s tough to isolate every system component that might be affected by a change in requirements.

Teams facing increasing complexity, pressure to comply with industry regulations, and the need to measure customer value must be able to search, track, and connect interdependent requirements. Achieving a faster time to market demands that teams collaborate quickly and effectively while they work on building out traceable requirements and test cases.

Why is it important to reduce tech debt?

Forrester reports that RM solutions can also help Agile teams reduce technical debt. Agile teams are focused on moving quickly, so they sometimes fall back on fixes that are easy to implement right now, but that will require rework down the line. Basically, tech debt refers to the work you’ll have to do tomorrow because you cut corners today.

You can’t avoid tech debt entirely, and you shouldn’t even try; you can’t move quickly without accumulating a little. But as the Agile methodology becomes even more widespread and project complexity continues to grow, RM tools will help development teams understand what has been done, what will be affected in the next sprint, and how to improve collaboration within distributed teams.

Finally, the report suggests, development teams can use RM solutions to embed visual modeling, design, and prototyping into their product development process. By modeling customer journeys, business processes, system designs, and user-interface components, teams can ensure that the final deliverable meets stakeholder expectations.

How has Agile changed requirements management?

Agile teams expect to move fast, so RM solutions looking to penetrate this market must meet developers’ need for speed. Transparency is another priority for Agile teams, and the transparency and traceability offered by an RM platform empowers teams to move beyond what the report dubs “static, text-based requirements.” As we noted above, traceability enables more effective and timely impact analysis, a critical consideration for rapidly evolving requirements.

Even though plenty of Agile teams see the value of a requirements solution, Forrester notes that “vendors have shied away from the term [requirements management] and evolved their offerings to fit new product niches.” Part of this avoidance of the term is because people tend to associate “requirements management” with clunky, tedious processes that lacked the efficiency and ease of use that current solutions offer. In contrast, the requirements solutions favored by Agile teams are less highly specialized; they have different capabilities and focus on different segments of the development lifecycle. As such, the Forrester report suggests that Agile teams consider whether the best solution for them is not one solution but a combination.

How do you choose the right requirements solution?

To maximize success in requirements management, the report found, teams should choose a platform that works for their discipline (product management, engineering) and their industry (medical, automotive).

As we wrote in our recent post, “Systems Thinking for Complex Product Development,” collaboration is easier and delivers better results when teams are encouraged to find approaches that are effective for them within their disciplines.

Before investing in a RM solution, Forrester suggests that Agile leaders engage in some strategic thinking to determine which RM platform will deliver the most value in concert with other tools and solutions. Decision-makers should:

  • Audit the tools already in use. Company and industry requirements drive investment, so understanding the existing ecosystem of tools already in place at your organization is essential in choosing the best RM solution for your particular needs. Take a close look at your Agile planning/project management, design, testing, and continuous integration tools to determine the best solution for your organization.
  • Identify where requirements fall apart. If you have issues uncovering requirements to begin with, consider a tool with more advanced collaboration, design, and modeling capabilities to help you define exactly what you want to build. If your challenge is understanding the impact of requirements, passing tests, or avoiding bugs in production, you need a tool with greater traceability and robust reporting capabilities that can integrate with automated testing tools.
  • Anticipate change. What changes are ahead for your industry? How will you be affected by new or evolving government regulations? Will your products be integrated with sensitive customer information? Now is the time to start laying the foundations for compliance with these future requirements.
  • Right-size the need for documentation. What’s the future of Agile at your organization? Are you looking to scale Agile companywide? Even if you don’t need a super-robust RM solution now, you’ll need to implement some governance early unless you want to be drowning in technical debt.

To learn more about how Jama Connect® stacks up against other requirements solutions, download our eBook, “Selecting the Right Product Development Platform.”

Whether you’re just entering the automotive market or looking to improve your development process, you’ll need to become extremely familiar with the ISO 26262 standard.

In 2011, ISO 26262 was created to set the standard for the automotive industry and its suppliers around functional safety in electrical and electronic systems development. To address the industry’s rapid evolution and to ensure that these new electronic functions remain functionally safe in the new environment, the International Organization for Standardization (ISO) recently introduced a second edition of ISO 26262 in December 2018.

There are plenty of updates to sort through in the ISO 26262 2018 version, from building motorcycles to providing more guidance for the semiconductor industry.

Given that the first edition of ISO 26262 hung around for roughly seven years before it received an update, you can expect the most recent version to be the standard for driving quality and reducing risk in automotive functional safety for at least the foreseeable future.

What follows is a non-comprehensive overview to help familiarize you with important ISO 26262 second edition updates. However, it’s imperative that developers for the automotive electronics industry independently study and understand the updates and how their process must evolve to accommodate.

Expansion of the ISO 26262’s Scope

With the implementation of the second edition of ISO 26262, all road vehicles are now included – not just those with four wheels and a maximum vehicle gross mass of up to 3500 kg, as was the case in the first edition.

Motorcycles, trucks, buses, trailers and semi-trailers are now all covered in detail. Your development teams will need to familiarize themselves with the specifics. This webinar from Automotive World provides a good summation of the major changes with a particular focus on motorcycle and commercial vehicle development, and we’ll quickly touch on some of the key points.

Whereas passenger vehicles must adhere to an Automotive Safety Integrity Level (ASIL), the latest version of ISO 26262 introduces a Motorcycle Safety Integrity Level (MSIL). And, as such, the hazard analysis and risk assessment for motorcycles been altered to account for the differences. One thing worth noting is since motorcycles are so unique in their performance, there’s a larger emphasis placed on the responsibility of the rider versus the machine itself. For instance, whereas most cars are expected to still perform well in ice and snow, motorcycles are not, and so if a rider makes the choice to drive in those conditions, they are purposely accepting a higher degree of risk.

Since trucks and buses, on the other hand, are primarily defined by their larger size and mass, those factors tie into their controllability and, therefore, exposure to risk. For example, when a large truck is loaded with cargo, it’s going to have few issues with things like wheel spin on a steep hill than when it’s completely empty. And because different trucks, buses and semi-trailers all have unique purposes for use (for instance, long-haul semi-trucks versus city buses) and are typically exposed to different conditions and environments, the second edition of ISO 26262 makes distinctions between the base vehicle types of each. In terms of controllability, for example, concrete trucks should be able to withstand something like an unpaved construction site, whereas buses don’t regularly encounter that sort of terrain.

Software Tools Confidence Levels

Development software that’s used to create components for automotive systems must be qualified to do its job in a functional safety design environment. The qualification and classification requirements are described in Clause 11 of ISO 26262, Part 8. Software tools receive a certified qualification report if they are fit for purpose.

It’s worth noting that Jama Connect™ has already been certified fit for developing safety-related products according to ISO 26262 (up to ASIL D) by internationally-recognized testing body TÜV SÜD. That means Jama customers can use the TÜV SÜD certificate as an argument for software solution qualification in projects, instead of having to spend time qualifying it themselves. Jama is the first vendor that is both SaaS and Agile to receive the certification. You can read more about the benefits of this distinction here.

Learn how Jama Software worked with TÜV SÜD on our ISO 26262 certification process, and how you can lower the costs and risks of complying with functional safety standards, by watching our webinar.

Functional Safety and Cybersecurity

In response to increasing security concerns in connected devices in automobiles, ISO 26262 now requires a management plan that incorporates effective communication channels between functional safety and cybersecurity. These necessary channels have been identified at both the functional safety management level and at the system level for product development.

Guidelines for Semiconductors

The first edition of ISO 26262 did not include specific guidelines for semiconductors used in automotive application. This caused some confusion and led many automotive teams to create their own functional safety requirements for their semiconductor suppliers.

Now, a new section provides guidelines on and definitions for semiconductor components and semiconductor technologies used in automotive application. This should not only eliminate uncertainty, but also create uniformity when it comes to the design, verification and validation of semiconductors for the automotive industry.

What’s Not Included

One thing that was left out of the second edition is “the non-systematic and random safety issues that will occur with autonomous systems using neural networks.” Semiconductor Engineering explains that this is because a new standard coming later this year – SOTIF, Safety Of The Intended Functionality – will include new automation technologies for things like autonomous vehicles not covered in ISO 26262:2018.

To further assist in mitigating risks in the development process and maintaining compliance with automotive functional safety standards, learn how to mitigate common ISO 26262 mistakes with our whitepaper, “Top 15 ISO 26262 Snafus.” 

Systems thinking is an approach to solving complex problems by breaking their complexity down into manageable units. This makes it easier to evaluate the system holistically as well as in terms of its individual components.

A high-level, interconnected view of the product development process can yield new insights into how products are defined, built, released and maintained. Product managers sit at the center of the product development system, so they’re primarily responsible for understanding and directing the system.

You can think of systems thinking as a diagnostic tool: a disciplined approach to examining problems more completely and accurately before taking action. Systems thinking encourages teams to ask the right questions before charging ahead under the assumption that they already know the answers.

For product teams grappling with exceptionally complex design specs and requirements, systems thinking opens the door to procedure-level improvements and the ability to take full advantage of solutions that support them.

In this post, following up on our recent piece about systems thinking for medical device development, we talk about how product managers can leverage systems thinking to improve their processes.

The Iceberg Model: How to Put Systems Thinking Into Action

The Iceberg Model is a practical way to put systems thinking into action. We borrowed the following excellent example from the smart folks at the Northwest Earth Institute.

Picture an iceberg (doomed ship optional). The tip sticking out of the water represents the event level. Problems detected at the event level are often simple fixes: You wake up in the morning with a cold, so you take a couple of ibuprofen to feel better. However, the Iceberg Model encourages us not to assume that every issue at the event level can be quickly resolved by treating the symptom.

Just below the event level is the pattern level. As the name suggests, this is where you detect patterns: You catch more colds when you skimp on sleep. Observing patterns helps product managers forecast events and identify roadblocks before they rear their ugly heads.

Below the pattern level is the structure level. If you ask, “What’s causing this pattern?” the answer is likely to be structural. You catch more colds when you skimp on sleep, and you skimp on sleep when you’re under pressure at work or when your personal life is causing you stress.

The mental model level is where you find the attitudes, beliefs, expectations and values that allow structures to function as they do. These attitudes are often learned subconsciously: from our parents, our peers, our society. If “I’ll sleep when I’m dead” is part of your mental model, you’ll have trouble making the attitude and behavior adjustments that could help you avoid another cold.

The Iceberg Model encourages you to stop putting out fires and start addressing deeper issues. Using this model can align your team members through shared thinking and reveal opportunities to make small changes to the process that will yield big benefits.

More Visibility, Superior Collaboration

With a systems-thinking approach, complex product development teams can improve their processes by enhancing visibility and enabling more seamless collaboration and coordination between stakeholders.

Complex product development requires that the right people have visibility into the right parts of the system at the right time. Systems thinking drives teams to coordinate and communicate through a common system need. Collaboration becomes easier and more productive when teams are free to find approaches within their disciplines that are most effective for them, while still meeting the needs of the system.

Compliance & Traceability

Simple changes to requirements can have far-reaching impacts, and it’s hard to isolate every system component that could be affected by a requirement modification. It’s easier to assess the impact of proposed changes – that is, to perform valuable impact analysis – when you have a roadmap that shows you precisely where each requirement or business rule was implemented in the software. Traceability gives you that roadmap.

By helping identify all the areas you may have to modify to implement a proposed change to a requirement, traceability enables impact analysis. With proper traceability, you can follow the life of a requirement both forward and backward, from origin through to implementation.

Traceability is difficult to establish after the fact, so teams can use a tool like Jama Connect from the beginning to track tasks, keep tabs on evolving requirements and contextualize test results. Traceability gives teams confidence in the safety and quality of their products, and helps them demonstrate compliance with national and international standards for highly regulated industries.

Since lower-level requirements and outputs are defined within the context of a specific system need, traceability allows teams to understand that context and the downstream impacts of any change made.

Customized Solutions for Complex Product Development

Organizations across a huge range of industries are engaged in complex product development. Systems thinking encourages teams to work through a common system need, while still employing the approaches that work best within their disciplines. To assist, Jama Connect provides visibility throughout the product development cycle and keeps stakeholders connected to minimize miscommunication and unnecessary rework.

And our Jama Professional Services consultants work with you to understand your objectives and configure the platform to support your process in the optimal way. As your process, people and data change, our experts help you realign development methodologies to best practices, elevate your requirements management skills and reinforce your process. For larger teams that want ongoing deployment and optimization assistance, our adoption services give you a team of experts at your fingertips.

Learn more about some of the ways systems thinking helps overcome complex product development with our whitepaper, “Systems Engineering and Development.”

As 2019 gets further underway (it’s February already?), we’re thinking about the changes we can expect from the requirements management space this year. Last week, we wrote about the Engineering.com report we sponsored, which found that while more than 90% of design and engineering teams agreed that their products had become more complex over the last five years, only 15% relied on a dedicated requirements management solution.

That got us wondering how teams will change their approach to requirements management over the next five years.

To get a feel for requirements management trends in 2019 and beyond, we spoke with three experts at Jama Software:

  • Michael Jastram, Solutions Architect in Customer Success, based in our Amsterdam office
  • Robin Calhoun, Senior Product Manager, based in our Portland, Oregon headquarters
  • Steve Gotsch, Director of Product Management, also based in Portland

Here are their predictions for the requirements management trends to watch this year.

Requirements management will grow more complicated – and more essential.

Requirements management continues to be a priority for product development teams and will only become more complicated as a result of increasingly complex product designs and more hardware/software integrations. The growing complexity of requirements will drive the need for dedicated tools that save time, reduce errors and streamline collaboration and review cycles.

In the requirements management space, says Jastram, “things are changing faster and faster. Transformation is taking place on many levels, and they all affect requirements: at the organizational level, at the regulatory level and obviously on the product level. This trend is driven primarily by complexity, and Jama is addressing that complexity through its platform.”

Requirements management is growing into requirements modeling.

Jastram thinks requirements modeling is becoming “a huge trend,” though he doesn’t see it becoming mainstream in more heavily regulated industries for several years.

Requirements modeling is already a familiar concept in software, where it’s leveraged to test the system or application under development to establish a clear relationship between tests and requirements. Jastram notes that companies like Boeing and Airbus are already building “all-encompassing system models of their products,” but that “these are exceptions and not the rule.”

Systems modeling helps teams focus on the system’s external behavior, apart from its internal design; describe stakeholder needs with more precision; reduce gaps and inconsistencies in requirements; and cut down on the work associated with requirements change.

When it comes to managing requirements, Jastram suggests that modeling can help teams deal with the huge complexity of today’s – and tomorrow’s – products: “This will be a really big thing for the first company that does it right,” he says.

More organizations will invest in requirements management solutions.

As the Engineering.com study revealed, not everyone is using a dedicated requirements management tool, but companies are increasingly aware of the importance of managing risk and improving their development process.

According to Calhoun, “Managing risk is becoming more common with more companies focusing on medical devices and the continued confluence of hardware and software.”

This increase in complexity and in the amount of data that must be incorporated throughout the development process drives the need for companies to find a stronger way to manage requirements. Our product team thinks of requirements as the “steel thread” that ties together all the data throughout the product or application lifecycle.

As the Engineering.com report also noted, heavily regulated industries like medical devices, automotive, and aerospace and defense are more likely to depend on dedicated requirements tools. For less heavily regulated industries, Jastram notes, investing in requirements management may seem prohibitive, especially if teams don’t understand the value they can realize by transitioning away from a document-based approach.

Instead of emailing versioned documents back and forth, less regulated industries can derive huge value from using a requirements management platform to support their product development processes. These tools enable more efficient communication between users and stakeholders, streamline the review process, speed time-to-market and establish traceability to ensure you’re building the product you set out to build.

Requirements management practices globally are aligning, as US companies look to EU markets as examples.

Gotsch notes that there’s “an effort to better align practices globally using risk and FMEA and the Germany auto industry as an example.” Jastram agrees, adding that requirements management in the German automotive and aerospace industries is “considered fairly mature,” while Gotsch and Calhoun acknowledge that US companies have sometimes been notorious for doing product development on the fly. However, Calhoun says, this fly-by-the-seat-of-your-pants approach isn’t how the most valuable and successful companies work.

“US companies are maturing in their approach to requirements in the software and hardware space as complexity and interactivity grows,” Calhoun says. “The lessons from EU markets are becoming more the norm: more standards, more tools, more regulations and more predictability.”

Requirements management tools will change to meet the expectations of younger teams.

Calhoun and Gotsch predict that requirements management tools will become more intuitive and efficient, in part to meet the expectations of a younger workforce. “The younger generation of the workforce is (still) coming up in experience and influence,” Calhoun says. “There’s an increasing need for enterprise tools to begin catering to their expectations — which are efficient, modern and fast — to attract and keep talent. Companies no longer have the aging workforce’s willingness to work around inefficiencies.”

The best tools and platforms will be value-driven, not feature-driven.

Jastram, who worked in software development and requirements management before earning a PhD with an emphasis in requirements modeling, says the most successful requirements solutions of the future will be value-driven.

Rather than incorporating feature after feature, the best platforms will add value across the product development lifecycle by understanding and supporting business practices. Jastram cites Risk Management Center for Jama Connect™ as a value-based feature that supports and accelerates the work teams are already doing, rather than rolling out feature after feature that, in Jastram’s words, “look good on paper, but don’t really help your practice.”

To learn more about the changing landscape of product development and requirements management, check out the report we sponsored: Design Teams: Requirements Management & Product Complexity.

Many questions need to be answered throughout the development process, and quickly. But teams often don’t have the right approach to data collection, storage or analysis to enable fast, data-driven decisions.

One tactic is to dump a bunch of data from disparate tools into a spreadsheet in an attempt to glean insights. Not only is this a heavy, manual process, but the resulting data is not always complete, consistent or up to date. And it also doesn’t capture the full context of what’s happening behind the numbers.

All the while, timelines are slipping, release dates are approaching and costs are rising.

In a recent webinar, we explored how proper data collection and analysis can make your development process more predictable. We also discussed the current state of product development (based on data from McKinsey), and the underlying causes of costly overruns and how to avoid them.

In addition to underestimating complexity, which you can read about in “How to Decrease Overruns in Complex Product Development,” a lack of consistent data is another significant cause of overruns.

Why a Lack of Data Causes Overruns

When teams lack consistent data, things like benchmarking and consistency across projects and products is either lacking or altogether absent. This also makes it much more difficult to make informed decisions.

Yet, data-driven decisions are exactly what’s needed to ensure you’re building the right thing, the right way and that it will get to market on time.

Without reliable data, team leaders often put their faith in historical information that may be from less complex or completely different projects, or worse, simply go with their gut feelings.

This can bring about severe development issues in even the most successful companies, and cause even veteran project managers to make costly mistakes.

So, what can you do to achieve consistent and reliable data to make your development process more predictable?

Get Answers to Essential Questions

To enable predictability and accurate data analysis, you need a purpose-built Predictive Product Development solution, like the Jama Product Development Platform.

By importing data from Jama Connect™ and Jira Software, for example, Jama Analyze™ allows you to get data-driven answers to the onslaught of questions that arise during complex product development.

Here are just a few questions you can answer with Jama Analyze:

  • Does this product satisfy customer and stakeholder requirements and marketing goals?
  • Can we prove we’ve met these requirements?
  • Are we going to deliver on time? How confident are we?
  • Are changes being made to any of our items throughout the process?
  • How good is our team at finding defects before they hit the public?
  • How long do things stay in each status?

Having these key performance indicators (KPIs) at your fingertips empowers you to set the right expectations and have necessary conversations if those expectations don’t align with the data you’re seeing.

Ultimately, measuring and tracking these metrics will help you make better, more profitable products.

At Jama Software, we’ve been lucky enough to work directly with some of the world’s most forward-thinking medical device companies. What we’ve learned is that these innovators must balance increasingly complex development processes; the need to release high-quality, regulatory-compliant, market-driven products; intense pressure to nail delivery timelines; and the imperative of patient safety.

With the recent findings by the the International Consortium of Investigative Journalists that more than 1.7 million injuries and nearly 83,000 deaths may be linked to faulty medical devices over a decade-long period, coupled with the FDA’s promise to overhaul its system for approving medical devices, it’s clear there are still plenty of areas for improvement within the industry.

In a recent webinar, we offered project and engineering teams working on medical devices some strategies for gaining a competitive edge by streamlining process, mitigating risk, reducing rework and easing the path to regulatory compliance.

Jama Software’s mission is to modernize, digitize and transform the process of complex product development by transcending the headaches and limitations of document-based requirement systems. To that end, we’re constantly working to ensure our platform and services help teams better manage the growing complexity of developing Class II and Class III medical devices.

Our medical device customers depend on our platform to standardize and optimize their product development processes to mitigate risk, improve quality and trim time to market.

  • Jama Connect helps medical device development teams operationalize their development processes by enabling requirements definition, traceability, testing and collaboration across all stakeholders.
  • Jama Partners allows customers to extend the Jama platform via popular third-party integration hubs or an open REST API to support integration of technologies used throughout the development process.
  • Jama Professional Services assist our customers in speeding time to value for our solutions with a host of offerings including expert assistance in optimizing and implementing the platform, as well as industry-specific consultation and training.

Overcoming Low-Value Work

Over the years, our professional services team has spent many hours working closely with medical device developers, and we’ve learned a lot about their challenges and opportunities.

A key understanding has emerged from our deep dive into the world of medical device manufacturing: Teams are struggling to balance regulatory compliance with how they want to work.

More often than not, our customers are looking to modernize and become more collaborative, but the weight of regulatory requirements can keep them from realizing the benefits of updating their process. Teams can start to see the work and the documentation as being at odds with one another, but that doesn’t have to be the case.

The challenge is balancing the requirements of the quality system with your organization’s approach to product development. You find this equilibrium by ensuring that the quality system needs and documentation in the design history file (DHF), for example, are byproducts of your work rather than defining or constraining factors in themselves.

When this balance is lacking, we’ve seen that a heavy focus on documentation needed for the DHF can introduce time-consuming, low-value work and create friction in team hand-offs.

The Benefits of Greater Efficiency

Among the biggest challenges faced by medical device developers looking to improve their product development process is that teams are spending too much time on work that doesn’t add value – especially when they’re reliant on a document-based approach to defining and managing requirements and testing.

One study of nearly 250 manufacturing organizations, according to Tech-Clarity researchers, found that engineering teams spend a third of their time on non-value adding work, especially manual data management, including manual data collection, content editing and recreating lost data.

In the requirements management space, this time might be spent checking documents in and out and tracking down the latest version for updates or reviews – not to mention time spent in meetings getting everyone aligned and establishing the path forward.

Medical device developers need to bring higher-quality products to market faster, with less risk and at a lower cost. Giving engineering teams a third of their time back would help make this goal a reality.

Stay tuned for more posts about improving medical device development and the integral role Jama is playing for its customers. In the meantime, get a deeper dive into how Jama Connect helps developers balance medical device compliance and innovation by watching our webinar.

Companies in regulated industries often struggle to get the functional safety team involved at the right stage of the development process.

When building complex products that must adhere to standards such as ISO 26262, IEC 61508, or DO-178C, for instance, too often the functional safety team gets looped in after the system is already designed and development has begun. And, by that point, it’s too late.

Real-World Implications

Imagine a company that uses Word documents to house multiple test cases defined using ID strings to refer to other artifacts like design or requirements.

When it comes time to review the test cases or adapt to changes in design, think of all the agonizing time the functional safety team will waste manually going through the list. Then consider the increased risk and quality issues should something being missed.

Time for Change

We’re at a pivotal point in defining when and where the functional safety team fits in a modern systems development process.

In a recent webinar, Jan Mauersberger, Lead Software Architect with our partner ANSYS, described the four roles of the functional safety team, as well as the negative effects of integrating the functional safety team too late in the development process:

Risk Assessments

This is done in order to know the criticality of failures in the system. The risk assessment results may imply more testing or development effort, and can have a big impact on both the timeline and cost of the project. Logically, the earlier this can take place, the better.

Safety Concepts

Typically, not a one-and-done solution, a safety analysis needs iterations and refinement – which may affect the design several times. The results of a safety analysis have to be visible early in order to react to the required changes.

Reliability Engineering

Dynamic formulas — based on industry standards and handbooks — calculate reliability data and have to be quickly adapted. If the functional safety team does not know of a change in design, for example, it can cause a lot of manual work.

Safety Management

The functional safety team has to compile and sign off on the safety case, and they are responsible for the product. Involvement and traceability from start to finish is essential for eliminating issues in safety, development and testing.

A Modern Approach

Today’s processes are iterative, with modifications introduced later and later. That’s why it’s recommended – and why most safety standards demand – that safety management and engineering start at the beginning of the development process.

The functional safety team can then mitigate issues early and stay connected throughout. It’s also critical that the team’s tools integrate with other solutions in the development process – without that, traceability is near impossible.

To learn more about the challenges of modern systems development in a regulated environment, watch our webinar with ANSYS. Plus, you’ll find out how the integration of Jama Connect and ANSYS medini analyze can help address these issues. 

 

While every project is different, the same key components for project managers often dictate success or failure: creating realistic expectations, negotiating stakeholder priorities and accurately capturing the full scope of work.  

In a perfect world, these things would all happen seamlessly and every project would finish early and under-budget. But we all know that most often that’s just not the case.  

Whether you’re new to project management or a seasoned pro, take heed of these seven common project management mistakes to avoid missing deadlines, going over budget and contributing to overall project failure.  

Mistake #1: Not clearly defining success prior to starting the project  

If one stakeholder feels strongly that launching by a particular date is the measure of success while another is solely focused on increasing market share, you’re in for a nightmare when it comes to managing priorities and expectations.  

Avoid battling stakeholders by ensuring everyone has a common definition of success prior to kicking off.  

Start by identifying who is most important to this project and defining their interests and expectations. This will allow you to agree on clear and measurable business goals that can be tracked and measured throughout the project lifecycle.  

Mistake #2: Not defining when a product will be ready for release  

In addition to defining measures of success, it’s vital to a project’s success to clearly define when a product will be finished and ready to make its debut before embarking on development.  

When stakeholders have different definitions of when a product is ready to be released, you’re sure to run into tension and frustrations across the board.  

To avoid this, decide what criteria will indicate whether your product is ready for release early in the process. Make sure the criteria are realistic, objectively measurable, documented and most importantly, mutually agreed upon.  

Mistake #3: Making commitments you’re not sure you can keep 

As a project manager, you’re no stranger to mounting pressure. With that said, one of the biggest (and easiest) mistakes a project manager can make is committing to deliverables or timelines that aren’t positively doable. The key here is to have good-faith negotiations with team members, managers and stakeholders and agree on goals that are realistically achievable.  

When things inevitably change (like budget or resources) or you run into unanticipated problems, be upfront and clear as soon as you know that things have shifted.  

Having these tough conversations and realigning commitments with everyone involved is the best way to avoid disappointment and frustration. 

Mistake #4: Misestimating timelines  

Projects never go 100% as planned. However, as a project manager, it’s your job to anticipate what might happen throughout the product development cycle (good and bad) and give your best estimated timeline.  

The good news is that you’re not alone. Many commercial tools are available to help you estimate entire projects. These solutions give a spectrum of possible timelines to help you get a better idea of how things might shake out based on the project’s breadth and depth. 

Mistake #5: Failing to plan for rework after a quality control activity  

Speaking of misestimating timelines… many project managers make the dire mistake of not planning for additional work after a quality control activity.  

While we all hope that we get it right the first time, the reality is that almost all quality control activities find needed improvements.  

To stay on the safe side, great project managers always include time for rework after every single quality control event. The best part? If there isn’t any rework that needs to happen, you’ll be ahead of schedule and you’ll look like a rockstar.  

Mistake #6: Failing to track progress throughout the entire project 

When stakeholders ask for an update on the project, you’ll want to be a specific as possible. This is only possible if you track the progress of the project throughout the entire lifecycle. The reality is, unless you record the actual effort or time spent on each project task — and compare them to the estimates — those estimates will just be guesses. 

As project managers, we sometimes give project updates that are misleadingly optimistic (see above). Remember, you can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind and what issues and risks still need to be tackled. 

Mistake #7: Not learning from past projects  

Expanding on mistake #6, another downfall for project managers is failing to conduct a project retrospective (AKA postmortem) following the completion of a project.  

If you tracked your progress meticulously and thoroughly throughout the entire project, you should be able to glean some vital lessons that you can take with you into your next project. Take note of what went well, what didn’t go well, what surprised you and what you still might not understand.  

This information will help guide you in your next project and allow you to create better time estimates and set realistic expectations.     

As a project manager, you’re the key communication hub between team members, managers and stakeholders. The success of a project can often be directly related to a project manager’s ability to effectively manage requirements and expectations, communicate with all parties involved clearly and concisely and direct the project when adaptations need to be made.  

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.  

 

The role of a project manager is a tough one. Between balancing schedules, deadlines, compliance and budgets, you’re constantly being forced to shift and adapt to avoid obstacles along the way. But one of the hardest parts of the job is undeniably managing stakeholders and their priorities.

Most of the time, the bigger the project, the more stakeholders involved. This can be a major challenge when each stakeholder has a different agenda and definition of success.

So how do you keep the project moving and keep everyone happy? Well, there is no silver bullet here, unfortunately. But we’ve come up with a set of guidelines that can help you manage stakeholder priorities and mitigate conflict.

Identify Key Stakeholders

This may sound obvious, but a huge source of conflict can arise if all stakeholders aren’t identified and looped in from the very beginning. All the legwork that happens prior to a project will have to be redone if new stakeholders pop up along the way. This can mean pushed deadlines, budget increases and generally unhappy stakeholders. Make sure that you’ve identified, and communicated with, everyone who may have a dog in the fight early in the process.

If there are many stakeholders in a project, it’s often beneficial to identify high-priority and secondary stakeholders. Naturally, those who are high priority will hold more weight and have more pull than secondary stakeholders.

Remember, not all stakeholders will be directly involved in the work. There may be others who are directly impacted by the project and its outcome. And those people need to be involved, too.

Identify Priorities and Potential Conflicts

Having a kick-off meeting is a great way to identify the different interests, priorities and perspectives of each stakeholder.

If all goes well, each stakeholder will have similar goals and priorities and the project can move forward with perfect alignment. The reality is, though, that there will likely be a variety of perspectives and wish lists, and they may be competing.

Should this happen, a good way to start prioritizing interests is by asking each stakeholder, “How does this support our business objective and company goals?” If the answer is that it doesn’t, or that it can’t be clearly tied to a business objective, it falls towards the bottom of the list of priorities.

Having these conversations early in the process helps us avoid future conflict and uncertainty about the project, and gives us a better shot at completing the project successfully and on time.

Mitigate Conflicts as they Arise

Understanding and addressing stakeholders’ needs and concerns early in the process decreases the likelihood of problems arising further down the line.

However, things happen. Priorities shift. Budget gets slashed. What’s the best way to deal with it? This is where your interpersonal skills make their debut for effective conflict resolution.

Many conflicts can be simply handled by clear communication and a review of the goals and priorities set forth in the planning phases of the project. Re-aligning goals and commitments is often enough to mitigate a conflict, especially when they’ve been clearly defined and documented.

As a project manager, you’re often able to block and tackle to prevent conflicts from arising. Managing expectations is a big part of the job, and your communication skills can be the difference between success and failure.

For example, when something related to the project inevitably changes (like budget or resources) or you run into unanticipated problems, be upfront and clear as soon as you know that things have shifted.

It may be tough to deliver news of setbacks to stakeholders, but having these conversations and realigning commitments with everyone involved is the best way to avoid friction and frustrations.

Want to learn more about being a pro at project management? Check out our eBook “Project Management Best Practices” for 21 tips on taking the pain out of project management.

 

5 Things Killing Your Product Development Process

Product development involves a veritable ballet of deadlines, teams and goals, all of which must be harmoniously synchronized to ensure success.

There are a multitude of hurdles for developers to clear on the path to bringing a product to market the right way, and the collapse of any of the key elements can grind the process to a halt, or result in a finished product that fails to meet customer expectations or release at all. Such failures can be costly in both time and money, and in extreme cases, irreparably damage a company’s reputation.

However, many of these project-killing blunders are avoidable if teams approach each step of the development process judiciously and with an eye toward effective communication, realistic expectations and a rigorous dedication to fixing problems early. The following are five pitfalls to avoid in the development process.

1) Teams Not Working Together

In order for a project to stay on task, especially a complex hardware or software development project, disparate teams must be brought together under one umbrella. Siloed teams working on different facets of the same product risk, but with zero visibility into each other’s projects, escalates the probability for error.

These teams must also be fluent in the common parlance of the project, aware of their individual responsibilities, and have all expectations clearly communicated and regularly updated as changes arise. This collaboration is pinnacle to the development process, and failing to keep teams and contributors on the same page can spell disaster.

2) Testing Only at the end of the Process

You’ve gotten the team working together like a well-oiled machine, the goals have been established and met, and the finished product is ahead of schedule. One problem: it doesn’t work. Developers can’t afford to reinvent the wheel after countless hours have been spent wrangling the stakeholders and putting the pieces in place.

Revisiting completed projects to fix issues not addressed during the development process takes workers away from other projects and can be costly in both time and money. Problems have a nasty tendency to compound as subsequent work is done on top of it, which wastes effort, fosters frustration and can risk a product running afoul of regulatory requirements. Testing throughout the development process lets teams home in on problems early before they become calamities.

3) Employee Churn

Every company has turnover, and losing key team members during a development project can have a ripple effect up and down the stakeholder chain. That is, unless you plan for it by making sure project work is well documented in a shared tool.

Let’s face it, people have low incentive to spend time documenting their work on their way out. When documentation is stored in Word documents in a networked folder it might take weeks for the team to dig through the data to figure out what the missing teammate was working on. Project teams recover faster if you implement a solution that fully captures document work, reviews, requirements, etc., as part of the normal day-to-day workflow. That way you’re not scrambling to capture knowledge when someone finds a new job.

4) Not Assigning Responsibility

The more complex a project, the greater the onus on management to properly delegate responsibility among the teams involved. That includes tracking the progress along the way and keeping meticulous records of not only who is responsible for which task, but who is charged with overseeing the completion of each step.

This reduces or eliminates duplicated efforts and risk of misunderstanding. Each team member’s role should be clearly delineated and referenceable, which cuts down on finger pointing if something goes by the wayside. On each team, it should also be established who has decision-making responsibility to ensure the completion of deliverables, and who keeps the team on the same page.

5) Bad Requirements – Not Starting With the End in Mind

Poorly defining the requirements of a project can doom the process to budget-busting rework. In fact, according to Carnegie Mellon Software Engineering Institute, rework can eat up as much as 80% of a software development project budget, so it’s critical that all team members understand what exactly they’re building, how it should look and function, and what value it provides to the market.

Complex software or hardware development projects can have thousands of requirements, so managing them effectively is the only way to keep team members from ending up lost in the weeds. This involves keeping track of completed requirements, understanding all interdependencies and managing changes to better anticipate issues and ensure inter- and intra-team continuity. Good requirements are easily understood and followed by all team members, so all oars in the water are moving together towards the same, clearly articulated set of goals.