Tag Archive for: product management

Digital Twin

Jama Software is always on the lookout for news and content to benefit and inform our industry partners. As such, we’ve curated a series of articles that we found insightful. In this blog post, we share content sourced from AI Multiple – 15 Digital Twin Applications/ Use Cases by Industry in 2022  – which was originally published on April 25, 2022, by Cem Dilmegani.


15 Digital Twin Applications and Use Cases by Industry in 2022

Digital twin technology is becoming more widespread. According to Deloitte study, the global market for digital twins is expected to grow with 38% CAGR to reach $16 billion by 2023, and the proliferation of IoT technology accelerating this growth.

A digital twin is a virtual/ digital replica of physical entities such as devices, people, processes, or systems that help businesses make model-driven decisions. Digital twins are changing the way work is done in different industries with varying business applications. Knowing those applications can help businesses implement digital twins into their processes. Therefore we examined digital twin applications in manufacturing, healthcare, supply chain and retail. And we created the list of digital twin use cases, applications and examples.

Supply Chain

Digital twins are also widely used in the supply chain/logistics industry. Some applications are:

Predicting the performance of packaging materials

Product packaging can be virtualized and then tested for errors before being packaged. Digital twins help logistics companies determine material feasibility.

Enhancing shipment protection

Logistics companies can analyze how different packaging conditions can affect product delivery with the help of digital twins.

Optimizing warehouse design and operational performance

Digital twins enable logistics companies to test warehouse layouts so companies can choose the most efficient warehouse design to maximize operational performance.

Creating a logistics network

A digital twin of a road network carries information about the traffic situation, road layout, and construction. With that knowledge, logistics companies can design the distribution routes and inventory storage locations.

Construction

A digital twin can help construction firms understand how a building is performing in real-time, which allows them to tweak performance to optimize efficiency. Data collected from digital twin can be used for planning and designing future buildings.

Healthcare

Digital twins can help healthcare providers virtualize healthcare experience to optimize patient care, cost, and performance. For healthcare, use cases can be categorized into two groups:

Improving operational efficiency of healthcare operations

Creating a digital twin of a hospital, operational strategies, capacities, staffing, and care models helps healthcare providers examine the operational performance of the organization.

Improving personalized care

Healthcare providers and pharma companies can also use digital twins to model the genome code, physiological characteristics, and lifestyle of patients so that healthcare companies can provide personalized care such as unique drugs for each patient.


Related: 2022 Predictions for Medical Device Development: Increased Focus On Cybersecurity, Clarity On Standard Compliance, and the Challenge of Human Variability


Manufacturing

Applications of digital twins are most widely used in the manufacturing industry. Manufacturing relies on high-cost equipment that generates a high volume of data which facilitates creating digital twins. Digital twin applications in manufacturing are as follows:

Product development

Digital twins can help engineers test the feasibility of upcoming products before launching. According to the test results, engineers start producing or shift their focus to creating a feasible product.

Design customization

With digital twins, businesses can design various permutations of the product so that they can offer personalized products and services to their customers.

Shop floor performance improvement

A digital twin can be used to monitor and analyze end-products and help engineers see which products are defected or has lower performance than intended.

Predictive maintenance

Manufacturers leverage digital twins to predict potential downtimes of machines so that businesses minimize non-value adding maintenance activities and improve the overall efficiency of machines since technicians take action before a failure happens.

However, using digital twins for predictive maintenance tasks is not scalable as it is a machine-specific virtual replica and requires expensive data science talent to build and maintain twins.

For more info on digital twin applications in manufacturing, feel free to check our article about AI applications in manufacturing where we explain each application.

In aerospace and automotive manufacturing, there are further applications of digital twins:

Aerospace

Before digital twins, physical twins were used in aerospace engineering. An example is Apollo 13 program in the 1970s where NASA scientists on earth were able to simulate the condition of the ship and find answers when critical issues arose. Later in 2002, the digital twin concept is introduced by John Vickers from NASA.

Today the importance of digital twins in the aerospace industry is acknowledged by experts that 75% of air force executives have cast the vote of confidence in favor of the digital twin, according to Business Wire’s survey report.

