Each system – or system of systems, in some cases – goes through an engineering lifecycle, which is sometimes referred to as a product development lifecycle (PDLC). In terms of today’s DevOps and value chains, these life cycles can range from a very early ideation phase to end-of-life activities for an obsolete product. It is essential to link several of these practices together in order to guide the engineering team from its initial concept through the full-scale implementation and into the operations phase. With today’s technology, we can easily complete the lifecycle using different frameworks, industry best practices and tools, but they rarely work well together. The result is often a series of isolated practices with dead ends, unnecessary documentation or data that is either not collected when it should be or processed during the wrong step. In some cases, key practices are simply added on to existing legacy workflows, whether it is modern engineering methods or new regulatory requirements, as detailed below:
When faced with new regulations or novel methodologies, enterprises often adopt an approach that simply adds the minimum regulatory changes to a legacy quality management system (QMS). The intention may be to make on-the-spot improvements at the request of a stakeholder, but it often results in unwelcome issues in the overall end-to-end workflow. Spot improvements may also conflict with the overall vision of a QMS that was designed as a conservative approach to achieve basic regulatory compliance.
As a result, the new core processes end up as a patchwork of practices that are
Disciplines that are outside the focus of a traditional QMS, such as portfolio management, update management, preventive maintenance, etc. are often forgotten. More critical activities from cybersecurity to agile practices are added without being fully integrated or adapted to the needs of industry-specific regulations or company-specific practices/tools. This causes additional workload, confusion within the engineering team and bad quality/documentation.
As discussed, simply adding spot improvements often results in an inflexible process landscape without an integrated, consistent end-to-end approach. Though this setup is often driven by audit/regulatory needs, it often lacks guidance for real-world practices and the right support for modern, automated systems engineering. Enterprises may end up with three different parties driving the actual workflows, each with a different view and mindset.
Your QMS could end up becoming very generic, without providing real guidance for the teams involved. Management will throw in their ideas from consultants, trainings or whitepapers. And while quality and engineering management teams struggle to agree on frameworks or procedures, the engineers use development plans to implement their own ideas for instructions and tools. In the best case, you achieve minimum compliance with the existing process landscape. In the worst case, you end up creating duplicate work, reverse-engineering the necessary documentation or producing useless documentation just to have something in place.
It is impossible to overestimate the value of seamlessly integrating your process elements (often called base practices). We have developed a process model that supports integration from initial policy development to the tool workflow, covering everything from portfolio management to post-launch activities. As a backbone of this model, we adopt base practices from different maturity models, identify the relevant methods and trainings as well as the right instructions and tools.
If this idea appeals to you, we would be happy to explain it to you in more detail. Click on the contact on right side of the page to get in touch.
We offer
If improvement and change are at the top of your agenda, we would love to partner with you for an initial consultation or an in-depth analysis of your specific situation.
Learn more about: