We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.
×

Project planning: Customising solutions and weighing up off-the-shelf options

Implementing any form of digital transformation, regardless of the size of the business, comes with many pain points – particularly financially.

According to a report by McKinsey, half of IT projects priced above $15 million blow their budgets. On average, they run 45% over budget, 7% over time and deliver 56% less value than predicted. Software development projects score the highest risk of all: 66% of projects run over budget and 33% over time. 

With these seemingly damning statistics, it’s easy for you, as a client, to blame the team contracted to do the work. You’ve paid them because they’re experts with experience and impeccable creds. So why is it so hard to get it right? And is there anything you can do to prevent this kind of overrun from impacting your project? 

Most literature talks about effective planning, risk management, keeping a contingency budget up your sleeve, and ensuring you hire an effective team. And you should absolutely do all these things. But unfortunately, that’s probably not going to be enough. Why? Because even though you may not realise it, you’re probably also (unintentionally) part of the problem. 

This series you’re about to read is meant for those thinking about, or already in the middle of, a digital transformation, a new customer-facing digital solution, or any kind of large website development. It aims to help you avoid the project overruns by looking mirror firstly at your role, to demystify the process, and to support you in making better decisions when contracting and managing a large IT project. 

It all starts with the decision whether to adopt customised or off-the-shelf solutions. It sounds relatively straightforward, and indeed, many clients will have a preconceived idea that out-of-the-box solutions will save them time and money. But in reality this may not turn out to be the case. 

Custom-building a house is perhaps the closest analogy to building a website or any piece of software. It helps illustrate not only the process, but also the folly of how we think about software development. The way people instinctively blame the developers, the way the procurement process impacts outcomes, and how all these things contribute to the statistics we just saw earlier. 

While building a house may seem complex, when contrasted alongside software development it can often be relatively simple: after all, everything you need is largely available in an off-the-shelf form. Thousands of the components used to build a house come with a known price tag, can be assembled in a relatively standardised and well-known way, are required in a known quantity based on well-defined modelling and specification tools, and can be purchased off-the-shelf at hundreds of suppliers.  

Most house builds contain relatively few truly custom elements, and yet, many still run over budget and blow their timelines. Imagine what this would be like if everything in the house was custom-built from scratch, as is the case in most software development projects?  

While there is a trend towards ‘off-the-shelf’ in the industry, and there is certainly the belief that solutions in 2022 can be delivered with an expensive enterprise platform license and a bunch of ’out of the box’ features, the reality is that, unlike an average custom-build house that involves only one or two ‘truly custom’ pieces (e.g. that magical spiral staircase or the bespoke gable woodwork), a typical software or website development project still involves an incredibly large degree of custom development work. 

But why? Haven’t we evolved past that? The short answer is no, and evolution is part of the problem. In fact, the technology industry is evolving so fast that by the time any technology or standard approach is ready to be included as an “’out of the box’ feature and widely adopted, there is usually something newer and arguably better already available. Consequently, these ’standards’ don’t have time to settle in before there’s a newer, better way of doing something. And even when they do, code reuse (often touted as a silver bullet for saving time and money) is actually  not as simple to implement nor as widespread as it needs to be to make a tangible difference to the cost and time involved in large projects. At best, reusing code saves you a fraction of the overall project cost: still worth something, but not as much as you’d think. 

On top of that, and more importantly, the fact is that the features you (and only you) require are often just not quite the same as anything else that already exists. When that happens, sometimes even a slight variation can mean the thing you’re asking for will require custom work. The difference might seem minimal in some cases, but software development can be deceptive this way: the size of the apparent difference and the size of the effort required to make it a reality are often not proportionately related, so often, even small variations can mean hours, days or weeks of additional work. 

What it boils down to is this: almost nothing truly comes out of a box. 

Of course, that doesn’t mean you shouldn’t pay for a large platform if it aligns with what your service providers are recommending, or what you need. Nor does it mean that you shouldn’t demand that libraries, accelerators and packages are used, that code reuse is an important factor in how you expect your developers to operate. But understanding that even small variations to off-the-shelf features can often result in pushing against the grain, a situation where the outcome is often that it’s simpler just to custom-build the thing you’re after in the first place, means you’re far more likely to align your expectations with reality and therefore have a positive overall outcome. 

Because here is where you come in: it’s your responsibility to brief your team of architects and builders on exactly what you want, so make sure you do it right, and make sure you do it in a way that acknowledges the reality of what will actually take place on the ground. This is the first step of project planning. Working in collaboration with the development team and your partners, being clear about requirements, expectations and (most importantly) the budget, will set up your project for success and help your partners work with you to get you the most bang for your buck. 

 

Christian Brenner has spent over two decades building enterprise websites for businesses and organisations. He is currently the National Head of Technology for Merkle Australia, the country’s leading customer transformation partner, empowering brands to create distinctly better experiences. 

This article is the first in a five-part series. Follow Merkle Australia on LinkedIn to follow along!