The culture of the military often adds different dynamics to our operations that are not comparable to civilian operations. Often times, rank or military authority can advance a project forward rather than influencing others to a common goal. This is done by issuing orders to subordinate organizations to ensure compliance. As a result, some military project managers operate under the assumption that everyone will do their part for a project because they will receive orders that tell them to do so. This function is very convenient on enforcing project compliance but lends to some project managers missing experience in critical areas such as stakeholder analysis.
The Project Body of Knowledge (PMBOK) defines a stakeholder as “individuals, groups or organizations who may affect, be affected by, or perceive themselves to be affected by a decision, activity or outcome of a project”. In other words, even if a person or organization THINKS they are affected by their project, they are a stakeholder and thus should be considered in soliciting input for your project planning. Stakeholder analysis is a technique to identify these stakeholders and gather their interest, expectations and influence as they relate to your project.
How is this applicable? Why should I care if they are just going to receive orders to go along with my project anyway? Let me give you a real example that some can relate to.
As a Warrant Officer, my career field focuses on electronic maintenance. My first duty station was with 11th Armored Cavalry at Fort Irwin, California. Within the first 15 minutes of meeting me, my new Battalion Commander says “Chief, night vision goggles in the Regiment have not been properly serviced in over five years. I want a mobile arms room team to visit every unit within the Regiment, identify the broken NVG’s and briefings at our maintenance meetings on which units have / have not submitted these devices for repair”. Day 1 as a new Warrant Officer and I have a project given by my Battalion Commander! I was eager to get started on this project and rushed back to my shop and conferred with my project team (Non-commissioned officers and soldiers) on how we would plan and execute this mission (project). After providing a list of the additional equipment needed, my project team began contacting units for scheduling appointments for our visits. So far, everything I mentioned sounds like an experience my fellow service members can identify with. Let me tell you how a better understanding of project management would have helped me manage this project better.
My Support Operations OIC (SPO OIC) is a key stakeholder in my project. Although I provided their office with a list of equipment needed, I never made contact with the SPO to gather his concerns, expectations or requirements for this project. Although my Battalion Commander (project sponsor) clearly outlined my mission (project), I failed to gather the input of key stakeholders for my project. My SPO had a different priority for which units would get serviced first and how soon my requested equipment would be available. As a result, my project team ended up contacting units to reschedule their appointments that aligned with the priority of my key stakeholder. We had to rework our project plan because we missed the input of our SPO in our original plan.
That is the main lesson for military project managers. Have you ever had to rework portions of your project plan or all of your project plan because entities like your SPO, S-3 or budget personnel had additional requirements or constraints for your project? If so, a stakeholder analysis would have identified these stakeholders and allowed you to gain their input BEFORE you worked too hard on your project plan. A proper stakeholder analysis can also help you figure out how much you should communicate with these stakeholders. By identifying their level of interest versus the power they have over your project, you can figure out the appropriate means of communicating project updates with your stakeholders. Here is a sample stakeholder register and analysis to illustrate what I am talking about:
Although the stakeholder register above is for operations within civilian industry, the point is still applicable to military operations. The register above (first chart) shows that Gary Moore has a high level of power and interest over the project. The register also shows his need / want that the project is completed by the end of the third quarter since he is worried that a competitor will deliver a similar product first. Knowing this, on the second chart, he would be in the upper right quadrant for the power / interest grid. This grid quadrant is labeled as “Manage Closely” and means that regular project updates should be utilized with this project stakeholder and also the method I give those updates may be considered. The chart also shows Bill Monroe as having a low-interest / low power stakeholder. Looking at his role, he is the Director of Accounting. Bill’s main interest is that the project does not go over budget. He is not as concerned with the project overall and thus we can exert minimum effort in how we engage him during our project. As long as Bill gets his weekly expense report, he is fine with the project.
For my fellow military project managers, this is something that we do not always do as we manage projects. We might rope in people that we think need a hand on plans, but by using the best practices of project management like Stakeholder Analysis, we can be more effective on how we shape our projects in the future.
Project Body of Knowledge (PMBOK) 5th ed. pg .394-395, Project Management Institute