May 4, 2025 • 21 mins
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
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
Welcome to the Productivity Podcast.
This is the second in ourmini-series with our friends at
WH People, and I'm delighted tobe introducing a returning guest
, Paul Konoski from WH People,one of the founding partners.
How are you doing, Paul?
Speaker 2 (00:15):
Yeah, I'm doing great , Simon.
Thanks for having me on.
Speaker 1 (00:17):
Good, you're back again, in a slightly different
guise this time.
So do you want to give us a bitof an update on remind us about
your career and a bit of updateabout how you landed?
Speaker 2 (00:29):
at wh people, absolutely, and apologies for
those that have listened to theprevious episode that I was on
and I've heard this before, butmy name is paul kernoski.
I have been in this sort of hdm, wfm, payroll tech space for
over 15 years now and in thattime I've held various roles
i've've worked in operations,I've worked in implementation,
I've worked in productdevelopment and I've also worked
(00:50):
on the sales side oforganizations.
Recently, in mid-2024, after astint at an organization called
Dayforce, running their team ofsolutions consultants for EMEA,
I decided to stop doing thatbecause the business is as good
as it is, and go intopartnership with two of my
ex-colleagues, wendy Muirheadand Helen Steele, to form a
(01:11):
little consultancy called WHPeople and we offer things like
assisting organizations innavigating the global payroll
and workforce management marketand we do also do tech and
process performance coaching andsupport.
Speaker 1 (01:26):
Amazing, and Wendy did a detailed intro into WH
people in episode one, so feelfree to for people to go back
and listen to that.
And today we're going to talkabout how to have or land
successful tech projects.
So I'm sure you I'm sure you'vebeen involved in many of those
in your career, paul, in termsof Dayforce and the stuff you're
(01:47):
doing now We'll work throughkind of some points I know
you've got in your head, butlet's say we've got our
organization, organization X,that we both work in, has bought
a new tech solution.
It could be anything butsomething that's tech.
Where do you kind of start inyour head in terms of laying the
foundations for a successfulproject?
Speaker 2 (02:09):
Yeah, so, and you're right, I have you know, from
various different perspectives.
Over the course of my careerI've been involved in quite a
large number of technologyimplementations, from sort of
being right at the coalfacedoing the work and pressing the
button, through to managing theprojects and then through to
sort of seeing them from theoutside.
And really what I was going totry and focus on here is a
(02:32):
number of things that mightsound super basic or like
no-brainer, but you'd besurprised at the number of times
that I've seen one, a few orall of them missed by
organisations, because quiteoften, particularly for sort for
smaller and medium-sizedenterprises they don't
necessarily do this every day.
The people that are doing thesetechnology implementations
aren't in their day jobs, sosometimes things that might
(02:55):
appear obvious to people thatsort of live in this world day
to day can be missed by thoseorganizations.
So I was just hoping to call afew of those out.
So I think in a lot of cases,the first thing that you really
need to be thinking about iswhat is the makeup of your team
going to look like when it comesto implementing these projects,
because you will have peoplethat have a day job.
(03:15):
They won't necessarily beworking full-time on this
project, so you have to plan outhow those people are going to
be able to find the time to dowhat they need to do in order to
get this project over the line.
Excuse me, but I do also thinkit's important from an
organizational point of view, asmuch as possible to mirror what
the, the vendor or theimplementation team's governance
(03:36):
structure is going to be.
So if the implementation team'sa project manager and what's
being lead, you could have aproject manager and work
families noway in lead.
Now I think for work-stay inlead, that's potentially okay if
those guys also have a day job,but I do think it's really,
really important for you to atleast have a dedicated project
manager on that project whodoesn't have a day job and can
(03:57):
focus entirely on making surethat that project goes smoothly,
that you're hitting your plan,that you're making your
deadlines and everything's beingdelivered when it needs to be.
Often I've seen in my careerorganizations that thought they
could get away with not having aproject manager on their side
and I've often seen that causeissues and delays and actually
delivering the project and it isthat.
Speaker 1 (04:19):
I mean, some of that comes down to cost, doesn't it?
I get people are managingbudgets and stuff, but it always
feels a bit perverse if youtech solutions generally aren't
cheap and I'm making a broadstatement there and shoot me but
um, there'll be a significantinvestment in a tech solution,
so to then kind of fallinternally by not putting the
right resource on feels like abit of a known goal yeah,
(04:41):
absolutely.
Speaker 2 (04:42):
I couldn't agree more .
And not only that.
You know I think mostorganizations that have lived
that would agree that the thecost of overrun, slippage,
things going wrong, is likely tovastly exceed the cost of just
putting a project manager intoit to manage all of that sort of
stuff.
And, and to your point, notonly is tech solutions not from
(05:04):
a cash point of view.
Once this is in, it's likelysomething that you're going to
be living with for three, five,ten years.
So it's really important todedicate the right amount of
resource up front so that you'renot constantly having to go
back and rework or implementworkarounds because you can't
get things over the line on time.
So, whilst that cost of aproject manager might not seem
(05:27):
essential to some organisations,I strongly believe that it is.
Speaker 1 (05:32):
Okay, so team make-up .
Point one where do we?
Speaker 2 (05:34):
go next.
So I think another reallyimportant thing to get on top of
as early as possible and in myview, you should be trying to
get on top of this before youeven sign a contract with any
provider as your datapreparation for data migration
and also for ongoing integration.
I don't know what yourexperience in this is, simon,
(05:56):
but particularly with workforcemanagement solutions, and
particularly if you're doingthings like labour optimisation
or forecasting, the amount ofdata that needs to be migrated
over is pretty significant, andso I think, as an organization,
you need to be thinking really,really early.
What is that data?
What format am I going torequire?
And I would always recommendthat you try and get things like
(06:19):
data migration templates,integration specs and all of
that sort of stuff prior to evensigning any contract.
Now, a lot of vendors, I think,may not be particularly keen to
give you that, and I think thereason for that is sometimes
they feel like it makes it lookscary when they present you for
a massive Excel spreadsheet ofdata migration requirements, but
that's just the reality ofdoing these types of projects,
(06:41):
and so there's a lot of timeinvolved in working out how
you're going to get that data.
What's this?
What current systems that dataneeds to come out of?
Can you get that data yourself,or will you need to involve
some of your other partners orvendors, or potentially even the
provider that you're movingaway from?
Is that provider going to putup roadblocks?
Are there going to be anyadditional costs associated with
(07:02):
getting that data out?
And so that, in my experience,is something that I have seen
derail or delay projects onnumerous occasions is the
inability of the customer topresent the required data in the
required format in a timelyfashion, and that is just going
to delay your project and Ithink there's also a recognition
(07:25):
of clean data as well, isn'tthere?
Speaker 1 (07:27):
So the actual?
It sounds simple.
Let's use workforce management.
Give me two years EPOS data bystore by 15 minutes.
You'd think is relativelysimple.
Providing the data I think mostpeople have probably got an
angle on now of getting it outof their systems.
But that data actually beingusable and clean, when you think
of all the events that go onmaybe system outages, hangovers
(07:49):
from issues, it issues becomes alot trickier when you start to
get into the detail.
Speaker 2 (07:55):
Yeah, absolutely, and , as you say, that's really
important.
I think it's important tounderstand how clean your data
is.
If it's not clean, what sort ofactions can you take in the
receiving system, deal with anyanomalies that might be present
in the data, if you do feel toidentify and cleanse them?
(08:25):
Because what you don't want isto get a certain period of the
year following yourimplementation and, all of a
sudden, your forecast are wayout of whack because the the
data that you input from theprevious two years had some
anomalous data in it.
Speaker 1 (08:41):
For whatever reason, yeah, okay, so point two, then
data preparation.
Where do we go next?
Speaker 2 (08:47):
So another thing that I think is really, really
important and there's sort oftwo points here that are almost
merged into one, I think isdecision-making and pragmatism
when it comes to these types ofprojects.
So I think that the first thingthat I would say is it's
important, I think, as acustomer, to understand or
(09:07):
recognize that no amount ofarresting questions, requirement
specifications, softwaredemonstrations, discussions
prior to getting into theproject no amount of that is
going to capture everything, andall of the vendors that you're
speaking to, they're going tointerpret those requirements and
(09:28):
questions and RFP questions inthe way that's going to make
them look the best.
I'm not saying that they'regoing to lie to you, but they're
certainly going to interpretthings so that they can give the
most positive possible answerbecause they are interested in
getting you to purchase theirproducts.
So when you do get into thenitty-gritty of the project,
(09:49):
what you're going to find isthat there are going to be
different interpretations of howthings work.
There's going to be differentinterpretations of how certain
things are achieved, of howcertain things are achieved.
The technology that you'veselected may be able to achieve
your requirements, but it maynot be able to achieve the
requirements in exactly the waythat you thought that
requirement was going to beachieved, even though,
ultimately, that requirement isgoing to be achieved.
(10:11):
So I think there's a few thingsthat are really important for
organisations to recognise andalso to be able to do throughout
the life of the project toensure that you're able to keep
moving forward.
So I think it's reallyimportant for everyone to remain
pragmatic and work as one teamtowards resolving these types of
(10:33):
issues and to be able to cometo a solution that everyone can
sign off on and is able to moveforward on.
And one of the things that I'vecertainly seen a few times in my
career is, if the relationshipwith you, between the customer
and the implementation team,slash, the vendor becomes
adversarial and it becomes likean us and them sort of situation
(10:54):
that is going to negativelyimpact your project, and I have
seen that happen during mycareer, where people are no
longer working together to getto a solution, but they're sort
of siloed and there's anadversarial relationship and
there isn't any opencommunication anymore, and that
just causes all kinds of issuesgoing forward.
(11:14):
The other thing I would say isI do think it's really important
to have people that are able tomake decisions involved in the
day-to-day running of theproject.
For example, every singledecision that has to be made
needs to be passed up and down achain of command, or every
single decision that needs to bemade needs to wait for a
(11:36):
monthly steering group in orderto be resolved.
That is going to have asignificant impact on your
project timeline.
Now, particularly for thingslike a workforce management
implementation, there are somefairly big decisions that could
affect your employees or yourworkforce that should have been
made up front.
What you what?
The other thing that you don'twant to do is get into weeks or
(11:59):
months into your implementationand then realize you need to go
and have an extensiveconsultation with HR or whoever
else it might be in theorganization before you can sign
off on some particular decisionthat needs to be made.
But that all, I think, needs tobe considered upfront and as
early as possible as well.
What's your thoughts on thatone, simon?
Speaker 1 (12:18):
Yeah, I mean like, like you, I've seen
organizations get stuck intreacle where it's, you know, in
in a demo, you told us it coulddo this, or in the requirements
.
Here's what you answered inblack and white and and it, like
you say, it's interpretation isit?
I've seen examples of vendorssaying yes to something and it's
delivered by a report and thenthe client's dissatisfied or
(12:40):
thinks that it's not been aconversation that's been clear
or documented well, because theydidn't think it was a report,
they thought it was delivered bythe system.
Yeah, absolutely.
It's tricky, right?
Because, like you say, you canspend an eternity trying to belt
and brace an RFP andprocurement.
You know, procurement want onepart and technology want another
(13:01):
and operators want somethingelse, regardless of what type of
system you're procuring, and itcan be death by a thousand cuts
in that process to then findout that, yeah, somebody can do
it, but the interpretation isit's delivered in a different
way than you thought.
So it's never perfect.
I think, yeah, if you get tothat stage where you're kind of
(13:22):
pulling out the RFP and showingit to somebody saying this is
what you'd have answered, youprobably need to sit and regroup
and everybody take a breath andsay right, we are where we are.
How do we implement this?
And both parties understandmore.
To get a solution because itprobably comes on to your last
point everybody's got to be ableto bend and change a little bit
(13:43):
and be flexible, otherwise it'sa.
Speaker 2 (13:46):
It's a relationship which is based on a black and
white contract or document withno context yeah, and I do think
sometimes it can help I think,particularly from a customer
point of view to understandalmost the different motivations
of the different people withina vendor organization that
(14:07):
you're going to be dealing with.
The people that you're talkingto prior to signing the contract
, they're motivated to get youto buy their software.
They're going to answereverything, not necessarily
incorrectly, but in the way thatreflects best upon the
technology that they are tryingto sell you, and that's their
motivation and that's just thereality of it.
(14:27):
And then when you get into theactual project yourself, you
tend to be talking to adifferent set of people within
the organisation.
They probably haven't answeredthe RFP questions and their
motivation is to get yourproject implemented as quickly
as possible to an acceptablelevel of quality and then move
on to the next project thatthey've got coming up.
So there's very different setsof motivations of different
(14:50):
people or different areas of thevendor or your implementation
team organization that you'll bedealing with and sometimes when
you're talking to, when you'rein the project and talking to
the implementation team, ithelps to understand that that
team that you're talking to isare probably not the people that
gave that answer to the RFPquestion that you think they've
interpreted incorrectly, and soit's important to be able to
(15:11):
understand that and work as ateam to move forward and get
over those challenges.
Speaker 1 (15:15):
Yeah, and there's always a win-win.
I think in most of these.
I've never really seen anexample where it's caused
somebody to terminate a contractor whatever.
I've seen it cause exampleswhere it slowed things down or
caused big frustration movingforward.
But ultimately there must be awin-win in the middle, because
interpretation grayness isn'tgreat, um, but actually the fact
(15:36):
that somebody said we can do itmust mean there's a way forward
agreed and I think the morepragmatic and the more sort of,
the more of a sort of one teamlook that you have in those
circumstances means you get tothat resolution and you get to
that way forward a lot morequickly than if you start off
from a sort of he said, he saidperspective and assume that
you're not working together asone team yeah, agreed, okay.
(16:00):
So we've got, we've got a goodteam, we've got good data, we've
got some decisions that arebeing made other than the big
ones, kind of locally.
Rather than um protecting thekind of project length, we're
being pragmatic.
Where do we go from there?
Or what's the?
What's the kind of cherry onthe cake?
Speaker 2 (16:16):
so I think the last one and I think this is a really
important one and iswillingness 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 theimplementation actually doing
the work, to sort of lose sightof the vision of why the
(16:36):
organisation wanted to initiatethis change in the first place.
But, excuse me, one of thethings I often used to tell
customers is that you wouldn'tbe making this change if the way
that you were or are doingthings was good enough or
satisfactory.
The reason that we're doingthis project is because what
came before needed to change.
(16:57):
But I do think sometimesthere's a lack of almost
top-down communication from thesort of high-level
decision-makers who understandthat we need to make this change
for these reasons.
Sometimes that's notcommunicated strongly enough all
the way down the hierarchy, andso the people that are actually
doing the day-to-day work don'tunderstand the goal that
(17:18):
they're working towards.
And I do think that often theeasiest default fallback
position for people is we'lljust continue to do it the way
we've always done it.
That way we're getting throughthe days.
It might not have been perfect,but we can just continue to do
it the way we've always done itthat 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 quiteoften not the best way to
approach these things.
And I do think that it'simportant and I and I genuinely
(17:39):
think this comes from the top aswell it's important that
everyone in the team needs to bewilling to make those changes,
to accept practices, to acceptthe way that the technology that
they've purchased produces theresults that they need.
They need to be willing to adoptnew processes and the
likelihood is there is a fewsort of sacred cows for people
(18:02):
that will need to be killedalong the way and it might be
painful for some people toaccept.
There might be a period ofadjustment in order to make
those changes and really embedin those changes and communicate
those changes and ensure thateveryone's on the same page with
them.
But if you go through all ofthat expense, effort, pain and
time to implement a newtechnology solution and you end
(18:24):
up just doing everything exactlythe way you did on your old
technology, you've kind ofdefeated the purpose of
undertaking that project at allyeah, agreed, and um, I think
it's interesting how, yeah,people revert to putting a new
system in and wanting it to workthe way the old system did.
Speaker 1 (18:42):
Back to your point when.
Why have you changed it then,not having back to your first
point?
In that team makeup, peoplethat are responsible for the
change, because you, there'sdifferent skill sets isn't there
.
You've got your projectmanagers, you've got your
solution specialists, you've gotyour data specialists, you've
got your operational specialists, but also you might need some
input from hr, depending on onthat to manage change.
But also people that are goingto communicate the change and
(19:04):
help deploy the change.
So it's back to some of that,the project setup.
But, yeah, just a taking asystem out and putting a system
in.
If you end up with the sameresult as you had before you
took it out, you're back toquestioning what the motivation
to change was, absolutely and Ithink you make a really good
point there, actually, about theteam makeup, simon, as well.
Speaker 2 (19:25):
I think one of the most overlooked things when it
comes to these types of projectsis the organisational change
management.
It's often if you implement anew technology but you get no
engagement with it nobody usesit then also, what was the point
?
It's really important, I think,to ensure that from the very
(19:46):
start of the project, throughoutthe life of the project and
beyond, these sort of changesare communicated and managed
consistently and positivelythroughout that entire process.
Otherwise, you're going to getto the end of it, but only the
people who are on the projectteam are actually going to
understand what you've done andwhy you've done it, and the
wider organization isn't goingto have any visibility or
(20:08):
knowledge or understanding ofwhat you were trying to achieve
by by doing that.
Speaker 1 (20:13):
Yeah, absolutely okay , so kind of five structured
points there before we kind ofclose, any other final closing
thoughts you'd like to share uh.
Speaker 2 (20:23):
The only final closing point I would say is
sort of subjective, personal isthat there always comes a point
during these types of projectswhere they're like projects
involve pain, they just doimplement projects.
Technology implementationprojects just do involve pain.
And there always comes a pointwhere you think to yourself is
this really worth it?
(20:44):
Are we going to get to the endof it?
But as you say, simon, there'salways, 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 tryand get to the end of it as
painlessly, as quickly andefficiently as possible and end
up with the best possibleresults excellent wise words and
if people want to pick up withyou, paul, to get in touch, have
(21:06):
a further conversation.
Speaker 1 (21:07):
Where's the best place for them to find you?
Speaker 2 (21:09):
oh, please reach out to me at paul at wh-peoplecom,
or you can just go to ourwebsite wh-peoplecom and fill
out the contact form in thereand we'll get right back to you
cool, and I'll put a link toyour linkedin profile in the
show notes as well, so if peoplewant to get in touch that way,
they can hook up excellentbrilliant.
Speaker 1 (21:27):
Well, that's number two in our mini series with our
friends at wh people.
Number three will be helen, andwe'll be talking about changing
culture.
So thanks for coming on again,paul, great to catch up, and
we'll speak soon thanks, simon.
Welcome to the Productivity Podcast.
This is the second in ourmini-series with our friends at
WH People, and I'm delighted tobe introducing a returning guest
, Paul Konoski from WH People,one of the founding partners.
How are you doing, Paul?
Speaker 2 (00:15):
Yeah, I'm doing great , Simon.
Thanks for having me on.
Speaker 1 (00:17):
Good, you're back again, in a slightly different
guise this time.
So do you want to give us a bitof an update on remind us about
your career and a bit of updateabout how you landed?
Speaker 2 (00:29):
at wh people, absolutely, and apologies for
those that have listened to theprevious episode that I was on
and I've heard this before, butmy name is paul kernoski.
I have been in this sort of hdm, wfm, payroll tech space for
over 15 years now and in thattime I've held various roles
i've've worked in operations,I've worked in implementation,
I've worked in productdevelopment and I've also worked
(00:50):
on the sales side oforganizations.
Recently, in mid-2024, after astint at an organization called
Dayforce, running their team ofsolutions consultants for EMEA,
I decided to stop doing thatbecause the business is as good
as it is, and go intopartnership with two of my
ex-colleagues, wendy Muirheadand Helen Steele, to form a
(01:11):
little consultancy called WHPeople and we offer things like
assisting organizations innavigating the global payroll
and workforce management marketand we do also do tech and
process performance coaching andsupport.
Speaker 1 (01:26):
Amazing, and Wendy did a detailed intro into WH
people in episode one, so feelfree to for people to go back
and listen to that.
And today we're going to talkabout how to have or land
successful tech projects.
So I'm sure you I'm sure you'vebeen involved in many of those
in your career, paul, in termsof Dayforce and the stuff you're
(01:47):
doing now We'll work throughkind of some points I know
you've got in your head, butlet's say we've got our
organization, organization X,that we both work in, has bought
a new tech solution.
It could be anything butsomething that's tech.
Where do you kind of start inyour head in terms of laying the
foundations for a successfulproject?
Speaker 2 (02:09):
Yeah, so, and you're right, I have you know, from
various different perspectives.
Over the course of my careerI've been involved in quite a
large number of technologyimplementations, from sort of
being right at the coalfacedoing the work and pressing the
button, through to managing theprojects and then through to
sort of seeing them from theoutside.
And really what I was going totry and focus on here is a
(02:32):
number of things that mightsound super basic or like
no-brainer, but you'd besurprised at the number of times
that I've seen one, a few orall of them missed by
organisations, because quiteoften, particularly for sort for
smaller and medium-sizedenterprises they don't
necessarily do this every day.
The people that are doing thesetechnology implementations
aren't in their day jobs, sosometimes things that might
(02:55):
appear obvious to people thatsort of live in this world day
to day can be missed by thoseorganizations.
So I was just hoping to call afew of those out.
So I think in a lot of cases,the first thing that you really
need to be thinking about iswhat is the makeup of your team
going to look like when it comesto implementing these projects,
because you will have peoplethat have a day job.
(03:15):
They won't necessarily beworking full-time on this
project, so you have to plan outhow those people are going to
be able to find the time to dowhat they need to do in order to
get this project over the line.
Excuse me, but I do also thinkit's important from an
organizational point of view, asmuch as possible to mirror what
the, the vendor or theimplementation team's governance
(03:36):
structure is going to be.
So if the implementation team'sa project manager and what's
being lead, you could have aproject manager and work
families noway in lead.
Now I think for work-stay inlead, that's potentially okay if
those guys also have a day job,but I do think it's really,
really important for you to atleast have a dedicated project
manager on that project whodoesn't have a day job and can
(03:57):
focus entirely on making surethat that project goes smoothly,
that you're hitting your plan,that you're making your
deadlines and everything's beingdelivered when it needs to be.
Often I've seen in my careerorganizations that thought they
could get away with not having aproject manager on their side
and I've often seen that causeissues and delays and actually
delivering the project and it isthat.
Speaker 1 (04:19):
I mean, some of that comes down to cost, doesn't it?
I get people are managingbudgets and stuff, but it always
feels a bit perverse if youtech solutions generally aren't
cheap and I'm making a broadstatement there and shoot me but
um, there'll be a significantinvestment in a tech solution,
so to then kind of fallinternally by not putting the
right resource on feels like abit of a known goal yeah,
(04:41):
absolutely.
Speaker 2 (04:42):
I couldn't agree more .
And not only that.
You know I think mostorganizations that have lived
that would agree that the thecost of overrun, slippage,
things going wrong, is likely tovastly exceed the cost of just
putting a project manager intoit to manage all of that sort of
stuff.
And, and to your point, notonly is tech solutions not from
(05:04):
a cash point of view.
Once this is in, it's likelysomething that you're going to
be living with for three, five,ten years.
So it's really important todedicate the right amount of
resource up front so that you'renot constantly having to go
back and rework or implementworkarounds because you can't
get things over the line on time.
So, whilst that cost of aproject manager might not seem
(05:27):
essential to some organisations,I strongly believe that it is.
Speaker 1 (05:32):
Okay, so team make-up .
Point one where do we?
Speaker 2 (05:34):
go next.
So I think another reallyimportant thing to get on top of
as early as possible and in myview, you should be trying to
get on top of this before youeven sign a contract with any
provider as your datapreparation for data migration
and also for ongoing integration.
I don't know what yourexperience in this is, simon,
(05:56):
but particularly with workforcemanagement solutions, and
particularly if you're doingthings like labour optimisation
or forecasting, the amount ofdata that needs to be migrated
over is pretty significant, andso I think, as an organization,
you need to be thinking really,really early.
What is that data?
What format am I going torequire?
And I would always recommendthat you try and get things like
(06:19):
data migration templates,integration specs and all of
that sort of stuff prior to evensigning any contract.
Now, a lot of vendors, I think,may not be particularly keen to
give you that, and I think thereason for that is sometimes
they feel like it makes it lookscary when they present you for
a massive Excel spreadsheet ofdata migration requirements, but
that's just the reality ofdoing these types of projects,
(06:41):
and so there's a lot of timeinvolved in working out how
you're going to get that data.
What's this?
What current systems that dataneeds to come out of?
Can you get that data yourself,or will you need to involve
some of your other partners orvendors, or potentially even the
provider that you're movingaway from?
Is that provider going to putup roadblocks?
Are there going to be anyadditional costs associated with
(07:02):
getting that data out?
And so that, in my experience,is something that I have seen
derail or delay projects onnumerous occasions is the
inability of the customer topresent the required data in the
required format in a timelyfashion, and that is just going
to delay your project and Ithink there's also a recognition
(07:25):
of clean data as well, isn'tthere?
Speaker 1 (07:27):
So the actual?
It sounds simple.
Let's use workforce management.
Give me two years EPOS data bystore by 15 minutes.
You'd think is relativelysimple.
Providing the data I think mostpeople have probably got an
angle on now of getting it outof their systems.
But that data actually beingusable and clean, when you think
of all the events that go onmaybe system outages, hangovers
(07:49):
from issues, it issues becomes alot trickier when you start to
get into the detail.
Speaker 2 (07:55):
Yeah, absolutely, and , as you say, that's really
important.
I think it's important tounderstand how clean your data
is.
If it's not clean, what sort ofactions can you take in the
receiving system, deal with anyanomalies that might be present
in the data, if you do feel toidentify and cleanse them?
(08:25):
Because what you don't want isto get a certain period of the
year following yourimplementation and, all of a
sudden, your forecast are wayout of whack because the the
data that you input from theprevious two years had some
anomalous data in it.
Speaker 1 (08:41):
For whatever reason, yeah, okay, so point two, then
data preparation.
Where do we go next?
Speaker 2 (08:47):
So another thing that I think is really, really
important and there's sort oftwo points here that are almost
merged into one, I think isdecision-making and pragmatism
when it comes to these types ofprojects.
So I think that the first thingthat I would say is it's
important, I think, as acustomer, to understand or
(09:07):
recognize that no amount ofarresting questions, requirement
specifications, softwaredemonstrations, discussions
prior to getting into theproject no amount of that is
going to capture everything, andall of the vendors that you're
speaking to, they're going tointerpret those requirements and
(09:28):
questions and RFP questions inthe way that's going to make
them look the best.
I'm not saying that they'regoing to lie to you, but they're
certainly going to interpretthings so that they can give the
most positive possible answerbecause they are interested in
getting you to purchase theirproducts.
So when you do get into thenitty-gritty of the project,
(09:49):
what you're going to find isthat there are going to be
different interpretations of howthings work.
There's going to be differentinterpretations of how certain
things are achieved, of howcertain things are achieved.
The technology that you'veselected may be able to achieve
your requirements, but it maynot be able to achieve the
requirements in exactly the waythat you thought that
requirement was going to beachieved, even though,
ultimately, that requirement isgoing to be achieved.
(10:11):
So I think there's a few thingsthat are really important for
organisations to recognise andalso to be able to do throughout
the life of the project toensure that you're able to keep
moving forward.
So I think it's reallyimportant for everyone to remain
pragmatic and work as one teamtowards resolving these types of
(10:33):
issues and to be able to cometo a solution that everyone can
sign off on and is able to moveforward on.
And one of the things that I'vecertainly seen a few times in my
career is, if the relationshipwith you, between the customer
and the implementation team,slash, the vendor becomes
adversarial and it becomes likean us and them sort of situation
(10:54):
that is going to negativelyimpact your project, and I have
seen that happen during mycareer, where people are no
longer working together to getto a solution, but they're sort
of siloed and there's anadversarial relationship and
there isn't any opencommunication anymore, and that
just causes all kinds of issuesgoing forward.
(11:14):
The other thing I would say isI do think it's really important
to have people that are able tomake decisions involved in the
day-to-day running of theproject.
For example, every singledecision that has to be made
needs to be passed up and down achain of command, or every
single decision that needs to bemade needs to wait for a
(11:36):
monthly steering group in orderto be resolved.
That is going to have asignificant impact on your
project timeline.
Now, particularly for thingslike a workforce management
implementation, there are somefairly big decisions that could
affect your employees or yourworkforce that should have been
made up front.
What you what?
The other thing that you don'twant to do is get into weeks or
(11:59):
months into your implementationand then realize you need to go
and have an extensiveconsultation with HR or whoever
else it might be in theorganization before you can sign
off on some particular decisionthat needs to be made.
But that all, I think, needs tobe considered upfront and as
early as possible as well.
What's your thoughts on thatone, simon?
Speaker 1 (12:18):
Yeah, I mean like, like you, I've seen
organizations get stuck intreacle where it's, you know, in
in a demo, you told us it coulddo this, or in the requirements
.
Here's what you answered inblack and white and and it, like
you say, it's interpretation isit?
I've seen examples of vendorssaying yes to something and it's
delivered by a report and thenthe client's dissatisfied or
(12:40):
thinks that it's not been aconversation that's been clear
or documented well, because theydidn't think it was a report,
they thought it was delivered bythe system.
Yeah, absolutely.
It's tricky, right?
Because, like you say, you canspend an eternity trying to belt
and brace an RFP andprocurement.
You know, procurement want onepart and technology want another
(13:01):
and operators want somethingelse, regardless of what type of
system you're procuring, and itcan be death by a thousand cuts
in that process to then findout that, yeah, somebody can do
it, but the interpretation isit's delivered in a different
way than you thought.
So it's never perfect.
I think, yeah, if you get tothat stage where you're kind of
(13:22):
pulling out the RFP and showingit to somebody saying this is
what you'd have answered, youprobably need to sit and regroup
and everybody take a breath andsay right, we are where we are.
How do we implement this?
And both parties understandmore.
To get a solution because itprobably comes on to your last
point everybody's got to be ableto bend and change a little bit
(13:43):
and be flexible, otherwise it'sa.
Speaker 2 (13:46):
It's a relationship which is based on a black and
white contract or document withno context yeah, and I do think
sometimes it can help I think,particularly from a customer
point of view to understandalmost the different motivations
of the different people withina vendor organization that
(14:07):
you're going to be dealing with.
The people that you're talkingto prior to signing the contract
, they're motivated to get youto buy their software.
They're going to answereverything, not necessarily
incorrectly, but in the way thatreflects best upon the
technology that they are tryingto sell you, and that's their
motivation and that's just thereality of it.
(14:27):
And then when you get into theactual project yourself, you
tend to be talking to adifferent set of people within
the organisation.
They probably haven't answeredthe RFP questions and their
motivation is to get yourproject implemented as quickly
as possible to an acceptablelevel of quality and then move
on to the next project thatthey've got coming up.
So there's very different setsof motivations of different
(14:50):
people or different areas of thevendor or your implementation
team organization that you'll bedealing with and sometimes when
you're talking to, when you'rein the project and talking to
the implementation team, ithelps to understand that that
team that you're talking to isare probably not the people that
gave that answer to the RFPquestion that you think they've
interpreted incorrectly, and soit's important to be able to
(15:11):
understand that and work as ateam to move forward and get
over those challenges.
Speaker 1 (15:15):
Yeah, and there's always a win-win.
I think in most of these.
I've never really seen anexample where it's caused
somebody to terminate a contractor whatever.
I've seen it cause exampleswhere it slowed things down or
caused big frustration movingforward.
But ultimately there must be awin-win in the middle, because
interpretation grayness isn'tgreat, um, but actually the fact
(15:36):
that somebody said we can do itmust mean there's a way forward
agreed and I think the morepragmatic and the more sort of,
the more of a sort of one teamlook that you have in those
circumstances means you get tothat resolution and you get to
that way forward a lot morequickly than if you start off
from a sort of he said, he saidperspective and assume that
you're not working together asone team yeah, agreed, okay.
(16:00):
So we've got, we've got a goodteam, we've got good data, we've
got some decisions that arebeing made other than the big
ones, kind of locally.
Rather than um protecting thekind of project length, we're
being pragmatic.
Where do we go from there?
Or what's the?
What's the kind of cherry onthe cake?
Speaker 2 (16:16):
so I think the last one and I think this is a really
important one and iswillingness 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 theimplementation actually doing
the work, to sort of lose sightof the vision of why the
(16:36):
organisation wanted to initiatethis change in the first place.
But, excuse me, one of thethings I often used to tell
customers is that you wouldn'tbe making this change if the way
that you were or are doingthings was good enough or
satisfactory.
The reason that we're doingthis project is because what
came before needed to change.
(16:57):
But I do think sometimesthere's a lack of almost
top-down communication from thesort of high-level
decision-makers who understandthat we need to make this change
for these reasons.
Sometimes that's notcommunicated strongly enough all
the way down the hierarchy, andso the people that are actually
doing the day-to-day work don'tunderstand the goal that
(17:18):
they're working towards.
And I do think that often theeasiest default fallback
position for people is we'lljust continue to do it the way
we've always done it.
That way we're getting throughthe days.
It might not have been perfect,but we can just continue to do
it the way we've always done itthat 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 quiteoften not the best way to
approach these things.
And I do think that it'simportant and I and I genuinely
(17:39):
think this comes from the top aswell it's important that
everyone in the team needs to bewilling to make those changes,
to accept practices, to acceptthe way that the technology that
they've purchased produces theresults that they need.
They need to be willing to adoptnew processes and the
likelihood is there is a fewsort of sacred cows for people
(18:02):
that will need to be killedalong the way and it might be
painful for some people toaccept.
There might be a period ofadjustment in order to make
those changes and really embedin those changes and communicate
those changes and ensure thateveryone's on the same page with
them.
But if you go through all ofthat expense, effort, pain and
time to implement a newtechnology solution and you end
(18:24):
up just doing everything exactlythe way you did on your old
technology, you've kind ofdefeated the purpose of
undertaking that project at allyeah, agreed, and um, I think
it's interesting how, yeah,people revert to putting a new
system in and wanting it to workthe way the old system did.
Speaker 1 (18:42):
Back to your point when.
Why have you changed it then,not having back to your first
point?
In that team makeup, peoplethat are responsible for the
change, because you, there'sdifferent skill sets isn't there
.
You've got your projectmanagers, you've got your
solution specialists, you've gotyour data specialists, you've
got your operational specialists, but also you might need some
input from hr, depending on onthat to manage change.
But also people that are goingto communicate the change and
(19:04):
help deploy the change.
So it's back to some of that,the project setup.
But, yeah, just a taking asystem out and putting a system
in.
If you end up with the sameresult as you had before you
took it out, you're back toquestioning what the motivation
to change was, absolutely and Ithink you make a really good
point there, actually, about theteam makeup, simon, as well.
Speaker 2 (19:25):
I think one of the most overlooked things when it
comes to these types of projectsis the organisational change
management.
It's often if you implement anew technology but you get no
engagement with it nobody usesit then also, what was the point
?
It's really important, I think,to ensure that from the very
(19:46):
start of the project, throughoutthe life of the project and
beyond, these sort of changesare communicated and managed
consistently and positivelythroughout that entire process.
Otherwise, you're going to getto the end of it, but only the
people who are on the projectteam are actually going to
understand what you've done andwhy you've done it, and the
wider organization isn't goingto have any visibility or
(20:08):
knowledge or understanding ofwhat you were trying to achieve
by by doing that.
Speaker 1 (20:13):
Yeah, absolutely okay , so kind of five structured
points there before we kind ofclose, any other final closing
thoughts you'd like to share uh.
Speaker 2 (20:23):
The only final closing point I would say is
sort of subjective, personal isthat there always comes a point
during these types of projectswhere they're like projects
involve pain, they just doimplement projects.
Technology implementationprojects just do involve pain.
And there always comes a pointwhere you think to yourself is
this really worth it?
(20:44):
Are we going to get to the endof it?
But as you say, simon, there'salways, 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 tryand get to the end of it as
painlessly, as quickly andefficiently as possible and end
up with the best possibleresults excellent wise words and
if people want to pick up withyou, paul, to get in touch, have
(21:06):
a further conversation.
Speaker 1 (21:07):
Where's the best place for them to find you?
Speaker 2 (21:09):
oh, please reach out to me at paul at wh-peoplecom,
or you can just go to ourwebsite wh-peoplecom and fill
out the contact form in thereand we'll get right back to you
cool, and I'll put a link toyour linkedin profile in the
show notes as well, so if peoplewant to get in touch that way,
they can hook up excellentbrilliant.
Speaker 1 (21:27):
Well, that's number two in our mini series with our
friends at wh people.
Number three will be helen, andwe'll be talking about changing
culture.
So thanks for coming on again,paul, great to catch up, and
we'll speak soon thanks, simon.
Popular Podcasts
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Cold Case Files: Miami
Joyce Sapp, 76; Bryan Herrera, 16; and Laurance Webb, 32—three Miami residents whose lives were stolen in brutal, unsolved homicides. Cold Case Files: Miami follows award‑winning radio host and City of Miami Police reserve officer Enrique Santos as he partners with the department’s Cold Case Homicide Unit, determined family members, and the advocates who spend their lives fighting for justice for the victims who can no longer fight for themselves.