This is deeply insightful, delving into the reasons why almost all ambitious complex software projects fail:
https://bigthink.com/smart-skills/complex-project-galls-law/
In a nutshell, to succeed you must:
Really like Gall’s Law - I have an old copy of Systemantics somewhere. Aligns well with the ideas of the NASSS framework as well.
Excellent article. I’ve always found it interesting that the business generally insist on having all the functionality delivered during the project as opposed to starting with a simple project and then making a decision on the next level of investment/project. The reason given is normally that ‘if we don’t get it all in this project, then we are never going to get it’.
Many times I’ve noticed the level of functionality that the organisation is aspiring to, does not match the organisations current level of maturity. This results in an overly complex system that the majority of the users are not ready for and is therefore not well received.
I think if we got better at delivering base level projects and incrementally adding to them, (if required) we would be much more successful than planning out massive projects, (and don’t even get me started on ‘the system must meet all our requirements’ vs trying to work out which ones are more efficiently/effectively met outside of the technical system).
There are always strategic considerations but that’s what programmes are for.
This is a great writeup, and Systemantics is a classic if somewhat tongue-in-cheek response to the difficulty inherent to any complex system, not just IT. However the example of healthcare.gov is interesting not just because of the failure at launch, but the subsequent (and ultimately highly successful) almost “skunk-works” efforts to fix it.
Quite a read thanks Ryan! Was a bit tricky to evade the paywall (is an old article) but all good.
One point that really resonated with me was that a small software team usually produces good software significantly faster than a large team (and a hell of a lot cheaper too).