Writing about past decisions that we wish we could change is always a fun topic - consider the possibilities! However, given that would require time travel, I have to heed the advice of Emmett Lathrop "Doc" Brown that “the encounter could create a time paradox. The results of which could cause a chain reaction that would unravel the very fabric of the space-time continuum and destroy the entire universe!”. An extreme scenario of course but best to obey the laws of time travel and not change the past, so instead we will have to settle with learning from it.
Every portfolio is unfortunately littered with a few bad decisions which have had some sort of impact. Most of these experiences will be unique and are usually to do with optimistic or outright false assumptions in the business case about the product, vendor, stakeholder or users becoming true throughout the lifecycle.
While there are some unique aspects to every case, there can be no doubt that there is usually a pattern and that bad decisions are often a case of history repeating. The good things about patterns are of course that if you can recognise them, you can avoid them (the bad types at least).
So let’s explore my top three of those bad decision patterns and see if it can help you to know to watch for in order to skip them or at least know what you might be in for if you do decide to take them on.
Investment Type 1: The ‘MySpace’ Project
Ah, MySpace (pause for nostalgia). Perhaps some are too young to remember but there was a social network before there was Facebook and it had a huge adoption rate when it went mainstream in 2004. Such was its mass appeal that it caught the eye of media giants which led to the MySpace $580m acquisition by News Corporation in 2005. However News Corporation sold Myspace in 2011 for just $35 million. So what happened and how does this relate to the next business case which might hit your desk?
There are perhaps two key learnings we can draw on from the MySpace story which you need to look out for in new projects. What you may notice is that these issues can occur on any project from the mega-bucks technology acquisition to the small budget projects.
Excessive legal, compliance and governance
As Sean Percival (vice president of online marketing for MySpace 2009) put it “As opposed to being this nimble, fast-moving sports car, they started to become slow”.
- Unfortunately different stakeholders will have different views on project success metrics which for some is keeping things so locked down and risk free you never release anything at all.
- Where an investment has a lack of clarity on the involvement of legal, compliance and governance stakeholders or worse, where it is clear and there is a very high cost for it, the investment should be questioned and potentially skipped.
Confused success metrics
It is certainly unclear to me whether MySpace existed (in the end) as a digital marketing and advertising platform or an end user platform focused on feature use and adoption (one might say the same for the current crop of social apps I suppose). In the end the two collided in a bad way for MySpace users with access to features becoming lost behind the friction of heavy advertising.
- It is one thing to clearly define ROI as well as other metrics such as user experience and adoption, however if the business case is unclear on how they will be integrated to avoid conflict that should raise red flags.
- Beware of aggressive ROI for short term ‘wins’ which may serve to undermine future growth or adoption and ultimate long term success.
Key takeaway
It is easy to get lost in the lucrative quick wins in an Investment business case including opening up processes to ‘too many cooks’. Balance and restraint in the short term should be evident in a business case as should the long term success criteria and value. If those things are not there - skip it.
Investment Type 2: The Dark Knight Project
Many of us have seen new Investment requests tabled which seem, on the surface, to have a very aggressive timeline. That is perhaps fine if your organisation has the capability to deliver thy type of change being promised but if it is at all new or any new capabilities are required - look out. Projects might seem simple with a few months to develop and test code to eventually deploy and get value from. Everyone wins right? Of course everything going perfectly to plan is one scenario (I’ve never seen it) but without being a doomsayer that the perfect project does not exist, it is pragmatic to take a review all risks before authorising the investment.
A famous case study of a project which had all the hallmarks of a short, aggressive timeline with the promise of high returns once live, is about Knight Capital.
Knight Capital was one of the leading financial services firms on Wall Street and on 1 August 2012 had code flaws in newly implemented software erroneously buying $7billion of stocks in the first hour of trading (engineers caught the issue at 9:58AM after the market had opened at 9:00AM).
What can we learn from Knight Capital case
In the Knight Capital case study there were a number of factors that should have killed the project before it started. The change was being made to an existing platform and code base which did not seem to have proper quality assurance, configuration management or an established DevOps capability that could be drawn on to better assure the outcome.
Not only that but the project was to rely on manual deployment practices and had workarounds to manage the risk of redundant code in a legacy platform that has been developed for years for other requirements.
Key takeaway
Any investment that promises an accelerated timeline which will develop modern features (or use modern practices to develop) on a legacy platform should be rigorously challenged. Risk Management must account for the worst case scenario if things go wrong and the project should have the mitigation strategies to deal with all outcomes.
Finally, if the project is to rely on modern DevOps and release management capabilities, the question MUST be asked if those skills exist in the enterprise and if they don’t, ask how the project will source them to complete the work.
Investment Type 3: The Cloud First Business Case
Now I know what you’re thinking - why would a Cloud computing project be something to skip? Ultimately it is not and hopefully all organisations are benefiting from cloud technology or will at some point soon. The pattern that can emerge in an investment portfolio which should be treated with extreme caution is when business cases are being submitted for technology projects based on a ‘cloud first’ principle...and not much else.
It is easy to get blind sided by the benefits of cloud computing or any other modern technology especially when most organisations are wrestling with legacy technology and obsolescence risk. However cloud projects which promise to solve these problems should be treated like every other project and they MUST have a clear link to an agreed business strategy.
The types of dependencies that should be accounted for in Cloud technology business cases include the use of vendors (during the project and beyond), business process management, network infrastructure and most importantly, the impact of introducing new financial concepts once the services are operational.
Referencing principles or buzzwords in a business case is fine but if the investment request does not also provide sufficient information on the major dependencies a cloud project should have assessed - skip it.
Key takeaway
Solid business cases are not based on principles. They are based on factual data and robust analysis as well as clear alignment to an approved strategy. Every dependency should be risk assessed and the project should have accounted for management of them in the plan.
The final word
I’m sure that the stakeholders and Executives of some of the organisations mentioned in the case studies may like the time machine idea but while we wait for that technology, it is our obligation to learn from these investment decisions. With the red flags that were all over these three we have gone through in this article, it is very clear that the investment decisions should have been skipped if not at least challenged and changed with risks mitigated. Hopefully you can take these learnings into your portfolio and investment decision making and that we won’t be appearing in someone else’s case studies any time in the future!