Tag Archive for: Product Development Process

Product Development Process

I am writing this post about reducing the risk of negative outcomes in the product development process in the hopes of saving at least some of you from the fate that has befallen many companies before they reach out to us. Unfortunately, many of our new clients come to us AFTER theyve had a negative product outcome at their current company, or even more common, at their new one.   

According to an Engineering.com survey (full disclosure: we sponsored it) 83% of those companies surveyed experienced at least one negative product outcome including: significant delays, cost overruns, product defects, compliance gaps, recalls, omitted requirements, and lengthy rework. In many cases these negative outcomes were quite significant and led to changes in management and staff.   

Root Causes of Risk in the Product Development Process 

All of these companies conducted root cause analyses to determine what led to these negative product outcomes. The root causes identified are quite similar across the organizations: 

  • Limited customer and cross-functional involvement in the review and approval of requirements 
  • Static requirement documents rarely viewed by key stakeholdersmaintained in Microsoft Word/Excel or a standalone tool, and used only be a few as a repository 
  • Missing decomposed requirements  
  • No ability to track the life of a requirement through development, test and release 
  • Release cycle misalignment across engineering disciplines 
  • Misinterpretation of requirements across engineering disciplines 
  • No process exception tracking to determine requirements that have been omitted or modified 
  • No identification of process risk patterns  delays in development, multiple test failures, rework cycles, etc. 

Product Development Process is Not Under Control 

With all of these informational and process gaps, the end-to-end product development process is “not under control”, to extend the concept of Six Sigma statistical process control to a complex process. A process that is not under control cannot be relied upon to deliver predictable results. The outcomes can vary widely and with no ability to truly monitor risk probabilities as the process moves along, the negative outcome occurs as a surprise at the end of the process where the cost is highest.  

Many companies operate under the illusion of risk mitigation. The process is “not under control”, so management relies on managing people and takes each team lead’s assessment of progress and risk as comfort that the risk of a negative outcome is low. Unfortunately, the team leads are only assessing their teams and what they see. This misses the most likely points of failure that connect teams and extend over time. Without Living Requirements™ its hard for anyone to see across all teams (and time) to identify the exceptions, omissions, defects, rework, delays and dependencies.  

Even organizations more mature in their end-to-end product development process management are still often surprised by negative outcomes.  A very thoughtful root cause analysis of an actual situation of this type has been done by Michael Panis and presented at the 2020 IEEE 28th International Requirements Engineering Conference (RE). His key findings include:  

  • “Poor traceability and missing subsystem requirements when a system requirement is decomposed through an error budget or other complex logic.” 
  • “Missing requirements due to a decision to only trace to subsystems directly responsible for given system requirements.” 

ROI from Risk Reduction in the Product Development Process 

Investments to improve the product development process are typically justified through gains in engineering productivity. What is often missed is the even greater benefit to the organization of bringing the product development process under control and reducing the probabilities of negative outcomes. A basic approach is to quantify the magnitude of the various negative outcomes — and the likelihood of their occurrence — to determine the current risks in financial terms that could be faced by the organization. The next step is to estimate the reduction in occurrence probability given the improvements in the process and then calculate the overall reduction in the magnitude of the expected negative outcomes.  A more advanced model is described in the paper by Machac, Steiner and Tupa.   

A Common Mistake to Avoid 

Let’s wrap up with a common mistake many make when measuring risk in the product development process. There is an obvious difference between the likelihood of a negative outcome and the financial impact if the negative outcome occurs as the graphic below shows. 

product development processHowever, many confuse a constant likelihood of a negative occurrence (scenario A – unmanaged risk in the graphic) with a constant level of financial impact when, in fact, it is growing dramatically throughout the product development process as investment and costs to remediate omissions, defects, and reputation grow over time. The only way to maintain a constant and low level of risk is to actively manage down the likelihood of a negative outcome continuously through the development process as shown as scenario B in the graphic. For a deeper dive into this concept please check out a fine piece by Preston Smith in Research- Technology Management, Managing Risk as Product Development Schedules Shrinkand the source of the graphic above. 

Watch this webinar to learn more about moving away from documents-based design control and risk management.



Requirements Management Tools

This post on modern alternatives to IBM DOORS® is part of a series. You can find Part II on legacy software pains here, Part III on enabling innovation here, Part IV on the difficulties of compliance here, Part V on moving from DOORS to Jama Connect here, and Part VI on migration solutions here

Current market dynamics include disruptors that put innovation at the heart of your product development process. Organizations must be able to navigate these disruptions to remain competitive and sustain business growth.

Requirements management (RM) tools include many legacy options, such as Microsoft® Office® toolsets to software applications like IBM® DOORS®. These legacy solutions may have handled managing requirements in the past, but often fail to keep pace over time.

