Understanding common issues & risks
Home » Podcast library » Replatforming advice » Understanding common issues & risks

Understanding common issues & risks


This episode is focused on the common issues & risks that teams face when going into a replatforming project, how they can be managed sensibly and avoided wherever possible. Key discussion points:

  • Why replatforming projects have risk.
  • Planning considerations for projects.
  • The importance of understanding contractual obligations.
  • Putting a sensible governance structure in place.
Read the full podcast transcript

James: Hello and welcome to the second episode of the re:platform podcast. Today we’re talking about common issues and risks associated with replatforming, something we both feel quite passionate about because no project is 100% perfect and it makes sense to understand where it could go wrong up front and plan for that effectively. So we will talk about what risk is and why you need to face up to it. Burying your head in the sand does not help anybody. All it will do is push the problem further down the line, which normally ends up snowballing and costing more. Then we’ll discuss planning considerations. What can we do to ensure projects are set up well? We’ll also touch upon contract structure and its impact. Paul made a really good point to me earlier about some of the issues he’s seeing when people don’t even think about contract structure, what’s the impact of how a contract is defined?

James: And then we’re going to finish up with good practice for governance, those principles that help keep a project on track. So first and foremost, why is a replatforming project complex? And why does it come with risk?

A couple of key things. A replatform involves technology, people and processes and all three of those can add complexity. When you have people in the mix as well, you have people with different viewpoints, different experiences, and in this way politics creeps in and you have to be able to manage that. These projects also involve complex technology, lots of different people with diverse stakeholder needs from that tech, so it’s not ever 100% plain sailing. That’s why risk and issues occur. That’s why you need to have a decent planning process and understanding of what the common risk are and how you can mitigate them. That might sound daunting. That’s just the reality. And you’ve got to understand the reality when looking at these projects. The good news is that with sensible, proven project management controls, you can identify, mitigate and manage risk. So now’s quite a good time now to hand over to Paul. You’ve got a lot of experience around these projects and have seen certain commonalities amongst all of them. So what, what in your mind are the most common issues and what creates them? What things can people do about it?

Paul: Yeah, absolutely. So I’ve seen different types of risks going into replatforming and budgeting and it tends to differ dependent on the size of business and how the business is structured. So from a kind of hands on perspective, I think one of the biggest risk areas is SEO, which I think it’s probably a good thing for us to talk about a bit more later. But that to me has been one of the biggest areas where a project has been deemed a failure or at least short term when traffic and revenues dropped. And the project is then looked upon in a negative way as a result of revenue dropping. I think cost is also a big one. And it’s always going to be a big one. So how costs are structured, setting expectations as early in the project as possible, making sure that budgets are set and they’re realistic as well.

And cost models need to broadly cover all of the different areas of replatforming and not just the build cost or the licensing cost. For me, the biggest challenge is Discovery. So this is the area where I’ve seen projects delayed or again, considered in a negative way as a result of the initial definition not matching up to the actual scope of the project or certain areas of the project not being scoped out properly. And when there are big gaps in terms of the scope, whether the project is on a T&M basis or fixed scope, one party will always lose out and depending on how big that area is, it can have a really big impact on the success of a project or even the delivery of a project at all. So they’re probably the ones that have impacted me the most.

James: Yeah, that makes perfect sense. And I think the Discovery or the project initiation phase is something that’s often underestimated by clients who haven’t been through it before. From your experience, what are some of the techniques people use to make sure what Discovery delivers quality outputs instead of just somebody sitting in the meeting room talking about requirements and documenting everything under the sun and thinking that that’s the job done?

Paul: I think there are different sides to that. The main Discovery, in my opinion, should be led by an agency. And I think it’s important for an agency to really kind of structure the areas and topics based on how they’re going to deliver. And then it’s important to have different skilled people in the room from that perspective as well. So most of the agencies that I’ve seen deliver a project on budget and on time have had a certain level of technical input in the room from the start. They’ve had a good business analyst or solution architect kworking on the both the back end and the front end considerations with the client. It’s a lot more of a broad conversation rather than just kind of saying this is how it’s going to look, or just looking at the front end for example.

