Alien abduction and project management

“Wouldn’t it really suck to get abducted by aliens in a foreign country? They wouldn’t even know what language to use when they probed you.”

These words of wisdom were spoken by a companion during a drive on French country roads in the wee hours of the morning. This is really quite a revealing phrase; both of the underlying psychological issues of my companion, and of what we as modern citizens consider really “foreign”.

Let’s set aside the fascination with alien probing, and look at our perceptions of foreign. While it may technically mean a different country — a physical, cultural, or political boundary — I don’t believe that’s how most of us view it. If you’re scheduling a trip to tour the Guinness brewery in Ireland, you’re much more likely to call it an international trip, or an overseas trip. Foreign has a connotation of something we don’t understand. Language illustrates this. You might consider French a foreign language, but a visit to Paris an international trip. Why the distinction? I think the basic difference is that you know how to find Paris, but not speak French. You have the ability to understand the context around the geography but not the language.

Understanding
This is where alien abduction meets project management. You don’t know what you don’t know. Poor Zlarp the Alien Project Planner has an impeccable plan. He’s identified a perfect area outside of Paris, optimal times to avoid radar detection, and briefed his team on communication methods using French. Instead, by bad luck he ends up with Americans. What did his project plan say? How many potential languages could his abductees speak? This is a variable that is not accounted for in his plan — and realistically cannot be. We see the same things in our project plans — variables that just weren’t even imagined. Long-service employees leaving, technological advancements, changes in the marketplace — all things that cannot be predicted. I say cannot be — but truly it is that they should not be predicted. Analysis paralysis is what can occur if we try to capture all of these variables. Inability to move forward because we just don’t know enough. That occurs often with traditional project planning due to the appeal of things like Six Sigma or PMP, they pretend that if you’re good enough, all can be controlled.

Some methodologies talk about trusting the judgement of the people (agile) or pivoting based on new information (lean start-up). Regardless of this most companies want adherence to a plan. “We’ll work it out and adjust accordingly” isn’t acceptable to most finance departments. There needs to be scope and controls on the process.

Failing according to plan
How does Zlarp keep his commander happy? Assume that Zlarp has some kind of critical path map that shows successful communication as a milestone. He can’t just drop you off, and go pick someone else up . . .he’s spent time, money, and flying saucer fuel to get you. Pivoting may sound good logically, but won’t look good on his mission performance review. He should have thought of potential foreign visitors. It will definitely be held against him. So he juices up the probe anyway — and your lack of ability to understand French results in the average intelligence of humans being underestimated for the next 200 years.

This is the result of a highly structured and politicized organization. Many of us have experience in this environment. There is NO methodology that can save you once you’ve reached this point of the process. And — most methodologies take you right down this path. Sound depressing? Here is the solution: negotiate outcomes.

Outcomes
Not tollgates, milestones, sprints or any of the other semi-useful mechanisms for project control. If you are in Zlarp’s position and getting your project defined, focus on outcomes and boundaries. For example — our alien friends don’t really care about individual probes — they want data. Task based methodologies would quantify the number and cost of tasks in some fashion. If you focus on outcomes you look at the data requirement alone. This gives Zlarp the freedom to quickly drop us back in the wilds of the French countryside and move on to a more opportune target that may have more data. Even better — if the first three visits were very successful, he could move on to another species not repeating a task just because the plan said to do so.

The challenge here is management acceptance. Program plans are not designed for success. They are designed to deflect blame and show due diligence in case something fails. It takes leaders and project managers with a high risk tolerance to step outside their comfort zone and focus on what really matters — the outcome.