Avoid Project Crashes: File a Flight Plan First!

Avoid Project Crashes:

File a Flight Plan First!

By Jigs Gaton, PM / Pilot

First, let's step back 30,000 feet

We all know the drill as we start projects: pick or subserve to some PM methodology, gather your resources, erect lines of communication, etc. Agile, Waterfall, Bootcamp, Basecamp, whatever, we always begin there. But what if we are starting our projects on a wayward waypoint in the first place?

So, let's step back and look at this hypothesis; perhaps some of our projects might be crashing because our planning always starts in the wrong place. Think of this through a pilot's eyes, who instinctively knows you don't start a mission in the middle of the air... no, you always begin working far earlier than that, on the ground, even with a pre-plan for any take-off.

Continuing this analogy, in a pilot's pre-plan for the mission (think of every project as a mission), the pilot has a checklist shared between the pilot and co-pilot, and then portions are shared with the entire crew.

This project planning metaphor should be familiar if you are a PM with any experience; you are starting a new project, collecting a team, and strategizing what to do in the days (or flights) ahead.

(If not, see this article that compares pilots to project managers.)

So, let's dive into the idea of Flight Planning and compare that with what we all do when planning projects.

Where does Mission Project begin?

Sure, you might think a project begins with setting objectives, defining scopes, and clarifying goals. But in reality, these are just words to help us off the literal project runway, and truth be told, any Mission Project starts well ahead of all these fine activities.

Think of the pilot and crew the afternoon before a long-haul flight, none may have met, but all come together with one thing in mind: mission success.

Note: if a pilot or the crew feels compromised to endanger the mission's safe success, there is no penalty for declining the job (mandated by law in many countries).

In addition to this mental analogy of [pilots & crews] with [PM planners & teams], we should look at the physical tools the aviation industry deploys, but most PMs do not. The first one that comes to mind is a flight plan.

The flight plan.

All commercial aviation missions begin with a flight plan; consider starting your project with one. In this way, you are taking off from a cleared runway and not starting your project from mid-air, destined for trouble.

To a layperson, a flight plan may look like a form required by the FAA or other local authorities, but it's much more in a pilot's eyes. A flight plan for any pilot is a philosophy and a set of tools. The philosophy of the flight plan is to follow a set of actions that includes preflight, inflight, and landing checklists, as well as checklists for any emergency that modern aviation can envision.

The toolset behind a flight plan is extensive. Based on the aircraft flown (think project types), requirements, resources, and tailored checklists must be completed before any engine is switched on. These tools are modeled and taken from real-life experiences, simulators, manufacturers' specifications, and various other sources like the weather, weight on board, and fuel capacity.

The pilot and co-pilot complete and double-check the flight plan together, sometimes entering separate plans into a flight computer that double-checks the two human inputs and reports any conflicts. All of these calculations and checks lead to one question: Can mission success be safely achieved or not based on the destination? And remember, this is well before a single engine is fired up.

To complete the picture, here is a rough comparison between a flight plan and PM practices today:

Flight Plan vs. PM Plan

All variables are modeled and checked for compliance against specifications before starting.

Variables are considered ongoing risks and handled loosely.

Any change in plan is modeled in real-time (by a flight computer), and potential problems are immediately flagged with alerts sent to the pilot and co-pilot.

Changes may not be tested/modeled nor communicated to the PM or co-PM (or even with a flight control tower, or in PM terms, the PMO).

The flight continues along established waypoints, and cannot proceed unless all safety parameters are met.

Projects try to achieve arbitrary milestones and often proceed recklessly without meeting any.

Historical data is factored into the plan from the get-go.

Historical data on like projects is often unknown or not factored.

This type of plan is double-checked by a copilot with equal say in making changes and is also always communicated with flight controllers.

Plans often come down from "on high" and are developed without an independent double-check.

Inflight services...

Once in flight, or once Mission Project is safely off the ground, PMs have activities lumped into phases, sprints, and closings instead of a pilot's routine take-off, inflight, and landing procedures, yet these divisions serve the same purpose; to chunk the workload into manageable parts.

Yet more critical during these mission stages (even more than the lights displayed on the flight deck) is something called CRM, or Crew Resource Management, which often changes crew parameters and practices inflight, besides dictating normal behavior and communications. Every pilot or crew member has an HR department – inside their head!

One example of a CRM practice is the required sterile cockpit during takeoff and landings. This is when the pilot, co-pilot, and crew follow a strict protocol of keeping all chatter to a bare minimum, thus reducing the stress level during these critical moments and helping the crew execute the flight plan flawlessly. This is a feature developers of chat-based PM tools should take note of if they can.

Another example (also audible) is called a call-out within the Aviation industry. Ever wonder why pilots over radios repeat each change in the flight plan when communicating with air traffic controllers and even themselves? Because these call-outs have proven to save lives and planes from disaster! For example, you may have heard something like this in the movies when a tower is communicating with a jumbo jet: "Climb and maintain one two thousand" (climb up to and level off at 12,000 feet) with the pilot of the plane responding to the tower with the exact phrasing, "Roger that, climbing to one two thousand and maintaining."

This keeps planes from colliding on take-offs; in other words, there is confirmation and agreement between all parties on the line at the moment of decision. It is important to note that in the case of aviation call-outs, they are public so that other planes around the tower and ascending aircraft can also listen to the communication; but are respectful and keep it one way unless they have something urgent to contribute. Imagine your PMO is the control tower, you are the pilot, and your project is your mission - now you get the picture! Also, here's a shout-out to include call-outs in all PM software.

And while on the topic of tools and services, here is where the Aviation Industry flies far above what we have at our disposal as land-based PMs. They have a flight computer. And the flight computers on modern aircraft are remarkable, as they use the flight plan and constantly check progress against the plan, alerting pilots before anything goes off track. And as with any device, you can plug in new numbers and get updated results in milliseconds.

