Episode Summary
.
Migrating to an existing system
In this episode, Laurence advises companies looking to migrate to a new system, describing the process and risks that can occur if a company is closed off and protective about their existing products. ACF’s technical team are able to create a lot of helpers and wrappers to try and migrate data / integrate processes, transmitting data through processes like APIs.
.
Limitations of self-building products
In our discussion, Simon explains the positives of choosing off-the-shelf products, with real life examples sprinkled throughout the episode. Here are some key takeaways:
-
- Issues of scale – The reason why self-building could provide problems is due to the limited testing that businesses are able to do. Off-the-shelf products provide years of experience reducing unknown risks and developing core data security.
“These days it’s quite easy to write a software platform on a small scale, with proof concept as you test the idea… but if you’ve taken it from one store proof of concept to 3000, then you’ve got many issues of scale”
.
- Issues of scale – The reason why self-building could provide problems is due to the limited testing that businesses are able to do. Off-the-shelf products provide years of experience reducing unknown risks and developing core data security.
-
- Simple Integrations – Off-the-shelf can help you deliver a successful product as seamlessly as possible, while the technical teams can also make the product as similar as possible, transmitting data through APIs or processes.
“Solutions should be simple to integrate, with the team needing to keep the skill set on board continually. We aim to remove the road-blocks ourselves as opposed to the client changing their processes”
.
- Simple Integrations – Off-the-shelf can help you deliver a successful product as seamlessly as possible, while the technical teams can also make the product as similar as possible, transmitting data through APIs or processes.
-
- Maintainability – Maintaining the same team is crucial to your project flourishing, giving you regular updates and improvements that can remove bugs or vulnerabilities. Off-the-shelf products give you the reliability and security you need to remove significant disruptions and expensive overhauls.
“If something is written years ago, no one would really know how it works and everyone is too afraid to touch it in case it gets broken”
.
- Maintainability – Maintaining the same team is crucial to your project flourishing, giving you regular updates and improvements that can remove bugs or vulnerabilities. Off-the-shelf products give you the reliability and security you need to remove significant disruptions and expensive overhauls.
.
Need an off-the-shelf product? Explore the options now.
.
Project Stories
In this episode, we dive into Simon and Laurence’s most memorable stories, from companies that had to be beeped out, memories of travelling to sites with servers in the back of cars and having to get a train from London to Manchester because of company placing printer paper upside down into a kiosk!
.
To find out more about Simon and Laurence, check out our full episode – available on all your favourite channels. Now including YouTube!
.
This article summarises podcast episode 103 “How to Deliver Large-scale Technology Projects” recorded by CX Insider.
Written by Octavian Iotu
Full Episode Transcript
.
Octavian: Welcome back to the CX Insider Podcast. Today we have a very special episode lined up for you. This week, we thought we would give our sponsor, ACF technologies, the opportunity to tell us a little bit more about the work that they do. We’re going to be talking all about project deliveries, the importance of stakeholder and account management, whether you should use off the shelf products or self-build and much, much more. With Simon Ronald, VP of business Development and Technical Director, Laurence Leach. Enjoy the episode and if you do, subscribe to our YouTube channel for more episodes. Now let’s get into it.
Octavian: Do you enterprise projects scare you?
Laurence: Not anymore.
Simon: Not anymore, no.
Simon: The size of the contracts scare me slightly because there’s a lot of reading and you can’t miss a single thing. You’ve got to analyze it for absolutely everything. But other than that, no, no, we’re quite natural at it now, aren’t we? I think we prefer it. They’re easier to structure. They’re easier to work with companies when they’re working at scale, because they’ve had a lot more thought process put into obtaining a budget of that size.
Laurence: We’ve worked up to this over quite a few years now, starting off with small projects and growing our knowledge and expertise and, uh, skill base. We’ve worked our way up to delivering big enterprise projects quite successfully now. But it didn’t just happen overnight. It’s been a long road.
Simon: We went from one location queue management in 2008.
Laurence: Local authority was it?
Simon: It was Hull City Council. Was it to now on every single high street and 44 million people have gone through o`ur product.
Laurence: 100 million appointments.
Simon: Yeah that’s crazy. So yeah. So no do they scare us now? No. I think it’s just what we do. That’s what we’re good at.
Octavian: So what is the difference between defining success of a smaller project and an enterprise project?
Simon: Larger projects tend to have quite well defined KPIs, like targets on what they want from the project, and they tend to be a smaller list of target kind of achievements that they want to do. What benefits do you want to deliver to the business? It may be something broad, like improve the customer experience, but then in that there are actual numbers that big companies want, reducing no show rates for customers. The bigger the company gets, the bigger the return on investment is. If you can reduce the number of no shows.
Laurence: Quite often a smaller business is looking at buying a product for something, whereas a larger enterprise is looking at buying change, if I could describe it that way. So they’re looking to implement change and your product just happens to help them do that. And so naturally the goals are slightly different and the success criteria are slightly different as well. Often with a smaller project, delivering the product is the success in itself, where with a larger enterprise product, there is a whole web of other things surrounding your delivery of that product that needs to fall into place. Change management throughout the business, communication to all of the stakeholders, many, many integration points and data points as well that all need to go with that. And that all gets wrapped into that success. Whether or not you deliver your product successfully or not. All of those other things have to work as well.
Simon: It could be something as well. The success could be deemed as the delivery of the project because some companies are migrating from existing providers. So it might be that our gauge of success is we’ve helped them migrate from an existing system to our platform seamlessly so that customers and users didn’t even notice it happened in the background.
Laurence: Yeah, yeah, that’s a good point. Larger, more enterprise businesses have to manage their change much more carefully because they’re such a large number of stakeholders and dependent systems involved in that. So they kind of want to minimize the apparent change as much as possible, because it’s quite hard to get buy in over a large user base to change where a smaller business can adopt change a bit more quickly. So you can throw in a new product, a new approach. Simon. With enterprise deliveries, often the business has the opportunity to self build a solution. What would you say are the benefits of taking off the shelf product compared to self building?
Simon: Yeah, with our enterprise customers, that’s nearly always the case in that they’ve trialled their own proof of concept internally to prove that there is a requirement from the customers, or that there is a benefit to the business. The reason that I see those projects don’t work is just the idea that they need to produce a product now that scales from the small POC they did, because these days it is quite easy to write a software platform on a small scale, on a proof of concept, deliver it quite cheap and test that the idea works. But then the problem comes when you want to take it to your entire network. So if you’ve taken it from one store proof of concept to 3000, then you’ve got all sorts of issues of scale. That’s where buying off the shelf really benefits you because they’ve done the performance testing, the surge testing, the at scale system tests that you need. Their core data security issues have been resolved. If you buy a product off the shelf. All of those initiatives have been worked on for for years and years and years in your particular area. And the other thing that I think as well is that all solutions should. Be really simple to integrate with each other these days as well. So off the shelf now is becoming, I think, a more viable option than it is to build in-house.
Laurence: Yeah, there’s a maintainability as well. So with an in-house built product, although you can often kind of change that product quite quickly, you need to keep that skill set on board continually, and you need to have a team to develop that going forwards. Often you’ve heard in a company that there’s an old Excel spreadsheet that someone wrote back in, back in the years ago. No one really quite knows how it works, and everyone’s afraid to touch it in case it gets broken. But obviously with a off the shelf product, there is an external team that manages that and that develops it, that supports it, maintains it going forwards, and it’s just down to due process of that enterprise business to make sure that they do their research into choosing the right enterprise products.
Simon: And I like talking about risk as well. When you develop a product in-house, you’ve got unknown risks. When you purchase a product from a supplier that’s been working on that for so many years, you’re reducing the risk. When we deliver projects, there are risks. There always are risks, and things always go wrong. That’s one thing you’ve got to realise. There are no simple enterprise software deliveries that can be delivered without any problems. And that’s the one thing that we always talk about here at ACF is we know what could go wrong with projects at scale. We’ve delivered so many projects at scale that 99% of the problems that we hit, we’ve hit before. There are some that are new. Obviously, Laurence will probably talk about them. There are new problems that we hit, but because we’ve hit so many of them, we’re reducing your risk, guiding you through what could go wrong. And then if that goes wrong, we clearly know what the pathway is to fix that problem and building something in-house. You are putting that delivery, I think, slightly at risk. We all want to sleep well at night. We don’t want to be kept awake with the projects that might not go live in the morning because something went wrong. So for our mental health, it’s quite nice to know that we’ve hit most problems out there and we know what to do to fix them. When you deliver these projects at scale, these large enterprise projects, what keeps you awake most?
Laurence: Like you mentioned in a previous answer, any problem that could come up, we’ve probably encountered that problem beforehand from our first little projects where there was bugs and network problems and things like we’ve been through that and we know how that works now. To enterprise projects now, where often the problems are now to do with stakeholder management and buy in and things like that, because the product is tried and tested. We’ve been through that and it works. There have been sleepless nights. I guess there have been periods where you’re concerned about how this delivery is going to go, but we’ve got an experienced team, we’ve got a heritage behind the product and the knowledge in house. So I think everybody is a lot more confident in their abilities. Reassured. We’re pretty good at identifying the risks that we might encounter going forwards and mitigating those before they come up. So I think we sleep pretty well these days. We’re not kept awake too much. It’s always the day before go live. Is everything going to work? But that’s more of a concern for smaller projects. For enterprise projects. It’s already been working for weeks internally in test environments, even in a production environment, it just hasn’t been pushed out to all of the users so far.
Simon: That’s a good point as well, isn’t it? And something that I strongly recommend to anybody who’s procuring a bit of software and interacting with the supplier, you need to ask them what could go wrong. Where are the risks? We you know, of course we plan for success and we know which parts are going to go well, but you really need to be asking your suppliers, what am I at most risk of? What do I need to mitigate against? What problems are going to keep me awake at night?
Laurence: Yeah it needs to be a collaborative thing, a partnership. If you’re buying in a product that is an enterprise product, there’s two companies meeting of minds here and meeting of expertise. And you need to share that expertise, share that knowledge and collaborate on what this delivery is, not just demand. You need to deliver this product and put it in. You need to ask them what their expertise is and say like you say, what could go wrong? What are my opportunities as well for going forwards with this?
Simon: Going back to the risk, I think there was only one thing that kept me awake at night we delivered a nationwide project, we had to deliver it at speed. And when you do that, clearly we know some issues still exist when you go live, but some are acceptable. You can leave, some are unacceptable and are showstoppers and will delay a go live. Sometimes you know of tiny little minor issues that exist and you need to get this product live. And there was one moment I was quite happily working in a gym listening to, I think it was the Prime Minister’s questions or First Minister’s Questions, and they asked about one of the small issues that we had. It was minor. It was fixed very quickly. Everyone knew it existed. But just in that moment, I didn’t expect to see one of our projects being discussed on TV, which is a great thing because we’re now delivering projects of that significance.
Laurence: That was an interesting time period to delivering that project because it was delivered very rapidly, but also continually over the period of, what, six months or so. And we would be putting a change out into the live system. And then a few days later, it would be discussed on television to say, oh, you know, now our system is capable of doing this or capable of doing that.
Simon: Which comes on actually to the collaboration, because, as you say, we rapidly deployed a project nationwide that everybody knows about. But what people don’t realise is in the background we had what was there was three teams of people. There would have been us at ACF, there would have been the customer and there would have been another infrastructure company, actually Microsoft as well. And what people don’t know is in the background, a team of people were forced together that didn’t know each other. ACF knew what our product is clearly, but the teams at Microsoft and the teams at the NHS didn’t know what products you’re forcing teams of people together that are going to have to collaborate, they’re going to have to work well, they’re going to have to deliver together in a short space of time. It’s everything that goes against the normal delivery. You’ve got a super tight deadline. You’ve thrown people together that don’t know each other, you’re running to a budget and more importantly, it has to go live on a certain date. There was no choice on that one. That moment in time. A lot of respect for the teams of people that did collaborate, the technology teams that did work together because it did go live on time to budget and it worked really well.
Laurence: What you raise there highlights the importance of stakeholder management, which is something that becomes more and more important in an enterprise project. It’s less about the technology and the product, and more about the expertise identifying the people who need to talk to each other, work with each other. Because if you can’t get those people on board, or you can’t identify who needs to talk to whom, then the product is going to be a lot more challenging to deliver.
Simon: That goes back to what we were talking earlier about. What do we deem as a successful delivery? And the risks that we handle from ACF includes what Laurence just said, the communication. I always describe it as we understand the culture of teams that are delivering- as ACF, we get dropped into so many different cultures, ways of working, political environments, stakeholders. So we’ve instantly got to understand the culture of the teams that we’re working with. What’s their driver? How do we do that? That’s a massive key thing that we do is understand even how teams within our customers talk to each other, because that’s different across every industry, isn’t it? Yeah.
Laurence: It’s funny. It’s funny because we have worked with so many businesses. Now, when you look back on the things we’ve encountered about how the businesses work, you know, some of them are well-oiled machine. Some of them we’ve come in and no one’s talking to anybody, and we’ve had to try and pull in a team from different groups to say, right, you need us to do this, but you need to work together as well with us on this.
Simon: If you are out on the market going to a supplier looking to adopt their technologies, you’ve got to understand everything that we’re talking about here. Can you communicate with them? Do they understand how to communicate with you? Is their product right? Is the future right the roadmap right. Technology delivery, delivery plans, the risks? You’re going to talk to them about all of those things. You have to understand from a supplier before you even consider signing a contract with them.
Laurence: And it’s probably worth talking to that supplier about their knowledge and experience on working with businesses from a personnel and stakeholder and communication point of view as well, not just the product or technology they’re delivering, because they can help you form those teams and identify the communication channels that need to take place, I guess.
Simon: What do you think end customers worry about when signing a contract with a new supplier?
Laurence: They’ve signed it with the right supplier.
Simon: I think you’re right.
Laurence: That’s one of the big things. Have they signed it with the right supplier? Have they made the right choice?
Simon: Some companies just go to RFP with documentation and select a provider from the documentation and maybe one demonstration. So yeah, that’s I find that a huge risk. We have won lots of projects like that with companies. But I still find that quite amusing that we filled out a document and had one hour demo session where they’ve then selected us. Yeah, but you’ve not asked us about anything we’re talking about today. This is kind of crazy. Yeah.
Laurence: And sometimes we’ll have a project where we have spoken to the commercial team, and then the project gets signed, and then we start talking to the technology team, and they’re actually kind of adverse to this project, and they don’t really want to be making a change or have a new supplier coming in. So then you have a challenge there. You know, you’ve been signed by the commercial team, and the technical team haven’t really been told much about it. So now we have a new issue that we have to convince the technical team. You talk to commercial team. We need to get everybody on board to deliver this successfully. So one of the.
Simon: One of the high street customers that we’ve got, I hated it at the time, but we had about 6 or 7, two hour sessions. They yeah, they drilled into everything. I kind of joked that they knew what color underwear I was wearing because they wanted to know everything, and I hated it at the time, and they kept calling us back for another session. You sort of pulling your hair out, but we’ve now been with them for. Seven, nearly eight years. What we’ve delivered is truly amazing. And I looking back, I do realize actually that’s probably the one time we’ve gone through an effective procurement.
Laurence: I remember those sessions, I remember traveling, we went to branches all over the country with various stakeholders looking at the process, and I think they were looking at the process themselves. You know, they have a business process that they have defined of how their branches need to work. And then they were going to those branches and finding that’s not how it works at all. And it was quite a revelation for them as well, and discovery process for both of us to then kind of, you know, work. How how are we going to deliver this change our product to these branches, get everybody on board, considering we have such a wide variety of ways of working just across your own branches, that was that was quite interesting. I thought that.
Simon: That particular project, we were selected from a group of around eight potential providers, but they were they were deliberately chosen suppliers, um, all of a certain size. And they, they didn’t want to go to tier one providers because they knew that tier one providers would potentially be writing the project in the background. They would say they have the product, but be writing it in the background. I guess my question from that is really the size of the supplier. Does that matter? Because there’s so many good start up companies now. There’s so many amazing software products now from start up companies who probably aren’t being given a chance because their start up companies, you’ve got to cross a boundary, haven’t you? I remember when we started ACF, the fact that you’ve got to demonstrate that you’ve got a reference customer in the same industry to prove that you can deliver this one to. Somehow we overcome that one. I guess the question, Laurence, then, does knowing what you know about technology now, does the size of the supplier matter? Do you have to go to one of the big companies if you’re an enterprise organization?
Laurence: No, certainly not. Certainly not the the one thing you’ll get with a larger enterprise supplier is some stability and some depth to their pool of resource and stuff like that. But a smaller supplier is agile, is faster, can be quite hungry as well to deliver. You know, they’ve got something to prove. And as long as you do your due diligence on finding a supplier and analyzing them, how they work as a supplier and not just the product that they have, then it can be a really successful kind of procurement and relationship. I think you’ve got to you’ve got to ensure that they’ve got some history, some heritage, and they’ve encountered all of those problems such as networking, security, understanding of risk, all of those sorts of things. And that’s one of the hurdles that a smaller supplier probably has to learn and overcome. And that just comes with time. I think you don’t have to be big, but you have to have experience.
Simon: And we found out recently don’t go to [unnamed company] because they don’t really do very good software platforms.
Laurence: There you go exactly.
Simon: Even if you give them 100 million, they can’t write products without a bug in it.
Laurence: So we we have delivered. Yeah, we have delivered a system that is as big, maybe bigger than what [unnamed company] delivered and in the five years it’s been running, it hasn’t had any major problems like that.
Simon: And we might want a soundbite that doesn’t potentially put us in litigation in.
Laurence: Yeah. With the word [unnamed company]. Yeah.
Simon: As we know right now, there is a major tier one provider that we all know has failed to deliver a platform.
Octavian: We’ll beep the name out.
Simon: Just beep out [unnamed company]
Laurence: With a black box over his mouth as he says it.
Simon: But it is true. I think that and that’s one of the smart reasons, I think, that the customer we’re talking about didn’t want to go to a tier one provider, wanted to come to a smaller, smaller supplier. And at the time, I think we had maybe 2 or 3 other high street organizations. So we we had the pedigree to deliver. I think that that’s exactly one of the things they were looking at, our operational capacity to support an organization of the size that they were. So yeah, we weren’t a small company, but we clearly had the right procedures in place to satisfy that we would deliver this without a resourcing issue. Being a small company and we did.
Laurence: Mhm.
Laurence: Yeah. And kind of going back to your point, there have been plenty of other enterprise deliveries from large businesses that have gone wrong. You know, there’s been lots of other scenarios where they’ve been in the news where something doesn’t work, whereas we’ve delivered and it does work. So it doesn’t really come down to the size of the company.
Simon: What’s the worst thing that’s gone wrong for you?
Laurence: The worst thing.
Laurence: In a project delivery.
Laurence: Yeah. Worst thing that’s worst thing that’s gone wrong in a project delivery is PII data. So personally identifiable information data either concern that there has been a breach or concern that something’s been corrupted or been lost. Those are the moments that keep you awake because now you’re dealing with real people, real data, and you have to really quickly jump on and address the problem. If a system goes down and it’s not working for people, that is. A severe issue that’s causing a lot of inconvenience. But often businesses have processes that they can make do in a short time whilst that gets repaired. But if you have any concern of security breaches or anything like that, those are the things that keep you awake at night, making sure that that isn’t going to happen. Those things are why we’ve chosen to work with other experts in the industry, like Microsoft, for this project. To make sure that we have, we outsource some of that knowledge to others that have expertise on board to make sure these things don’t happen.
Simon: That’s a great comment, actually, isn’t it, because we the amount of support that we’ve got from Microsoft has been genuinely really good over all of our projects that we’ve ever done. And as you’ve just said, we’re not just kind of experiencing our risks and potential issues that could occur. We’re also getting that from other providers such as Microsoft along the way. Yeah, which is a huge benefit, isn’t it?
Laurence: Yeah.
Laurence: I mean, we are we’re experts in our product. And you know, we are experts in in the field and where we deliver our product as well. But we are also wise enough to know when we need to outsource skills to other businesses and bring them in. We’d love to be able to do everything ourselves, but sometimes that’s not the right thing to do. And you need to bring in others.
Simon: There are other providers out there better than us at X, so we’ll go and use them such as yeah, hosting Microsoft, which is kind of I think quite a key thing isn’t it, from us and our point of view, it’s, you know, the idea that it’s not just our platform and our software now that’s being tested on a huge scale, will select other providers along the way that have done the same. So, you know, you’re kind of reducing risk in that way. And for me, I sleep perfectly well at night. Now, I didn’t historically because my problem contractually with big organizations is they put things like service credits into contracts, which they should do, absolutely should do, because that then forces us to commit to 99.5% uptime and system availability. Historically, that kept me awake because infrastructure was nowhere near as good as it is now. You know, Microsoft’s ability to keep uptime and scale and autoscale, I’m kind of from that generation where when my first ever web project I did, if you wanted a web server, you had to buy a server and install it in a rack. Now you’ve got this crazy idea that you can click a button and it will auto scale. So for me, the biggest problem that I had, which still does kind of- it pops into my head occasionally when I read a contract. I still look for service credits around system availability and I don’t need to anymore. It kind of makes me laugh that we don’t need to, because the relationship we have with Microsoft, the product that they’ve got and the way that we’ve tested our product now, up to one of the projects being 44 million people, 150 million appointments, means that the only thing that kept me awake doesn’t anymore. Yeah, like.
Laurence: Like you say, the first projects we ever did was traveling to site with a server in the back of a car, installing it, cabling it up ourselves, and crossing your fingers hoping that nothing would go wrong once you’ve left. And if it did, you’d be in the car back up driving again to go fix it. But now, with pretty much instant on demand raising of servers and things like that from cloud providers.
Simon: That still blows my mind.
Laurence: It’s amazing. And I remember we were one of the early, fairly early adopters of kind of cloud computing and Azure and things like that. We analyzed quite a lot of providers, and when it first came on board, again, you had to kind of build a server yourself. And yes, it was virtualized, but you had to ensure all of the redundancy and integrity was put into place yourself. But we’ve we’ve been through that. We know what makes a good server and hosting setup. So now we can put together solutions and things like that that are robust and secure and scalable very quickly because we’ve been through it before and we’ve say we’ve discussed these things with Microsoft or whoever it might be to say, how do we do this properly? What’s the correct way of doing it?
Simon: And my funniest problem with the project was I once had to get the train from London to Manchester to help a branch put printer paper into a kiosk because they kept putting putting it into the kiosk upside down.
Laurence: Yeah, and it wouldn’t print.
Simon: Thermal. Thermal. Yeah. Thermal paper prints on one side. Yeah. And they couldn’t do it over the phone. And so yeah, I literally got on a train from London to Manchester to turn a bit of paper roll around.
Laurence: That was Simon’s worst project.
Simon: That’s how lucky I’ve been.
Simon: That’s my worst one. No, that was my funniest one. Yeah. Laurence, how do we help enterprise organisations deploy? As we all know, they do most if they follow a standard model, do a proof of concept or say, 5 or 10 branches and then deploy to a thousand, 2000. How do we help organisations do that and minimize risk?
Laurence: Uh, stakeholder buy in is one of the first steps you need within the business. Because we’re delivering this change, we need to make sure that everybody is comfortable with what that change is, and it’s going to work for how they understand the business is going to use it. And then once we do that, we need to. Make that change as straightforward and simple as possible. So for example, we have our product. It’s an off the shelf product that we can deliver. And it has its own look and feel as you would expect. But a simple thing that we can do to make that change easier to adopt is to update the color scheme, update the logo, change some of the styling so that when users start using it, it feels a bit more familiar to them with the other corporate products they’re using small things like that that can actually make a really big difference. Obviously, there is some dependency within the business for those stakeholders to do that, train the trainer approach or whatever it is. We can’t train all users, end users individually because there may be thousands or tens of thousands of them. So we take that train the trainer approach and it’s it’s ensuring that we have a really good subset of voice of the customer, I would say. So all of the users that we’re going to deliver this to get a really good subset of them and make them champions of change, make them keen to work with this new project, this new product, make sure that they understand it as well as possible, and bring them on board so that they can be that train the trainer approach and drive that forwards.
Simon: I like that approach. The champion of change from users adopting the software. In my head, it’s 2024. The amount of time you spend training users on IT software systems should be reducing. Right now. We should be able to deploy systems one day where we can claim zero training required. You just deploy a piece of software and it goes. We know that’s not the reality right now, but yeah, getting your users on board with a bit of a marketing piece before so that they’re excited about this change, getting them to understand that this change is to benefit either them or them and the customer or just the customer. But somewhere you need to tell and educate staff, the users, ultimately, that this is a change that’s going to benefit the business. It’s going to improve something, it’s going to improve your workday or it’s going to improve the customer. I think when you’ve got an organization of scale, you can kind of lose sight of the user and ultimately your staff who are serving customers are your biggest and most important asset. Really.
Laurence: I think you’re not. Just delivering a product, but you need to be proud of what you’re delivering as well. For example, there may be some people working within branches who don’t particularly like working with technology. They’d rather not use technology. And like you say there, you need to work with those kind of users to try and help them understand that this is going to benefit them, it’s going to benefit their customers and so on, and listen to their concerns. This is why you need, like a wide range of voice of customer across all of your user base. So don’t just take the people who are willing to work with the product and the change. Try and find those that really don’t want to work with your product and listen to their concerns and be proud of what you’re delivering. Maybe you need to make some changes. Adapt what you’re doing so that it makes their transition for that change easier. You know, don’t just drop it on them and walk away.
Octavian: So what role does an account manager play after the initial delivery?
Simon: What’s worked very well for us is maintaining as many resources on a project as you can. So whoever’s there from the beginning should be there through not just the sales process and commercial side of it, but through the project into delivery and into go live and as long as you can, if possible, the role of the account manager that really works well with us is one that’s involved from the very beginning, first contact with the customer, potentially through to identifying requirements with the project teams, one that knows and understands the contract and can translate from potentially project teams to dev teams through to maybe a commercial discussion, something that’s in a contract somewhere. So it’s kind of like the- I see an account manager as someone in the middle who knows just a little bit about everything. They know enough about the requirements to find the person that the customer needs. They know enough about the contract to discuss changes with the legal team. They just know a little bit about everything. And if you can keep and maintain the same account manager on a project, I think it just benefits and flourishes. Ultimately, the projects that I’m always involved in, from an account management perspective, I always say from the outset, I’m accountable.
Simon: That’s what that means during the initial stages. If I say something that our products can do and then we get to go live and it can’t do that, I’m still there and accountable. That was me that sat there and said that. So I should be the one that is held accountable for that. And that makes me super conscious then as an account manager, to make sure that just the process is being followed. I mean, Laurence talks to the dev teams about stuff that I don’t understand, but my job is to follow up with the dev team to make sure that the communication bit works. Like we mentioned earlier, understanding the culture. So I’ll go to the dev teams to understand that what Laurence just said to them, do you get it? And I’ll probably document what they agreed. It might just be a short email to say, this is what you agreed, because my my thoughts are that even basic email communications should form that contractual tie between us. So yeah, I think an account manager is super important and yeah, should be involved as long as possible.
Laurence: Yeah I mean there’s a good communication within the business. So you’re doing the account management side and you know enough about the product to be able to ask the right questions and give the right responses to the customer. But you also know. From my side. I know a little bit about the sales side, so we can have a good discussion and I can convey that to our development teams. That requirement, all the way from the original business requirement through to fairly technical requirements, without really losing too much of what the original gist of that was. And we have good communication within the business so that you know what we can deliver, what we can’t deliver.
Laurence: Yeah.
Simon: And I you know, more importantly, I think as well is just my ability to go and find the person to answer the question from the customer and say instead of there and just sort of um-ing and urr-ing or saying, can I come back to you as some sales and account managers do, I know where to go to get the absolute expert to answer that question, to give the customer the confidence that we have got these experts behind the scenes. So, Laurence, what advice would you give to customers that are migrating from an existing system? What advice would you give to a company that’s looking to do that?
Laurence: To try and be as open as possible? You don’t want the approach of being closed and protective about your existing product. Sometimes we have encountered that where they don’t particularly want to tell us about the outgoing product. Maybe that’s through sensitive commercial reasons, I don’t know. But really, to make this work, they have to be as open as possible so that we can explore the sort of data we’re going to be bringing in, the kind of processes we’re going to be integrating with, to help us plan to make it as smoothly and easy to to do as possible. We are there to help, you know, we’re there to deliver our product and to make this a success. And we’re there to help. So the more we know about what your current landscape is, the better we can plan that change and make it as seamless as possible. That would be my first point, I think.
Simon: And I guess it goes back to what we said earlier, that will allow you to list out all of the potential risks more comprehensively.
Laurence: Again, it comes it comes down to finding the right people as well. So no doubt there’ll be someone within the business who is a product expert, champion of that outgoing product, and it’s good to talk to them. It’s good to talk to them, to say, you know, what are what are the things that you need us to keep in mind? What are some of the positives and negatives of this product or process that you’ve got that we can either ensure are there or can improve upon when we deliver ours? Because ultimately, you’re choosing a new product to try and get some improvement and benefit out of that. The more, the more we can know about how the business currently works, the better we can do that. I think obviously there’s a big technical side to these things as well. So our our technical teams are real experienced in this sort of thing, and we create a lot of helpers and wrappers to try and migrate data and to integrate processes. We’re willing to to go that extra mile to try and make it as like for like as possible, often with transmitting data through APIs or processes and things like that.
Laurence: If you’re going to a new product, they’re they’re different, you know, different technology, different processes and things like that. What we have learnt is to try and change some of our APIs so that they match what’s currently there, or change some of our product interfaces. They match what’s currently there to make that transition almost plug and play. We’re aiming to remove as many roadblocks to this project as possible. If we can use our technical teams to overcome some of those roadblocks, we will do. Rather than asking our client to change their processes. And they’re already changing a product. So it’s even more difficult for them to say, can you change your processes and change your technology and networking stack as well? Because we’ve got new product that doesn’t work that way. That’s a big ask to do that as well. We pride ourselves in being quite an agile company, I think, and so it’s probably easier for us to change some of the things that we’re doing to make that change and transition more straightforward.
Octavian: And that concludes the end of the episode. Thank you to everyone for listening. I’ve been Octavian and I hope you’ve enjoyed the conversation. Let us know what you think by carrying on the conversation on LinkedIn. This episode has been brought to you by ACF technologies global leaders in customer Experience Management solutions. Now let’s get into some quick fire questions. What is both of your favorite holidays that you can think of?
Simon: Well, just come back from Scotland in the Mull of Kintyre. And I’ve never been that in the middle of nowhere in my life or at night time. All you could hear was your heartbeat in your ears because there was nothing. It was absolutely middle of nowhere. So at the moment that’s fresh in my mind and I can’t wait to go back.
Laurence: It’s not even favourite holidays, but favourite memories from many different holidays. I’ve got ones like that going to Kansas, standing out and Kansas is flat as anything you can see for miles, and driving from the airport to stay with my relatives and you could see tornadoes on the horizon.
Octavian: Damn!!!
Laurence: Like not just one multiple tornadoes forming on the horizon, just that flat. And you can see that that far.
Simon: That must have been quite a childhood excitement.
Laurence: That was that was pretty cool.
Simon: Did you get the urge to drive towards one of the tornadoes?
Laurence: No, but I’ve seen those.
Laurence: Tornado chaser programs. And those guys are quite brave. So that’s that’s one interesting memory from a holiday.
Octavian: Have either of you got any 2024 New Year’s resolutions?
Simon: I failed mine really quick.
Simon: Really, really quickly, really quickly because I love going to the gym and the plan was to go to the gym every day in January and is now 17 days in. I’ve been three times I did and in my head I was dedicated to it. But then family.
Laurence: You’re just a stereotypical gym drop out story, aren’t you? Basically, I’m going to get fit in the new year. No. That’s it January. You’re done.
Simon: I was hoping to join the hordes of people that turn up just for January and then never go again.
Laurence: So my plan, my plan. I’m also gym for the new year. But my plan I started in November, so I didn’t appear to be one of those oh, I’ll get fit for January and the new year. I started in November and I’ve kept it going, so I-
Octavian: Started it early.
Laurence: Resolution get fit, live longer.
Octavian: Have you been going consistently now.
Laurence: Reasonably? Yeah, yeah, 2 or 3 times a week. So it’s not too bad. Okay. I’m over Christmas and New Year’s. A bit of a break and pause because you’re stuffed full of turkey. You can’t really get on.
Laurence: Yeah, a cycle machine full of turkey.
Laurence: But, um, yeah, since then.
Octavian: Simon, you’ve said that you’re going to a football game with Brentford. Who are you guys playing against?
Simon: Nottingham Forest this weekend.
Octavian: Okay. Have you got any predictions for that. Because this is gonna come out afterwards. So we’ll see how your prediction.
Simon: Oh that’s a good one.
Octavian: Ivan Toney’s back isn’t he. He is back.
Simon: I was going to say one all.
Laurence: I was gonna say one all.
Simon: Brentford seem to do particularly well against top teams and not so well against the teams at the bottom. Not saying Nottingham Forest, are a bottom team.
Laurence: I am slightly, I am slightly, yeah. No, no I’m.
Simon: Not apologizing to forest fans. That’s is your problem. Yeah I’m going to go one all. And I think it’s going to be a bit of a bottom fight for Brentford this season. But I just love being there. It’s great fun at a football match.
Laurence: Yeah, I I’ve recently moved to Weymouth and over Christmas I went to see Weymouth versus Dover and these guys are below Vanarama National League as far as I know. They’re like League Six or something like that. I couldn’t believe the quality of the football. It was really, really good. I was expecting some Sunday League type stuff. It was fantastic, really good quality football. So, you know, over the last 20 years or so, the standard quality of football has just trickled down throughout the leagues, and even lower tier teams are doing Ronaldo style dribbles occasionally. Yeah, it was really impressive.
Simon: You were seeing Ronaldo and Messi style football at Weymouth.
Laurence: Yeah, maybe over hyping it a bit, but I hope you’re not. I’m gonna I’m going. I was.
Laurence: Really impressed.
Simon: That’s it. Me and you were going to a game. Now I want to see this. This.
Octavian: We’ll have to see what it’s like.