The MedTech memory lapse in product development

When software maintenance becomes technical debt

I once dealt with a company that, more than 10 years earlier, had created some analytical software, which it had made available to customers as an add-on for its diagnostic device. The software was alive, but barely – it was very much on life support. The team had mainly been adding and releasing language support and batch parameters. The tools used to code the software had never been updated, neither had the libraries.

In addition, the team’s working practices were not in keeping with current standards. The software had missed out entirely on software engineering best practices such as continuous integration, UI & integration testing, automated unit testing, and a mature versioning system like GIT. This was likely both the cause and consequence of the high level of staff turnover in the department, with young, highly skilled professionals coming and going regularly.

When rigid processes replace product vision

Another company had a line of clinical monitoring equipment which it had been selling and developing for more than ten years. It had been replacing discontinued components and regularly adding software extensions, accessories, and sensors in order to meet tender specifications.

The work packages had tended to be fairly limited in scope. They were executed using meticulously defined work processes, that used mandatory process specifications to manage dependencies between departments, optimising work for individual workers in the R&D department.

The problem here was that it was not clear what the overall plan was, and this had led to logjams in addressing the interface and integration. Every time there was a key deadline looming, every single developer, plus allied departments such as purchasing and regulatory affairs, got press-ganged into working day and night to get the product release out the door.

Communication and collaboration between disciplines

It’s not just electronic engineering, software development, and mechanical engineering that have to work seamlessly together, though this alone creates more than enough communication problems and coordination workload. You also need input from specialists from the requirements engineering, quality management, regulatory affairs, purchasing, manufacturing, and clinical research departments, to name but a few.

It’s really important that your disciplines and departments don’t fall prey to a silo mentality. Setting up interdisciplinary teams and giving them both accountability for and authority to create sub-functions is a good approach, though it often constitutes a break with established organisational structures.

Two approaches to agile product development

One team: 

It’s the leadership’s job to ensure that all participants regard themselves as owning the project. For leaders at all levels, in addition to setting out clear goals and a clear vision, it’s important that you also communicate your commitment: 

• Business and R&D managers to the overall project.
• Product managers to the technical benefit the first version of the product will deliver.
• Project managers and architects to the pending development phases and solutions.
• Team leads to dishing out tasks and responsibilities to sub-teams.

One project: 

A further key element for getting the team to buy in to ownership of a development project is clarity in assigning individual team members to the team. People filling core roles should predominantly be assigned solely to this one project. If only 50% to 60% of your time is allocated to the project, your sense of ownership will be half-hearted at best.

There will always be other, even more important things to do and reasons why you can’t work on the project as agreed. These people then end up being little more than spectators. (See also the fable of the chicken and the pig, beloved of Scrum trainers.)

Firming up priorities and quality requirements

The phases in new product development vary widely in their level of maturity and therefore also in their objectives. In the early stages, it’s all about concepts and feasibility – the focus is much more on fundamental analysis. Later, the focus moves to extremely detailed investigations in specific areas and design spikes. Then there’s another phase of implementing a wide range of functions, before the work finally moves on to getting the product to a point where it’s ready for large scale manufacture.

It’s really important that you keep everyone in the team motivated to achieve these different goals at all times. This ensures that everyone is pulling in the same direction and knows where they’re going. It’s also important that the direction, for example in terms of supplier qualification vs. rapid prototyping, re-use of old libraries vs. new software frameworks, etc., is clear to everyone at all times. This requires more than just mentioning it once, or documenting it in the development process. For developers, the key thing day-to-day is clear guidance on what you’re trying to achieve and how you’re trying to achieve it, and continuous communication.

Planning and transparency

In my projects, this is an area where agile methods have really shown themselves to be super effective. Frameworks like SAFe® enable proper coordination between multiple teams, even in large projects, and enable continuous visibility of progress, results, and obstacles. Also indispensable are structured project management, mitigating project risks, continuous technical integration, using planning tools, and above all discipline.

A sense of urgency

For many of the people involved in them, development projects spanning several years are just too long a time span. The project goals and finished product are just too far off, too intangible. In view of this, many businesses take the tried and tested approach of splitting large development projects into a number of smaller 6-12 month phases, each with tangible interim results.

For example, the first phase might involve establishing the technical feasibility of the project, with the goal for this phase defined as building a laboratory prototype. This is then followed by a second step which culminates in the production of a functional prototype featuring all of the main functions. This continues right through to the finished product. The route to each of these goals is also sprinkled with interim goals (sprints and product increments), to which the whole project team has to intermittently contribute deliverables. This helps the team to stay motivated and focused, and to continue to work actively together and take rapid decisions.