I think it’s important that a client is fully invested in Discovery as well. So a lot of the time when a discovery hasn’t been as effective, It’s because certain stakeholders aren’t involved in the process and they’re one of the biggest drivers of change requests further down the line. Or it’s the people have kind of rushed Discovery because they’re too busy or certain people have been too busy to attend certain sessions. And I think it’s really important that the Discovery is seen as the most important part of the project. A lot of the time the client will try and bring down the cost of but I think this is when you need to flush everything out and the client benefits from a really detailed spec; they can then refer back to it and say this is how we want it to be delivered.

Insufficient detail in a spec impedes the project. So it’s key to allocate enough time and have the right people fully invested.

James: Yes, I couldn’t agree more. Often people want to rush ahead, save a few thousand pounds during Discovery, which often causes loads of issues later on because they might not have thought out requirements in sufficient detail to help developers set things up in the way they want to, which then adds more cost retrospectively to fit back in. Sometimes it actually pays two to divorce the Discovery costs and agreement away from the main contract. And have that as a separate piece of work and a letter of intent because then if you discover anything bad during the initiation process where the choice of partner might not be right and they might not be able to deliver what you want, then you’re not committed to an onerous contract. Instead, you’ve got your learning and that learning can be taken across to somebody else and the cost and effort isn’t a write-off.

So lots of valid points thanks Paul and it ties in with some of the other things that I’ve seen. One of the key challenges for me is I getting a board level sponsor. So this is the ownership piece. If you don’t have a single board level sponsor, and I mean single not multiple people, there’s no clear escalation path and no final sign off or ownership. That’s so important because if you don’t have executive support, it’s so hard to get things over the line, especially if there’s a change in budget or any change in scope based on what you’ve learned through a complex discovery process.

Paul: Yeah, getting the complete scope of deliverables is essential. Completely agree with that because when you get to UAT, user acceptance testing, how on earth can you evaluate the platform fit for purpose and readiness if you don’t know what you’re evaluating it then becomes a case of, “Oh, it looks nice”, rather than it functioning, delivers what is needed and what’s committed to in scope. You often get a compromised go live as a result of that.

James: Having an unrealistic timeframe is also an issue. I’ve seen this too many times. People rush to get things done. It’s like; “We want to be live by January”. There’s often no business critical need, it’s an arbitrary date, so there’s nothing such as the old platforms becoming obsolete and revenue is compromised. Instead it’s an internal random desire of “We want to be live by January” and they’ll compromise the project in order to get there.

One of the challenges facing a consultant is to get people to relax, calm down, and think through what’s most important. Is it the January deadline or is it the scope? Is it the budget? What is driving that fundamental decision? Sometimes waiting a little bit more means you get better quality outputs, which is more cost efficient in the long run. Instead of suddenly having to allocate more budget to fix the things you didn’t think about properly.

And my absolute favourite is personal bias, where somebody says something like, “I love Magento, it’s the best platform”, or “We had Magento in my last business, it was awful. It just didn’t work. We couldn’t do the basic things without pain and development”. You need to start rationalising the reasons. Ask why?

Because Magento in itself is a proven platform. Implementation is either good or bad depending on the quality of input from the client team, the budget of resource, the quality of the development partner. So sometimes it’s the right platform, but the wrong implementation. Other times it’s the right implementation, wrong choice of platform based on the business operational model. So you have to tease these things out. So all of these things need to be thought through in close detail. And I think the most important thing I’ve learned is always ask the “why?” question, don’t take things at face value. When people say, this happens or this is our process or this doesn’t work, find out why before you start making any assumption.

