Have you ever wondered why military aircraft have names stenciled on their side? The short answer is that it’s the name of the dedicated maintenance crew chief responsible for ensuring the plane is operationally ready for flight. The deeper answer is a concept of full ownership. If the plane is broken and can’t fly, then the name is a public reminder of who is working to fix it. Military leaders learn the importance of ownership early in their career, and those lessons can be applied to every PMO in corporate America.
All PMO’s understand the importance of assigning names to projects. However, it might take more than just assigning projects to ensure your team truly takes ownership. Try these tips to increase the level of ownership on your team.
Detail what ownership means
As a former Air Force pilot, I would sign my name on the crew orders before every flight. The Air Force had regulations which detailed exactly what responsibility I was assuming by signing my name to that form. If you have PMO standards, make sure there is a section overviewing what it means to own a project. If you don’t have a set of standards, take the time to ensure your project managers know what is expected with ownership. In addition, your team will be more likely to tell you they are running out of bandwidth because they have clear expectations of owning a project.
Ensure names stay on the project
Like the airplane with the maintenance crew chief’s name stenciled on its side, ensure your project managers have their names associated with their projects. Once a project is owned, the name must stay on the project regardless of who is getting status. Full ownership means project managers get the good and bad credit. If your project gets briefed to the CIO every month, do everything you can to have the project manager’s name next to the project. The military doesn’t cover up the names on the plane when a General is walking the flight line, you shouldn’t shield the names either.
Full owners vs status owners
There is a difference between taking full ownership of the project versus owning the status of the project. The best way to distinguish the two is the presence of action. A red stoplight chart, or a planned missed milestone, is going to happen on a project, just like a plane is going to have maintenance problems. The key distinction of ownership is the action required to bring the project back in-line. Full owners come with a problem and an action plan, while status owners only communicate a problem. It is incumbent on the PMO manager to ensure the standards of ownership are upheld and enforced.
The military has understood this concept for hundreds of years and it’s engrained in how we lead our teams. Think of your portfolio of projects like a fleet of aircraft and make sure every plane has a name stenciled on the side.
Emails are the necessary evil of our modern organizations. It’s insane how much precious time is wasted writing and reading unstructured emails. They are often too long and can even be a complete waste of time. There is a solution which can save your team time and keep your sanity in-check. The acronym “BLIND” describes an email structure used by military staffs to effectively communicate to leadership. Use this structure and be amazed at the amount of time you’ll save with the increased effectiveness of emails.
BL = Bottom Line. This is the first thing that gets communicated. It should be at the very top of the page, or you can put it in the message subject line. Refine your key point to one or two sentences. What would say to your manager if you were passing each other in the hall and couldn’t stop to talk? For example:
I = Impact. After the main point has been communicated, assess the impact of the key point. This section answers why the person would care about the issue. If you can’t come up with an impact, the email might not be worth sending. Impact statements should be less than two sentences.
N = Next Steps. This step is crucial because it forces the development of a plan of action. Articulating a next step will foster an action-oriented culture. It won’t always be the best course of action but at least it’s a place to start! Try and keep this section shorter than a paragraph. If the next step is a series of actions, then bullets points are a great way to lay out the plan. Below are some examples.
D = Details. At this point you have given the recipient all the critical information in the communication and can let loose on relevant details. This typically involves a background, a more detailed explanation of the problem, and maybe some potential risks. It is now up to the reader to determine if they want to dive deeper. Try to provide the right amount of information so the email can be forwarded up the chain without the need to add more information. This section should also concise, to the point, and as short as possible.
This format allows managers to quickly forward information to executive leaders. It doesn't require reformatting to pull out important information because it's already done. Another key benefit is its ability to reduce email clutter. How many times has a project risk become a non-issue after some reflection? This email format will flush out key information and save you the embarrassment of sending out a “never mind” email.
If you feel like your team can be more effective with its emails, give this format a shot. Office life is busy and leaders get more emails than they can read in a given day. BLIND emails allow leaders to get the point of the email, and make the decision to flag or discard while scanning their phone between meetings. It’s about time we do something about our inbox madness, and this is a step in the right direction.
I’ve served as a military officer and Air Force pilot for the last 14 years. Over the past three years I’ve also worked with some of Seattle’s smartest software engineers as an Agile project manager. These two worlds, which appear to be on opposite ends of the spectrum, are far more similar than you may realize. Below are three lessons I’ve learned from military aviation which will benefit your Agile software project.
1. Slow Down
The phrase “Slow is smooth, smooth is fast” applies to military aviation and software development. Think about this training technique taught to all Air Force pilots. The first thing a pilot should do when they have an engine fire notification is…nothing…for 60 seconds! Why? Imagine a two-engine aircraft with one engine on fire and the wrong engine is shut down. You are now in a single engine aircraft, and your only working engine is on fire.
Situations can get worse and slowing down to ensure you are doing the right thing is better than doing the wrong thing fast. This applies to Agile projects where everything can feel like a crisis. The next time you are faced with impending doom, ask yourself how important immediate action is? Are you bypassing your normal safeguards for a production defect? The risk you are accepting might be worth it, but it should be a well thought out decision and not a quick reaction based on emotion.
Key Takeaway: Take a moment before doing something which turns a bad situation into a crisis.
2. Humans make Mistakes
Your Software developers are the best in the industry and are experts in their trade. I understand this mentality as a former Air Force pilot with over 3,000 hours of flight experience. Here is a shocking fact, every pilot I know, at some point in their career, has forgotten to put the landing gear down before landing. The point is that most pilots don’t land without the gear because we created processes to ensure we catch those mistakes. We adhere to checklists which are run before each landing, we have a pilot and a co-pilot verbally confirm each step, and we have internal systems which will warn us if we get too low without the gear. These countermeasures have dramatically reduced the amount of human error in aviation.
Does your Agile project have any countermeasures in place for human error? If the answer is no, or you don’t know, then acknowledge mistakes are happening and ensure every crisis results in a process to ensure it doesn’t happen again. Taking the time to do a full root cause analysis will save you time and money in the long run. A great exercise to prevent future mistakes is a Failure Mode Effects Array (FMEA)which can give you a great starting point for countermeasures.
Key Takeaway: Humans will make mistakes and you should build processes to help reduce those errors.
3. Plans are useless…
One of my favorite quotes is from President Eisenhower on preparing for battle “Plans are useless, but planning is indispensable.” I've been handed a 14-day flight mission, with 20 stops in austere locations, and given less than 24 hours to plan. I also knew without a doubt that the plan would change in the first 7 days. Does this mean we shouldn’t plan…NO! You must go through the planning process because the more you plan the faster you can adapt to changes. The key distinction is how you plan. I use the below steps as a guide to help me structure planning and it can be applied to military aviation and software development projects.
- Create a high-level overview to identify critical dependencies and choke points.
- Develop a plan for those critical dependencies and choke points.
- Ensure everyone on the team is aware of the big picture plan.
- Create a list of parking lot issues which need to be addressed but could be tackled later.
- Finally, create a detail plan the initial portion (first two legs of the mission / first sprint).
The rest of the details we would constantly adjusting as we went. I’ve seen Agile projects struggle on both ends of this spectrum. They either plan too much and waste effort on details which will change, or they don’t plan at all (because they are Agile) so nobody knows what is going on. A good rule of thumb is a 10-week high-level plan and a two-week detailed plan which is updated weekly. Regardless of how you set up your planning cadence, remember the process of planning is important, even if the plan doesn’t survive first contact.
Key Takeaway: Continually assess your planning cadence to make sure you aren’t too far on either end of the planning spectrum.