Yet here is where this metaphor becomes stretched. The variables involved in programming an Airbus or Boeing flight computer are finite compared to the number of variables in today's most complex projects. Yet, with that wide range of projects planned and executed over time, we could derive them, and predictive analysis is possible (with some margin of error). If only we had more of that, maybe our projects would not spin out of control as often as they do.

Note: Ever wonder why the airline industry has such an excellent record of success (as compared to our projects)? Then see this series of PM vs. Aviation articles.

Landing, not crashing

But even if you disagree that flying an Airbus is like landing a project on time, within budget, and with all goals achieved, you have to admit that the Airline industry has a much better record than ours, and with much less disastrous results in lost resources, wasted time and actual damage inflicted.

So perhaps even the thought of using a flight plan before project takeoff can’t hurt and possibly will prevent projects from becoming lost over some ocean, never to be heard from again. For those willing to try, here is a summary of thoughts for your next project flight plan:

  • Always make sure you start your project from the ground, and not mid-air, by stepping back 30,000 feet and examining exactly where you are – first!
  • Develop checklists based on past project performance and histories, and categorize and implement them by type of project.
  • Try to model a project’s results based on inputting historical/industrial-standard values for as many variables as possible – before taking off!
  • Use your plan to fly from one waypoint to another, ensuring all safety concerns are met before proceeding to the next.
  • Employ the latest model “flight computer” possible, to check your plan’s operating parameters in-flight and to alert you before problems arise.
  • Before taking off, always double-check your plan with a co-planner (call it a sanity check) and also share that planning with your PMO.
  • Even before assembling your team, consider the mental state of all involved. And during the mission, also be aware of cognitive problems such as bias, workload stress and other human-factor problems that arise within all hard-working teams.

Final (destination) thought…

So, in light of the above list of recommendations and other considerations within our theoretical Mission Project, here's wishing you the best in keeping the shiny side up whenever piloting a project to success.

For more info on the latest PM “flight computer” available, see the Project Plan 365 product page to learn how advanced planning software can improve your chances of safely landing your next project!

Is It Worth the Effort?

Is It Worth the Effort?

In Daniel Defoe’s novel of Robinson Crusoe and his adventures at sea, a notable quote stands out:

“[N]ow I [see], though too late, the folly of beginning a work before we count the cost, and before we judge rightly of our own strength to go through with it.”

Judging from the quote, there appears to be a point of no return in everything we do- our project endeavors included. As the S-Curve of “Cost” as it relates to “Time” ramps up the steep incline during project execution, we must ask ourselves: will it be worth the Effort?

Take an analogous jungle survival story:

Should a 300lbs lion burn 500 calories chasing a small rabbit that will give him only 100 calories in return? Of course, the answer is no. This reward is clearly not worth the Effort. Why is it then that you will never turn on Animal Planet and see such a lion act in this way, but you often hear of small businesses (90%) that fail in the first year and projects (80%) failing overall?

Common in the field of project management are the phases of project initiation and project planning which involve a Go/No Go decision template. It is one thing to make decisions before things begin to pick up, but what happens after we decide to Go and realize along the way it is not worth the Effort? Well, this when jungle-like survival skills must kick in.

Before anything else, you as a project manager must recognize and admit things are not going as planned. Then, you must act fast before is too late. If you find yourself in this position, begin by returning to your baseline assumption cost. What was it? You can easily name this “Day One Initial Estimate” and, you can usually assign a number (for example, $1 million).

Next, let’s consider your initial consideration of Total Estimated Effort for the work. What did you think the project would look like when finished based on the Effort? Here, my friends, is the tricky part... you didn’t consider this and that is why you are facing a problem. Had you known the Total Estimated Effort, you wouldn’t be reading this article and would be doing more enjoyable things with your time right now.

What I suggest at this point is you deal with Hope. Hope is your best friend and worst enemy. That is to say, you know there is a problem, but you Hope everything will be okay, right? Here, an additional lesson can be applied from Robinson Crusoe’s adventures- A lesson that I find to be magic put into practice:

 “Today we love what tomorrow we hate.”

 We tend to Hope for more happy days in our planning and wish that tomorrow too there will be a good day, but it doesn't always happen. Therefore, Hope should be a set for an exact period of time where you expect to see some specific positive results. 

 For example, if I take a pill for 5 days I Hope to see my fever decrease from 102 to 98 in about 5 days. Hope may prove positive or… maybe I die. Who knows? 

Unlike a pill, we sometimes know there is barely any Hope, but we still try for that 1% chance. This is part of our innate decision making process that we cannot help but do (at least until AI takes over).

So, let’s define our Hope Period and Hope Target to try and determine if Hope assumptions will come true or prove to be false. You’ve got your project started, you are excited, everybody is on fire, budgets are approved, there are successful kick off meetings… now is exactly the time to be worried. Pay attention to the first 20% Effort period- it is the most critical part of your project. Add an extra 5% for the Hope Period where you can determine how much Hope you can hold onto; only then will you be in a good position to make some thorough Go/No Go decisions. And if you’re already deep into your project and all you have left is Hope, determine when Hope should be lost for the sake of your budget and team.

Don’t believe me about the importance of Hope? Google these big project failures that extended the Hope period just a little too far: The Canfranc Titanic of the Mountains project and The New South China Mall, Pearl River Delta.

Remember this: most of the project Effort understandings happen in the initial execution period, so pay close attention and the next time you begin to build your Microsoft Project, Primavera, Smartsheets, Project Plan 365 or any other project plan, add a Robinson Crusoe Milestones along the way and be prepared to answer his question:

Is it worth the Effort?

Happy Planning!