Today, we’re launching a new blog series, Legacy Sunset, featuring experts exploring topics relevant to legacy requirements management tools, why customers elect to move away from them, and what benefits are realized after making the switch.

In the coming posts we’ll also touch on how to navigate the data migration path from a legacy system to a new platform, and how innovation is realized in product development lifecycles with a modern requirements management solution.

As part of this series, we’ll evaluate legacy RM solutions like IBM DOORS, and cover:

  • Key reasons why customers are replacing these legacy solutions and which solutions they’re replacing them with
  • How compliance is impacted adversely using legacy requirements management solutions
  • How modern requirements management solutions are enabling innovation in the automotive, medical device, and aerospace industries
  • Why legacy requirements management tools do not adequately meet the needs of modern product development processes
  • Options to support migration and enable replacement of legacy solutions
  • How to deploy a co-exist strategy with IBM DOORS and connect to the supply chain using data exchange for Jama Connect™

Learn more about thoughtfully selecting the right requirements management solution by reading our guide.

Time for a Change

Those still entrenched in legacy software for product development may soon find time is not on their side. Oftentimes, legacy solutions are built on outdated architectures and contain bloated features with many customizations that may simply not support the needs of product development teams.

While these legacy requirements management tools still support critical product development processes and information that the business depends on, they may grow unstable over time and eventually introduce risk to the product development lifecycle. That complicates things further for organizations that must stay current with compliance regulations, while developing integrated, complex products that sustain business and maintain market relevance.

Learn how Alight Solutions transformed requirements management for its clients by downloading the case study.

Check back for future entries in this series. In the meantime, learn more about Jama Connect and how it can help you modernize your requirements management toolchain through ease of use, collaboration, traceability, and compliance. Our customers can also combine the power of Jama Connect with leading tools across the ALM-PLM landscape to support a powerful, integrated solution that manages requirements in support of complex product development.

See first-hand how Jama Connect can transform the way your work. Connect with an expert or test drive the Jama Connect solution.

Requirements Management helps in the Product Development Process

Although requirements management is just one part of the product development process, many organizations fail to realize its importance in the successful delivery of a finished product.

In fact, The Standish Group indicates that three of the biggest contributors to projects that fail or are “challenged” are:

  • Lack of user input
  • Incomplete requirements and specifications
  • Changing requirements and specifications

Another recent study showed that of all failed projects investigated, more than 40% concluded that failure was because of bad requirements or being unable to understand the stakeholder’s true needs in the first place.

In addition to avoiding negative business outcomes, better requirements management and investing in modern requirements management tools provides numerous benefits. One analysis of the potential return on investment from better requirements suggested that requirement errors can consume between 70% and 85% of all project rework costs.

Here are just a few ways that investing in better requirements management — and more modern requirements management tools — can help your team improve its product development process and cut down on costs.

Better Requirements Management Helps When Selecting Projects

The connection between good requirements and positive business outcomes is clear: Good preliminary requirements enable senior managers to make effective business decisions as organizations decide which, among a set of potential projects, to move forward on.

Better requirements management allows a more accurate projection of business returns. Once a project is funded, better requirements allow project managers to more sensibly partition tasks among their teams and individual team members.

Requirements Help Teams Prioritize Work in the Product Development Process

Documented requirements allow teams to prioritize remaining work. Most projects need to make compromises to ensure that they implement the most critical and timely functionality. A prioritized requirements baseline helps the team incorporate those changes that will deliver the maximum customer value. One study revealed that just 54% of the originally defined features were delivered in an average project. If you can’t implement all the requested functionality, make sure the team implements the right portion.

Requirements Management is Key to Developing Designs

Requirements are the foundation for design. Therefore, well-understood and well-communicated requirements help developers devise the most appropriate solution to the problem. High-quality requirements also ensure that the development team works on the right problem in the product development process.

Many developers have experienced the frustration of implementing functionality that someone swore they needed, only to find that no one ever used it. One survey by The Standish Group indicated that fully 45% of the delivered software product features were never used. Wasting less time implementing the wrong functionality accelerates the project and maximizes its business return.

Improved Requirements Management Can Accelerate the Product Development Process

Believe it or not, investing more effort in developing requirements can accelerate software development. This seems counterintuitive, but it’s true. Defining business requirements — the expected business outcomes the product will provide — aligns the stakeholders with shared vision, goals, and expectations. Effective user involvement in establishing the requirements reduces the chance that users will reject the new system upon delivery.

Accurate requirements ensure that the functionality built will let users perform their essential business tasks. The requirements also establish achievable quality expectations. This lets the team implement both the capabilities and the product characteristics — the nonfunctional requirements — that will make users happy.

Additionally, emphasizing requirements development is less expensive than relying on beta testing to find requirements problems. Fixing problems that late in the game is far costlier than correcting them earlier.

Learn more by downloading our eBook, “Jama Software’s Guide to Requirements and Requirements Management.”