In April of last year, I wrote a blog post called “Parenting as a Project“. I wrote it while I was on maternity leave, pondering my return to the workforce. I had been working on a failing project, and the PM had been removed from the contract just 3 weeks before Carrie was born. As I found myself unexpectedly calling the temporary PM to inform her that I was in the hospital, I was wondering if I would have a job to come back to. The project failure really was that bad. When I wrote “Parenting as a Project”, I had been asked to become the permanent PM when I returned from leave. The customer was difficult, at best; the team was attempting to perform beyond their capabilities (because the previous PM was an @sshat), and I knew that even if the option year was exercised, my services would only be needed until September 30th — then I would need to find a new position. It’s amazing how God works sometimes — the one thing that I feared the most was the area of personnel issues, and that’s exactly what I had to confront head-on from the start. I had to remove someone from the project … for cause. And then, slowly but surely, the team pulled together and things turned around.
That experience has reminded me of something that I’ve heard John say: “Fly the airplane.” It’s a pilot’s mantra that boils down to: when all hell is breaking loose, figure out how to fly the airplane, and fly it… everything else is secondary. If you’ve ever heard the story of the United Airlines Flight 232, then you probably understand the concept. The DC-10 suffered a rear engine failure which resulted in catastrophic damage to the entire flight control system which was located in the tail of the airplane. With complete loss of the ability to use the control surfaces, the pilots (and “dead-heating” flight instructor) had to use the remaining engines to steer the aircraft towards a runway in Sioux City, Iowa. That crash landing is the ultimate example of “fly the airplane.”
So, how does the Sioux City crash fit in with Project Management? Simple: no matter what else happens, always concentrate on running the project. Set aside the non-essential tasks; figure out how to make it work with what you’ve got; ignore any unhelpful influences; and do your absolute best to keep it flying all the way to the end. Sure, you might end up with a cancelled contract or even the need for a new job, but you will have your integrity intact and very valuable experience for your next go-round. Or as Dori said in Finding Nemo: “Just keep swimming! Just keep swimming!”
There are two other very important lessons to be learned from United Flight 232. The first is the concept of Cockpit Resource Management. United had been training their pilots in CRM prior to the accident, and it played a major role in the successful outcome of the incident. Prior to CRM, the Pilot was understood to be in charge of the airplane, and the more junior-level staff were expected to obey his/her orders without questions. But CRM was a new paradigm: all of the flight staff, from the most senior pilot to the flight engineer, and even the off-duty flight instructor were empowered to speak up when they had ideas, questions, or concerns. Each person brought their experiences and training to the situation, and provided valuable input. Each person on your team brings their own experience and perspective, and they should be encouraged to express it.
The other lesson to be learned from United Flight 232, and aviation in general, is the concept of Positive Transfer of Control. Everyone in the cockpit, and the project, should know who is in control at all times. There should be no opposite flight control inputs or arguments from team members. Each person needs to know, unequivocally, what they are responsible for. With PTC, when a co-pilot takes control of an airplane, they say something similar to “I have the airplane.” They do not actually HAVE control until the pilot responds with “You have the airplane.” Transferring control of the airplane requires acknowledgement from both the gaining and losing parties. John and I actually practice this when it comes to picking Carrie up from daycare. If there is any question of who is picking her up, one of us will initiate with (as appropriate) either “I have the airplane” or “You have the airplane.” The issue isn’t closed until the other responds appropriately. While project teams might see it as a bit mundane, positively acknowledging ownership of tasks can remove a lot of ambiguity from Project Management and eliminate the “I didn’t understand” and “No one told me” excuses.