Multichannel Success Podcast Season 3 Episode 3 - Transcript
Why you don't need an SI....or you do
David Worby [00:00:08 - 00:00:43]
I'm delighted to be joined this week by my co-hosts Mark Pinkerton and Kevin Murray to discuss the lovely subject of why you don't need an SI. Welcome to you both. Let's start if we may with a kind of brief explainer on what we think individually and collectively the SI is. There are a number of kind of roles that could map to being an SI but Kev what do you think an SI is all about?
Kevin Muray [00:00:42 - 00:01:04]
Well, I suppose what an SI is, I think, compared to maybe what it was, a lot has changed. I would certainly consider an SI to be having capacity to be able to help businesses, particularly, you know, I'd say retail, evolve their technology landscape, either project-based or we're having individuals to be able to bring their expertise to help the business meet the technology goals.
David Worby [00:01:05 - 00:01:22]
Now i know mark offline we were talking about some of that potential role also being related to my maybe more front-end stuff and often done by web agencies as we used to call them so did you think of web agencies being in the si ecosystem.
Mark Pinkerton [00:01:23 - 00:01:58]
Yes, I do think of them in the SI ecosystem, and we haven't actually said that SI stands for systems integrator. And as you rightly say, web agencies tend to focus on the front end, but things do blur. They may have a stronger creative role. Typically, people who use a back end focused SI will probably be doing their own creative in-house, whereas a web agency will be creative driven, but then needing to do a bit of technology to make that creative work in the right way. So I think it's just a degree of focus. Yeah.
David Worby [00:01:58 - 00:02:21]
yeah so i remember back in the day when we didn't really know what we were doing because believe me we didn't know what we were doing um we needed a partner who was with us for kind of everything because we we kind of knew product and we kind of knew a bit about service but we didn't know any about technology so right back in the day they were more of a partner than us than an integrator really do you recall those days yeah i mean i suppose Yeah, I mean, I suppose, look, the systems integrator at that point was like a service
Mark Pinkerton [00:03:43 - 00:03:50]
provisioning partner. So back when, you know, pre-cloud, you would buy some software, you would then have to install it on servers, you don't have to configure it, integrate it with your day-to-day systems. SIs came along and said, hey, we can do some of that or take that some of that pain away from you. And we will, as I said, install, maintain, manage. I suppose that's changed over the last kind of number of years now, I said, with cloud over the last kind of 15 years. And actually, the need for setup isn't as much as there anymore. It's more about, okay, can we integrate more? Can we use those key features that are currently rolling or constantly rolling off the production line and cloud systems, and bring them in and make full use of them within your kind of internal ecosystem. So I think where it's changed and looking at the different reasons as to, you know, why maybe you should use an SI is, are you looking for somebody, a partner who's just got great expertise in a certain technology? Have you got capacity challenges where you need to be able to dip into certain key individuals or key capabilities across your year? Do you want to hand all of it to someone else to go, do you know what? I just want to be a retailer, not a technology partner. You go run with it. So an outsourcer? Pretty much, yeah. And it's something, yeah. And it could be, and the outsourcing is interesting because the outsourcing could be just a technology. It could be all of it, the delivery. We've reviewed that option for clients in the past, including all the warehousing, everything from an eco point of view.
David Worby [00:03:50 - 00:04:08]
Which kind of suggests that the market might be becoming polarized a bit, you know, either you want to outsource it because you don't really want to get involved in any of that because that's not your core competence or it is your core competence and you kind of want to do it all yourself. So in that polarizing world, does that squeeze the SI marketplace?
Mark Pinkerton [00:04:08 - 00:04:35]
I think even if you want to do it yourself, sometimes you need a systems integrator or you know a typical SI body because effectively you're using capacity or getting their capacity in to help you over a short-term hump that you're not going to recruit full-time staff for. Maybe you can't get freelancers or contractors for your particular skill set that you need in your area.
David Worby [00:04:35 - 00:04:40]
talk about body shop as another kind of part of the ecosystem. There are people providing just boots on the ground.
Kevin Muray [00:04:40 - 00:04:51]
Yeah, that's it. You basically want to have a certain level of capacity of resource and within your own business, you will decide what you will do with them rather than giving them a project. You just buy days or hours.
Mark Pinkerton [00:04:51 - 00:05:02]
and that's the typical sort of large si cap accenture sort of model isn't it they'll give you a hundred people who are sat in india overnight if you need it yeah
David Worby [00:05:03 - 00:05:41]
We touched on it a moment ago, or Kev you did rather, about how you've seen the landscape change and I just kind of referred them to maybe if the world is becoming more polarised what challenges does that present to the SI community. I know personally I have a slightly you know challenged view of how this might emerge but it feels to me as though it is getting squeezed because 20 years ago none of us knew anything and we needed to buy the capability and the experience of experts. Now we know more and now we know how to access resources more easily. I'm not easy but it's more easy than it used to be. Does that change
Kevin Muray [00:05:40 - 00:05:41]
Does that?
David Worby [00:05:41 - 00:05:47]
the next 5, 10, 15 years of the SI landscape in your mind?
Kevin Muray [00:05:45 - 00:06:47]
I think it does because the types of skills that are actually required now are constantly changing because of cloud and because of the serverless systems now that and versionless systems that allow continual progressions. If you're going to buy a license for something and you buy it and it's constantly delivering new features and value, why would you need very very complex resources now to do it? I do think though when we look at change and maybe the type of skills that are needed, there isn't a level of maybe simplification. So I've noticed back you know many years ago my kind of early days of being involved in kind of system integration e-commerce and our clients wanted very complex, very experiential experiences to be able to offer to their end customers. But that was hard and it was difficult and it was time consuming and actually you know I've found recently I think I don't know my personal view is the ambition of the retailer has possibly gone into itself because they just want an easier life because some of these really difficult things that you could do are just too hard.
Mark Pinkerton [00:06:47 - 00:07:12]
Yeah, I mean, as we've covered in other podcasts, actually, the whole, you know, days of old, we had the situation where growth was kind of just there in the market. And you didn't really have to do a great deal to be able to grow 2025% a year. Whereas the last two years, it's been minus 8% ecom in the UK, and this year is flat plus 1%, maybe.
David Worby [00:07:13 - 00:07:21]
and the other thing we used to have is monolithic stacks where everything was pre-integrated now we're into a microservices world where everything is infinitely complicated so that
Mark Pinkerton [00:07:22 - 00:07:40]
Which means you then need to decide on exactly what you want and how you want to configure these things. And you can go down an enormous rabbit hole in terms of the amount of time it would take you to architect your new platform or your new setup. Particularly if you're going down the whole headless microservices route.
Kevin Muray [00:07:41 - 00:07:58]
I think that's one of the interesting things about this as well. I don't know yet in this kind of proliferation of headless and kind of these very flexible architectures, is anybody able to quantify the cost of that flexibility? I don't know yet.
Mark Pinkerton [00:07:57 - 00:08:15]
We know quite a few people who've run into difficulty because if you're going to the ultimate end of that spectrum, you end up having to define everything. Whereas if you take something off the shelf, clearly you don't define it, you just accept it for what it is and run with it.
David Worby [00:08:15 - 00:08:31]
I think it's a good example of a measure of complexity, but back to the S.I. challenge, maybe that offers an opportunity for the S.I. market. So before we go on to some of the reasons why you might not want to have an S.I., let's think about some of the value an S.I. can bring.
Mark Pinkerton [00:08:31 - 00:09:11]
Yeah, I mean, clearly, if you get the right SI, they will have expertise in the technology that you are looking to develop. So they may well have lots of previous examples of implementing that technology, or they might have access to the latest learning of the latest version of it, well in advance of it going out into the market if they have a relationship with the technology vendor. So from an expertise point of view, it is likely they will have a greater degree of expertise than you will, particularly on a new technology. If it's an old, mature technology, much less so.
David Worby [00:09:11 - 00:09:18]
So first 101 question, do all SIs look at and cover all technology?
Mark Pinkerton [00:09:18 - 00:09:25]
No, they couldn't possibly. I mean even Accenture won't cover everything. I don't think Accenture do shopping either, do they?
Kevin Muray [00:09:20 - 00:09:32]
I mean, even I would like it's one of those ones where there's certain ones who will say they do it because all they've done is they've just one page ahead of the manual than the customer right so they've
David Worby [00:09:32 - 00:09:34]
And they run very fast.
Kevin Muray [00:09:32 - 00:09:38]
just run very fast yeah exactly right so and there is that question said should do you want a
David Worby [00:09:34 - 00:09:36]
Yeah, exactly right.
Kevin Muray [00:09:38 - 00:10:00]
generalist because while you could have a level of capability who could train that's that's not cost effective you might as well hire that resource in yourself you want an SI who comes in with that proven track record of knowledge of doing things and actually who has the scars and who has found the problems so you don't have them and you get that really early warning beforehand and then somebody who knows what they're doing have things to avoid
Mark Pinkerton [00:10:00 - 00:10:51]
And in the same way, you know, in the old Magento world, there were probably three or four really good agencies in the, you know, SI slash agencies in the UK who really knew their stuff on Magento and you could know that technically they were doing a really good job. You've got the same situation now emerging with headless where there are a few people who know how to do headless really well. And actually that's less technology driven because everything is defined in microservices than the experience driven aspect of it. They know what you have to define, what you don't have to define, what modules you can take off the shelf versus ones that you actually want to fully customize and define. So they can therefore make things happen slightly quicker than perhaps you could do by going back to first principles on everything. Okay.
David Worby [00:10:51 - 00:11:10]
something that we're going to come back to a bit later here which is the challenge of trying to find an SI who is truly independent because let's be honest very few of them could ever really say they're independent but at the same time once you've appointed them you want them to be a specialist on the thing that you want them to be a specialist on so but we'll come back to that later
Mark Pinkerton [00:11:07 - 00:11:41]
But I don't think you necessarily need the SI to be completely independent because I would argue people like us, Brospro, would be able to provide some of that independent view up front but then participation in the project would reduce and we would maybe just take a governance view on the project. But knowing actually how to manage an SI or how to work with an SI is a skill in itself that a client may actually need a little bit of support from.
David Worby [00:11:42 - 00:12:27]
So let's come on to that, because I think if you've made a decision that you're going to do that, then there are certain, I guess, bits of advice we'd give our listeners about best ways to engage with and set yourself up for success. So let's just come on to what kind of things we think you should think about. The first thing I'm going to throw into the pot is the extent to which you want to be or your SI is agile or wants to work in an agile way. Now, in a previous podcast, we've talked at length about agile and about the benefits and the challenges. And we posed the question whether agile is dead. Clearly, agile isn't dead, but it does present challenges if you as a business don't work in an agile way. Kev, how do you kind of sum those up?
Kevin Muray [00:12:27 - 00:13:33]
I think the you know you have to find an SI who's going to work the way your business works so there's an element of where if your business is maybe needs to know a lot more planning up front more waterfall style having a systems integrators maybe taking a more agile iterative approach may find huge compatibility issues when it comes to dependency management and really trying to have you know a good and easy way of delivering on an ongoing basis and there is an element as well of of the commercial aspect to it because you're bringing in a level of expertise but if you don't necessarily have that completely well defined and locked down and be able to measure how effective an SI is to be able to deliver your your projects if you don't know what the end game is going to be what the end point is going to be or what the right things should be being worked on by your SI that can have a I suppose a knock- on effect where commercially you're paying for something where the SI is maybe not doing exactly what you need them to do because hey it's agile everything changes but at the end of the day the business needs to see a return on investment and deliver
David Worby [00:13:33 - 00:14:00]
and i see that as a real challenge because i've kind of got some experience of a while ago of not working in an agile way and wanted to be very clear about what was being delivered and when it was being delivered and precisely where it went and and the si wanting to work in a way that didn't make me feel as though i really understood that because it was all constantly seemed to me anyway to be constantly on the move how do you square that circle mark how do you i mean do you just not appoint an si who insists on working in an agile way if you don't want to do that
Mark Pinkerton [00:14:00 - 00:14:17]
if you don't yeah i think you're going to end up with long-term conflicts if you have a fundamentally different way of doing things i don't think you can resolve that very easily you either have to agree that you're going to change or you have to find an s.i who works in the way that you're comfortable with
David Worby [00:14:17 - 00:14:22]
So that's kind of one of the big decision points really for you in selecting an SRI.
Mark Pinkerton [00:14:20 - 00:14:35]
Yeah, I mean you may want to use an agile based SI specifically to make you more agile as an organisation, i.e. to force that change. But then you're in learning mode rather than in a different mode.
David Worby [00:14:32 - 00:14:36]
But then you're in learning mode, rather than, yeah, different mode. Yeah.
Mark Pinkerton [00:14:35 - 00:15:13]
Yeah, simultaneously with trying to action it. But one of the other big things in terms of working alongside an SI, and I know we'll come onto it in terms of challenges, is if you want to run the project yourself, or run the programme yourself, after the initial work is done by the SI, you have to work with somebody who is comfortable doing knowledge share and knowledge transfer across into your business. And again, not all SIs are very good at doing that. So some will work in that way and some won't. I guess some of them don't have a vested interest.
David Worby [00:15:12 - 00:15:22]
Just before we leave, how do you work with an SI, quite apart from KPIs and costs which No, absolutely not.
David Worby [00:15:22 - 00:15:38]
Clearly it's not in there. Their motivation is misaligned. Yeah. we'll come on to, should you align your internal resources to them, should there be some kind of meeting of the, clearly you want to understand where they're at at each step and you want to be able to report back to your own business where you are, what kind of role should be aligned across the divide between them and you?
Kevin Muray [00:15:39 - 00:16:31]
I think that there's two sides of this. One is a commercial role and one is a technical role. So absolutely you should be very close because ultimately whatever the SI is delivering it's a strategic capital investment for your business and so you want to be close to it. And being close to it obviously commercially makes sure that you understand that things are happening in the right direction, you're getting an ROI, so having those regular touch points, regular understanding of what's coming off the production line. But also technically you do want to have maybe your teams being close to understand okay what actually is in the lower levels being delivered, what are the different elements of security that's maybe being considered, the solution approach that you've decided you may want to take it on yourself. What you don't want to happen is maybe part of the reason why agile came around was the waterfall days where everything was written. SI would disappear for six months, come back and say here it is and only start to
David Worby [00:16:29 - 00:16:31]
Here it is
Kevin Muray [00:16:31 - 00:16:50]
look at it you go okay well that's not quite what I wanted and so at least you have a better idea to not only see it continually moving but you also have ability to be able to change before it's too late or stop something say hey what you've just done there doesn't meet with our standards or our guidelines yeah so you get to see it at that point in time rather than when it's too late.
David Worby [00:16:50 - 00:17:10]
And I guess if you're, we'll come on to this a bit later, but if your, if your relationship with the SI is for a defined project and you wish to migrate that knowledge, as Mark said, to your business after it, then aligning those resources is even more important because you don't just want the ball to be thrown over the fence for you to catch it, you want, you want some kind of learning together on the job.
Mark Pinkerton [00:17:09 - 00:18:02]
Absolutely, absolutely and you know in these agile days with you know people trying to deploy design thinking to things so that you're looking at things more holistically it is likely that the development team that is working on this is some combination of SI and internal resource anyway. You know you may well have your own CX, your own internal designers and maybe some product specialists working in cahoots with the SI's team. So you know the difference is between having a written specification and having an ongoing conversation so that you end up with as you say this iterative approach where you get to a common understanding which should be a better understanding than just a one- off written in a document.
David Worby [00:18:03 - 00:18:07]
It's the difference between being done to me as to being done with me isn't it?
Kevin Muray [00:18:06 - 00:18:12]
I've certainly recognized sometimes in kind of my past where obviously if a business decides
David Worby [00:18:07 - 00:18:08]
Absolutely.
Kevin Muray [00:18:12 - 00:18:29]
to go use an SI and sometimes you merge those two teams together to have your existing customer technology there can be either resentment or definitely a level of um I would say sabotage is not a hard word but it's definitely like this oh that's not being done exactly the way I do it
David Worby [00:18:24 - 00:18:27]
But it's definitely like this
Kevin Muray [00:18:29 - 00:18:53]
and you know I've seen examples of where a lead technical architect or somebody who's running the technical team had pitched to say hey we can do all of this stuff ourselves the business said no we need expertise we're going to move faster and that immediately creates that initial conflict where oh the SI isn't doing it exactly the way I would have done it and I think it's wrong and it creates a lot more noise in an already kind of fraught and difficult project so I think
David Worby [00:18:52 - 00:18:56]
I think we need another podcast to unwrap all of that.
Kevin Muray [00:18:53 - 00:18:57]
a lot of self-protection I think we need another podcast to unwrap all of that
Mark Pinkerton [00:18:57 - 00:18:58]
Well, let's go back up. Okay.
David Worby [00:19:22 - 00:19:46]
I know there's a big middle ground, but for the sake of simplicity, let's assume there isn't right now. So I'm in a world now where I think I should be able to do it for myself. What are the challenges of buying licenses or buying software and trying to do the job myself? In a position where I've never done it before.
Mark Pinkerton [00:19:46 - 00:20:56]
I think it's actually probably more important with an internal team developing things that you actually have the business involvement available to you. We have worked with clients in the past where there has not been the business guidance given to internal IT teams who are developing, in particular example I'm thinking of a headless solution, and they therefore go off and try and cover every base under the sun when actually they probably don't need to, which meant that the cost has escalated, the time has slowed down, and after 18 months they haven't delivered something they should have delivered in about three months. So you need to be cognizant of that and make sure, because an SI may have some of those business analysis skills or business leadership skills that they could deploy having seen these things elsewhere, that you don't have internally as a business. So that's a challenge for the business, but it's not a reason not to do it yourself. I mean you should be able to have a better understanding of what your business needs and yourself and your customer, and if there is any
David Worby [00:20:52 - 00:20:53]
and yourself.
Mark Pinkerton [00:20:56 - 00:21:07]
concern about that then you should be able to ask your customer very quickly, whereas an SI, even if it's reasonably well integrated into your business, is still a little bit more remote from your customer.
David Worby [00:21:06 - 00:21:17]
kevin, in your mind, does that extend beyond the front end? I mean all businesses like to do the front end because it's, you know, painting lovely pictures, but should it extend into the integration layer on the back end?
Kevin Muray [00:21:17 - 00:22:09]
It could potentially. I suppose going back to the kind of initial point is that I look at the two C's. Have you got the capacity and have you got the competency? And you know the question of those you know answering those two because if the both of them is yes then I think you then have that ability okay do I need to go and acquire talent and is that talent going to allow me to be able to do the new thing I want to do but also maintain the old thing do I need to do the integrations and you're always going to probably already have expertise internally about the systems you may want to integrate to so we're talking about an e-commerce platform for example you probably already have an ERP or you'd already have a finance system so you're going to have that capability there so the question is if you can bring in someone who maybe has worked as on this new e-commerce technology before they're able to work together with the existing stakeholders of your current systems there's no reason why that couldn't work.
David Worby [00:22:10 - 00:22:24]
And you mentioned before that the prevalence of these body shop type operations, where you can just buy in the resource that you need, rather than having to engage a full suite SI, if you're uncertain, maybe that's an approach you could take, just to complement your own resources with some of the small gaps that might exist.
Kevin Muray [00:22:24 - 00:23:02]
Potentially. I think one of the challenges you always have with the likes of a body shop is you get who they've got on the bench and that may be okay. That may be, well actually the good people are already out on client sites anyway. I've seen examples of where the person on the bench happens to have just done training and hasn't had actual capabilities. And depending on what you need, because maybe there's just a, you need someone just to do stuff, not the complicated stuff, but just stuff that might work. But there's definitely an element of very specific, highly skilled individuals like architects that you may want to bring in for those temporary times.
Mark Pinkerton [00:23:05 - 00:23:10]
Maybe we should take a break here for a message from our sponsor, SWEFT, Retail's leading solution
Kevin Muray [00:23:05 - 00:23:07]
Maybe we should take a break.
Mark Pinkerton [00:23:10 - 00:23:30]
for product workflow automation. SWEFT is designed to replace the in-house tools and spreadsheets retailers use to manage product workflow by bringing buying, planning, marketing, studio and e-commerce teams together on a single powerful platform to launch products faster and more efficiently. Find out more at gosweft.com
David Worby [00:23:45 - 00:23:53]
Okay, right. So let's move on to some of the KPIs that we think might be relevant. If you're going
Kevin Muray [00:23:45 - 00:23:45]
Okay.
David Worby [00:23:53 - 00:24:19]
to engage your SI, let's assume that this is maybe the first time you've done it and your project is kind of enterprise kind of scale. Mark, what kind of KPIs do you think ought to be in your mind when thinking about how you hold your ecosystem of suppliers, because there may be more than one here, accountable for the work they do, whether they're doing a project maybe or whether they're doing something a little bit more long term.
Mark Pinkerton [00:24:20 - 00:25:37]
Well clearly you need to agree the scope and that's the critical thing is what are they going to deliver and if it's phased to make that very clear. Then the tier of detail below that would be to look at the minimum viable product because assuming everybody's working in an agile way there will be a minimum viable product delivered and making sure that that is actually a viable product for you and defining that in some way contractually will help because they tend to get mitigated as the project goes on and less and less and less goes into the MVP. And then the next layer of detail down is making sure the definition of done for the critical user stories is actually clear and understood. We have worked on projects where the definition of done is not agreed or even understood internally in the business and that has caused horrendous problems and what has been delivered is not fit for purpose as a result. So having an understanding of the clearly you can't understand pre- define all of that because then you end up in a waterfall world but there will be some things where it is critical to agree what the definition of done is for certain things.
David Worby [00:25:38 - 00:26:10]
And whenever I've looked at projects I've been involved in, looking back on things that didn't work well or didn't work as well as I expected, I often reflected that I should have spent more time trying to define success so I could make a clearer picture, I could define or paint a clearer picture of what was expected. And whether you do that through KPIs or whether you do that through definitions of things, I don't really know, but I think it's one area where we underspend our time and often regret it in defining that end picture.
Mark Pinkerton [00:26:11 - 00:26:36]
strategist slash planner I would always agree with that with that view I think people need to to think about it and it doesn't always necessarily need to be fully documented but if you haven't done the thinking behind things how can you provide the direction that you need or an SI will need on your you know to be able to do things on your behalf
David Worby [00:26:35 - 00:26:40]
back in the day they used to tell you what it was so the yes i would come and define the sky
Mark Pinkerton [00:26:39 - 00:26:51]
If the product is relatively fixed then that's easy because that's what you're buying but in this world where things are more flexible you can buy a system and you have a choice
Kevin Muray [00:26:47 - 00:26:49]
more flexible, you know.
Mark Pinkerton [00:26:51 - 00:27:01]
of 20 different CMSs now instead of 2 or 3 so you have to understand what is driving your decision about a CMS as part of the overall mix for example.
David Worby [00:27:01 - 00:27:10]
okay kevin what about what about the point of story points i kind of love and hate it's all in the same kind of breath but should that be part of the kpis do you think
Kevin Muray [00:27:08 - 00:27:34]
But we. At story points in some way being able to measure velocity or what's coming off the production line. So there's definitely an element of being able to say okay well how fast can the business move and deliver features or the SI deliver features and can we measure them in some way. Now story points I think is always a very interesting one. I'm not so sure about them myself because they're arbitrary but you need to fix some you come up with something and be consistent about it through the whole project.
Mark Pinkerton [00:27:34 - 00:27:51]
But if you have, say you've got a velocity of producing, I don't know, 70 story points a week on the project, as a client, how do you know whether or not ultimately that's giving you enough capacity to deliver what you need at the end of six months?
David Worby [00:27:49 - 00:27:50]
Hmm.
Mark Pinkerton [00:27:51 - 00:28:06]
Very often you don't. You don't have an inkling at the beginning of the project and still the way the story points are described and assigned is actually arbitrary and different from most projects.
David Worby [00:28:05 - 00:28:12]
yeah i mean i was looking at looking at agile projects and story points just seem to be an arbitrary way of measuring something it is and all i was thinking about as a business
Mark Pinkerton [00:28:11 - 00:28:14]
And all I was thinking about as a business user is capabilities.
David Worby [00:28:13 - 00:28:15]
is capabilities and you and you have
Mark Pinkerton [00:28:14 - 00:28:26]
And you have a fixed capacity, very often, and without necessarily knowing what the total number of story points you need to deliver what you want, your MVP.
David Worby [00:28:25 - 00:28:25]
Hmm.
Mark Pinkerton [00:28:26 - 00:28:33]
So how do you know whether or not you've actually got enough capacity to deliver, after six months, your MVP?
Kevin Muray [00:28:33 - 00:28:40]
Part of the reason I think that you're bringing in an SI is because they should give you an idea of what they think that should look like. So to your point earlier, Mark.
Mark Pinkerton [00:28:40 - 00:28:45]
i've never seen it agreed they just bamboozle you
David Worby [00:28:44 - 00:28:47]
These are the foreign currency you've got to get your head around.
Mark Pinkerton [00:28:47 - 00:28:53]
I've never seen somebody saying this will take 500 story points across six
David Worby [00:28:47 - 00:28:48]
I've never seen...
Mark Pinkerton [00:28:53 - 00:29:00]
months therefore you need this much capacity I've never seen it done that okay I mean I suppose that's for me
Kevin Muray [00:28:57 - 00:29:38]
For me, I'm a believer in iterative development. So what I would tend to do is that once you define the MVP, you define up front what the MVP is and you don't agile build that, you iteratively build that to a point where you said, okay, so we will deliver every two weeks, I mean your sprints are two weeks, you'd say, okay, we're moving towards our MVP and we are hopefully better on a regular basis at determining how long it's going to take to get to that MVP. At the point you hit your MVP, you then move into pure agile, which is we now have a baseline for us to be able to work on so that, and then you can kind of go in any direction, but you've got your critical mass of the first steel threads.
David Worby [00:29:38 - 00:29:40]
what's it called, steel threads.
Kevin Muray [00:29:38 - 00:30:06]
That makes sense. And that means you can control it more. There is an element of, you know, with agile. David gets his certainty. Yeah, exactly. A bit more. The CFO can kind of cut a check feeling that, you know, it's never ending because they think, okay, do you know what? That MVP could be anything between half a million and a million quid. There's a large range there. At least it's something where sometimes somebody's cutting a check for agile and the answer is I don't know what that number is going to be at the end. It never worked.
David Worby [00:30:05 - 00:30:11]
I was just resistant to writing a check out for story points because I don't think you can cash those these days. Maybe one day you'll be able to.
Mark Pinkerton [00:30:10 - 00:30:33]
Maybe one day you'll be able to. The other thing we've talked about is the number of defects in the code, but the key thing is the degree of trust that you have with your SI and making sure that that works. Clearly if trust breaks down mid project you're done for, you've got to find a new SI, you're never going to fix that and we've seen examples of that and
David Worby [00:30:31 - 00:30:33]
You never get old.
Mark Pinkerton [00:30:33 - 00:30:46]
it's not technology specific, it's just relationships. That's not a KPI unless as a program manager or program director you wanted to...
David Worby [00:30:38 - 00:30:39]
Yeah, we'll, we'll, we'll come on.
Kevin Muray [00:30:39 - 00:30:41]
And that's not, that's...
Mark Pinkerton [00:30:47 - 00:30:50]
Check that and validate that across your internal teams.
Kevin Muray [00:30:51 - 00:31:03]
why not though, nps it every month and find out the real heartbeat of how that relationship is going and if you know, address it, fix it, don't wait until it gets so bad.
Mark Pinkerton [00:31:02 - 00:31:06]
yeah because then you should pick it up before it becomes a problem yeah yeah i like that
David Worby [00:31:06 - 00:31:49]
I mean we like giving practical advice so that makes a lot of sense to me. Okay before we come on to our final subject which is really about mitigating risk because you know SIs do this all the time, business doesn't do this all the time and it's therefore kind of scary and a bit unknown. Let's just talk a little bit about the value of an external perspective. Mark you talked earlier about if you are in the market for external advice which can bring you a variety of benefits albeit that there's a cost to it. Where best do you spend that? Do you spend it pre-decisions about technology? Do you spend it pre- decisions about SIs or do you spend it actually in the project? Where would you where would you pitch that? I think there's value.
Mark Pinkerton [00:31:48 - 00:33:05]
I think there's value in doing both to be honest but you need to make sure that you have a clear understanding of what you're getting and to try and get an external view on things. Your CTO may be suggesting going down one particular route because that's what he wants to do. His next job he actually wants to show that he's done a headless program and we've definitely had that in clients before where it's being driven by the CTO's ego. That's not a good situation and you need an external perspective to be able to say yes you should probably do this internally but not like this or actually you might be better off because it's new technology using these people who've at least done one project before using this technology. So you're going to get that internally because they're always going to be learning. And then there is from a program governance point of view there's value in having an external party involved like us where we have enough knowledge to know whether or not the SI is trying to pull the wool over the client's eyes and whether or not it's actually the client not doing what the client needs to do for the SI which is also problematic.
David Worby [00:33:04 - 00:33:49]
Yeah, and I think also to paraphrase that, you know, we would say, wouldn't we, that people constantly underestimate a number of key things, one of which is the agile challenge. That's a big thing. I know it's overused in this context, but it is really important. And secondly, the technology decisions. So you kind of think everything else stems from that. You appoint your SI on the back of the technology, you appoint your SI on the back of agility, capital A or not. And therefore, your program, the root of all evil, are the early day decisions that you make. So getting some external perspective, not just on making the right decision, but also putting the governance framework and financials around the project, I think, can be
Mark Pinkerton [00:33:49 - 00:34:03]
Because you're therefore setting expectations and actually it might help align everybody internally so that they have an understanding of how are you going to validate whether or not this is on course or or not on course. Yes, yes, yeah, okay.
David Worby [00:34:02 - 00:34:40]
Yes. Okay, right. Let's move on. Time is pressing. Let's move on to the final section here. We just wanted to give our listeners some thoughts and ideas around how best to mitigate risk. And if we kind of broadly bucket risk in this context as falling into the commercial stuff, things can cost a lot more than you think. Time, that's often one. Things do tend to take an awful lot long. With one of our clients, a six-month project became a three-year project. That's obviously extreme. And there's also the quality perspective. So how do we give some of our listeners, Kev, some thoughts on how to manage the risks associated with those three things?
Kevin Muray [00:34:41 - 00:35:53]
A lot of this, let me go back to this trust and obviously having a partner to be able to assist with what the selection process looks like is very important and as part of that, you know, one of the examples being, which I still found very interesting, is that you're going to pick a partner you're going to do a lot of work with and no one does their reference calls. So there's an element of saying hey speak to other people who have done this before, ask them about how long did it take when you were quoted versus when it was delivered, what was their quality like. Also, particularly if you're already talking to the technology, if you've already chosen your technology, ask the vendor why is this SI one of your preferred or have you suggested them. It's about asking as many questions as you can and as I said if you don't know the questions to ask, you bring an expert like Prospera who's going to be able to help you ask those questions. But you've also got a level of chemistry. Are they going to work well with you? I always took the approach that with customers, something is going to go wrong. Prepare yourself for that but also be aware that it's the reaction of when something goes wrong is more important than in some way trying to prevent it because something will always go wrong. I'm more interested in when things go really badly, what are you going to do to fix it?
David Worby [00:35:54 - 00:35:59]
And therefore asking for a reference of when things go bad is probably more useful than plane sailing.
Kevin Muray [00:35:59 - 00:36:14]
yeah i mean look it's very easy for somebody to be able to give you references of where things were brilliant you know what as for really challenging which is when things weren't great um give me that phone number to someone i can call that will also say hey things went really bad and this is why this is what they did to fix it yeah okay
David Worby [00:36:15 - 00:36:50]
Mark, on the challenge of a business out there who is embarking upon this program of change, but who wants to take ownership of the end result, therefore they're in a phase during the program towards the end of knowledge migration, how would you encourage them or get them to think about the risks associated with this project? Because they're ultimately going to be running it, they're going to be doing it at the end, they're not going to have an SI there to pick the phone up to and say what you will, but in reality they're not there, they're on to something else. What risks associated with that transition would you encourage? I think that's a...
Mark Pinkerton [00:36:49 - 00:38:02]
I think that's something that has got considerably more difficult as time has gone on because agile promotes delivered code over documentation so the more agile things become the less documentation you have about it and certainly in a retail environment that you know many of our clients are in you've got staff migration happening all the time so you have this corporate amnesia even if you have stuff documented you've forgotten about it in about three years because all the staff have changed so in that environment making sure that you have some way of migrating knowledge not just one-on-one because they're working together in a team but having some sort of wiki or universe or university in the background that actually records things even in a relatively informal way you know here's a video and some screenshots of me doing x y or z because it was tricky is enormously valuable it gives you a reference point to go back to because it's related to your specific instance your specific combination of technologies okay that makes sense
David Worby [00:38:02 - 00:38:05]
That makes sense. I mean, that's another reason why I hate agile.
Mark Pinkerton [00:38:05 - 00:38:10]
Yeah I mean you know the other risks that you're talking about are going to be dealt with by a
David Worby [00:38:05 - 00:38:06]
Yeah, I mean, you know,
Mark Pinkerton [00:38:10 - 00:38:40]
reasonable amount of program governance but you've got to be capable of looking at it from both a technology point of view and a commercial point of view. We were talking off, I was going to say off camera, but off mic earlier about a client who had six risks for their project and then by the time we'd spent three weeks with them we'd identified 86 risks with them because they weren't considering the commercial risks of what they were doing which were actually far greater than the technical risks.
David Worby [00:38:40 - 00:38:47]
Yeah, that holistic view is often forgotten about. I guess the final kind of risk mitigation thought
Mark Pinkerton [00:38:43 - 00:38:43]
Yeah.
David Worby [00:38:47 - 00:39:28]
we want to leave our guys with, particularly in this very uncertain world, was the extent to which your SI or your development capability may be distributed amongst parts of the world. It not only gives you potentially 24-7 capability, which is sometimes quite helpful when you're coming to deliver code, but also it mitigates the risk of awful things happening in certain parts of the world. I think we just throw that one in there. If that's possible, it's an advantage. If it's not possible, it's not the end of the world, but just be aware of it. Okay, all right. Okay, look, I think time has beaten us. We've come to the end of it now. So I'm going to say thank you to Mark and Kev. Thank you very much. And join us again on the next one.
Other similar Episodes in Season 2:
Episode 3 - Understanding headless and Compossable
Episode 2 - Strategy and Planning
Episode 6 - Optimising physical and Digital
Articles you may be interested in from Our Blog:
Why do many Headless/eCommerce strategic initiatives fail - 8 key reasons
Man vs. the Machine: The Future of AI in Retail and Digital Commerce