With digital twins, engineers can use predictive analytics to foresee any future problem involving the airframes, engine, or other components to ensure the safety of the people onboard.


Related: Jama Connect® for Aerospace and Defense


Automotive

Developing new cars mostly takes place in a virtual setting. Digital Twins are used in the automobile industry to create the virtual model of a connected vehicle. Automotive companies use the technology to design the ideal automotive product even before production starts. They simulate and analyze the production phase and the problems that might occur once the vehicle hits the roads.

Self-driving car development

Though digital twin practices can be used in the traditional automotive manufacturing industry, digital twins are handy for autonomous vehicle companies. Self-driving cars contain numerous sensors that collect data regarding the vehicle itself and the environment of the car. Due to the liability questions that surround autonomous vehicles, creating a digital twin of a car and testing every aspect of the vehicles is helping companies ensure unexpected damage and injuries will be minimized. Some applications of digital twins in the automotive industry are road testing and vehicle maintenance.

For more on digital twin applications in manufacturing, feel free to watch the video of Dr. Norbert Gaus who is head of R&D in Automation and Digitalization at Siemens. He is explaining how digital twins help streamline the production process in the real world and providing examples:

Retail

Customer modeling & simulations

Retailers can create digital twins of customer personas to improve the customer experience they deliver. For example, retailers can provide ideal fashion clothing products to customers based on their digital twin models.

Finally, you can view our data-driven list of digital twin software to find the best solution that suits your business needs. If you still have questions about digital twin applications, we would like to help:

RELATED



reduce risk product development

In this blog, we will recap a webinar on reducing risk in product development


Over the last 20 years, product development complexity has expanded exponentially, creating innovations in areas such as space tourism, autonomous vehicles, satellite communications, and more. In this webinar, Kemi Lewis, Senior Consultant at Jama Software, will demonstrate how Jama Connect© creates Live Traceability™ through siloed development, test, and risk activities to effectively reduce risk in the product development process.

In addition to a walkthrough of the platform and our Live Traceability dashboard, we’ll cover:

  • The critical challenges to reducing risk in product development
  • Why deeming requirements “good enough” to allow teams to proceed with an acceptable level of risk culminates in static requirements, unplanned rework, and compounded product risk
  • How “Project management” activity is a fallacy — it is the management of requirements, people, risks, change, opportunities, expectations, resources, commitment, and suppliers

Below is an abbreviated transcript and a recording of our webinar.


Reducing Risk in Product Development

Kemi Lewis: Today’s agenda covers a deep dive into the critical challenges to reduce the risk in product development, what are the viable solutions to this problem, key takeaways, and wrapping up with a question and answer session at the end of the webinar

Let’s get right into it. What are the main critical challenges that product development teams are facing? In my experience, the main factors that lead to adverse product outcomes and risk are, number one, no upfront and iterative collaboration during requirements and design creation and review stages due to limited customer and cross-functional team involvement in the review and approval of requirements. This lack of cooperation results in missed and misunderstood requirements driving the product design into severely costly errors later on.

Second factor, no digital thread connecting the product and team to the end to end product life cycle process. What do I mean by the digital thread? A digital thread is a data driven architecture that links together information generated from across the product life cycle and is envisioned to be the primary and authoritative data and communication platform for a company’s product at any instance in time. Without this digital thread, there’s no ability to track the life of a requirement through development, test and release.


Related Reading: What Is the Definition of a Digital Thread


Kemi Lewis: This missing digital thread results in static requirement documents rarely viewed by critical stakeholders maintained in Word, Excel or standalone tool used only by a few as a repository. I’ve personally experienced this at companies where only the systems engineers were accessing the repository and the rest of the product development team from product managers down to testing and integration engineers never accessed it.

You can only imagine how this turned out. Countless rework during testing and integration in addition to postlaunch rework this early, which was severely costly to the customer and left them very unhappy. So lacking this digital thread leads to no management visibility into crucial metrics for the end to end process and no identification of process risk patterns, such as delays in development, multiple test failures, rework cycles, etc.

