The United States’ Naval Air Systems Command (NAVAIR) is looking to advance its development process for aircraft and weapons, and at least one commander believes ditching paper will be the path forward.
Grosklags is heavily in favor of moving away from paper-based product development. Instead, he’s advocating for transitioning to a model-based systems engineering approach that would foster the creation of specifications, digital drawings and testing in virtual environments.
USNI News reports that Grosklags thinks model-based systems engineering would help decrease the time and headaches associated with designing, vetting, reworks, and testing of new aircraft, weapons and ships. Plus, it would also assist with integration and training issues, which he specifically called out as current pain points for the operators of these products.
Moving NAVAIR to a model-based systems engineering approach would offer increased visibility for engineers into the actual environmental conditions these products would be operating in, for instance. Currently, NAVAIR is managing requirements through a less precise process.
“We write a 500-page specification with 20,000 shall-statements,” Grosklags said, according to USNI News, “and we give it to industry and go, here, (design) this. We don’t give them the threat models, we don’t give them the blue force models, we don’t give them that system of systems family model we just built. We give them a 500-page document with 20,000 shall-statements.”
“In the end, capabilities-based test and evaluation is about testing the capabilities – it’s not about ensuring industry met every one of those 20,000 specs,” Grosklags said, via USNI News. “That’s where we spend all our time today during T&E, validating that industry met the specs. The fleet couldn’t care less, the fleet wants to know that the attributes and the capabilities that they’re counting on will be met.”
While Grosklags expressed his enthusiasm for moving to a digital, model-based process, he noted it’s a lot easier than implementation. That said, NAVAIR intends to begin adding model-based engineering any way it can, including implementing it into into new designs and sustainment programs, and learn quickly through the process.
Read full coverage of Grosklags’ talk at USNI News, and check out our e-book, “All Systems Go,” on how to unify systems engineering processes and people.
The marriage of hardware and software is no longer a niche trend in product design. With the growing phenomenon, The Atlantic recently ran a piece, titled “The Coming Software Apocalypse,” about the serious challenges industries face when developing products that rely on both hardware and software, and the real-world consequences occurring as a result.
According to Nancy Leveson, a professor of aeronautics and astronautics at the Massachusetts Institute of Technology, it’s not always a matter of problems with software code. Instead, one of the toughest obstacles of merging hardware and software is engineers being too concerned with getting code to work correctly, instead of focusing on the solution the product is supposed to provide. “The serious problems that have happened with software have to do with requirements, not coding errors,” Leveson tells The Atlantic.
What Could Go Wrong
The article details terrifying, real-life stories of hardware and services malfunctioning due to issues with implemented software, including a car being unable to brake on a highway and 911 dispatch software leaving 11 million people without access to emergency response.
In the case of the 911 outage, cell phone technology drove changes to the 911 infrastructure, causing the issues. The Atlantic states that emergency calls traditionally were handled locally – less risk, but less technological advancement. The spread of smart phones brought about all sorts of supplemental possibilities to facilitate 911 services, such as texting instead of calling or sending videos to dispatchers. These prospects pushed more complex, connected systems for 911 to be developed. And it’s these advanced systems that contributed to the outages.
The updates to 911 services mirrors similar changes in many other industries, where the rapid adoption of internet-driven technologies over the past decade has pushed companies to add connectivity to everything from vehicles to personal accessories.
Given the evolving demands of the consumer, the speed at which these devices are being produced, and the increasing complexity of the products themselves, problems like the aforementioned have emerged. Leveson gives The Atlantic an excellent diagnosis of the complexities of today’s software issues: “The problem is that we are attempting to build systems that are beyond our ability to intellectually manage.”
As The Atlantic points out, previous generations of engineers could prove a creation reliable by testing all of its physical parts. A problem with a new bicycle, for instance, could be discovered by checking its tires, spokes, chains, etc. With software code, as Leveson notes, the complexities are “invisible to the eye.”
Getting Requirements Right
Requirements are a huge part of making sure products are built the right way. It’s not just enough to have requirements though; they have to be expressed clearly and effectively to all stakeholders. Otherwise, you risk leaving those tasked with creating each piece of the product to interpret things for themselves, resulting in all kinds of problems — including building the wrong thing, costly reworks and missed market opportunities.
And, as mentioned in the article, misunderstanding requirements is a common ailment for development teams. When a requirement is written ambiguously, for instance, the person responsible for coding or building it may interpret it differently than was the intention of the person who wrote it. Requirements also change throughout the development process, through both internal and external feedback, for instance, which also creates opportunities for the introduction of error.
And, with so many products being hardware-software hybrids, it’s made their development a lot more complicated. For instance, vehicles with connected technologies now include millions of lines of code — related to everything from acceleration to parking assist features. In such cases, changing even one line of code, intentionally or not, can set off an unintended chain reaction that devastates a product. With so much information, it’s impossible for the human brain to account for all of the variables that can occur when it’s altered.
Better Requirements Management
A solid requirements management solution can solve several of these challenges. A good requirements management platform improves the end result by facilitating collaboration, traceability and testing. It also assists with fulfilling compliance in regulated industries, cutting down on risk and allowing for verification and validation.
Not only that, but a good requirements management platform allows team members to provide feedback in real time, cuts down on meetings and provides more time to focus on ensuring quality and getting the product out the door.
Requirements management alone won’t solve all the issues raised in The Atlantic’s article, but it is definitely a step in the right direction. The introduction of integrated software to so many traditional products — especially devices and services we have come to rely on for our own safety — means requirements have become too complicated to languish in antiquated document or legacy software.
Instead, companies need to rethink their processes when developing software-infused products, and partnering up with outside organizations is one way to do that. For instance, according to the recent report, “Bridging the Gap in Digital Product Design,” more than half of businesses building complex, connected products are teaming up with software or other companies to improve their abilities and processes
The faster organizations creating complex products realize the benefits of using different platforms and methodologies, the better off we’ll all be. And hopefully we can avoid anything close to a software doomsday.
Product development is already a stressful endeavor. For companies focused on merging hardware and software into smart products, it’s only getting more intense.
According to the Harvard Business Review Analytic Services report, “Bridging The Gap In Digital Product Design,” nearly 90% of companies are either adding or planning to implement digital technologies to their products.
Given the new process and competitive landscape, 80% of those same businesses say they’re feeling extra time-to-market pressure. Not only that, but an even larger majority (89%) believes the strain will only grow in severity.
“There is pressure to always innovate and create the next generation version of your product,” Jama Software’s vice president of product, Jennifer Jaffe, says. “Sitting in that market is, by definition, a very uncomfortable place— specifically for a lot of companies who have been around a long time and who didn’t used to have all these pressures.”
Driving business concerns are fears of disruption. From cell phones to taxis, home energy management to automobiles, it can feel like no industry is immune to being blindsided by new technology. While companies can’t stop a savvy new competitor gunning for their position, how they innovate in response is crucial.
Software vs. Hardware Traditional product companies are used to building hardware. When you add software development to the mix, there needs to be some alterations to the process.
That’s why one of the biggest priorities for businesses adding digital technologies to their products should be creating a plan to integrate the hardware and software teams. To do this, businesses must have a firm understanding of their existing development process, its necessary documentation, and logical gaps.
They’ll also need to recognize that software developers and traditional hardware developers work very differently. Figuring out how to unify these two practices, so they’re operating in tandem and not as opposing forces, is key. One of the best ways to do that is by having a method facilitating open communication and accountability.
“Most critical is having real time transparent communication, so that when things change on the software or the hardware side, all parties are informed and can adapt,” Jaffe says. “Without that collaboration, the two teams run the risk of working in isolation and developing products that are incompatible with each other.”
When to Innovate
Another area to consider when moving to connected products is not trying to start from scratch with every release. If a strong hardware platform has already been built, for instance, it makes sense to reuse it. Then, you can focus on incremental gains that can be handled in software updates.
“The more you can put the heavy lift of innovation on the software side,” Jaffe says, “The more likely you are to be able to respond quickly and create lots of different, compelling variants of your product’s experience — and do it as cheaply as possible.”
In that case, the product management team can set about envisioning the requirements of the future and brainstorm all the different use cases for the coming years. For instance, maybe that means creating hardware that can scale to accommodate a heaver usage on processing or memory. Then, looking ahead, if 80%-to-90% of the hardware requirements will basically remain unchanged, the development team can really be pushed to innovate on that extra 10%-to-20% of a new product.
This is also where a product development platform can really give developers an edge. With a simple, efficient solution for saving and reusing your hardware requirements, teams can focus on innovating iteratively.
That’s also why more than half of the companies going digital are partnering with software or other companies to assist with the digital transformation, according to “Bridging The Gap In Digital Product Design.”
What to Focus On
Today’s market is driven by consumer choice. Whether we’re talking about watches or coffee makers, customers have high expectations from products, and there’s a heavy push to constantly move forward. When one company’s product family goes smart, it almost feels inevitable competitors will too.
So businesses must listen to their customers to develop requirements. “The companies that are getting disrupted are oftentimes legacy companies whose business model, technical model, or both, don’t support newer methods for developing products,” Jaffe says. “And, specific to this idea of building to customer requirements, they’re companies that don’t have specific practices or tools to bring customer requirements to the forefront when they’re defining their product.”
Before production, then, companies should be putting prototype ideas in front of consumers for feedback on usability and value. And then running those customer requirements past engineers to sift through what’s feasible. Also, ensuring the requirements are documented in a clear way will keep various teams aligned throughout the process.
Moving Forward
All these shifts and crunches can significantly rattle a traditional product company not used to dealing with them. Keeping your team laser-focused on the evolving process will guide it to success.
“You have to prioritize the work that’s being done by your product development team and then not allow additional scope to creep in,” Jaffe says. “You really have to be judicious about the decisions you make, about what to prioritize, what to work on, and make conscious decisions to say no to projects that aren’t priority one for your development team.”
One thing that titans of any product category should avoid is kicking back with the belief that their winning days will be endless.
“A new, fresh company can come in today without all the legacy of old development practices, of old expectations of what it meant to serve a market,” Jaffe says. “Not only can they be more nimble and receptive on the technology front, but frankly, as a business, they can pivot quickly in the face of shifting consumer demand. That’s how they roll.”
Get a deeper look into the pressures driving companies to develop connected products with our report, “Bridging The Gap In Digital Product Design,” featuring insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services, and more.
Today, most consumers research products online before purchasing. Doesn’t matter if the product is B2C or B2B, or even if there’s a single competitor in the marketplace. You can bet customers are searching for opinions on your product, as well as alternative options.
“We are seeing the growing power of a customer in driving perceptions of brands/products, and reviews is just one way,” Tom Collinger, Executive Director of the Spiegel Research Center at Northwestern University, wrote in an email to Jama Software.
Recent research has highlighted the ways in which consumers perceive online reviews and how they inform purchasing decisions. And from that has come insights into how companies can think about online reviews — including why negative ones aren’t all bad — as well as ideas for future-proofing from backlash.
Turns out the subjects’ opinions were very much swayed by reviews, as their second round of ratings fell somewhere between their original score and the average. As Science Daily notes, “Crucially, when products had a large number of reviewers, participants were more inclined to give ratings that lined up with the review score, particularly if they lacked confidence in their initial appraisals, while they were less influenced by ratings that came from a small number of reviewers.”
As the study showed, people leaned more toward group consensus when their confidence about a product’s overall quality was low and the pool of reviews was large. Anecdotally, this seems to track. If you see a product online with over a thousand five-star reviews versus one with just two five-star reviews, you’re probably more likely to trust the one with more reviews, since it appears more credible.
Importance of Average Scores
Not that products with tons of 5-star reviews receive a blanket pass. Another recent study on the power of online reviews, this time conducted by Northwestern University’s Spiegel Research Center, in conjunction with the platform PowerReviews, analyzed millions of customer experiences from online retailers.
Northwestern discovered that products with near perfect scores can sometimes appear almost too good to be true. “Across product categories, we found that purchase likelihood typically peaks at ratings in the 4.0 – 4.7 range, and then begins to decrease as ratings approach 5.0,” the report states. So while you shouldn’t seek to attract purely negative reviews, some can help your product’s authenticity.
Beyond that, Northwestern also detailed some other ways in which negative reviews can help a product. By displaying at least five reviews online, positive or negative, the purchase likelihood is 270% greater than that of a product with zero reviews, according to the study.
Importance of Early Reviews
The study also discovered that nearly all increases in purchase likelihood of a product from online reviews occurred within the initial 10 reviews posted, with the first half of those being the most influential.
Of course, not all websites display reviews the same way. Some sort by review quality over chronological order, for instance. For the purposes of this research, the first five were found to be the most important regardless of how they were presented. “Our analysis describes the first five the consumer sees,” Collinger wrote in an email to Jama Software. “This is independent of the way in which they are listed by the retailer.”
This is why it’s so important for a company to get a product right at release. If a new offering gets savaged by a wave of online reviews initially, regardless of how they’re sorted on a website, those will be the first and most influential opinions people read when considering a product. And that reputation can stick. Patching the problem in future releases well help, but then you’re counting on people updating their reviews later on, which is no sure thing.
Good Products Come From Good Processes
When managing online reviews, the Northwestern study urged companies to focus on the first five reviews, embrace critical reviews, and follow-up purchases via email to urge consumers to write reviews. In fact, reviews from actual, verified buyers — as opposed to those who post reviews anonymously — are more likely to be positive than negative. Also, making it easy for buyers to post reviews on a company’s website, for instance, regardless of their device or platform, was recommended.
From a business standpoint, one other fundamental way to get online reviews working in your favor is by releasing the best product possible. That starts with a solid development process, with plenty of quality safeguards in place.
Best practices like implementing test management early and often, for instance, will reduce the number of defects or bugs that are likely to show up in your final release. Often, it’s exactly those types of design misfires that’ll get a product maligned by early online reviews.
And while ensuring the quality of a final product is a key factor of success with online reviews, according to Collinger, it doesn’t stop there. “Getting the entire customer experience right is the very simple solution to leverage this growing customer influence,” he wrote.
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.
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.
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.
In the product development process, requirements are the foundation to success. They define what a company is trying to build. And they identify what a product needs to do and what it should look like. As the number and complexity of products increases, so do the requirements to support them. Today’s sophisticated products and software applications often take hundreds or thousands of requirements to define their scope so exercising successful requirements management is more important than ever.
It takes an entire team to define and track product requirements. A product manager, for example, will request a feature that describes how the product will solve a problem. A designer will write requirements to illustrate how the product should look or perform from a usability or user interface standpoint. A business analyst will want to make sure the product is built to specific technical or organizational constraints.
Mismanagement of stakeholder needs results in drawn out project timelines and increased costs. According to Carnegie Mellon Software Engineering Institute, 60 percent to 80 percent of the cost of software development is in rework. Development teams can end up wasting their budgets on efforts they didn’t do right the first time. In fact, it can cost up to 100 times more to correct a defect later in the development process, after it’s been coded, than when it’s still in written form, according to Borland Software Corporation.
On the other hand, successful requirements management can eliminate 50 percent to 80 percent of project defects. The entire team can work seamlessly together because everyone is aware of the goals, feedback and decisions. And that increases the likelihood of completing the product on time and within budget.
To effectively manage requirements, it’s important to understand the ins and outs of these four primary principles:
Over the last two years, the semiconductor industry has seen an unprecedented wave of consolidations and M&A activity – deals worth $85B in 2015 and a whopping $115B in 2016! As a result of all of this consolidation, semiconductor companies are finding themselves having to integrate diverse teams, technologies and IP on an ongoing basis.
This consolidation is driven at least in part by the exponential rise in the cost of building chips at the newest nodes (16nm, 14nm, 10nm…). Semiconductor companies are trying to leverage their existing IP[1] – and the IP acquired through M&A – into more designs to control this rising cost. This leads to a greater emphasis on IP reuse than ever before.
In order to be successful in this new world order, many teams are beginning to adopt industry standard best-practices for managing their projects. One of the key components for the successful management of a distributed, complex and time-critical SoC (System on Chip) project is Requirements Management (RM). Having a full set of requirements, easily accessible and constantly updated for the project makes it much easier to bring transparency and tracking to the SoC.
Once requirements management is in place, it is also essential to be able to tie requirements back to the context of the IPs being used in the SoC. Since IP management and requirements management are two separate systems, being able to connect these two is critical.
Implementing a requirements management system like Jama with an IP Management system like ProjectIC allows fully traceable hierarchical SoC development during the IP Lifecycle Management process and closes the loop between system design requirements and IP implementation details. This represents one more step forward to reaching the important goal of implementing IP reuse strategies that reduce development costs, improve time-to-market, and keep semiconductor companies profitable in today’s highly competitive SOC marketplace.
To download Vishal’s whitepaper on this topic here.
[1] IP: In this context, IP or Intellectual Property is a self contained design block that can potentially be used in multiple projects.
Finding the requirements management sweet spot means being concise, specific and parametric, and answering the question, “What do we need?” rather than, “How do we fulfill a need?”
In the post below—the first of three transcribed from his Writing Good Requirements workshop, with notes and slides from his presentation deck included—Jama Consultant Adrian Rolufs explains common problems teams go through, and how to avoid them.
= = Start Part I = =
Today I’m going to be speaking about product definition and how to ensure that you are using requirements correctly and to maximum benefit.
A bit about myself: For the first 10 years of my career I worked in the analog and mixed-signal semiconductor industry, first as an applications engineer and later as a product definer.
As a product definer I became a customer of Jama Software. Adopting Jama to manage requirements completely revolutionized how I built products. So much so, that a couple of years ago I joined Jama Software to help as many teams as possible benefit from using Jama.
Product development teams face many challenges, but the ones we are going to focus on today are how to systematically navigate the path from a high-level market need to the specification of an actual product.
Specifically, we’ll be looking at this challenge in the context of development teams that work from a specification, but the concepts apply to all development.
So, the ultimate question is, really, why do we write requirements at all?
Requirements are a tool that guides the journey from the vast number of possibilities for products we could build, to determining whether the product we want to build is going to be successful or not, down to picking exactly the right product we’re going to build.
Particularly in systems and hardware development, designers are typically not able to start developing a product until there are sufficiently detailed requirements, or possibly even a specification.
So for the purposes of the discussion today, I’m going to use the term product specification to mean the detailed document that describes what the actual product is, the final result of the development process.
One way of looking at this challenge is shown below. Imagine that the orange circle is every product that a given team knows how to build, and the blue dot is the exact specification for a particular product. The specification defines exactly which product the team will produce.
Let’s say we have a product we’ve developed, and we have the specifications that go along with it that tell us exactly how it works, how well it performs, size and cost, and requirements are the guide we use to get through those.
In many industries, you have to have a fair amount of detail fleshed out before teams and resources get assigned and dedicated, so there are milestones to meet as you go through this. So, you’ll get some level of detail and you have a milestone to review it. You’ll get more detail; you’ll have more milestones.
Usually in the process, companies follow step by step guides for getting into the details, but there is usually a lot of room for interpretation along the way, so we’ll talk about some of the structures you can apply along those ways.
In more iterative environments, perhaps more software-type environments, you might actually go through this loop much, much more quickly, so you might do all of this but still focus on a very specific function and do it in a couple of weeks.
The same concepts are still applicable; it all depends on the scope of the product, time frames, interactions, and things like that. What we’re going to talk about here, in terms of systematically defining what to build, applies to almost any kind of product.
So, one of the first steps is defining the overall kind of space that the product team is going to operate in, and that’s typically done with a market definition or market requirement document, or something along those lines.
There are different approaches to doing that. The approach I recommend is defining that solution space with problem statements and constraints, because problem statements are clear descriptions that answer the question, “What is this product supposed to do such that it adds value to the market?”
So, if the product solves a problem that a lot of customers have it should sell well, and if it does it meeting the constraints, this should also result in it selling well. This is kind of the starting point for our product development process.
This might include, in addition to the problems that it’s solving, certain amounts of functionality that are required for the industry. The right amount of performance, functional and non-functional types of requirements, schedules, and things like that. This is really a kind of visual way of thinking of a market requirement set.
Important things here are not over constraining the development team or the design team. If these requirements are so specific that we can only build one product, then there is not a lot of room for the teams to innovate. If the requirements are really vague, the teams don’t know what to build, so we’ll talk through that next.
So the first example—and this is a common scenario that a lot of teams face— is that the solution space or the market requirements are so vague that the design team doesn’t know where to start.
It could be they’re too high-level, say, a problem statement with no constraints, in which case the design team doesn’t know whether the solutions that they can think of are valid solutions to those problems or not.
From the perspective of a designer, the detail that a marketer can provide is usually insufficient. So many questions remain unanswered, that either they go and build something, and it doesn’t end up resulting in a successful product, or they ask a million questions, that the marketer doesn’t have answer to.
The problem is that while the blue space is completely enclosed here, it typically isn’t. Many more detailed requirements are needed to fully enclose the box. Specifying those details completely will also likely dramatically shrink the blue area.
Even though, this approach is clearly problematic, many teams fall victim to it. Designers may feel that they can’t trust marketing because they know they aren’t getting enough detail and often have experienced failed products as a result of it. Marketing doesn’t understand why designers can’t just get on with building the product and why the products are missing the target, late, or both.
It could be there are other factors not considered, and so a lot of times this results in design teams starting to ask lots and lots of questions, which is good. It’s better they ask those questions than don’t, but it does mean that you possibly spend a lot of time iterating in this phase of the project because there’s not enough definition around, well, what problem are we trying to solve and what are some valid constraints around that?
The other possibility is the design team might say, “Hey, we can build whatever we want,” and they proceed without asking questions. It might be brilliant or it might be a complete failure, but because there are no controls for predictability, it’s definitely a high-risk situation.
Another common scenario is that the market requirements are so specific that the design team doesn’t have room to innovate. The market requirements could be a copy of a competitor’s specification with a couple of lines changed to say, “Build me one of these.” Or it could be a previous specification produced by the company with a few modifications that say, “Improve everything by five percent.”
Those kinds of requirements documents tend not to lead to a lot of innovation. It’s okay to have them, because sometimes you need to make a derivative part that’s just a quick improvement to an existing device; this can be very successful in the market.
But if you have too many of those types of products it becomes more difficult as time goes on to react quickly to new requests because you don’t have new technology. By focusing on modifying your existing technology, you’re likely falling behind in the competitive landscape with your customers.
You want to have a good mix of products that are defined in such a way that innovative technology can be developed. Design teams can go solve creative problems using their engineering skills, and that’s really the biggest benefit to the overall organization; it also makes the engineers happier because engineers love solving problems. If you just say, “Build me one of these,” they’re usually far less satisfied and far less enthusiastic about working on a project.
All right; so the third common scenario where this can go wrong is you define what your problem statement is, you have constraints, you think you’ve got a really well defined solution space, and the team goes off and builds something. And along the way the team finds there are challenges in the design, make some changes, and build a product that simply doesn’t meet the original requirements.
Marketing may have provided high-level problems to solve with constraints initially, but the focus moved to agreeing on a specification. As design challenges come up and trade-offs are made, the specification slowly drifts outside of the blue “acceptable products” area.
The result is that the team is so focused on building that they end up not building the right thing.
While this can be addressed by periodically reviewing the specification against the high-level requirements, there are likely many details in the specification that do not clearly trace to any high-level requirements.
As a result, the team doesn’t actually know they are building the wrong product.
When teams say, “Okay, we can make that change,” but don’t have a “live” source of traceability back to the requirements, problems are guaranteed.
This is very common scenario when managing the process in documents and spreadsheets because it’s very difficult to actually have traceability in those kinds of tools.
And what happens as teams go through the discussions and make the compromises, is that they stray from solving the original problem, meeting the original constraints and focusing on the original solution space.
Now, sometimes you get lucky and you can still sell what you’ve built, but what I’ve found in the industry overall is that as time has gone on, things have gotten sufficiently more complicated such that the chances of one these products being successful is decreasing.
It used to be that if I got things wrong, using what I built for another application was possible. That’s rarely case with today’s complex systems.
= = End Part I= =
Few complex processes require more scrupulous attention to detail than taking a product from concept to design, through development and into manufacturing. And when it comes to medical device design and manufacturing, nothing is more critical than quality and compliance.
For more than 30 years, Fortune 500 companies have turned to Plexus engineers to design, develop and test healthcare and life sciences products. Plexus is ISO 13485 and Quality System Regulation compliant with engineering teams and manufacturing facilities around the world.
In order to ensure regulatory approval, Plexus needs to be able to guarantee traceability and documentation. After considering a variety of solutions for a collaborative, compliance – and audit-friendly requirements management tool, the team selected Jama.“Our main performance measurement is the repeat business we receive from our customers. They don’t come back if we’re not meeting the schedule and project budget. And these are things that Jama helps us do,” says Dave Strandberg, Director of Engineering Solutions.
Since introducing Jama, Plexus’ distributed teams are able to more efficiently collaborate on the requirements of their Class II and III medical devices. With Jama, Plexus has dramatically reduced the time it takes to assemble test data and shortened time to market.
Learn more about how Jama is helping Plexus deliver to their customers again and again with the confidence of proven compliance. Read the case study.
“Engineers are relatively good at logical decisions. The problem is with the assumptions. Testing the assumptions is the most important trait of a good systems engineer. Keep the critical-to-customer requirements always in mind; everything else supports these. Must not strangle the project with many meetings. System Level cannot be the only verification approach—Need to do things right the first time (at lowest level). There are thousands of ways to fail; most have not been explored.“
Dr. Steve Jolly, Systems Engineering Director for Lockheed Martin Space Systems. Assembled from material presented at the 2011 NASA PI Forum.
Leave it to the Systems Engineer responsible for overseeing NASA’s early warning alert spacecraft to sum up the worries that keep Systems Engineers up at night.
Here at Jama, we work regularly with Systems Engineers and know how comprehensive their skills and responsibilities are. Many of our customers serve as trusted advisers to Project Managers, and assist in decision making. Most must also be skilled leaders, listeners, negotiators and diplomats. As Jama Solutions Architect Cary Bryczek explains, “To be a successful systems engineer, you should be a natural problem solver and excellent communicator. You need to be able to consider multiple factors and figure out ways for all of these factors to come together and form a whole process.”
Suffice it to say that for Systems Engineers, achieving the desired state of harmonious integration is no easy undertaking:
Tall tasks:
Delivering on requirements while dealing with multiple interests, competing agendas and numerous constraints.
Pressure points:
Missing out on critical customer feedback during early development stages.
Optimizing systems design for integration and balance, with no system or sub-system sacrificed or favored at another’s expense.
Being able to accurately assess relationships among the parts of a complex system to understand where compromises in development can be made safely and efficiently without harming functionality.
Guaranteeing that different components produced by specialty engineers will work as a cohesive and efficient system or product.
Burning desires:
To be able to assess and address, in one single platform, design compatibility, requirements definition, management of projects, cost analysis, scheduling, maintenance needs, ease of operations and future systems upgrades, and to communicate with engineers, managers, suppliers and customers regarding system operations.
With Jama, Systems Engineers can turn foreboding “Twilight Zone” episodes into fearless “Quantum Leap” epics.
How so? You’re able to…
Identify possible errors early in the project so they can be remedied before they impact quality.
Gain visibility upstream to understand the business requirements being worked on and receive prompt notification of requirements changes that impact tasks.
Understand (and help others understand) how complex systems and products integrate and operate, how well they meet overall goals and objectives, and how they can be improved.
Communicate easily with the entire project team to get clarification and decisions made, regardless of location.
Read 2 Brains, 1 Product: The Builder’s Dilemma to find out how Systems Engineers can use Jama to balance disciplines and create high-performing systems and products that meet goals and objectives.
Check out other ways Jama helps business and engineering teams get and stay aligned:
“Our main performance measurement is the repeat business we receive from our customers. They don’t come back if we’re not meeting the schedule and project budget. And these are things that Jama helps us do,” says Dave Strandberg, Director of Engineering Solutions.