Over the many years I have been working with businesses to help them deploy a new commerce platform or replace their current one, time and time again we find projects stall before they’ve even started.
In the fast paced environment of eCommerce and changing customer expectations, project delays compound challenges for business. Not only do they have to deal with any direct consequences of the delay, but also the indirect costs of missing out on revenue or savings due to the delays in the “time to market” or opportunity costs these cause. We are reaching the point where if a retailer has not yet properly begun the technology transformation necessary to meet customer experience needs, then they are going to be too late, and will be left behind.
I thought it would be helpful to share my experience of some of the main causes of delays and ways to avoid this happening to help you keep your project on track. Nothing can be more frustrating than spending months discussing the requirements of the new platform, preparing a business case, getting executive buy-in, drafting a detailed RFP, reviewing umpteen lengthy proposals, sitting through supplier presentations and making your choices on which technology and digital partner, for it to get put on hold or even shelved.
Obviously you can’t foresee every delay and not every situation will be within your control, but below (and in no particular order) are the most common causes for projects stalling that we come across. By being aware of these and taking steps to ensure you’ve considered everything before you start a project, you can help mitigate against unnecessary delays:
1. Budget
While it sounds obvious, we have been involved in processes where the budget has not yet been fully approved, but this has not come to light until after the initial stages of the project have started. If work needs to be done to determine feasibility and get a better idea of the whole budget, this should be communicated and agreed with all parties before any work has started. If the early stages of the project need to help financially justify the later stages, the suggested approach to delivery may well be different.
Related to this is where a business is looking for approval to start a process procuring a new technology or service and there has been an underestimation in the early planning stages. After the first round of RFPs or initial meetings with potential providers, prospects realise that they have not set the correct expectations at the senior level regarding costs for this new technology and related ongoing costs.
The most common situation we see is related to the “known unknowns” of the wider cost to business. While the client understands there will be some level of impact, and therefore cost, that could effect the wider business, they hadn’t fully considered how much.
2. Haven’t considered the wider knock-on effect to business
The impact on a business can be seen in two main areas that determine a pause and re-think: project delivery and post-project service enablement. Business often don’t realise the impact of delivering a new project. They try to get the build done at the same time as doing their normal day-to-day work. This is often is considered an optimistic ideal until the business understands the amount of work they will have to do to help prepare for a new digital technology.
One key justification for acquiring new technology is to offer new goods and experiences to the end customers, but sometimes the full considerations of what it takes to deliver this within a business is not considered enough. A good example I often cite is related to “click & collect” as this highlights the trading impact on bringing on a new service offering thanks to a new platform.
While the technology has been around for a while to help deliver this service, the business process related to doing this well can become costly (training, issue management, security and verification, etc.). Once the business considers this, they sometimes decide to pause or go back to the drawing board on their new project plans.
3. Uncovering new requirements that fundamentally change the nature of the original goals of the project
We are large advocates of taking time early in a project to consult in what we call Discovery. Whether you work using Agile, Waterfall or other iterative or fixed methodologies, the team should sit together and look at the future solution, goals and constraints as a whole before looking to tackle the detailed delivery. Doing this allows everyone to understand and check that everything that has been requested is considered in scope for the short or medium-long term of the new solution.
While this proves very useful, it also can sometimes stall a project because this exercise unearths some fundamental challenges that cause a re-evaluation of project elements, or in some cases, the entire project. While this is the intention of this Discovery exercise (as you want to try and find this out before you start work), it causes project delays.
What we have seen work well is where clients provide a high-level view of their existing solutions. This should include any background (bullet points) on how or why it has evolved in the way it has, to help set the context for a future solution. What doesn’t work well is a generic checklist of “future requirements” of a platform or solution provider without any context of why the business is looking for this, or what has stopped them from having these features in the current platform.
4. There isn’t a clear and defined strategy
We find many replatforming projects start out from a purely technical standpoint e.g. the current solution is unreliable and needs continuous bug fixing. When an RFP is sent out, the technical requirements for the new platform are clearly listed and providers are asked to give costs to implement the defined list of features.
However, often what has not been defined is the overall strategy or goal of the project. This means replatforming projects can fail to progress because the business doesn’t see tangible benefits or what return the investment will provide.
Be sure to map out the wider benefits and goals of your project and include these with your business plan, so stakeholders can quantify the reasons to replatform beyond just the technical aspects of the software.
5. Haven’t involved all stakeholders
Previously an eCommerce replatforming project involved a relatively small group of business stakeholders. Now, because of the scale and complexity of these projects, a far wider stakeholder group from across a business is involved. This breadth of stakeholder inclusion is a vital component of the success of these more complex projects.
When advanced discussions have progressed regarding new projects, and parts of the business are only hearing for the first time that things are happening that will impact them, they have put large pauses on the project. This can sometimes trigger a complete re-evaluation of the business case, budget and goals.
A good project Discovery will help highlight parts of the business where a project will have a major impact that hasn’t already been identified.
6. Key stakeholders leaving
Keeping to the same topic of stakeholders for reason #6, we have found that the start of the project suddenly comes to a stop when a key person leaves. While the vision and drive to change may initially come from a single person, if a project stalls when someone leaves, it indicates that the wider business hadn’t really bought into the project. They were happy for the individual to drive it, rather than have the whole business behind it because they believed it was right.
The key thing here is honesty. If the person leading the project shares with us upfront they may be a “lone wolf” trying to reshape the ideas of the business, we can help them to bring more stakeholders on the journey. This is often an issue of culture, which is something for another day and another blog!
7. Incumbent technology provider and partner “lock-in”
As we are in a fast-moving industry, clients rely upon technology vendors, agencies and system integrators like us to help and deliver solutions to their problems. But in many cases, the overall in-depth knowledge of those solutions remains with these partners and is not transferred to the business. So when it’s time to find out what the business wants in their “new world”, or how it does things today, and how it may be impacted in the future, there is a large reliance upon the existing providers to be involved. This can prove to be difficult as the incumbent’s involvement, as per its definition, typically means they are coming to the end of their relationship.
This can be usually dealt with by a few implicit and explicit actions. The first thing is that the business needs to remember that it is “their” solution. Taking ownership means embracing the solution and ensuring there are key individuals who are involved in running the platform and roadmap. Other specific actions include ensuring the vendors are always providing continued access to their relevant documentation, providing specific documentation related to your specific customisations and ensuring who owns the intellectual property of the solution.
In many cases, particularly where the business has engaged with a vendor who is partner-led (as in, they allow partners to deliver their platform rather than having to rely on the vendor’s own technical delivery teams aka as “closed vendor environments”), they tend not to find this issue. The technology will have many partners, meaning the client is not locked in and can pick and can change partners without the need to change technology.
We have also witnessed instances where the incumbent starts to add-in many exit fees, expensive engagement fees or plainly don’t make themselves available to assist, as ways of trying to frustrate the process. This creates knowledge and budget challenges that can bring new projects to a halt. We have experienced instances where clients have had to keep the project a secret so they do not feel the wrath of the incumbent. We advise against this. The incumbent is a stakeholder due to the evolution of their relationship and needs to be part of the solution moving forward, including having their services transitioned away.
8. Complete misunderstanding on what was asked for early in the process
As an expert agency and systems integration in the commerce space, we have gained a wide breadth and depth over many years. However we understand that many businesses haven‘t had the luxury of the same exposure as us. This can lead to large, fundamental gaps in their understanding on digital commerce and operations. This is fine. We don’t expect clients to know everything, but sometimes clients need to trust the experts. It is, after all, what we are here for. But this can stall a project as a client starts to understand how things work and the impact that will have on their assumptions, goals and constraints of how their new future will look.
9. Setting unrealistic deadlines
When a business decides they want to replatform, they usually want to do this as quickly as possible. In many cases, this is to try and swiftly demonstrate ROI, but it can also be to put the key stakeholders at ease about the decision they have just made. However, going too quickly can also cause projects to stall due to the business itself not being able to keep up with its ambitions. We have had a number of businesses come to us over the years as they know we have a reputation for delivering projects quickly (find out how we delivered a new website for British Home Stores on SAP Hybris in just 7 weeks).
When we then tell them, “we can move very fast, but we need to have the following things from you: requirements in a bit more detail, the systems we have to integrate to, the people to test and learn the new system, etc.”, it suddenly dawns on the business that they may not be able to move as fast as they think. This then creates dwell time as they consider the resources, time and effort the business needs to free-up to start the project, which in the excitement of making a decision to do this, was overlooked.
Conclusion
There are of course going to be times when it makes sense to delay a project. Where it’s better for the business to take the time to recalibrate and get all its ducks in a row, rather than push ahead to the detriment of the future success of the project. But I hope that by sharing some of the most common reasons why we see eCommerce projects stall it can help others in the early stages of planning help keep their projects on track.