Third main factor is having a low level of requirements management maturity. Let’s discuss this in more detail. Level zero: There are no formal requirements. So no documentation exists for user or system requirements. Instead, development operates off of user stories with no clear distinction between the functionality of the system being built and expected user experience. Level one: Document based requirements. Static requirement documents are created and most often maintained by each author on their desktop with various emails, slack comments containing more information. This especially gets fun when you have to merge 10 different versions of the same document from 10 different people from 10 different timeframes, none of which have visibility to each other’s feedback in real time. I’ve seen this at several companies where they lose technical product proposals due to this inefficiency of being able to get a proposal out in time representing the right design specifications of their product.


Related Reading: Bridge Engineering Silos with Living Requirements Management in Jama Connect


Kemi Lewis: Level two: Siloed requirements tool. A standalone tool in place to draft review, track comments, version and store static requirements documents, compliance steps, limited reuse, defects and recalls. Level three: System based compliance. Compliance is the forcing function to shift from static to live traceability to meet standards for requirement validation, verification and traceability into a single end to end system. Level four: Product risk reduction. A process centric focus to reduce the likelihood of all forms of product risk via a system enabled live traceability. This requires detection and alerts for specification and functional changes, process exceptions and test failures with resulting impact analysis. The risks mitigated include failure to meet the needs of the customer, failure to perform specific functions, delays, cost overruns, defects, compliance and regulatory gaps, delays and fines in addition to recalls.

And the last level of maturity, level five: Development process improvement. Moving past compliance and risk into the spirit of standard based on quality management and process control. These stages place focus on measuring, managing and improving the product development process. The unintended result of this fragmented process is that critical function such of requirement, traceability, verification, validation, risk mitigation, product integration and compliance are often fraught with information gaps, defects, delays, reworks, recalls, missed requirements and significant manual effort. This includes all areas of the complex product system and software delivery life cycle that can experience negative outcomes and should be actively managed to reduce the likelihood of appearance, such as performance.

Watch the full webinar to learn more about Lessons Learned for Reducing Risk in Product Development

Defining Project Scope

Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document (often including a use case diagram and a context diagram), otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification. 

Vision and Project Scope

defining project and use case diagrams-1

Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. 

A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. The scope statement defines the boundary of the project manager’s responsibilities. 

Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project, but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release: 

  • There will be no virtual or fantasy games via the Web. 
  • There will be no ticketing facilities on the site. 
  • There will be no betting facilities available. 
  • The demographic details for newsletters will not be collected. 
  • Message boards are out of scope for phase 1. 

Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success. 


Related: Project Management Best Practices  

Context Diagram

The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system. 

The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow. 

defining project and use case diagrams-2

The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. 

Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. 


RELATED: High Cost of Poor Requirements Management

Use Case Diagram

Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram. 

defining project and use case diagrams-3

Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction. 

The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases. 


RELATED: Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)

The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams. 

Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events. 

Check out Part 2, Defining Project Scope: Feature Levels and System Events 

Check out Part 3, Defining Project Scope: Managing Scope Creep 


Download our eBook, Best Practices Guide for Requirements and Requirements Management, to learn the fundamentals of requirements and how effective requirements management can keep your projects on time and on budget.

READ THE EBOOK


This is an updated version of a 2014 article by Karl Wiegers. You can read the archived original here https://www.jamasoftware.com/blog/context-and-usecase-diagrams-defining-scope/.


Product Development Challenges
Help us personalize your content experience!

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to download this informative whitepaper and learn how to up-level your risk management practices:
Conquering the 5 Biggest Challenges of Requirements

Click to download this informative whitepaper and learn how to enable testing earlier in the process to reduce risk:
Verify, Validate, Trace, and Test

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to watch this informative webinar and learn how to establish effective review cycles across distributed stakeholders:
How to Streamline Reviews and Collaborate with Remote Teams, Customers, and Suppliers

Click to dowload this info-packed ebook to improve collaboration and alignment across key stakeholders:
Guide to Optimizing Engineering Team Collaboration

Dowload this ebook to learn the importance of tracing requirements without the headaches and risks of a traceability matrix in Excel and set your organization up for future success:
The Jama Software Guide to Requirements Traceability

In this webinar we address how to solve some of the key challenges teams face when integrating hardware and software requirements, risks, and tests, with a document based or legacy tool approach:
Managing Product Development Complexities Across Hardware and Software Teams

