ReThink Productivity Podcast
In this exciting podcast, Simon Hedaux from ReThink Productivity shares his insights and strategies for improving productivity and efficiency in the retail and hospitality industries. With the help of clients, partners, and the ReThink team, Simon covers everything from measuring and tracking productivity to developing and implementing effective strategies.
Whether you're a business owner, manager, or employee, this podcast is a must-listen for anyone who wants to learn how to get more done and improve their bottom line.
Here's what you can expect to learn:
- How to measure and track productivity
- Proven strategies for improving efficiency and reducing waste
- How to create a culture of productivity and innovation
- Tips for motivating and engaging your team
- Real-world examples of how other businesses have used ReThink Productivity to achieve success
Don't miss out on this opportunity to learn from the experts and get ahead of the curve with your own business.
ReThink Productivity Podcast
Insights from WH People: Mastering Tech Project Success
Focusing on the fundamental aspects of successful tech implementations, we explore the importance of team composition, data readiness, and fostering change within organizations with Paul Karnowski founding partner at WH People
• Importance of having a dedicated project manager
• Effective data preparation is crucial for success
• Need for quick decision-making and transparency
• Emphasising collaboration between vendors and internal teams
• Cultivating an organisational culture that embraces change
#theproductivityexperts
Register for the 2025 Productivity Forum
Find us in the Top 50 Productivity Podcasts
Connect to Simon on LinkedIn
Follow ReThink on LinkedIn
Welcome to the Productivity Podcast. This is the second in our mini-series with our friends at WH People, and I'm delighted to be introducing a returning guest, Paul Konoski from WH People, one of the founding partners. How are you doing, Paul?
Speaker 2:Yeah, I'm doing great, Simon. Thanks for having me on.
Speaker 1:Good, you're back again, in a slightly different guise this time. So do you want to give us a bit of an update on remind us about your career and a bit of update about how you landed?
Speaker 2:at wh people, absolutely, and apologies for those that have listened to the previous episode that I was on and I've heard this before, but my name is paul kernoski. I have been in this sort of hdm, wfm, payroll tech space for over 15 years now and in that time I've held various roles i've've worked in operations, I've worked in implementation, I've worked in product development and I've also worked on the sales side of organizations. Recently, in mid-2024, after a stint at an organization called Dayforce, running their team of solutions consultants for EMEA, I decided to stop doing that because the business is as good as it is, and go into partnership with two of my ex-colleagues, wendy Muirhead and Helen Steele, to form a little consultancy called WH People and we offer things like assisting organizations in navigating the global payroll and workforce management market and we do also do tech and process performance coaching and support.
Speaker 1:Amazing, and Wendy did a detailed intro into WH people in episode one, so feel free to for people to go back and listen to that. And today we're going to talk about how to have or land successful tech projects. So I'm sure you I'm sure you've been involved in many of those in your career, paul, in terms of Dayforce and the stuff you're doing now We'll work through kind of some points I know you've got in your head, but let's say we've got our organization, organization X, that we both work in, has bought a new tech solution. It could be anything but something that's tech. Where do you kind of start in your head in terms of laying the foundations for a successful project?
Speaker 2:Yeah, so, and you're right, I have you know, from various different perspectives. Over the course of my career I've been involved in quite a large number of technology implementations, from sort of being right at the coalface doing the work and pressing the button, through to managing the projects and then through to sort of seeing them from the outside. And really what I was going to try and focus on here is a number of things that might sound super basic or like no-brainer, but you'd be surprised at the number of times that I've seen one, a few or all of them missed by organisations, because quite often, particularly for sort for smaller and medium-sized enterprises they don't necessarily do this every day. The people that are doing these technology implementations aren't in their day jobs, so sometimes things that might appear obvious to people that sort of live in this world day to day can be missed by those organizations. So I was just hoping to call a few of those out.
Speaker 2:So I think in a lot of cases, the first thing that you really need to be thinking about is what is the makeup of your team going to look like when it comes to implementing these projects, because you will have people that have a day job.
Speaker 2:They won't necessarily be working full-time on this project, so you have to plan out how those people are going to be able to find the time to do what they need to do in order to get this project over the line.
Speaker 2:Excuse me, but I do also think it's important from an organizational point of view, as much as possible to mirror what the, the vendor or the implementation team's governance structure is going to be. So if the implementation team's a project manager and what's being lead, you could have a project manager and work families noway in lead. Now I think for work-stay in lead, that's potentially okay if those guys also have a day job, but I do think it's really, really important for you to at least have a dedicated project manager on that project who doesn't have a day job and can focus entirely on making sure that that project goes smoothly, that you're hitting your plan, that you're making your deadlines and everything's being delivered when it needs to be. Often I've seen in my career organizations that thought they could get away with not having a project manager on their side and I've often seen that cause issues and delays and actually delivering the project and it is that.
Speaker 1:I mean, some of that comes down to cost, doesn't it? I get people are managing budgets and stuff, but it always feels a bit perverse if you tech solutions generally aren't cheap and I'm making a broad statement there and shoot me but um, there'll be a significant investment in a tech solution, so to then kind of fall internally by not putting the right resource on feels like a bit of a known goal yeah, absolutely.
Speaker 2:I couldn't agree more. And not only that. You know I think most organizations that have lived that would agree that the the cost of overrun, slippage, things going wrong, is likely to vastly exceed the cost of just putting a project manager into it to manage all of that sort of stuff. And, and to your point, not only is tech solutions not from a cash point of view. Once this is in, it's likely something that you're going to be living with for three, five, ten years. So it's really important to dedicate the right amount of resource up front so that you're not constantly having to go back and rework or implement workarounds because you can't get things over the line on time. So, whilst that cost of a project manager might not seem essential to some organisations, I strongly believe that it is.
Speaker 1:Okay, so team make-up. Point one where do we?
Speaker 2:go next.
Speaker 2:So I think another really important thing to get on top of as early as possible and in my view, you should be trying to get on top of this before you even sign a contract with any provider as your data preparation for data migration and also for ongoing integration. I don't know what your experience in this is, simon, but particularly with workforce management solutions, and particularly if you're doing things like labour optimisation or forecasting, the amount of data that needs to be migrated over is pretty significant, and so I think, as an organization, you need to be thinking really, really early. What is that data? What format am I going to require? And I would always recommend that you try and get things like data migration templates, integration specs and all of that sort of stuff prior to even signing any contract.
Speaker 2:Now, a lot of vendors, I think, may not be particularly keen to give you that, and I think the reason for that is sometimes they feel like it makes it look scary when they present you for a massive Excel spreadsheet of data migration requirements, but that's just the reality of doing these types of projects, and so there's a lot of time involved in working out how you're going to get that data. What's this? What current systems that data needs to come out of? Can you get that data yourself, or will you need to involve some of your other partners or vendors, or potentially even the provider that you're moving away from? Is that provider going to put up roadblocks? Are there going to be any additional costs associated with getting that data out? And so that, in my experience, is something that I have seen derail or delay projects on numerous occasions is the inability of the customer to present the required data in the required format in a timely fashion, and that is just going to delay your project and I think there's also a recognition of clean data as well, isn't there?
Speaker 1:So the actual? It sounds simple. Let's use workforce management. Give me two years EPOS data by store by 15 minutes. You'd think is relatively simple. Providing the data I think most people have probably got an angle on now of getting it out of their systems. But that data actually being usable and clean, when you think of all the events that go on maybe system outages, hangovers from issues, it issues becomes a lot trickier when you start to get into the detail.
Speaker 2:Yeah, absolutely, and, as you say, that's really important. I think it's important to understand how clean your data is. If it's not clean, what sort of actions can you take in the receiving system, deal with any anomalies that might be present in the data, if you do feel to identify and cleanse them? Because what you don't want is to get a certain period of the year following your implementation and, all of a sudden, your forecast are way out of whack because the the data that you input from the previous two years had some anomalous data in it.
Speaker 1:For whatever reason, yeah, okay, so point two, then data preparation. Where do we go next?
Speaker 2:So another thing that I think is really, really important and there's sort of two points here that are almost merged into one, I think is decision-making and pragmatism when it comes to these types of projects.
Speaker 2:So I think that the first thing that I would say is it's important, I think, as a customer, to understand or recognize that no amount of arresting questions, requirement specifications, software demonstrations, discussions prior to getting into the project no amount of that is going to capture everything, and all of the vendors that you're speaking to, they're going to interpret those requirements and questions and RFP questions in the way that's going to make them look the best. I'm not saying that they're going to lie to you, but they're certainly going to interpret things so that they can give the most positive possible answer because they are interested in getting you to purchase their products. So when you do get into the nitty-gritty of the project, what you're going to find is that there are going to be different interpretations of how things work. There's going to be different interpretations of how certain things are achieved, of how certain things are achieved. The technology that you've selected may be able to achieve your requirements, but it may not be able to achieve the requirements in exactly the way that you thought that requirement was going to be achieved, even though, ultimately, that requirement is going to be achieved. So I think there's a few things that are really important for organisations to recognise and also to be able to do throughout the life of the project to ensure that you're able to keep moving forward. So I think it's really important for everyone to remain pragmatic and work as one team towards resolving these types of issues and to be able to come to a solution that everyone can sign off on and is able to move forward on.
Speaker 2:And one of the things that I've certainly seen a few times in my career is, if the relationship with you, between the customer and the implementation team, slash, the vendor becomes adversarial and it becomes like an us and them sort of situation that is going to negatively impact your project, and I have seen that happen during my career, where people are no longer working together to get to a solution, but they're sort of siloed and there's an adversarial relationship and there isn't any open communication anymore, and that just causes all kinds of issues going forward. The other thing I would say is I do think it's really important to have people that are able to make decisions involved in the day-to-day running of the project. For example, every single decision that has to be made needs to be passed up and down a chain of command, or every single decision that needs to be made needs to wait for a monthly steering group in order to be resolved. That is going to have a significant impact on your project timeline.
Speaker 2:Now, particularly for things like a workforce management implementation, there are some fairly big decisions that could affect your employees or your workforce that should have been made up front. What you what? The other thing that you don't want to do is get into weeks or months into your implementation and then realize you need to go and have an extensive consultation with HR or whoever else it might be in the organization before you can sign off on some particular decision that needs to be made. But that all, I think, needs to be considered upfront and as early as possible as well. What's your thoughts on that one, simon?
Speaker 1:Yeah, I mean like, like you, I've seen organizations get stuck in treacle where it's, you know, in in a demo, you told us it could do this, or in the requirements. Here's what you answered in black and white and and it, like you say, it's interpretation is it? I've seen examples of vendors saying yes to something and it's delivered by a report and then the client's dissatisfied or thinks that it's not been a conversation that's been clear or documented well, because they didn't think it was a report, they thought it was delivered by the system. Yeah, absolutely.
Speaker 1:It's tricky, right? Because, like you say, you can spend an eternity trying to belt and brace an RFP and procurement. You know, procurement want one part and technology want another and operators want something else, regardless of what type of system you're procuring, and it can be death by a thousand cuts in that process to then find out that, yeah, somebody can do it, but the interpretation is it's delivered in a different way than you thought. So it's never perfect. I think, yeah, if you get to that stage where you're kind of pulling out the RFP and showing it to somebody saying this is what you'd have answered, you probably need to sit and regroup and everybody take a breath and say right, we are where we are. How do we implement this? And both parties understand more. To get a solution because it probably comes on to your last point everybody's got to be able to bend and change a little bit and be flexible, otherwise it's a.
Speaker 2:It's a relationship which is based on a black and white contract or document with no context yeah, and I do think sometimes it can help I think, particularly from a customer point of view to understand almost the different motivations of the different people within a vendor organization that you're going to be dealing with.
Speaker 2:The people that you're talking to prior to signing the contract, they're motivated to get you to buy their software.
Speaker 2:They're going to answer everything, not necessarily incorrectly, but in the way that reflects best upon the technology that they are trying to sell you, and that's their motivation and that's just the reality of it. And then when you get into the actual project yourself, you tend to be talking to a different set of people within the organisation. They probably haven't answered the RFP questions and their motivation is to get your project implemented as quickly as possible to an acceptable level of quality and then move on to the next project that they've got coming up. So there's very different sets of motivations of different people or different areas of the vendor or your implementation team organization that you'll be dealing with and sometimes when you're talking to, when you're in the project and talking to the implementation team, it helps to understand that that team that you're talking to is are probably not the people that gave that answer to the RFP question that you think they've interpreted incorrectly, and so it's important to be able to understand that and work as a team to move forward and get over those challenges.
Speaker 1:Yeah, and there's always a win-win. I think in most of these. I've never really seen an example where it's caused somebody to terminate a contract or whatever. I've seen it cause examples where it slowed things down or caused big frustration moving forward. But ultimately there must be a win-win in the middle, because interpretation grayness isn't great, um, but actually the fact that somebody said we can do it must mean there's a way forward agreed and I think the more pragmatic and the more sort of, the more of a sort of one team look that you have in those circumstances means you get to that resolution and you get to that way forward a lot more quickly than if you start off from a sort of he said, he said perspective and assume that you're not working together as one team yeah, agreed, okay.
Speaker 1:So we've got, we've got a good team, we've got good data, we've got some decisions that are being made other than the big ones, kind of locally. Rather than um protecting the kind of project length, we're being pragmatic. Where do we go from there? Or what's the? What's the kind of cherry on the cake?
Speaker 2:so I think the last one and I think this is a really important one and is willingness to change for an organization. So I think it's very easy, first of all for the people that are at the cold state of the implementation actually doing the work, to sort of lose sight of the vision of why the organisation wanted to initiate this change in the first place. But, excuse me, one of the things I often used to tell customers is that you wouldn't be making this change if the way that you were or are doing things was good enough or satisfactory. The reason that we're doing this project is because what came before needed to change. But I do think sometimes there's a lack of almost top-down communication from the sort of high-level decision-makers who understand that we need to make this change for these reasons. Sometimes that's not communicated strongly enough all the way down the hierarchy, and so the people that are actually doing the day-to-day work don't understand the goal that they're working towards.
Speaker 2:And I do think that often the easiest default fallback position for people is we'll just continue to do it the way we've always done it. That way we're getting through the days. It might not have been perfect, but we can just continue to do it the way we've always done it that way. We're getting through the days. It might not have been perfect, but we can just continue to do it that way and that's quite often not the best way to approach these things.
Speaker 2:And I do think that it's important and I and I genuinely think this comes from the top as well it's important that everyone in the team needs to be willing to make those changes, to accept practices, to accept the way that the technology that they've purchased produces the results that they need.
Speaker 2:They need to be willing to adopt new processes and the likelihood is there is a few sort of sacred cows for people that will need to be killed along the way and it might be painful for some people to accept. There might be a period of adjustment in order to make those changes and really embed in those changes and communicate those changes and ensure that everyone's on the same page with them. But if you go through all of that expense, effort, pain and time to implement a new technology solution and you end up just doing everything exactly the way you did on your old technology, you've kind of defeated the purpose of undertaking that project at all yeah, agreed, and um, I think it's interesting how, yeah, people revert to putting a new system in and wanting it to work the way the old system did.
Speaker 1:Back to your point when. Why have you changed it then, not having back to your first point? In that team makeup, people that are responsible for the change, because you, there's different skill sets isn't there. You've got your project managers, you've got your solution specialists, you've got your data specialists, you've got your operational specialists, but also you might need some input from hr, depending on on that to manage change. But also people that are going to communicate the change and help deploy the change. So it's back to some of that, the project setup. But, yeah, just a taking a system out and putting a system in. If you end up with the same result as you had before you took it out, you're back to questioning what the motivation to change was, absolutely and I think you make a really good point there, actually, about the team makeup, simon, as well.
Speaker 2:I think one of the most overlooked things when it comes to these types of projects is the organisational change management. It's often if you implement a new technology but you get no engagement with it nobody uses it then also, what was the point? It's really important, I think, to ensure that from the very start of the project, throughout the life of the project and beyond, these sort of changes are communicated and managed consistently and positively throughout that entire process. Otherwise, you're going to get to the end of it, but only the people who are on the project team are actually going to understand what you've done and why you've done it, and the wider organization isn't going to have any visibility or knowledge or understanding of what you were trying to achieve by by doing that.
Speaker 1:Yeah, absolutely okay, so kind of five structured points there before we kind of close, any other final closing thoughts you'd like to share uh.
Speaker 2:The only final closing point I would say is sort of subjective, personal is that there always comes a point during these types of projects where they're like projects involve pain, they just do implement projects. Technology implementation projects just do involve pain. And there always comes a point where you think to yourself is this really worth it? Are we going to get to the end of it? But as you say, simon, there's always, you always do get to the end of it. But as you say, uh, simon, there's always, you always do get to the end of it. The important thing is to try and get to the end of it as painlessly, as quickly and efficiently as possible and end up with the best possible results excellent wise words and if people want to pick up with you, paul, to get in touch, have a further conversation.
Speaker 1:Where's the best place for them to find you?
Speaker 2:oh, please reach out to me at paul at wh-peoplecom, or you can just go to our website wh-peoplecom and fill out the contact form in there and we'll get right back to you cool, and I'll put a link to your linkedin profile in the show notes as well, so if people want to get in touch that way, they can hook up excellent brilliant.
Speaker 1:Well, that's number two in our mini series with our friends at wh people. Number three will be helen, and we'll be talking about changing culture. So thanks for coming on again, paul, great to catch up, and we'll speak soon thanks, simon.
