Darth Failure

What Star Wars: The Force Awakens can tell us about lessons learned. By Richard Young

The first rule of Star Wars is not to look too closely at the technicalities. You either become disillusioned with the inconsistencies (parsec is a unit of length, not time; why didn’t the original Death Star just blast the planet around which the Rebel base was orbiting?) or you become an obsessive justifier of nonsense. (Unless you’re tripped up by female lead characters, in which case, you create a fan edit of The Last Jedi that cuts them out.)

But what’s striking about The Force Awakens, the film that rebooted the Star Wars franchise as a cinematic force (pun intended), is the project management principle that lies at its core: you forget lessons learned at your peril.

Let’s go back to the very first film. Having stolen the plans for the Death Star, the general in charge of the Rebel forces tells his team: “An analysis of the plans provided by Princess Leia has demonstrated a weakness in the battle station. The target area is only two metres wide. It’s a small thermal exhaust port, right below the main port. The shaft leads directly to the reactor system.”

In Rogue One (the story of the theft of those plans), we’re told that the designer of the original Death Star, Galen Erso, included this as a deliberate flaw in the design. So maybe we can forgive the Empire for goofing up. Well, sort of. In the original film, an officer tells Grand Moff Tarkin within minutes of the Rebel attack on the Death Star that an analysis of their tactics demonstrates a real risk to the battle station. So… not that hard to spot. (It’s a reminder that internal audit and risk assessment can be a useful tool in project management.)

Well, we all know what happens. Luke turns off the targeting computer, Han arrives in the nick of time and kablooey – one dead Death Star.

Project sponsor Darth Vader is pretty much the only member of the senior leadership team who makes it out alive. So when Emperor Palpatine gets going on a new Death Star, you’d think management would have sat down and done a project review. What lessons did we learn from last time?

We can’t tell if the project management office has “don’t put a small thermal exhaust port right below the main port” on the briefing docs for the new build because, in Return of the Jedi, the Death Star is only half-finished.

We can surmise Emperor Palpatine is a bit of a fiend for a Gantt chart, though. Clearly he’s accelerated the part of the project aiming to get the main weapon up to speed without worrying about the defence system. Picture the scrum…

Palapatine: “Well, team, I know the dependencies on a conventional Death Star project call for structural integrity before the main weapon is functional. But can we brainstorm a way round that? I need to be able to shoot lasers pretty much immediately.”

Engineer: “Can’t be done. I mean, look what happened to the last DS, and that had fully operational defences.”

Project manager: “Hang on, let’s think outside the box. What about sticking a tiger team on development of a shield system down on the moon? That’d work. We bump the stage gate for the huge laser weapon up a few months, then backfill resources from the teams who’d normally be building the surface defences.”

Palpatine: “Excellent. Someone’s getting a five in their performance review this year…”

True, you might have expected a crack team of Stormtroopers to hold off an attack on the shield generator by teddy bear-like Ewoks. But many projects fail thanks to unexpected external factors – especially when the lessons haven’t been learned.

Result? Another blown-up Death Star. At which point, you’re saying: “Well now they must have developed a more efficient means of capturing and sharing lessons learned from their projects, right?”

By the time of The Force Awakens, the Empire have been replaced as bad guys by the First Order, and Palpatine by Supreme Leader Snoke. The new Darth Vader (spoiler alert) is Han Solo’s child, line-managed by General Hux. Figuring that a whole planet is probably more robust than a space station, they scale up the original project (always a risk) and… build in precisely the same weaknesses. The hugely powerful base is well defended against large-scale attack, but turns out to be dependent on technology susceptible to sabotage through infiltration, leaving an entire planet vulnerable to detonation by a small fighter craft. Well, duh!

The First Order’s first order should have been a post-action review of the Empire’s most notorious failings, and specifically its major infrastructure projects. True, there’s a 30-year gap between the destruction of Death Star II and the First Order building the Starkiller Base. But that just goes to reinforce the idea that your lessons learned documentation needs to be embedded in the institutional memory – not seemingly lost like some cheap memory stick.

This is not a new issue for the bad guys in Star Wars. In The Empire Strikes Back, Darth Vader kills at least two senior officers for momentary operational failures. Admittedly, debriefing Admiral Ozzel on project failures or quizzing Captain Needa for a post-action review is a little less dramatic than strangling them in front of their subordinates. But just look where that style of leadership ends up. “Just don’t mention the thermal exhaust port, OK...”

Whether it’s a First Order battle planet or a software rollout, making the lessons learned from earlier projects visceral, actionable and easily shared is the big lesson from The Force Awakens.

Richard Young is consulting editor of Project

A lesson on lessons

Project management enthusiast and Project contributor Martin Paver – unlike the Empire/First Order – has rigorously collated more than 15,000 lessons learned over hundreds of major infrastructure projects, often using data collected under the Freedom of Information Act. (You can read more about Paver’s mission in the spring 2018 edition of Project.)

He ascribes the failure to capture lessons learned to eight key areas:

• lack of forensic insight;
• variable standards for capturing lessons;
• a focus on process rather than outcomes;
• repetition – where lessons are recorded too many times;
• lack of context;
• lack of consequence (how serious was it?);
• lack of root-cause analysis; and
• difficulty in identifying correlations between lessons.

Ultimately, though, Paver argues that the real test is not so much whether a lessons learned box is ticked at the end of a project – or even whether lessons are captured. It’s how accessible they are and how well communicated.