Dowload this whitepaper to learn how to manage projects more effectively and efficiently using collaboration, traceability, test coverage, and change management:
Successful Product Delivery

Dowload this eBook to learn the business value of better requirements, the four fundamentals of requirements management, and finding the right level of detail in requirements:
Best Practices Guide to Requirements and Requirements Management

Dowload this eBook to gain insights to help you thoughtfully consider potential requirements and test management solutions. Plus, get tips on how to get the buy-in you need to undertake the kind of change necessary to succeed with complex product development:
Selecting the Right Requirements Management Tool: A Buyer’s Guide


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.


RELATED: Realigning Engineering Teams for Remote Work with Minimal Disruption

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.

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.


RELATED: Learn more about product development strategies for systems engineerings by downloading our white paper.

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.

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.


RELATED: Optimize Engineering Team Collaboration to Streamline Product Development

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.

 


Product Development Challenges
Help us personalize your content experience!

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to download this informative whitepaper and learn how to up-level your risk management practices:
Conquering the 5 Biggest Challenges of Requirements

Click to download this informative whitepaper and learn how to enable testing earlier in the process to reduce risk:
Verify, Validate, Trace, and Test

Download this whitepaper to learn how to reduce the risk of failing to comply with regulations, and how a single source of truth enables collaboration across distributed teams, increasing insight and minimizing the introduction of risk:
Safeguarding Regulated Products Amidst Growing Complexity: A Frost & Sullivan Executive Brief

Click to watch this informative webinar and learn how to establish effective review cycles across distributed stakeholders:
How to Streamline Reviews and Collaborate with Remote Teams, Customers, and Suppliers

Click to dowload this info-packed ebook to improve collaboration and alignment across key stakeholders:
Guide to Optimizing Engineering Team Collaboration

Dowload this ebook to learn the importance of tracing requirements without the headaches and risks of a traceability matrix in Excel and set your organization up for future success:
The Jama Software Guide to Requirements Traceability

In this webinar we address how to solve some of the key challenges teams face when integrating hardware and software requirements, risks, and tests, with a document based or legacy tool approach:
Managing Product Development Complexities Across Hardware and Software Teams

Dowload this whitepaper to learn how to manage projects more effectively and efficiently using collaboration, traceability, test coverage, and change management:
Successful Product Delivery

Dowload this eBook to learn the business value of better requirements, the four fundamentals of requirements management, and finding the right level of detail in requirements:
Best Practices Guide to Requirements and Requirements Management

Dowload this eBook to gain insights to help you thoughtfully consider potential requirements and test management solutions. Plus, get tips on how to get the buy-in you need to undertake the kind of change necessary to succeed with complex product development:
Selecting the Right Requirements Management Tool: A Buyer’s Guide


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

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

Know What You’re Developing, and Why

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

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

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

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

Requirements and Quality Assurance

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

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

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

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

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

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

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

Staying on Schedule Requires Visibility and Tracking

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

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

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

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

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

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

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

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

Avoid Rework by Defining, Agreeing, and then Developing

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

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

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

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

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

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

Inform and Justify Decisions to Understand Impacts

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

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

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

The dual forces of increasingly complex development projects and heightened expectations of quickly getting a safe and high-quality product to market have changed the way development teams must collaborate to meet these demands.

At the heart of successfully bringing together disparate teams to accomplish this is one skill, specifically: communication.

Learning to effectively communicate as a product manager can mean the difference between a successful product launch or a minefield of errors and missed deadlines.

During the development process, every team member needs clear visibility not only into their own responsibilities, but also insight into the whole of the project — including what every other team member is doing, what changes occur along the way, and all relevant requirements, feedback and deadlines. This makes communication a critical skill for a successful product manager.

Communication is a Soft Skill That Provides Tangible Results

The value of “soft” skills like communication can’t be understated for an effective product manager, especially in a development project with multi-discipline teams working in different locations on different parts of the same project. Teams may be working apart in proximity, but their efforts are no longer siloed.

Successful product managers should be prepared to articulate the big picture of the project at hand, as well as the granular details that can and will crop up during the process.