James: So next thing is planning consideration. So I’ll kick off a few things and then I’m interested in your thoughts as well. Paul. I’m a stickler for process. You know, I’m exceptionally dull really. But process helps. And what I’ve learned over the last 16 years is it pays to get people bought into a proper structured project from the start. Then there are no alarms or surprises and people work to the same tune.

There’s a few key things I’ll tease out I’d like your perspective on Paul. The first is get a project initiation workshop. So this is before you’ve chosen your vendor, your SI partner, before you even get down to the point of doing detailed discovery. Get the project team from the client in a room and explain what the project is, what the scope is, who’s involved in terms of stakeholder, what their responsibilities are, what the work streams, how you deliver it and turn that into a really simple high level brief that says this is our project, this is how we’ll deliver it.

Define the key milestones and circulate the information; get everyone bought in from the start. There’s nothing worse for a stakeholder than to suddenly be pulled into a workshop last minute when they have no idea what it’s about. Like no time to prepare and they’re chucked into a room just because they’re expected to be there because you haven’t thought through your communication properly. So set clear goals and objectives, also have clear metrics of success. Like how are you measuring success? Is it based on coming in on budget? Is it based on delivering the agreed scope? Is it based on protecting revenue?

Get all of this agreed up front, get the scope signed off. If you’re going to try to hit a fixed time frame and/or budget, you have to be really sensible about what’s realistic in scope. You can have an MVP minimum viable project which says that’s our phase one go live. That’s the minimum that you can go live with, there’s ways of chunking up the scope so you can actually deliver a comprehensive set of requirements without compromising the timeframe. You’ve got to think this very carefully and everyone’s got to buy into it. Then you’ve got to run the stakeholder interviews and the key thing here is get everyone briefed. Make sure people coming to them know why they’re there because if not, you’re wasting their time and you’re probably going to compromise outputs.

If you plan it well, get the right people briefed, ready to go, then you get much better quality and output. Once you’ve got those stakeholder demands captured, you can prioritize them. Then as a project team, you’re going to go to market to look at the platforms out there.

I use Forrester reports and Gartner Magic quadrants to help Clients understand the fit for purpose of key vendors. There are loads of articles out there, helping you compare platforms. Paul’s got some very, very good blogs that I’ve passed on to many clients over the years and they have found them invaluable reading, and there are lots of other consultants out there and agencies putting out good comparisons.

The next thing is to be very clear on how you can evaluate a vendor. If you go into a vendor demo with a simple, “Oh we want a new platform”, how do you pick apart what’s good, what’s bad? You should focus them on demo on the most important capabilities for your business. And you’ve got to have a clear process for evaluating vendors in those demos. If you don’t do that, then it’s completely subjective. So create scorecards, have clear criteria for scoring, brief everyone and get everyone comparing against the same criteria because then you’ve got a proper outcome you can evaluate.

The next thing for me is cost model as Paul alluded to earlier. Be clear on defining which elements are needed in a cost model. You need to think about not just the license fee and the cost of build, but also third party application costs, ongoing support, maintenance etc. Have all of those cost streams planned out and then work with vendors and agencies to fill them. Then you have a rounded view of costs. And even think about internal costs. Like do you need extra resource to service a new platform? Do you need more web admin people? Do you need a content manager who will add content and products?

So those are the key issued and challenges that I’ve learned to address. Is there anything different hat you focus on Paul in your project?

Paul: I think all of the points that you’ve made are probably the most important. You talked about the importance of a demo in showing different pieces of functionality to different people in the business. I think that’s really important. And the other thing outside of cost is time. We’ve talked about this a lot over the last couple of years. Do you require a third party that might actually involve a manual process or if a platform doesn’t have a market store capability and certain things need to be done manually in different ways, it’s also the time overhead and thinking about the cost to the business of that time. That is also then is part of a much broader cost of ownership analysis, which I know you’ve done a lot of in the past.

