Improve Software Team Collaboration - via the Military Decision Making Process (MDMP)

References:

• FM 6-0 - US Army MDMP: https://armypubs.army.mil/epubs/DR_pubs/DR_a/ARN35404-FM_6-0-000-WEB-1.pdf

• US Army MDMP Best Practices: https://usacac.army.mil/sites/default/files/publications/15-06_0.pdf

• MDMP Workbook - Instructions and Info Gathering Templates: https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fjuniorofficer.army.mil%2Fwp-content%2Fuploads%2F2018%2F02%2FMDMP_WKBK.xls&wdOrigin=BROWSELINK

1. Introduction:

   1. This is an overview of the Military Decision Making Process (MDMP) to allow Software Teams to assess what MDMP parts may bring additional value worthy of integration into their own processes, as it's especially effective in facilitating collaborative planning.

   2. it's especially useful when a new task is too complex (or divisive) for a team to understand all its aspects and agree on the best way ahead -- given the "Best" Course of Action is determined by data (not debate).

   3. To aid civilian understanding, the process is recontextualized for projects within a civilian organization.

      1. Org Chart as used in paragraph two (2): Organization > Project > Section

      2. Translations of positions: Higher Command = Organization; Commander = Project Leader; Executive Officer = Deputy; Staff = Section Leads (e.g. Developer, User Experience [UX], Business Analyst [BA], etc.), Companies = Sections.

2. Steps of MDMP:

   1. Receive a Mission: Receive either a new higher organization mission, or an in-Project proposal that is controversial among the Section leads.

   2. Mission Analysis:

      1. Project Lead and Section Leads analyze the mission for the project's specific context. See Annex A for more details.

      2. At the end of Mission Analysis, the Section leads brief each other and the project leader on the current situation and recommends a restated mission tailored to the project's context. It includes Who, When, Where, Why, & What (includes the METL noted in Annex A).

      3. Project Leader approves the restated mission, making it an official "Project Mission"

      4. Project Leader gives guidance to the Section leads to plan for Course of Action (COA) development, based on the restated mission. Guidance includes his/her Intent, which is a broad succinct vision containing the mission's purpose, any specific methodology, and the desired end-state.

   3. Course of Action (COA) - Development.

      1. Sections gather information in their own respective areas.

      2. Threat/Risk analyst (or group) gathers info.

      3. Operations lead ( or Business Analyst [BA]) develops a few COAs based on section leads input (requirements, costs, risks, etc.) at different levels of BA, UX, Dev compromise.

   4. COA - Analysis and Comparison.

      1. NOTE: This is where the key collaboration occurs.

      2. Section leads gather to assess (wargame) COAs against the costs, risks, etc. and come to an agreed COA based off the COA that yields the best Return on Investment. This avoids both wasting resources on high-cost 'gold plating', as well as avoids ignoring usability/accessibility in favor of easiest development with 'lowest cost'.

      3. When face to face with the 'evidence' in hand and the group's joint-reputations on the line - it is unlikely for someone to further attempt to 'strawman' another's argument, ignore each other, or not compromise to recommend to their boss the COA with best ROI for the app.

      4. Section leads then brief their combined analysis to the Project Lead, and justify their recommended COA.

   5. COA Decision: Leader chooses a COA.

   6. Plan Production: Team develops a formalized plan for subordinates, based on the chosen COA.

Annex A: Details of Mission Analysis

• The deputy (or Project Lead) should establish the timeline for the aforementioned, within the constraints of the greater organization's mission.

• Gather The Facts: All must have the same understanding of the mission and intent of 'higher' organization. Each specialty lead will determine all of the facts that pertain to their area of expertise. The team will limit their time to ensure subordinates have double the time they did for planning (1/3 - 2/3 Rule).

• Make Assumptions: Valid assumptions with reasonable probability that bring value to planning.

• Risk analysis. Assess the project's capabilities compared to threats/risks.

• Analyze Higher Mission: We must understand the purpose of the organization's mission and the intent.

• Create Mission Essential Tasks List (METL) by first identifying Specified and Implied task, then chronologically ordering only those 'critical' to mission success.

• Identify Limitations: Both Constraints on resources, and Restrictions on execution.

• Identify Assets available and related to the mission.

• Identify Risks and which risks the higher org and project lead will accept.

• During the assessment the project lead should be kept informed of only things he/she requested, or needs to know - to avoid burdening the him/her unnecessarily.

• The briefing should be prepared based on the leader's instructions, section leads knowledge of the situation and their good judgement; it should focus on the essential info that affects the mission.

Annex B: Formalized Mission Analysis Document Instructions (military context)

Annex C: MDMP Poster of Inputs, Actions, and Outputs (military context)