When Apollo 13 was drifting in space, it’s oxygen and hence its source of power for the Command and Service Module (CSM) leaking unstoppably out into space, the crew had to move to the Lunar Excursion Module (LEM) as a lifeboat to get them home. This meant they had to power up the LEM systems and crucially initialise the navigation system with their current position. They have to transfer the values from the dying Command Module computer into the LEM’s Inertial Measurement Unit (IMU) computer by hand. But they realise they can’t just copy the values directly; the LEM is rotated 2-degrees from the CSM so they have to correct all the angles before they can enter them; get it wrong and the planned course correction to bring them home will instead send them off into space.
Myth 1: You can take data from one system and use it in another
Ok sure, you can connect two systems together and have one read the data from the other, but that’s not what I’m talking about here. I’m talking about building digital systems that work for people; that can be trusted and really start to save people time. The data Context is absolutely essential and there are so many wrinkles in the road:
- Where the data is physically measured
- Data that can be changed retrospectively – e.g. approximate values vs lab analysis
- The time assigned to the data – e.g. recorded today but applies to yesterday, or recorded today but applies to tomorrow?
- Data in different units – e.g. cups of flour or grams?
- The naming conventions – is it surname, firstname or firstname- surname?
- How is it categorised – is it an engine or a turbine?
- The language of the domain – is a hedgehog an animal or an intercellular signalling molecule?
This myth is so seductive it usually finds its way into a project plan in the early stages by way of an assumption. But it’s often the reason a project takes longer and costs more in the end.
So what’s the solution? Am I going to tell you to spend longer planning? Well no actually, or at least maybe not!.
There’s certainly no point sitting in a room trying to think of all the problems you might encounter, you are far better getting straight on with trying to integrate the real data and flushing out the real problems as early as possible. But this means you have to start doing work, which costs money, before you know what the final cost will be. Yikes! Who would ever sign off on such a thing!?
Frame it as a pilot or an early definition phase and define the outcome as knowledge, not functionality. The goal is to de-risk the real project phase by getting as much knowledge as possible about the data you need and how to make it work for you.
If you have any questions, or would like to get in touch, please reach out! We would love to hear from you.
