To develop a medical demonstrator from a laboratory trial to a system with 10.000 clinical tests with test users in 6 months, that was our task as Verhaert group. It involved developing a point-of-care PCR test, a testing device that can be used at a general practice, for example. The system consists of a disposable to take a sample from the patient and a PCR essay development with integrated optical read-out unit for analyzing the sample. The test must be able to be administered and analyzed by non-specialist staff. Within 6 months the demonstrators for large field tests must be produced and made operational. Quite a challenge!
Working in parallel
To achieve the required speed, we needed to create a flexible team and approach to do as much work in parallel as possible and allowing us to scale the teams with additional resources. These were released gradually during the first 2,5 months. Initially the team started with 3 people, gradually scaled to first 25 and finally 40 people. This project couldn’t have been realized without the competences and available resources in the Verhaert group involving:
- Consultants and engineers from Verhaert for system engineering, physics and thermal design, electronics and mechanical design
- LambdaX for optical instrument design
- Moebius for delivering additional engineering resources
- BEACON for the project management team
By dividing the team into subteams, each of them works on one specialized functionality or subsystem of the product. The goal is to develop the different product functionalities in parallel, despite the mutual high dependencies. We work with 6 subteams of 4 to 6 members, most of which are multi-disciplinary and require special attention to interface requirements, documentation, communication and alignment.
Information flow
To avoid delays, the subteams work simultaneously on the development in their subsystem without waiting for input from other subteams. At the end of the project, a complete set of demonstrator units must be realized in which all subsystems can be finally assembled, tested and can prove their integral performances together.
Therefore, each subteam has a linking pin. They meet for status updates and exchange relevant information. Because of the project’s speed and many parallel developments, there’s a great risk that the necessary information isn’t always shared in a timely manner. “Having a technical background helped to deeply understand the ongoing work. It’s important that we understand what information is crucial and what needs to be exchanged with whom and at what time. As project managers, we constantly absorb what is happening in the teams and also check that the information is shared by the linking pins. This flow of information is essential. In doing so, we’re always looking for the balance between execution and consultation, so that there isn’t only enough time for exchanging information, but also for doing the substantive work.” says Yorick Koumans, Project Manager at Beacon.
80 percent rule
The second thing that contributes to speed is decision-making. Decisions in the project consistently are made on 80 percent of the information. Normally we would proceed to 95 or 98 percent certainty, but it’s precisely that last 20 percent that takes a lot of time. If it looks very likely that something will work, we opt for that solution. Even if we’re not entirely sure. Taking risks need to go together with informing the client about the drawbacks, while balancing it with the time savings. As a result, the risk is taken very consciously together. By actively planning for alternatives it allows to return to the second best option in line when the first choice turns out to be wrong. Should this happen, we make a decision together with the client: do we go for an alternative and slow down the process or do we adjust the scope? Suppose the time to result is slightly longer than the original goal, then we make the following consideration: can we be satisfied with what we have now? Or are we going to solve it, even if that means we finish later?
Risk-focused
Mapping risks on components and features allows us to zoom in on the potential failure modes, the effect on other subsystems or parts, and on the failure of delivering its service. This focus helps to keep the complete team well-informed about the potential causes and mechanism of failure to try to mitigate by inherent design aspects. Looking for a recommended action to reduce the risks helps in steering the complete team towards those design choices that limit the risk taken while keeping the timeline in focus. A well-done FMECA has a timetable with a target completion date for each risk. Only when risks are as low as reasonably possible, the remaining risk will be accepted when there are no more potential benefits within the timeline.
As innovation complexity increases; its delivery time decreases. Our MyInnovationFactory Blueprint helps you to win the agility in innovation battle. IR&D organizations need to be agile and open to cope with disruption and time-to-market.
