Build or buy your Software?
Bespoke v COTS (Commercial Off-the-Shelf)) – What’s best for me?
The sad history of failure in bespoke development projects
The world of custom/bespoke software development is littered with failed projects, costs that over-run so much that the original budget is long forgotten and so the world of business lives in fear of the words ‘bespoke development’. Whilst it is clearly true that there are many high profile examples of bespoke development projects going badly (just look at the government sector and their travails with electronic patient records systems etc.), the fact is that, for many of these projects, budgets were well and truly busted, projects cancelled and investments written off, are the same as for many seemingly lower-risk failed ‘out-of-the-box’ COTS software based projects.
The truth is that it’s nothing to do with the ‘bespoke’ part of the project – COTS (Commercial Off-The-Shelf) has the same risks
It’s a sad fact that, over the 30+ years’ experience I have in the software industry, every single customer I have met who tried to deploy a certain ERP vendors ‘package software’ (name not supplied as I’m sure they have a large legal budget), has ended up costing the customer 4-5 times the original budget (and when it started with a budget of £10’s of millions in the first place – these are telephone directory like budget over-runs). However, somehow, COTS projects are sold on the basis of their being lower risk than a bespoke build.
In my experience the reasons for failure often have some common themes, whether bespoke or product, with the following being a summary of the leading contenders for ‘things to do to make sure your project fails’:
1. The customer and the supplier don’t have a good enough handle on the scope, but insist on the supplier committing to the exact scope of the final deliverable too early in the project cycle, resulting in shaky foundations and an, almost inevitable ‘you said, he said’ recriminations. Suppliers can also be guilty of getting carried away with the enthusiasm of a new project and take a ‘flyer’ on too little detail in their desperation to get the project started.
2. The customer business sponsor cannot get the buy-in from all of the levels needed to ensure a successful roll-out, whether this is at senior management level (where execs have to make sure everyone in the company understands that this is happening, why it’s needed and that it’s critical that everyone is engaged and adapts, as needed to play their part in making it a success), or at end-users level, where change is resisted based on ‘we’ve always done it xxxx way’. Software projects fail when the new software cuts across established working practices leading to user resentment and ultimately rejection; COTS as a one size fists all solution is inherently this; there is no scope to tailor; or if there is scope to tailor then tailoring will always be restricted and will lead to cost increases in the short-term and upgrade nightmares in the medium/long-term.
3. Scope is allowed to get out of control during the build in an effort to bring on-board all of the people not on board with point 2, resulting in functions being developed that are ultimately little used, or make the system/process overly complex.
As mentioned above, unless you have managed to deploy a software package in a completely vanilla manner i.e. there is no bespoke/custom functionality and even configuration options are kept as close to vanilla as possible, then the 3 points above are issues for both bespoke and COTS. If the right controls and even project culture are deployed, then a successful project can be guaranteed and so the choice comes down to:
1. Is there a COTS solution that exactly meets my requirements, is within my budget (both now and as my company grows, acquires, allows me to modify to suit future organisational changes and allows me some level of certainty around projected costs in these scenarios)? Sometimes COTS looks financially compelling, until you look at the long-term cost of annual maintenance increases, having to upgrade every xxx months/years and the risk that the supplier will decide that, at short-notice, your core application is no longer strategic and so being sent into ‘retirement’.
2. Do you believe that your requirement is unique and /or the marketplace not wide enough to ensure that a COTS solution will be available, or the competition/choice too limited to ensure the cost will be competitive and solution maintained and developed to meet new compliance or fundamental market changes?
3. Do you believer that retaining the Intellectual Property in the system would be beneficial to you and a differentiator in your marketplace? Do you want a software package that defines and controls the how people do their day to day tasks – or do you want the expertise and experience of you employees to inform and define the software that you build?
Managing Risk – Take Small Incremental Steps?
I’ve worked across both software product sales and bespoke developments, starting out as a COBOL developer on Tandem Computers back in the 80’s (yes there are a few of us still alive), apparently I could probably make a living still in certain government departments and high street banks based on my ancient technical skill-set, so I do know what it is like to be at the coalface and trying to deliver a project on-time and too-budget.
Modern development tool-sets and techniques mean that it is eminently possible to quickly and easily address the main reasons for project failure (see above), by adopting, proven approaches to iterative/incremental delivery (Agile or whichever other flavor you adopt) of functionality. As the organisation starts to see early delivery of their ideas, they can really get engaged with the process. Traditional Waterfall type approaches soon lost the audience as they required too much up-front investment and then a slow and painful delivery cycle that, eventually delivered something that was likely to be out-of-date, overly complex and had areas of functionality that were never used again. An Agile/Iterative approach delivers fast, adapts quickly as needs change, whilst still having all of the project rigor you need, when done correctly, to be sure you will achieve your business goals.
Sharp-cut bespoke or generic off-the-peg?
The issue for many is that an Agile/Iterative approach makes people nervous as no-one can say that ‘we will pay £xxxx for the system and it will definitely deliver yyyy functionality’ as that would totally missing the point and removing the benefits of the approach. I would argue that the benefit of this approach is that you can fix a cost of £xxxx for your project with an associated delivery timescale, the only difference is that your system will exactly meet your needs at the point of delivery/launch, it just won’t be what you thought you wanted at the start, will be of higher quality, be faster to deliver tangible business benefit and should offer you competitive advantage in your space (whether delivering slicker processes, or a more pleasurable and effective customer experience). I would venture that, a fixed price waterfall project is actually a false security blanket that places restrictions on both parties, removes the flexibility of a more trust-based relationship, fosters disengagement and results in the cost overruns and wastage that they are meant to avoid.
Nirvana – Integration of Pre-Built Components/Services – The Hybrid Approach?
Well almost, the more recent projects we have worked on have actually been a combination of ready-built components/services from cloud platforms/Open Source Projects etc., combined with a ‘glue’ of bespoke code to create a new and robust solution, leveraging the investment others have made in building core building blocks that add no real distinct business value in themselves, but which need to be there for most applications (such as Access Control, Password Management, CMS functionality etc.). This approach, when done with a level of due diligence on the source of these re-usable assets, can deliver faster, more robust (if selected carefully you are getting well tested and widely deployed code reducing time-to-market with code that should be bug free). Of course, re-usable code/components is nothing new (those of a certain vintage will remember Paragraphs etc. in COBOL), but newer technologies make this far easier with well-defined methods of integrating to make the most of reusable functionality.
If you are considering using technology to deliver significant business change, or to release your staff from mundane manual processes to focus on creating real value, perhaps, taking a step back from the perceived wisdom that buying a COTS package and squeezing it, or your processes to fit, might actually be the worst decision you could make ? You never know that highly risky bespoke software development project/hybrid might actually be fun too!
Interested in finding out more?
If you are considering the deployment of a new application (Web, Mobile, Back-Office) and are unsure which is the right approach for you, we’d be happy to help with an initial discussion to help you think through the options open to you, giving you our best advice based on (quite a lot of) experience. We even have a specialist teams focused on new tech such as block chain, deploying real world solutions that have a solid business case. No commitment to any more than a conversation to see whether we can help I promise.