A product manager should also know the essential questions of any development project: what is being built (and why?), what problem is the finished product trying to solve, and how do you measure success. Keeping those questions front of mind, adapting the answers as needed due to changes or updated requirements, and always keeping stakeholders in the loop is equally important.

Providing teams with feedback and taking corrective action when needed will likewise keep stakeholders on the same page and ensure all oars are in the water and rowing in sync.

Discovering an error early in the process mitigates the need to revisit completed work, which can cost substantial time and resources, and put undue stress on team members.

The product manager must also keep the project scope clearly defined, updating it as needed to avoid mission creep or wasted effort.

Leveling Up Communications During Development

Clearly articulating the multitude of directives and shifting goals and priorities across teams is essential for ensuring all targets are hit and mistakes are caught and corrected early. Misunderstandings at any point in the development process can have knock-on effects that impact the entire project.

Old standby team communication methods like meetings and whiteboard presentations still have their place, but harnessing the power of software solutions like the Jama Connect will streamline the process and link your entire team, looping in all stakeholders to key decisions and big changes in real-time. This greatly reduces the chances of miscommunication with features like project dashboards, targeted alerts and notifications and customized reporting widgets.

The product manager is the central communication hub of a development project, bridging the gap between teams, and concisely relaying changes handed down from the client back to the stakeholders.

Depending on the complexity of the project, and the number of requirements involved, the team will need different amounts of feedback from the product manager to ensure a project is executed and delivered with as few difficulties as possible.

Sharpening your communication skills and investing in modern solutions as a product manager will pay dividends in countless ways, making you more effective in the process.

Learn 21 tips to manage every project like a pro with our eBook, “Project Management Best Practices.”

Not everyone leaves school and lands a role as a product manager. For many, becoming a PM was the culmination of an accumulation of skills and gradual transition from other positions.

These were some of the points made in a recent panel discussion of product management professionals held at the headquarters of Pivotal in San Francisco.

The roughly two-hour session, titled “How to Be the Best Product Manager: Navigating Evolving Tools and Trends,” touched on a range of issues currently impacting PMs.

We’ll be highlighting various topics from this panel in the coming weeks, but today we’re focusing on the conversation that unfolded around the various ways the panelists moved into product management, and the personal attributes needed to be successful in the role.

The event was organized by The Product Stack — a small group of like-minded companies, including Jama Software, which coordinates meetups around the country and hosts a Slack channel to support product managers.

As a quick reference for this excerpted discussion below, here’s the lineup of those who participated:

Poornima: There are a lot of people who want to transition to product management for the first time. Share a challenge of what that transition was like for some of you — from what your previous role was into being a product manager.

Jim: I was working for a startup helping to manage a community and my previous experience was not in the technical world. I did some technical writing and corporate training for tech companies, but I wasn’t really a technical person.

The startup was failing and the company was looking for the next thing that would move it ahead because they still had a little bit of VC money left in the bank. The VP came to me and said, “We need to get this one right, so how do we know that this thing we are thinking about is the right thing?” That was my first experience in product management.

I went through a process of interviewing potential customers and talking about the value proposition of the product. And uncovering what problems it would solve and all these things that we do as product managers and take for granted. That was my first foray.

Amy: When I graduated, I started as a management consultant for the federal government. In the federal government, they are very risk averse and things move at a snail’s pace compared to a startup, for example, which is where I eventually went.

When you jump into a startup environment, you’re pushed to make decisions in an instant. It’s this culture shock in the shift, and I think being successful is being able to understand the culture and the way that a company operates. It becomes more about: Can you handle it? Is that something you’re comfortable with to be successful?

Poornima: What about hard skills that product managers need to have?

Jeana: I think product management is very hard because it’s a horizontal role. And, actually soft skills matter the most in product management. When I’m exploring candidates for a product manager, I’m looking for candidates with coaching ability, adaptability and a certain type of humility.

The thing you realize as a product manager is that you are constantly getting it wrong. I’m looking for resilient folks because you are going to be wrong more than right, and you need to embrace that just like you are learning a new thing.

For folks who are really like, “I need to be right,” product management can be a super uncomfortable place because everybody’s constantly telling you how unhappy they are with you. Occasionally it goes right, and they’re like, “you’re the best,” but like 99 out of 100 times they’re mostly unhappy with you.

