Bespoke v COTS (Commercial Off-the-Shelf)) – What’s best for me?
Why bespoke development gets such a bad reputation
The world of custom/bespoke software development is littered with failed projects, costs that overrun 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.
COTS carries the same risks – it’s just better at hiding them
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 as lower risk than bespoke builds.
The three reasons most software projects failm regardless of approach
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’:
- 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.
- 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.
- 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.
The three questions that should drive your build-or-buy decision
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:
- Is there a COTS solution that exactly meets my requirements, is within my budget (both now and as my company grows), allows me to modify it to suit future organisational changes, and provides some level of certainty around projected costs in these scenarios? Sometimes COTS looks financially compelling, until you look at the long-term costs of annual maintenance increases, the need to upgrade every xxx months/years, and the risk that the supplier will decide, at short notice, that your core application is no longer strategic and so be sent into ‘retirement’.
- Do you believe that your requirement is unique and /or the marketplace is not wide enough to ensure that a COTS solution will be available, or the competition/choice is too limited to ensure the cost will be competitive and the solution maintained and developed to meet new compliance or fundamental market changes?
- Do you believe 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 how people do their day-to-day tasks – or do you want the expertise and experience of your employees to inform and define the software that you build?
Why agile reduces risk, but only if you reframe what a fixed price means
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 because they required too much up-front investment and then a slow, painful delivery cycle that eventually delivered something likely to be out-of-date, overly complex, and with functionality that was 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.
Fixed-price waterfall projects: a false sense of security
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 miss the point and remove 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 imposes restrictions on both parties, removes the flexibility of a more trust-based relationship, fosters disengagement, and results in cost overruns and wastage that it is meant to avoid.
The hybrid approach: building on pre-made components without losing control
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 reusable assets, can deliver faster and more robust results (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, reusable 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 for integration 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 a highly risky bespoke software development project/hybrid might actually be fun too!
Thinking about a new application? Let’s talk it through
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, with experts who deploy real-world solutions with a solid business case. No commitment to any more than a conversation to see whether we can help, I promise.
