During my career of implementing various eCommerce projects, a notable and key cause of tension is building a contingency budget into the projected cost. This is because you’re essentially saying ‘this might not all go to plan.’ Ironically, having a contingency budget in place means that, should anything happen, you’re still – in principle – financially on track.
Not planning a contingency budget into the wiring of a project doesn’t just open you up to the consequences of financial miscalculation, but it can potentially damage and ruin a commercial relationship. As an agency, we find that there’s nothing more likely to punch holes in a project – whether it’s replatforming, redesigning, resourcing or otherwise – than financial concerns.
Unforeseen and unaccounted costs can cause a lot of conflict between clients and agencies – and also internally. Going over budget is usually attributed to mal planning, misevaluation and mistakes – or at least this is the easy assumption. When everyone in a team plays a part, those parts are scrutinised, but often it’s in the unavoidable variables where the crux lies.
Not having a contingency budget can result in a lot of crossed wires and even crosser people. Frustration and anxiety surrounding the project can impact on the relationship between project managers, account managers, developers and creative design teams. Therefore, when it comes to completing day-to-day tasks, things are a little harder if there’s tension. Ultimately, budgeting should be effective and based on a realistic assessment of the company’s operating capabilities. Often extra resource might be needed which doesn’t reflect the original plan or manager’s judgement.
Why do businesses fear contingency plans?
The real fear many businesses have when working with agencies is that they’ll try to spend any contingency budget in order to elongate a project – with a view to it costing more. But this is hardly ever the case and such fear is assumed when there’s an element of distrust at the start of a working relationship – for whatever reason. Agencies strive to deliver on time and to budget. We’re not ever looking to spend the contingency. In fact, we’d rather deliver on time and then retain the client – retention is everything!
However, even the most experienced project managers can still fear estimating a project’s contingency correctly. The usual method is to add some form of calculated risk-based assessment and then add that value – for example 10% – to the projected cost. However, while this might seem sensible, there are too many variables to take into account to make such a rough estimate.
Contingency shouldn’t be a singular, separate budget
If you’re planning on – for example – replatforming your website, but your plans then expand to include the ability to have a new mobile app or the ability to register products returned in-store that were purchased online – or both, then your change in project scope will need recalculating, which means your contingency budget will also need adjusting to cover the new associated risks.
Changes in scope are so important to account for. Sometimes it’s preferable to have two contingency budgets. In this case, the second contingency, which can be known as ‘programme contingency’, is used to cover the risks that were not identified at the start of the project and may become clear further into development.
3 unexpected costs when building an eCommerce website
Here are some of the common issues that I often come across that add costs to projects:
- Third party dependency issues (late or changes)
This is quite a common challenge for eCommerce projects. Often, services that are being provided by a third party can be late or entirely defective. This will have a knock-on effect on the project, and skew timelines. It does mean that extra costs can be incurred to resolve the issue while waiting for the problem to be rectified by the third party or even maybe enlisting the services of a different, and more expensive, third party.
- Unexpected or unforeseen complexity only realised at the point of build or testing – perhaps caused by changing requirements or misunderstanding
Commerce projects are complex and sometimes there can be a clash of feature requirements that may only be realised during specific development or software testing. Extra effort and resourcing is then required to alter functionality in order to ensure all the features are working together effectively and no longer clashing. This type of unexpected cost usually relates to business processes that become apparent down the chain – so won’t be obvious when first planning and designing.
- Key personnel changes or unavailability – usually due to business as usual
It is difficult to run a project delivery without certain key people within the business to make decisions or provide input. If these people are unavailable, usually due to them performing their day-to-day business activities, a lag can be introduced in the project that increases timescales and therefore extra costs are introduced.
The real contingency effect
Ultimately, contingency is a risk strategy. When there is a contingency plan in place, the impact can be positive for a few reasons. With budgeting tactics in place, risk has already been accounted for. Risk can sometimes compel teams to produce even better work. When boundaries are pushed and there’s the budget to make add-ons that might improve the project, then often a culture of innovation and creativity flourishes. Having a contingency budget:
- Minimises disruption
- Costs less than the cost of unplanned, extra production
- Prevents panic
- Provides a comprehensive business evaluation should crisis arise (“A will lead to B, which leads to C.”)
- Promotes business continuity
How should contingency budgets be used correctly?
If a contingency is agreed, it should be tracked and managed as part of good project governance practices. It should be made very clear at the start what it should be spent on (as per the examples above) but also what it should not be spent on (e.g. brand new scope or non-project related costs such as extra third party service costs).
There should be utmost transparency when a contingency is used. Your main goal when it comes to using your contingency budget should be to maintain ‘business as usual’. A good example of the type of situation that would require using some of your contingency budget is:
If you’re replatforming your website, then in addition to their day jobs, replatforming teams will be focused on the current phase of their projects. They will be familiar with testing as it is widely accepted as best practice, but it can often be hurried or pushed to the end of a project plan. As ‘go live’ dates approach, the case often arises that the proper testing environments do not exist yet or there simply isn’t enough time to run all the tests needed to prevent post-launch issues. Teams are usually preoccupied with learning how to use the platform post-launch or focused on change management that it can be difficult to keep up with the usual day-to-day activities that affect important project KPIs. It’s instances like this where you may choose to use some of your contingency budget either to add extra resourcing towards testing, or towards day-to-day activities.
So, should contingencies be feared?
Businesses need to deliver a minimum level of functionality – the less disruption the better. When breaking into a contingency budget the goalposts of what success looks like will often change too. The project is morphing and evolving which will mean re-evaluating your ideas and your project’s end goals. This isn’t a bad thing, it’s highly encouraged.
And finally, don’t forget that contingency plans are part of business stability. It’s never risky business having one – quite the opposite.
Kevin Murray is Managing Director of Greenlight Commerce and has over 15 years experience of running projects in the technology, eCommerce and Omnichannel retail space.
