Share this
What should you expect from your IT service provider?
by Ray Cooke on 10 May 2016
As a business representative you are no doubt continouously looking to improve your organisation. Today any change often involves new or updated technology and requires you to engage with IT service providers. So in this Blab we answer the question "what should you expect from your IT service provider?".
You may also be interested in our previous Blab question on this topic IT services in solution delivery - How do you get the best results from your provider?
Blab presenters
Our presenters during the Blab presentation are:
- Top Left-hand side: Ray Cooke, Lean and Agile business transformation coach, Equinox IT Wellington office
- Top Right-hand side: Carl Weller, Senior Consultant, Equinox IT Wellington office
- Bottom Left-hand side: Paul Ramsay, Principal Consultant, Equinox IT Wellington office.
Transcript of conversation
Ray: So let's move on to. I guess we've already started answering some of these questions about...so the next one's coming up in the Twitter feed now, which is, "What should you expect from your IT service provider?" Should and can, I suppose. That's obviously dependent on the IT provider as much as it is on what you're asking them for. So we started talking there about analytical services and helping you scope that initial problem, and I guess coming up with things like elevator pitches and vision statements for the problem, and scoping that out and defining it.
And we talked a bit about assumptions there and testing those and defining what they are. I guess the opposite side of that, then, is being able to measure that you are in fact delivering on the assumptions that are implied in that, so the benefits you're expecting to get out the other end. So being able to test those. So from a services standpoint, what can we expect from a solution delivery organisation that we engage with? What should we expect?
Paul: I think a couple of quick observations here is that we're talking about services here, which is very different to products. It's much easier when we go and buy something that we can physically see and use and kick. With services, you're much more reliant on the capability of the organisation that you're working with. So an important consideration is that you are actually using the right provider to work on this particular problem or issue with you. A good provider who doesn't have the necessary skills or it's not in their line of business would be one that would say straight up, "Look, this is not something that we would do," but they may well be in a position to recommend or refer someone else.
So a key initial consideration is that the provider has the necessary skills and capability to undertake the work. The link to that, because you're not dealing with something as concrete as a product, you need to have a very clear basis of engagement, a statement of work, or terms or reference that really clearly sets out what you are going to undertake in terms of the provision of that service.
Ray: I think there's a lot of interesting talk around that. I'd actually like to park that particular conversation for slightly later on because we've got a question specifically targeting that later, which is the kind of contract types that might best suit that IT delivery, because I think there's an awful lot of problems that can be serviced as well as solved by putting that right commercial engagement in place.
So on this question, in terms of expectations, I guess if I was a business representative and knew relatively little about IT delivery, as I imagine most business representatives do, unless they've engaged with IT delivery before. I've kind of had that eureka moment and I've gone, "I've got an idea. I want to do this thing." Typically as a dev manager, I've been engaged a lot further down the line, and at that point, there have already been contracts and commercials put in place, there have already been project managers engaged, there have already been all sorts of other things done plausibly that don't necessarily get delivery off to the best footing.
So I guess what I'd like to be able to answer for business representatives is early on, from that eureka moment onward, what can they get from an IT department to help them ensure that successful delivery later? So part of that is the analytical skills we were talking about earlier from initially being able to provide business analyst services from a helping you analyse and scope the problem through to further down the line. Any thoughts on that?
Carl: You're really describing more of a partnership model rather than, say, someone whose sales team comes and listens for 10 minutes and says, "Aha, I know what you need. You need five of those and two of these. Sign here, please." If that's the scope of your piece of work and that's the engagement you want to have, then that's fine. On the other side though, there are things that, while they're not toasters or microwave ovens, they're also relatively straightforward. You may simply be wanting some resource to help you on a project where another one of your partners is directing that resource. So I don't, like everything in our business, the answer's, "It depends," and it really does depend on a lot of different things.
Paul: I was just going to say I guess Carl's touched on a couple of important points there. One is the nature of the potential problem that you're dealing with here. Is it relatively simple and straightforward? Or is it likely to be much more complex? Another thing that you alluded to as well, Ray, is who needs to be involved in the resolution of that problem and coming up with a solution? And have you consulted and worked with them to make sure that you have collectively understood what needs to be done?
In terms of the kind of work, in some cases it may be just a capacity question. The organisation doesn't have the capacity to do it. It has the capability, but the resources are potentially of being used on something else, so you need to get somebody in. That's where you might look at a contract-based relationship. So it's much more transactional, as Carl was talking about before. If it's a lot more complex and it's likely to require a specific capability and that's the difference to the capacity issue, it's about a capability issue now, then you need to look at that and understand that quite carefully because you approach the sourcing of those resources quite differently.
Again, as Carl alluded to, if you're talking with a business partner, they will have a good understanding of your organisation, they will be looking to understand the nature of the problem, and based on that understanding, then say whether or not they can help. So it's not just a sales pitch. You're actually looking for a partnership-based relationship with that provider, and I think that's really important.
Ray: Yeah, and being able to build that mutual trust. I suppose there's an interesting question there, which is, and I'm probably just about to pre-empt myself for the next question, which is about picking the best IT services company for your delivery needs. So I might stall that slightly, but the question there around actually being able to determine how do you know whether you can trust somebody. But yeah, I've just jumped ahead of myself again there.
So I guess the kinds of services you might expect for more bespoke delivery, say. So it is a lot easier if you're installing Outlook or you need help, you just want somebody to set up a load of desktops, that sort of thing, but something more specific to your business problem, business need that's more unique, say, and requires, even if it's bespoke on top of a COTS product or something like that, so solution delivery that's more unique. In terms of the services there, I guess there's obviously that engagement and building that relationship, which is very important, but also assistance in breaking down your idea. I mean, you kind of need to know from the outset how big is this thing.
"Am I thinking $100,000 or am I thinking $2 million?" those kind of open-ended early questions. So I'd like to think that IT service providers should be able to help with those kind of work breakdown estimation problems as well early on. Are there any other services that you think from an early engagement standpoint we should be able to expect from IT?
Paul: I guess a couple of observations would be that it depends, as Carl rightly pointed out before, it depends on the relationship that you have with your current providers, for example. Is it within their particular skill set and capability? If it is, I think it's a very different conversation than it is if you are looking at skill sets outside what is necessarily known either within the organisation or within your current provider set where, you are then looking at a procurement consideration and, "How do I go out and procure those services?"
I guess the other thing is, too, that the nature of our market is such that...very strongly based on reputation and relationships. So even within your internal IT team and with other people in your business, they will know other organisations, other people, other providers who may have skills and capability in that area. So you can go informally on that basis or there might be rules surrounding procurement within your organisation. As you said before, if it's a particular level or particular duration or financial threshold, you have to go through a much more formal procurement process. So a lot depends on the way that you approach that problem and the scale of that particular problem.
Carl: You can also make choices about how much of that problem you tackle at any one time. So let's say I am in a space where I'm a little bit unclear about the dimensions of my problem and I need a bit of help. Well, you can contract that piece of work. You can either go to vendors you already have or you can put it out to market, but more in the sort of, "Help me understand the dimensions of my problem, maybe proof of concept," just something to get you to the next point so you don't have to bet the whole farm on one procurement.
Paul: Yeah, and I think that's a really good observation that Carl makes. If you don't understand fully the nature of the problem or the challenge that you're facing, then it's much more prudent to actually break it up in that kind of way, because trying to estimate, going back to your comment before, Ray, in both time and cost when you fully haven't understood either the complexity or the nature of the problem to be solved, you know it's going to be wrong.
So it's much better to break it up, as Carl had suggested, into discreet pieces of work. So let's look at the initial elaboration phase. Let's make sure we've fully understood the problem, and let's treat that as a discreet piece of work. Once we then know what we need to do, let's go out for the tendering of that doing component, the construction or configuration stage. That way you can break it up and you can both manage the commitment and the cost.
Ray: Absolutely.
Share this
- Agile Development (153)
- Software Development (126)
- Agile (76)
- Scrum (66)
- Application Lifecycle Management (50)
- Capability Development (47)
- Business Analysis (46)
- DevOps (43)
- IT Professional (42)
- Equinox IT News (41)
- Agile Transformation (38)
- IT Consulting (38)
- Knowledge Sharing (36)
- Lean Software Development (35)
- Requirements (35)
- Strategic Planning (35)
- Solution Architecture (34)
- Digital Disruption (32)
- IT Project (31)
- International Leaders (31)
- Digital Transformation (26)
- Project Management (26)
- Cloud (25)
- Azure DevOps (23)
- Coaching (23)
- IT Governance (23)
- System Performance (23)
- Change Management (20)
- Innovation (20)
- MIT Sloan CISR (15)
- Client Briefing Events (13)
- Architecture (12)
- Working from Home (12)
- IT Services (10)
- Data Visualisation (9)
- Kanban (9)
- People (9)
- Business Architecture (8)
- Communities of Practice (8)
- Continuous Integration (7)
- Business Case (4)
- Enterprise Analysis (4)
- Angular UIs (3)
- Business Rules (3)
- GitHub (3)
- Java Development (3)
- Lean Startup (3)
- Satir Change Model (3)
- API (2)
- Automation (2)
- Scaling (2)
- Security (2)
- Toggles (2)
- .Net Core (1)
- AI (1)
- Diversity (1)
- Testing (1)
- ✨ (1)
- August 2024 (1)
- February 2024 (3)
- January 2024 (1)
- September 2023 (2)
- July 2023 (3)
- August 2022 (4)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- March 2021 (1)
- February 2021 (2)
- November 2020 (2)
- September 2020 (1)
- July 2020 (1)
- June 2020 (3)
- May 2020 (3)
- April 2020 (2)
- March 2020 (8)
- February 2020 (1)
- November 2019 (1)
- August 2019 (1)
- July 2019 (2)
- June 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (1)
- December 2018 (3)
- November 2018 (3)
- October 2018 (3)
- September 2018 (1)
- August 2018 (4)
- July 2018 (5)
- June 2018 (1)
- May 2018 (1)
- April 2018 (5)
- March 2018 (3)
- February 2018 (2)
- January 2018 (2)
- December 2017 (2)
- November 2017 (3)
- October 2017 (4)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (1)
- May 2017 (1)
- March 2017 (1)
- February 2017 (3)
- January 2017 (1)
- November 2016 (1)
- October 2016 (6)
- September 2016 (1)
- August 2016 (5)
- July 2016 (3)
- June 2016 (4)
- May 2016 (7)
- April 2016 (13)
- March 2016 (8)
- February 2016 (8)
- January 2016 (7)
- December 2015 (9)
- November 2015 (12)
- October 2015 (4)
- September 2015 (2)
- August 2015 (3)
- July 2015 (8)
- June 2015 (7)
- April 2015 (2)
- March 2015 (3)
- February 2015 (2)
- December 2014 (4)
- September 2014 (2)
- July 2014 (1)
- June 2014 (2)
- May 2014 (9)
- April 2014 (1)
- March 2014 (2)
- February 2014 (2)
- December 2013 (1)
- November 2013 (2)
- October 2013 (3)
- September 2013 (2)
- August 2013 (6)
- July 2013 (2)
- June 2013 (1)
- May 2013 (4)
- April 2013 (5)
- March 2013 (2)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (1)
- October 2012 (2)
- September 2012 (3)
- August 2012 (3)
- July 2012 (3)
- June 2012 (1)
- May 2012 (1)
- April 2012 (1)
- February 2012 (1)
- December 2011 (4)
- November 2011 (2)
- October 2011 (2)
- September 2011 (4)
- August 2011 (2)
- July 2011 (3)
- June 2011 (4)
- May 2011 (2)
- April 2011 (2)
- March 2011 (3)
- February 2011 (1)
- January 2011 (4)
- December 2010 (2)
- November 2010 (3)
- October 2010 (1)
- September 2010 (1)
- May 2010 (1)
- February 2010 (1)
- July 2009 (1)
- April 2009 (1)
- October 2008 (1)