What Does Done Look Like?

I started using the phrase "do we know what DONE looks like?" at Rocky Flats. It was first coined by a project manager in our PMO (I was VP PMO). He started reminding me "No Glen it's not Done, it's Done Done" to add a little humor to those who cooked the books when stating they were Done, mostly by using measures that were nonsense, like Story Points and Velocity for our agile work, and the passage of time and consumption of money for our metal bending and concrete pouring projects. This started in 2001 was turned in the 1^st of the 5 immutable principles of project success later in a book and now applicable to all the project we work:

1. What Does Done Look Like?
2. What is our Plan to Reach Done at the needed time, for the needed cost, with the needed capabilities?
3. What resources do we need to reach Done as planned?
4. What can go wrong on the way to Done and what are the Corrective or Preventive actions to reduce the probability of things going wrong (in the example below reduce that probability of as close to ZERO as possible).
5. How are well measures progress to Done, in units of measure meaningful to the decision-makers?

Done and progress to Done is defined in Measures of Effectiveness (MOE) and Measures of Performance (MOP) with their supporting Key Performance Parameters (KPP), Technical Performance Measures (TPM), and Critical to Customer (CTC) measures.

The Perseverance Lander mission has 38 Definitions of Done (1, 2, and 3 steps now shown on NASA Channel)

4. RCS Warmup
5. Spindown
6. Turn to Entry
7. Wait for Entry
8. Wait for Guidance Start
9. Range Control Slew To Commanded Bank Angle
10. Range Control Track
11. Range Control Bank Reversal
12. Heading Alignment Slews to Commanded Bank Angle
13. Heading Alignment Track
14. Slew and Sufr Slew to Radar Attitude
15. Slew and Sufr Wait for Chute Deploy
16. Allow Chute Deploy Transients to SEttle
17. Heatshield Sep Logic Enabled
18. RCS Control Inhibited
19. Wait for TDS Nav Init
20. TDS Nav Init
21. MLE Primimig Logic Enabled
22. Powered Descent Start Logic Enabled
23. Wait for backshell Sep
24. Free Fall
25. MLE Warm-Up
26. PD DeTumble
27. PD Turn to Initial Attitude
28. PD POwered Approach
29. PD Constant Velocity Accordion
30. PD Constant Deceleration Nominal
31. PD Constant Deceleration Saturated at Max
32. PD Constant Deceleration Saturated at Min
33. PD Throttle Down and Damp Transients
34. PD Deploy Rover and Damp Transients
35. PD Ready for Touchdown
36. PD Stop Vertical Motion
37. PD Altitude Hold
38. DONE

So What's The Point Here?

---

If you have a project, any project, especially a Software Intensive System of Systems (in any technical or operational domain) project and you don't have a definition of DONE in units of measure meaningful to the decision-makers. If you don't have a Plan and a Schedule for executing that Plan. All the Resources needed to execute that Plan on Schedule. Have all the uncertainties identified and the Risk that creates, along with the Handling Plans for each risk and the interactions of those Risks. And a way to measure Physical Percent Complete for each work activity in the Plan in units meaningful to the decision-makers, you likely don't have a good probability of success.

In the Perseverance example, everything had to work as planned, or as the briefer said yesterday Perseverance will have a bad day. 

Maybe your project isn't so complex, high risk, but any project needs to ask the five Principle questions.

Along with some other questions:

1. Do we have the right people for this project?
2. Are they trained, experienced, qualified?
3. Do they know their role?
4. Are they intellectually and emotionally mature to meet the demands of the project?

• Yes? - Let's get started
• No? Let's get the right people

And By The Way

---

The flight and ground software at JPL, Lockheed Martin, Ball Aerospace, and dozens of others for these missions are developed using Agile methods. The purveyors of Agile methods, frameworks, processes, or whatever they like to call them in their marketing approach rarely, if ever, understand that successful Agile deployment for non-de minimis projects starts with Systems Engineering Principles as their foundation.

Then those solutions need to identify the Root Causes before there is any hope of making improvements.

This is the core fallacy of most of the solutions providers, they have failed to define what problem they are solving, the Conditions and Actions that create that Cause of the Problem, and the effectiveness of the Corrective and or Preventive actions that remove or handle those Conditions or Actions.