What should you expect from your IT service provider?

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.