It’s never easy and believe it or not – apart from technical knowledge it’s the communication skill that often plays a big role.
Apart from a detailed audit and getting hands-on around the tech it’s a lot of discussions with owners, employees and other people that I determine could be relevant.
Some of these discussions and actions might seem irrelevant for you – but at least in my case I always have a reason for them and it’s usually some form of long-term strategy.
Frankly speaking I am trying to make sense out of following outputs:
- technical assessment: can it be reused? How easy it is to continue? Security? Snowflakes? Missing tech knowledge? Wrong tech choices? (misalignment)
- business: does it solve a problem? Is it a “legacy-critical” system? Can it “earn itself”? Can it be used to enhance current ops/offer? Are they measuring anything?
- dirt: why it failed/is failing? Are there procedures? Sunk cost fallacy? Internal sabotage? (often unwilling) Communication? People not ready? “Rock star syndrome” anywhere? Frustrations?
The list of questions is far from being complete. The problem is – you as the owner of the project (or major investor) might have a limited ability to judge what to do because most likely you will be trapped by the sunk cost fallacy.
At the same time an external company that can also “develop it for you” might be tempted to sell you dev hours and hence will make sure the audit does exactly that.
That is why it makes sense to partner with people that want and can help you but not necessarily want to sell you dev hours. Their independence is in fact their biggest advantage.
By compiling those outputs I get an overview: sometimes I suggest gathering more data, taking measurements, because often that data is available and almost always underutilized.
That is how I work with broken projects – a simplified approach.
