“Scope Creep” is the (often inadvertent) addition of incremental improvements to a design that are not explicitly identified as project deliverables.

Design Engineers are driven to succeed and impress – it’s hard-coded into our DNA, and it fuels our greatest strengths and assets. Our greatest strengths and our greatest weaknesses are often tightly interwoven, however, and almost inseparable from one another amidst a soup of deadlines, incentives, distractions, technologies, inter-personal challenges, and the lure of being seen as a miracle worker.

The risk of scope creep is particularly great in software and firmware projects. There are many reasons why:

• Developers often work alone;
• Code is often quite personal and stylized;
• Architecture and design directions are rarely final when coding begins;
• Design reviews often can’t include line-for-line examination of source files;
• Undocumented features, sub-routines, hooks, “easter eggs”, and other signature items are relatively easy to conceal, they aren’t subject to review, and they are fun to write

This is where project risk enters into the equation, as software and firmware are being ever more tightly scrutinized under 60601 Edition 3. Medical device software and firmware must be developed in accordance with IEC62304, which calls for comprehensive reviews of architecture, and risks before coding begins. Further, the FDA and other national authorities are tightening surveillance and audit processes.

Project managers need to be vigilant when managing software and firmware design, from architecture definition through to the production floor. A well-defined architecture document, Requirements, Risk Analysis, Design Specification, and Verification Plan are essential. If the feature is not listed explicitly in the project deliverables, then incorporating it is a risk to the project, on numerous levels.