Poornima: Maybe we could talk about some of the concrete skills people need in product management, just so that we don’t leave people hanging.

Robin: Well prioritization is probably the first one that comes to mind. I actually started more technical. My dad was an engineer and I thought, “This is cool I want to figure out what he’s doing.” I played with the computer when I was really young, but I wanted to know where the thing he was working on came from. And that’s when I started to learn about this person who organizes what he works on. As I got older, I understood that was product management.

So prioritization is probably the top thing and then communication is kind of both the hard and soft skill. The ability to synthesize what you are trying to achieve into words people can remember and actually write down, I would say is another essential skill. It’s one of those things you can see in interviews: Can someone take what they are trying to describe and write it on a white board and in order? The prioritization and communicating “the why” behind that is really essential.

Stay tuned for more highlights from the Product Stack panel in San Francisco, as well as announcements about upcoming events. In the meantime, check out our white paper, “Top Three Frustrations of Product Managers and Tips to Avoid Them.”

Mind the Product

Given how many responsibilities product managers have today, it’s easy to lose focus of the fact that the modern meaning of the role itself is still relatively new. And even still, the position’s duties can vary wildly depending on the organization.

This may be one of the reasons the folks running Mind the Product have found so much success building supportive communities around product management. The organization originally began in 2010 as a small meetup group of product professionals, dubbed Product Tank, in London, and has since expanded into over 100 cities around the world.

Whereas Product Tank facilitates local meetups, its offshoot, Mind the Product — which was initially started as a blog resource for those groups — has now grown to hosting annual product management conferences in Hamburg (April 19-20, 2018), San Francisco (July 16-17, 2018) and London (shown above in 2017; happening October 18-19, 2018), showcasing new job openings on its website and still producing regular content on its blog, among other things.

We spoke with Mind the Product co-founder and CEO, James Mayes, about some of the challenges facing product managers today, the traits of a good and bad PM and how the job itself can instill a sense of imposter syndrome.

James Mayes

Mind the Product co-founder James Mayes

Jama Software: Things are changing so quickly in product development. How can product managers not get left behind?

James Mayes: I think one of the things that really makes a difference for product management over engineering is with engineering you are looking at hard technical skills: programming languages and frameworks. And when something new comes out, you need to learn it and be on top of that.

With product management, there is so much more related to the mindset that you bring. You need to be open and to trust that you don’t necessarily know everything, but know you are surrounded by great people.

If you can learn to ask good questions — learn to continuously be curious — and have the humility to expect that people will be open and honest in return, that’s probably the strongest thing you can do as a product person.

JS: What would you say are the qualities that make a great product manager?

JM: The ability to be constantly learning. Certainly, a fundamental curiosity about everything you touch. The ability to be humble. When you’re trying to bring so many different teams together, your job is essentially to defuse the different empires that might be at play. You have to find the right path from stakeholders and the different requirements, and balance different priorities.

And all along, recognizing that, as product managers, typically while you might be writing the strategy, you don’t necessarily own any of the resources that you have to work with. They don’t report to you. They report to a CTO or VP of Engineering, something like that.

As a product manager, you’re there to build consensus and to get everybody going towards that vision without necessarily having the power to compel them.

Leadership Forum event

A Mind the Product Leadership Forum event in London.

JS: And then conversely, how do you know if you’re working with a bad product manager?

JM: That’s a tough one. And that’s one where we’re starting to look at more and more with the leadership series that we’re running. It’s a very timely question.

From our perspective, we’ve noticed that’s actually one of the biggest shifts in the marketplace over the last five years or so. When we first started going to the conference, a lot of the questions that people were coming with were things like, “What’s the best way to prioritize a backlog? What’s the best way to show my roadmap? How do I engage with key stakeholders?”

And typically, with product managers, there were only one or two of them at their organization. Right now, there are organizations out there with product management functions of 10, 20, 50, 100 product people.

How you identify a manager who’s struggling and how you support them better? That’s one of the questions a lot of people are bringing now.

One of the things that we found is that we have to actually separate out that side of stuff for some of the more mainstream meet-ups and conferences that we do because it’s hard for somebody to ask that question when their team is sitting around them. They wonder, “Is he talking about me?”

JS: How do you keep product managers from getting too discouraged? Because obviously you have to keep your head up if you’re going to complete development successfully, but there are a lot of setbacks along the way.

JM: It doesn’t matter how many times we say, “Keep your chin up, you’ll get through it.” What really matters to product managers is hearing it from other people who are also in those trenches. That makes a huge difference.

I think the other thing we have heard a lot more of over the last year or so is the idea of imposter syndrome in the workplace. The opinion that maybe I’m not up to it.

Listening to some of the talks we’ve had over the last year, one of the things that’s started to become a little bit more obvious is the breadth of skills required to become a product manager contributes towards imposter syndrome.

You’ll be working with a design team and you might be doing some prototype design work. The designers will be better than you.

You’ll be with the engineering team and you might hack a little bit of code together to try something. But the engineers would do it better than you.

You might be working with the commercial team to look at the pricing and marketing. But those people are specialists and they’re going to know it better than you as well.

Product manager? You’re going to have a very, very broad skill set. You’re going to be doing a little bit of all these things. But everywhere you look, there’s going to be true specialists who outclass you in that particular niche.

And that can very, very easily contribute towards this overall feeling of, “I’m surrounded constantly by people that are better than me.”

JS: Right, so what do I bring to the table?

JM: Absolutely. Yeah, that’s, that’s the point at which, as a product manager, you need to be engaging with those teams and say, “How can I be making you more effective? How can we work better on this? What can I do for you? What can you do for me?” And really making sure that those lines of communication are as open as they possibly can be.

It’s one of these things that, again, we’ve seen more and more on our side of things is product managers asking about communication skills and stakeholder management skills.

Those soft skills that, typically, people in technology-led companies don’t get trained for. They’ll get training on design tools or coding languages. But those other skills that make the best product managers? Not so much.

For more insights into becoming a more effective product manager, check out our white paper, “Top Three Frustrations of Product Managers and Tips to Avoid Them.”

With ever-looming deadlines and high expectations, it’s possible that software developers at some point in their careers will be subject to “crunch time” — weeks or even months of intense pressure that requires many extra hours to deliver a product on time.

These extended workdays, fueled by caffeine and cortisol, can wreak havoc on the health and mental well-being of those involved, and nobody does their best work under those conditions.

Product managers have a responsibility to their team members to plan and execute development projects in such a way that mitigates the need for such soul-crushing marathon sessions, and the successful delivery of a project may depend on taking those steps.

Failing to plan to avoid the need for crunch time can lead to team member flameout, and somewhat ironically, jeopardize a project’s timeline.

Planning and Communication Beforehand

Communication is a central component to fostering a development environment where developers’ resources are put to efficient use, limiting redundant efforts wherever possible and clearly enumerating every team member’s responsibilities.

Ernesto Mosquera, President at Global & Sustainable Products Consulting, emphasized this point in an interview, highlighting not only the importance of communication and planning in navigating a complex product development project, but also the key step of getting input from workers on the ground.

“For an on-time delivery it is essential that preliminary planning of the project is done in detail and involving all key resources,” Mosquera says. “In this phase, a realistic scope and timeline for the project is created that matches the requirements of the product management.

“My experience has shown me that if in this phase you do good and accurate work communicating with the team members and involving their input, you create the right foundation for a successful and on-time delivery.”

Staying on Track

Part of this involves setting realistic expectations from the outset and building in extra time for any complex development project that could result in excessive crunch time.

Establishing this time buffer allows team members to work at a sane, healthy pace, and can avoid last-minute time crunches that are all-too-often necessary elements of many development projects.

Of course, sometimes projects are thrown off track by unforeseen problems or changes. But the earlier and clearer those changes are communicated down the chain of command, the less likely they will lead to a potentially project-killing situation.

In these cases, using an effective product development platform that provides end-to-end traceability can also prove advantageous. With full traceability, teams can accurately assess the impact of changes up and downstream while making time to ensure full coverage for priorities and keeping everyone aligned throughout development.

Product Manager’s Responsibility

