Unnecessary repeated effort is an insidious source of hidden costs. In medical device development, an iterative work process is fundamental to creating a successful product, but if the iterative process is not performed with careful consideration, it can become the source of a lot of hidden costs.

Transitioning from one team to another, distributing work, or passing the baton typically involves some overlap in tasks and activities performed. Even within a single team, repeated work or practices could be optimized.

A systems team spends time and effort building a model and/or brainstorming ideas, then must  extracts this information and turns it into documents for various traceability and record keeping purposes. During the development of a single device, similar and repeated processes occur where brainstorming outputs are translated into documentation that is modified after speaking with stakeholders.

Derivative documents are created and regularly feed back into the original plan or requirements document with additional modification. This constant but necessary going back and forth between various outputs can quickly become inefficient and costly if processes are not implemented with great care and attention to efficiency.

As an example, picture a team of engineers developing a hypothetical product. After a lot of brainstorming and early design efforts they create some models and propose a System Architecture. The team then produces a Systems Requirement Document and other derivative documents for Risk Analysis and Risk Mitigation. etc. Further along, perhaps while dealing with Risk Mitigation efforts, a modification to the Systems Architecture is necessary. Now a cascade of new work is done to update and harmonize all the originally generated documents to reflect these newest changes.

Methods to Reduce Cost

To cut down on repetitious overhead, a well thought out design process can strategically implement tools and software to increase automation. Whereby work at one end automatically implements changes all along the path, reducing significant overhead and cutting down costs.

Aside from implementing automation tools, standardizing workflow processes between different teams and individuals can reduce repeated work and costs. If everyone is doing things a bit incongruently, any time the team meets to discuss the processes involved in the project, time and effort is spent getting everyone on the same page. But if the team uses the same functional definitions, with well-defined parameters, there will be less repeated overhead because they are more sharply aligned from the beginning.

A systems engineering team can benefit from:

1. Automating iterative processes and output generation.
2. Developing concrete team/project specific best practices.
3. Diligently maintaining a team/project wiki for best practices.
4. Dedicating time for harmonizing best practices and training.

Automating the Process

Translating between components of product development such as moving from problem identification↔ ideation ↔System Architecture ↔ Requirements Documents ↔ Risk analysis ↔ V&V → etc. can be automated and sped up quite dramatically by using modelling and requirements software like Capella with Jama. This streamlines the process of parsing the same system repeatedly to extract documents at each level.

When designing the system architecture, you essentially auto generate documents and spend a fraction of the time cleaning up documents, leaving most of your time for designing and problem solving. Additionally, human error is likely to be greatly minimized.

Developing Best Practices

Company wide Quality Management Systems and Standard Operating Procedures are important in codifying overarching goals and expected outputs from certain workflows. However, when it comes to more specific practices in small teams (like how preliminary work output such as models and drawings are produced and stored by group members working on different projects), practices are often not formalized on a company wide scale and each project or team implements drastically different methodologies. There is often little to no record or instruction available to allow team members from different projects to easily jump between projects.

For example, some teams manage work products in Visio, others prefer using Miro, etc. But who has ownership and/or the responsibility to maintain the files? To what degree does the team use that product (or combination of products) to complete drawings, architectures, schematics, or other outputs using a given tool? If a different product or tool is used to generate each stage of work and each group is implementing its own methods and practices, the resulting products will have different quality in generated work.

Maintaining Best Practices

More importantly, when work needs to be handed off to another team or team member, there is an inevitable learning curve. This doesn’t have to be the case. If teams have granular practices and processes codified and procedures are recorded somewhere, onboarding onto a new project will require far less ‘catching up’ and less repeated work between different teams.

This can be challenging to implement because it requires buy-in from everyone. It requires overhead time to create and formalize the practices, and there is a maintenance cost to remain up to date as new and better processes become available. Efficiency down the road is costly initially and requires a regular upkeep.

For a systems engineering team, well-suited requirements management software like Jama can help reduce time spent hopping between different sources and tediously managing traceability manually. A team Wiki such as Confluence or SharePoint with regular efforts to maintain the wiki, agnostic of any particular software, can also be used to help capture specific best practices and implement standardization across teams or projects.

Ultimately, it is important to select tools based on the needs of the project to optimize utility across individual contributors; a tool fit-for-purpose is very important. Equally important is having practices that record and keep the tools and processes up to date.

Training and Other Challenges 

Everything mentioned thus far requires the entire team to learn new software and develop new skills. It can be difficult for extremely busy and already overloaded individuals to invest their time in this learning curve. Lots of teams work on complex problems and develop novel and awesome solutions, but don’t necessarily spend the commensurate effort in documenting the processes and creating records of what was done. Consequentially, they end up having to repeat effort each time they perform a similar task or develop a similar product.

Having easy to use tools that allow a minimal effort in documenting and creating automatable documents will dramatically help optimize the ultimate engineering goal of making cool stuff.