In terms of the scope of the build, I think one thing that I’ve learned over the last couple of years is the importance of a Phase two and constant prioritisation of features. And then I’m thinking about the benefits of pushing things into that Phase two. So I worked on a project a while back there and the agency had this concept of a ‘fast follower’, which is basically a number of sprints post-launch where they could push things into, but they promised that it would be prioritised over other work in the business. And they would be flexible in terms of delivering that and that was really valuable to the client. There are a number of things that the merchant would have been really hesitant to take out of Phase one, but actually it was delivered a month later and the build was a much easier process. And there was a much better end result for Phase one as a result of pushing certain things into Phase two. So that was a really positive experience that I’ve tried to bring into other projects since then.

You talked about objectives and setting expectations as well. It’s important to understand different people’s expectations of a project. So you talked about kind of people trying to rush a project for no reason. I think a lot of the time when I’ve seen people try to rush projects, it’s to get something live before a peak, which makes sense, but there are consequences. The other thing I’ve seen is people having really high expectations around the impact of a replatform project, which haven’t been addressed. So for example, I’ve worked with retailers where they thought their conversion rate was going to improve considerably just by replatforming and these expectations need managing.

The when it comes to launch, there’s little to no impact on conversion rate, unless the project is fixing known conversion killers. There’s a good chance you’re going to lose some level of organic visibility. But realistically the replatforming project is a technology project and it’s a long term project, not short term. This is going to drive additional revenue. And I think that setting that expectation internally is a really valuable thing to do as well.

And then lastly, in terms of planning, which James has a lot more experience than I do for big projects. I think some of the retailers I’ve worked with have this expectation that when the development agency delivers a project plan, that will dictate everything that has to be done. Whereas realistically I think the project team internally need to be very well prepared in terms of what they need to do around change management and content readiness.

If your internal team are handling any integrations as well, that shouldn’t be an isolated process and all of those kind of critical pieces of the project should be started up front. And then it should be a collaboration to ensure that it’s not just left down to the final stages. And that’s been something that has been really critical in projects that have been delivered on time and on budget for me. I worked on a big one in the US about a year ago and they had a really strong product owner for the replatforming internally. She did a great job of owning internal stakeholder management. She was basically just pushing every party to agree to timescales and then trying to bring things forward, managing risk. And that had a really positive impact on that project and it was the fastest project I’ve ever worked on for probably the biggest retailer. Her planning and control was a big part of that project success.

James: Excellent. The point about unrealistic expectations is so important for me. Managing expectations so that when you go love people aren’t questioning why it hasn’t fixed all the problems in the business. Often there are process issues. It wasn’t a technology issue.

We were talking about contract structure earlier. We’ll touch on it now, but we’ll cover this in much more detail in a future podcast because we believe focusing on total cost of ownership is important for client teams. Paul, I like the point you made earlier about contracts, that they can trip you up. The terms within the contract can have an impact on you in the context of when it costs you, how much it costs you. And often people underestimate how quickly costs become payable in a project.

And that’s one of the issues and risk; if you haven’t thought through the impact from a budget and a financial flow point of view, it can cause issues for your Finance team. When you suddenly say, “Oh yeah, that 50 grand we had to pay, now that’s actually up front”. This also relates to when the licenses become payable, are they payable up front in advance when his hosting is established because you’ve then got development environments live and therefore you’re incurring costs.

So Paul, what are the key things then that you discovered that people should be thinking about in terms of the risk or issue of not getting a contract nailed down?

Paul: So that point you made at the end I think is a really interesting one. I’ve had loads of projects where people haven’t realised when third parties are going to start billing. So for example, if you’re implementing a third party search solution, personalisation or user generated content, most of these tend to start billing when you start integrating. And that’s something that has been a big unexpected cost in the past. And with something like Shopify, you will need to sign the contract pretty early in the project. And again, that’s something that people don’t always factor in. And I think that’s yeah, really good area where people get tripped up.

