Death to the Project

I come here not to praise project management, but to bury it. (And misquote Shakespeare. It’s my thing.)

Accounting like to run things. Which is cute, really. They know how to count things, and so we should organise things the way they count them.

Thought experiment: Turn off accounting’s computer access till they shut up, roll over and stop running everything. They can use big ‘spreadsheets’ on paper for a bit to discover that actually yes, computers are important.

Did you know there are software replacements for your entire finance department? Look at the efficiency gains! Mmm.

If you have a Program Management office too, well, that’s a symptom of bloat. Strip your org’s program processes down a bit, realise some cost savings. (If your org has grown these processes to farm government contracts, well… I’ve got an essay about that too.)

The core idea is that software development costs money, so it’s an asset, with CAPEX and OPEX.

And therefore with a Project to make it.

The Project delivers the Software, which transitions to Business As Usual (BAU) and the Project is now over. And is now funded as OPEX. So, less.

That works okay-ish for building a building. Yay for accountants and Project managers.

Not so good for software.

Firstly, and this is going to upset people, you’re never done with software. (Or boats.)

There are efficiencies to wring from the organisation by changing the software, and integrating with other systems.

Laws and ‘regulatory frameworks’ change over time.

And more often, defects often quaintly called ‘bugs’ are found and need to be prioritised and fixed. (That can be a cost-benefit analysis if you have data. If you have estimates and not data, then I estimate that Superman can totally kick Batman’s arse. Because that’s what an estimate is. A story. Bring data. Oh… you’ll only have convincing data when it’s done. So… let Engineering leads Engineer. It’s what they’re for.)

But more often than all of that, the 3rd party pieces of software that make up your software get updated to fix bugs, or because the guy in Arizona that originally wrote it to track, I dunno, his pet gecko decided to update it. And the operating system get updates etc. Mostly to fix horrible security flaws, but also because Gordon gave up on the old way thing-X worked and built a new thing, so half your operating system just got ripped out and replaced.

If you’re running on ‘cloud,’ your cloud vendor will change the operating system of the cloud at random. Because you’re just leasing time on someone else’s computer, when all is said and done, and they are all programming away like mad because well, reasons, mostly connected to their commercial business leasing computer time, and calling it ‘cloud.’

And every single change needs proper system testing. (It’s like you can’t afford manual testing, or something? Huh, is that an essay topic?)

If your company largely writes its own software, then if you’re lucky, security researchers will be kind and tell you that you have security vulnerabilities, and in return you pay them, and update your software. If you are not lucky, bad people will find your vulnerabilities and best-case blackmail your company. Worst case, they exploit it, and it gets publicly disclosed and your company tanks.

So basically, software system security is a continuous war, and just to make it extra fun, a number of nation-state actors are in the business, either for spying, or more often, extortion. North Korea, for example gets a lot of foreign currency via bits of the state security apparatus that do Encryption extortion attacks. Vendors who make more software, get hit harder. It’s all ‘attack surface.’

But the real problem with software Projects is that the people that designed the system in the “Project” phase, aren’t the ones maintaining it during the Business as usual or “BAU” Phase.

The key problem here is that what you’re doing is spending several millions building something, then letting all of those people leave, If they ever were employees. So all the intellectual capital and skill walks the day the project delivers. Including, of course, the architect that designed it. You keep the rapidly-depreciating software asset. And every ‘we don’t have time for that’ from when the software was first written, becomes an unhedged margin call. (That is reckless, from a risk-management point of view.)

The BAU staffing is whoever you can get, and now they are expected to operate something that… they have no idea how it works, how it was supposed to work, or why is that really complicated bit like that?

This lets organisations essentially pay to redevelop systems, but with what is generally the B-team.

The BAU team then has to maintain the system, see above. But they weren’t hired as smart enough to build it from scratch.

(If you’re going to build something expensive, why pay to do it twice? It will… cost twice as much. And take longer.)

A Quick interlude for Customer Customisation.

I wanted an example, and one organisation, globally stuck out for customising things to death.

The Australian Defence Force (ADF) is notorious for buying working aircraft, ships, etc, then customising them to the point where they no longer work. They are possibly the worst at it on earth.

Recently they destroyed two entire fleets of helicopters; neither design was fit for purpose, according to the Australian Defence Force. (Literally cut up and buried the pieces.) Weirdly though, every other country that bought the same models found that they worked okay. (Maybe Australia processes buyers remorse differently, or something.)

The ADF are special, and have special problems. Australia is very big, very dry, dusty and hot, and bases are very far apart. So everything the ADF buy gets a radio upgrade. They do need more power. But somehow that escalates to everything being broken.

The thing is, the ADF customise things to death with their Internal Engineering expertise. The problem being that those military officers with Engineering degrees, aren’t actually design engineers. (Some are instead, career civil servants with engineering degrees.) The have never worked as design engineers. They were, in fact the BAU team, coming in and making changes... till nothing works.

Let alone that some changes are done for ‘reasons’ without a clear cost-benefit analysis.

In Australia, (and this is not a joke,) they built a German Submarine design in two pieces, in two different states, and welded it together because jobs in two states. And replaced all the weapon systems with American weapon systems. Now the American torpedoes are good. Very good. But…. Given that the Aussies didn’t fire a single shot in anger, uh, well, couldn’t you have used the same weapon systems the Germans had ? (Only Kockums bid for the final tender because every other vendor said ‘you’re crazy.’ Kockums nodded and took their money anyway.)

In the final analysis the jobs portion of the submarine programme could have been just giving everyone who’d had a job on the submarine programme in the state of South Australia a million dollars.

Their replacement for that system is currently to buy Submarines from AUKUS, so something nuclear-powered from America and/or the UK. Before that it was to buy from France, a non-nuclear version of an existing nuclear sub. (Australia doesn’t have the infrastructure to maintain or refuel nuclear vessels, or the educational systems to train staff for nuclear systems of any kind, in quantity. So uh, if you can’t hire the BAU team, uh, why buy the design?) For the original tender, the best price that met most of the requirements was a turnkey Soryu submarine from Japan. Apparently the ADF is unable to deal with bids like “This is a Soryu, it costs X and has these features. We are allies, this is a good deal.” Because when asked “How much to put American weapons in it?” the Japanese said something like “No. This is the submarine. This is the price.”

Americans who feel smug can look at The NASA programmes SLS and Orion, which … well they were very expensive rockets that Congress kept funding for NASA, even after technology had moved on. (Though Congress also makes the US Army take delivery of more and more Abrams tanks, which is a continual pain in the backside. They go into storage, there’s not the troops to operate them, or a use for them.)

What I’m saying is that given that you’re never done, don’t have projects. (I’m not saying to leave all the accountants on a rocky island without food. That would be cruel. Just don’t give them a tin-opener, or not one that works, anyway.)

GANTT charts, that mainstay of project managers, were invented for the Apollo programme, where the USA spent billions making a rocket and sending it to the moon, taking two-man crews down to the lunar surface, and back, and bringing the three-man crew safely home. And doing it more than once. They only killed the entire crew once, on a pad test, so that doesn’t count. But more importantly, Apollo had subcontracting to every state, so every congressman had a jobs programme. That’s what GANTT charts are for; connecting up the parts of the rocket. (Or pinning the porkbarrels together if you’d rather.)

The catch being that everything including connecting rocket bits is setting delivery dates by estimates, so, again, I estimate Spiderman can totally kick Batman’s arse. (My point with my ridiculous, pointless estimates is, that it’s all made up and doesn’t matter. I’ve got more to say about delivery dates in another essay, and it’s not kind.)