A Very Simplified NASA-inspired Project Management Approach for SCA
Over the years I have been involved in and/or watched multiple projects in the SCA to revise rules, create new things, restructure organizations, etc. I have watched some succeed and some falter badly. They typically faltered because they did not have a plan for their project. They frequently started with a "solution" and failed when asked for an explanation of why or how that solution was reached and failed when asked how they would implement or verify their solution.
Famous "Then a Miracle Occurs" cartoon by Sidney Harris
Any project management approach will start at a much earlier stage and use a defined process to identify stakeholders and then progressively define, discuss, and refine first project goals, then list things necessary to achieve those goals, and then, finally, propose solutions that do those necessary things. This process inherently helps build buy-in and ownership as stakeholders from different points of view agree on goals, negotiate on necessary things, and only then consider solutions.
There are lots of different models and approaches for managing a project. This article describes one possible model. Any model should be as solution-agnostic as possible but provide a level framework for creating and choosing between possible solutions. And that level framework should not give advantage or disadvantage to an existing status quo; it should be considered on its merits the same as any change proposal.
A Quick Look at NASA
I'm a NASA engineer who did a 4 year detail as a project manager for a large research project where I managed over 100 people across multiple NASA centers and contractors. I also had about a semester worth of formal training in project management, but I hold no certifications. The NASA approach is massive overkill for SCA application, but I want to give a quick look at it to get an overview of some large features that we can consider using.
Take a look at the project management figure below. The project life runs from left to right on the figure. "Pre Phase A" is the earliest brainstorming and "Phase F" is disposal/retirement. If the project is a flight project, flight takes place at the end of Phase D. Going down the chart are the steps that are worked on during each phase.
https://www.nasa.gov/sites/default/files/styles/full_width/public/thumbnails/image/seh_table_3-0_1_product_maturity.jpg?itok=mm3CGzDm
Many of these steps should make sense to the non-engineer. "Stakeholder identification" is step 1. The actual design is not determined until step 11. Other notable steps include "implementation plans" and "verification and validation plans/results". They recognize that you not only need a solution, you need a plan for using the solution and for verifying that the solution is actually accomplishing its goals.
"KDP" on the NASA chart stands for "Key Decision Point". At each of these points in the project there is a review of the state of the project and a decision to move forward to the next stage, rework the current stage, or end the project. Depending on the scale of your SCA project, a planned external mid-point sanity check could be appropriate or unnecessary.
A Much Simplified SCA Approach
I hope you are all still with me. Now I will attempt to substantially simplify and de-jargon this approach to something that could actually be used in the SCA. Depending on the particular project, this could be simplified even more. (Even NASA "tailors" their process as appropriate.)
My simplified steps are
- Identify and engage interested people/groups
- Brainstorm, discuss, and select Goals ("why")
- Brainstorm, discuss, and select Things to implement goals ("what")
- Brainstorm, discuss, and select Solutions ("how")
- Ratify solution with identified people/groups
- Implement solution
- Verify solution is meeting goals or is in need of update
The discussion group will start with "Goals" which are high level aspirations for the project. These should be fairly easy for people to agree on. They also need to capture the scope of the project as the later steps need to refer back to the goal that they are helping to achieve.
The "things to implement these goals" ("requirements" to NASA) are one step more concrete. They still aren't a part of the solution itself, but are things that any solution will need to include. (I have an example coming in a moment, stick with me just a bit longer).
Finally, "solutions" are the concrete decisions on a part of the project. They need to meet the requirements and help satisfy a goal. In other words they need to have a reason to be included.
A very slightly disguised example
Multiple goals will be proposed and discussed. Some will get revised, combined, or dropped. Here is one example to hopefully clarify the different levels of aspiration/concreteness.
Proposed goal: The club policies need to be clear and understood the same by all.
Proposed requirement: We need to make people aware of the existing informal discussion of the policies on the club webpage
Proposed solution: Links to the existing informal discussion document will be shared more broadly.
Proposed requirement: We need a charter
Proposed solution: The charter will be on the club webpage
Proposed requirement: We need a video of an oldster talking about our history
Proposed solution: Senior member X will record a video, post it, and the link will be on the webpage
While it is possible that requirements and solutions will be contradictory with others, it is also possible that they won't be. In this case the informal article, formal charter, and video could all co-exist or one or more could be dropped. There would probably be another half dozen or so goals and multiple proposed requirements and solutions for each.
This process of starting with goals and then getting more specific to requirements and finally solutions helps to focus the discussion and build a common foundation that gradually gets built upon. Non-sensical solutions should be obvious and contradicting options should become clear so that explicit choices can be made.
Brainstorm, discuss, select, ratify, verify
Ok, I hear you say, back up a step. How do we get things on the list to consider and how do we choose between them? I'm going to be even more vague here. That will depend on the size of the interested group and the final decision making authority. Perhaps those two groups are identical. Or perhaps, all fencers are interested, but the final decision is being made by a particular officer, Crown, or the Board of Directors.
In general, my thoughts are that it is desirable to get input from as wide a pool as is possible, but that getting consensus or acceptance for concrete decisions gets less likely with larger groups. So, polls, survey, and discussions are appropriate for populating the pool of possible answers at each stage. But then a manageable and representative committee will need to adjudicate, combine, delete, and reword down to a reasonable list. That could be the end of the stage, or another round of polls to down-select between contradicting options might be appropriate.
Final ratification or acceptance of the finished result is important. The process planning group should include a plan for confirming that the final proposal is sufficiently acceptable to be adopted. It is also very helpful to create a plan to check back at some point in the future to confirm that the solutions are working as intended or if there is need for additional change.
End Notes
Let me make it clear again. This model is not necessarily what will be used for the current discussion on possibly changing the Academie. It is one possible model that I will suggest to the process committee. I hope that other possible models and certainly the final chosen model will be explained in a similar vein for both documentation and socialization reasons. As long as what we choose is fair, clear, and easy to implement I don't care what we use.
The "existing informal discussion of our club processes" is available here on my website and here on the Academie site.