The earth is dying. In around five billion years, the sun will run out of fuel and expand to engulf our little planet. Before then—presuming humanity is still around—it would probably be a good idea to have another place to go, so we can survive as a species.
But hey, baby steps, right? Conventional wisdom suggests that before we try to fracture spacetime and colonise another star system, we should work on colonising something closer, like the Moon, or Mars.
Which is why Mars missions are important. The lessons we learn from each unmanned probe or future manned missions will help us to survive the inevitable solar apocalypse.
In September 1999, scientists and engineers were initially perplexed when communications ceased with the Mars Climate Orbiter. At a total mission cost of over USD 650m, it had spent almost a year just getting to Mars. Then when the folks at NASA pushed the button to make a final adjustment that would get it into a stable orbit around the red planet, it just stopped talking to them.
Investigations later revealed that the probe had flown too low, and broken up in the Martian atmosphere. Why? Because the engineers at Lockheed Martin who built the probe used imperial thrust measurements in their software, while the software developed by NASA needed metric measurements.
Whoops.
Get everyone on the same page
There’s a lesson here for everyone. Never use imperial measurements.
Aside from that, there’s another important lesson: it pays to get things right the first time.
When you’re setting up a new project, how much time do you spend on creating a Gantt chart that accurately describes the volume of work, the sequencing of activities, the resources required to complete project tasks, etc.? Probably quite a bit.
But how much time do you spend working through things like definitions, or roles, or clearly defining the project scope so you can refer to it later?
At a minimum, think about the following:
- Quality. What’s acceptable in terms of output? What measures will you use to determine quality, and who signs off on them?
- Reporting relationships and requirements. Who needs to report to whom, on what, by when? How are reports disseminated? What meetings need to take place, about what, with whom, and by when?
- Stakeholder mapping. Who are the project’s stakeholders? What do they want? What’s their attitude to the project, and what do you need to do to bring them around so they support your actions?
- RACI Mapping. Map out who on the project team is Responsible and Accountable for project activities, and then who of your stakeholders need to be Consulted or Informed about project activities and developments.
- Communication. How are you going to get information out about the project to the people who are going to be affected? What do they need to know, by when, about what? What actions do you need to take to shore up support for the project from the people who are going to be affected?
- Information management. Projects generate a lot of information and documents. How are you going to store yours? Where? Under what taxonomy? Who has final say over storage requirements? What constitutes a record that needs to be kept vs. one that can be safely deleted? How are you going to treat project emails?
All of these questions need answering for any project of reasonable size. Once you take the time to get them answered the first time, you should never have to answer them again for the duration of the project—barring adjustments, of course.
If you aren’t keen on all the paperwork, you could always head to Mars. They’re even making a reality TV show about the first colonists. I wonder what measurement system they’re using?
