Open-source disruption in support of audacious goals Ian Quest, Director — Quick Release_ First broadcast during the Fall 2021 edition of the PLM Roadmap and PDT conference This is a machine-generated transcript, lightly tidied for readability. Speaker attributions and paragraph breaks have been added; the substance of the talk is preserved. --- IAN QUEST: Good morning. Just before the break, I've been given a very strict ten minutes to get an idea across to you about a different approach to systems and process — particularly with respect to audacious goals, to challenging, time-constrained complex engineering programmes. Firstly, three facts and an opportunity. Fact one: even just around global warming and the challenges there, we've never before had the need to develop engineered solutions as fast as we do now, and to scale them quickly. Second fact: the engineers, scientists and professionals working on those programmes are actually only spending one third of their time engineering. This isn't enough. The third fact: despite huge advances in the way our systems can work, in the integration of those systems, in the visibility they create and the availability of administrative resource at relatively low cost — this problem hasn't been fixed. In fact, it's hardly improved. We see an opportunity here. We see an opportunity to not have to change enterprise architecture, but actually be able to create radical programme acceleration. And I'm going to explain how. --- To put a bit of context around it, here's one specific example — a typical issue we see time and again in engineering programmes. This is the business release of designs. You'll see the original target plan (the dotted line), the red line (the plan, which gradually accepts reality as things change), and the green line (what's actually been delivered). And there is a huge gap. All of these things happen much, much, much later than planned — almost twice as long. So why is that? Well, to focus in on the specific part: this is a wishbone for a vehicle. During this whole timeline, which is all measured in days, only 14% of that timeline are we actually tracking in any granular detail the progress on that part. So any issues or slippages that occur in the first 148 days are not really visible until the end of that time, when we start tracking. That causes lateness after the event, much later on — around things that could have been fixed much earlier had we had visibility. There's not enough visibility. There's not enough granularity around this. --- So what tech options have we got to support a solution? What systems-type options? Firstly, you've got the concept of spreadsheets. They're very flexible. People understand them. You can implement them quickly. However, they're not robust. They're not easy to scale. And they're not easy to maintain and ensure they keep working. At the other end of the scale, we've got out-of-the-box enterprise systems. They are robust. They're easy to maintain. They're very much scalable. But they take a lot of implementation and a lot of time for people to get used to them, and don't lend themselves to high degrees of configuration and customisation. So is there another option? Could we create pop-up software based on open-source tools, and rapidly evolve those tool sets around the real process? We think there is a way of doing that. --- How would we go about doing it? What do we need to do? Well, the first thing is getting the basics right, and I can't emphasise how important these three things are. Firstly, data quality. These are your foundations. If the data quality isn't good enough, there won't be the trust, there won't be any real visibility on what's going on, and people will just lose faith. You have to be focused from an early stage on high-quality data. Get it right and keep it right. The administration and management of this data isn't simply something the system should do, and it's not simply an admin task — it takes dedicated, focused professionals to keep on top of it. Reporting and visibility. How many of us have had, of an evening or first thing in the morning, the nightly letter come out, addressed to 400 different people, once a day? We need the right data presented in the right way to each individual or each group of people, at the right time. That will drive real-time, proper decisions based on the latest data applicable to that person or to that function. Programme and process. So often these are treated separately. We focus on the tactical things we can do to keep the programme running, and separately we have big process-improvement projects that probably won't hit us until the next programme anyway. These two things need to be joined at the hip. The issue the programme team sees on one day should provide a small solution — an incremental improvement — from the process team the next day. These two sides need to be properly integrated and working together. --- Advantages of doing something open-source, if they're not already obvious. Firstly, you can make it right-sized for the immediate needs. The needs of a programme will evolve — early concept, early prototype phases are different to moving into production, and require different scale solutions. But you don't have to make the choice now between one or the other. You can make it right-sized for the time and develop it further as time goes by. It's easy to deploy and to customise those changes. You can have daily, or more than daily, drops of improvements and adjustments that just help people integrate with it much, much better. And it keeps that focus on enabling our engineers — on getting more than a third of their time focused on engineering, and we'll keep addressing the reasons why they're not spending their time doing that. Just to emphasise: on one example piece of software we developed, there were 660 links between already-built open-source modules. If we'd spent that time coding all of this, it would have been months and months later that any development was achieved. As it was, there were daily drops of the software, which allowed us to keep evolving it and for people to learn the process alongside the system. --- So in order to empower our engineers, what else do we need? Firstly, you need deep domain knowledge. We can't have process teams that are sat off in the distance, isolated, purely focused on tech or on process. They need to understand the day-to-day requirements of the people working. They need to be joined at the hip to really shorten the loop on requirements gathering. Then we need to take the first step. It doesn't have to be a giant step. We don't have to design the new infrastructure for this to work. We just need to make a small change that makes an improvement for the team on the ground. And we need to democratise the data. We need to get it to the right people at the right time, in the right way. Mobile phones can do so much now — making sure we've got things people on the shop floor, or wherever they are, can access quickly and communicate far quicker. --- So, the takeaways. Firstly, get the basics right. None of what I'm saying here is new, but it's so neglected compared to how it ought to be. We need to give this the focus it deserves. Take the open-source approach. Try it and see if you can create these high-impact, low-friction tools that can be developed very, very quickly. The investment isn't high. Try it. Address some problems, and you'll probably start to see the benefits very quickly. And lastly, focus on the engineers and the broader project teams. Empower them with real data that provides real insights and allows them to make better decisions. --- To give you an example of this in action: the big audacious goal — Ventilator Challenge UK. The rate of production went from two a day to 400 a day over a period of twelve weeks, delivering over 11,000 ventilators. That was only possible with a highly data-driven approach — always knowing what the constraints were, and which of the 700 parts you were going to run out of the next day or in 48 hours. And that was all supported by pop-up digital tools, focused on empowering the best athletes, developed hand-in-hand with the people executing the process at the same time. Thank you.