Top Gun: Project Management

Project management is a complicated subject, usually multi-dimensional and domain-specific. It is also a realm of incessant warfare between adherents and opponents of different methodologies. These methodologies are notoriously difficult to explain, visualize and/or reconcile. Fortunately, there might be a solution for all these challenges: watching the “Top Gun” franchise.

Both the 1986 “Top Gun” and the 2022 “Top Gun: Maverick” feature Tom Cruise as their main protagonist. They both contain dazzling air combat scenes. Yet, these movies could not be more different.

The original Top Gun was an ultimate male fantasy: fighting, friendship and love. The USN carrier team depicted there had a “simple” goal: to keep bogies away from the US naval assets, shooting them down as necessary. For this, they employed the F-14 Tomcat, an aircraft specifically designed to counter contemporary Soviet planes and long-range missiles. The Top Gun school was training F-14 pilots to dogfight, while developing new methods to defeat adversaries and survive. All this was done in iterations, under supervision of tough but understanding commanders. Despite all mistakes and painful losses, the 1996 Top Gun ended with Maverick overcoming his personal demons, winning in combat and winning in love.

The 2022 sequel’s mission concept was most likely borrowed from a real-life and incredibly daring Israeli bombing of the Iraqi Osiraq nuclear facility in 1981. Then, indeed, after training for months, a small group of elite Israeli pilots flew thousands of miles and attacked a well-defended and highly entrenched facility, knowing well they may never come back.

However, neither in real life nor in fiction would the US have any need for Israeli methods in that particular scenario. There are hundreds of USN and USAF assets in the Persian Gulf vicinity, and Diego Garcia is not far away either. All those Iranian air defenses and even a few so-called 5th generation enemy planes stand no chance against the present US military might. Yet, the sequel’s project leaders insist on using that one particular (and not necessarily the best) tool at their disposal. Then, to improve their admittedly meager chances of success they heroically invite an otherwise unwelcome expert to help iterating that mission into a positive (though not less suicidal) outcome.

As a matter of fact, the 2022 Maverick is not yet another lone homeless veteran, able to persevere and continue to do business solely because of the continuous patronage of his old friend Ice. Indeed, the biggest invisible feature in the sequel is the USN bureaucracy, with various admirals furiously fighting each other under the carpet. You literally cannot find a better metaphor for a complex enterprise project with multiple corporate interests involved.

The sequel is also a metaphor for the stubbornness of some Agile purists. Last month I personally heard a project manager claiming that coding must be started as soon as possible using whatever programming language/framework is available – and then iterated. When I asked about business-level objectives of the project, capabilities required to achieve these objectives, uncertainties related to the longer-term project execution time and budget – and then, the relationship of immediate start of coding to all the above, he scoffed: “we can always start coding from scratch.” In terms of the “Top Gun: Maverick,” we can always find another group of elite pilots and try again.

SAFe fanaticism is not healthy either. For me, SAFe is one of several common-sense responses to the chaos caused by the blind application of Agile. However, it seems to be tainted by a suspicion of ulterior motives. As someone noted defensively in an online forum: “SAFe is not only a certificate-selling business.” I find that statement extremely telling – and somewhat hilarious.

Alternatively, Adrian Cockcroft described AWS methods as 1) AWS teams are effectively independent business units; and 2) they are working backward from the expected outcome.

This is like building a presentation deck: if you know how the last slide should look, you put the other slides as stepping stones along the best path to get to this last slide. The problem with project planning is, oftentimes it is not entirely clear what that last slide will look like. So you start iterating in both directions, regularly adjusting the last slide as the development fog clears. Of course, you do not build it from scratch every time, but rather realign your prior work as your vision becomes more and more clear.

Incidentally, this methodology fits within the “Capabilities Based Planning” framework practiced by Senticore. In the context of project-planning practices, this means that 1) requirements are generated by business and system analysts using Agile/SCRUM, and 2) software developers iterate towards tactical goals using their own Agile/SCRUM. Altogether, a self-correcting process at work.

I prefer to think of the Senticore team in terms of trained professionals, always on the lookout for bogies – problem statements, root causes and risks. We are practicing an equivalent to what the US military call “multi-domain operations“: various technologies, tools and methodologies are coordinated in a perfect ensemble, increasing each other’s strengths, mitigating each other’s weaknesses. With on-premise, multi-cloud and multi-SaaS environments, and focusing on engineering and manufacturing domains.

We always want the right mix of innovation, stability and predictability, with as little chance-taking as possible, to avoid the lottery of unlikely heroes saving the day.

Talk to Senticore, and we will help you to hit the targets and eliminate the bogies – with the right features, on-budget, on-time, and without taking any chances.