In terms of the contracts, there’s a few things that we try to do when we’re working with a client e.g. do fixed scope, post Discovery.

So post discovery you would have a pretty detailed spec in an ideal world and you’d be comfortable committing budget against that. And then the development agencies should ideally be comfortable committing to a fixed amount of money for that scope. Given that they’ve done a big Discovery and they looked at all the third parties integrations, how things need to work on the front and back-end.

And again, I think that comes down to the importance of a detailed Discovery, that’s something that we’re both pretty keen on. I’m generally quite cautious with T&M work just because we’ve been burned in the past and to be honest it’s usually one of the biggest contributors to an agency relationship folding down as well.

The other one that we always try to do is have a big payment upon launch. And the reason for that is just because I think it’s important that the agency have some level of incentive for launching on deadline or at least for launching as soon as possible. And that’s been the way, the fairest way we’ve done it. I don’t necessarily believe in penalty clauses and things like that. I’ve seen people be paid bonuses in the past for delivering ahead of time or budget, which has worked quite well. But usually something like a 25% milestone payment upon launch has been a really good way. I’ve seen people do that.

James: Great, excellent points. The joys of time and materials planning where it’s an almost endless pot of development. So that brings us onto closing remarks.

From me, replatforming is complex and involves issues and risk, but you can sensibly manage them and put good project governance structures in place. As dull as that sounds, it’s actually critical. So just to recap on some of the key things: (1) Have a project initiation meeting and get a clear definition of what the project is (2) Get it communicated across key stakeholders (3) Make sure everyone involved knows what their role is and when they will be involved (4) Make sure that their managers are bought into it so that that resource is dedicated to the project (5) Put project management disciplines in place; even if you’re not an experienced and qualified project manager, there are simple things you can learn from other projects.

And I’ve done this, I borrowed off far smarter project managers than myself. So good example is a RAID log, which documents risks, actions, issues and decisions. So all it means is that every time you identify risk, you document it. If there’s an action documented, you know whom it’s allocated to. If you ever need to refer back to why a decision was made, you know what date it was made on, who made it. It removes loads of emotive discussion later on of he said, she said, I didn’t agree to that. It’s documented and everyone has visibility.

But you’ve got to ensure it’s visible to key project members. Don’t rely on emails; emails are the plague for big projects because they get buried down in inboxes. People are busy, they miss an important email or emails communicate to 40 people with no clear explanation of who needs to act. Ensure you use proper collaboration tools, whether you’re using a Dropbox or Jira, or whatever you use in your business to do it.

Just make sure there is a centralised place where anyone can follow discussions and contribute to them, share documentation and then have a clear escalation process as well. Things are going to go wrong but if you have an escalation process, you can manage it, nip it in the bud and do it sensibly and not let it derail the project. Effective project management is a critical capability. Take it seriously. If you do it right, you’ll get your people aligned with the project and the deliverables, you’ll minimise issues like scope creep because you’ll be on top of it and you have a process for evaluating what the impact is and making a decision and you have everything clearly documented.

So there’s always something to refer back to, to help you make decisions on the ongoing projects. So that’s my parting point. Always take governance seriously and learn from the mistakes other people make and help avoid them yourself.

Paul, what won’t be your parting words of wisdom?

Paul: I think it’d probably a similar point. I have seen projects fail where process and control hasn’t been put in place. And I think anyone doing a really big replatform needs to be really investing in stuff like that. If it’s a smaller build, you can probably get away without certain parts of the process. But I think if it’s a big project bring in an external, experienced consultant if you don’t have someone in-house. Someone that can independently pull together a steering committee and kind of put all of this kind of governance in place is really valuable.

James: So hope everyone’s felt that useful. As always, if you’ve got any comments or questions, feel free to hit us up on LinkedIn or Twitter and we hope you enjoyed it. Stay tuned for the next podcast!


Listen / Subscribe