Lance Ellisor, Chief Growth Officer at Journyx, said he favors an approach where a product manager creates clarity and ruthlessly prioritizes throughout the process, which hedges against zero-hour panic and frustration as key team members realize they’ve been working from an out-of-date set of instructions.

“The product manager’s most important responsibility is to ensure utter clarity — of both scope and timing — between the stakeholders (customers/market) and the team delivering the work,” Ellisor writes in an email.

“Not only does this clarity avoid last-minute changes, it also optimizes project costs by frontloading any changes such that they have the least cost and the most impact on the project success.

“This means involving stakeholders (and the team) in clarifying needs, reviewing the proposed design, interacting with prototypes, test-driving the solution throughout as it’s being built, and affirming the candidates for release.”

Staying Afloat

The responsibility for building a foundation of clarity of purpose falls squarely on the product manager. Prioritization of project goals and deadlines must be understood and communicated to the stakeholders, and it’s not always an easy decision to make, according to Ellisor.

“The product manager must prioritize the needs with vigorous discipline, and frequently throughout the project as realities unfold and the time gets short,” Ellisor writes. “This is where a product manager quintessentially proves her mettle, as she’ll have to make some very tough tradeoff decisions — informed by both stakeholder needs and engineering constraints — to ensure a timely delivery of a solution that has the most value.

“It’s akin to having to throw some supplies off the boat in order to keep it from sinking; not a fun responsibility, but heroic.”

By meticulously planning each phase of a project, including budgeting time for the unexpected, and above all continuously communicating changes and expectations to your support staff, you can greatly reduce the odds of those long, miserable hours of crunch time.

Learn how to overcome more development challenges with our white paper, “Top Three Frustrations of Product Managers and Tips to Avoid Them.”

Bridging the Gap in Digital Product Design

Digital technologies are converging with traditional products at dizzying speeds. This fast-paced, integrated evolution is changing product development, and many companies are struggling to retain their footing.

Despite the shifting landscape, one thing remains clear: an excellent product requires a solid development process. Helping companies improve product development is at the heart of what Jama Software does, but we know this complex practice extends far beyond our platform.

To get a better feel for the methodologies and pain-points teams are facing creating connected products, we sponsored a Harvard Business Review Analytic Services study. The resulting report, “Bridging The Gap In Digital Product Design,” features insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services, and more.

What We Discovered

While we knew connected products were becoming more prevalent in our everyday lives, that trend has only just begun. A full 86% of organizations in our study have either applied digital technologies to their existing products or services, or are in the process of doing so.
86% of business and IT leaders are developing smart products or planning to
For many businesses, adding software to their physical products is already a challenging proposition. It’s compounded by stress from new competitors threatening disruption. To maintain an edge in this new reality, companies are being forced to act fast, and that’s placing significant strain on the development process.

In fact, 80% of those implementing digital technologies say they feel either somewhat or significantly added pressure to increase time to market for products and services. And an even greater majority (89%), expect that pressure to grow in the future. According to the report, some of the other big challenges businesses are facing with this transformation include ensuring new smart products work within the ecosystem of other connected devices, the clashing of traditional and digital product design, and trouble staffing and training the right employees.
89% of business and IT leaders expect somewhat or significant increases in time-to-market pressure from implementing digital technologies
When implementing any new process, there’s bound to be some unforeseen obstacles along the way. For instance, just 24% of respondents in the report identified the need to manage and secure customer data as a major challenge. The problem is many organizations may be underestimating this responsibility, according to Hans Brechbühl, executive director of the  Glassmeyer/McNamee Center for Digital Strategies at the Tuck School of Business at Dartmouth, who was interviewed for the report. That’s because while the constant flow of usage data can be advantageous for informing future product iterations, companies inexperienced in managing this information may not realize the evident risks.

What’s Next

There are so many valuable insights and trends within “Bridging The Gap In Digital Product Design” it’s more than will can fit into a single post. That’s why we’ll be diving deeper into some of the themes and findings in the coming weeks with a dedicated blog series, featuring observations from Jama Software experts.

And let me know any feedback or questions in the comments below. With so many major industries refreshing product offerings with connected devices, the conversation about the best methodologies for improving and maintaining this process is just getting underway.