IT services in solution delivery – How do you get the best results from your provider?

Many organisations work with IT service providers when undertaking solution delivery projects. Solution delivery can be complex and working with IT service providers can be an important factor in the success or otherwise of a project. So in this 7 minute recorded Blab we explore the question 'IT services in solution delivery - How do you get the best results from your provider?'' 

You may also be interested in our article How to pick the right IT consulting company in New Zealand.

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, Equinox IT Wellington office
• Bottom Left-hand side: Paul Ramsay, Equinox IT Wellington office.

Transcript of conversation

Ray: Welcome to our latest Blab session on procuring IT services for solution delivery, how to set and manage expectations with your solution provider. We've split this up into four questions. I've got Paul Ramsay and Carl Weller joining me, Ray Cooke, here from Equinox IT. We'll see if we can't cover this off.

The first question we're going to cover is coming up in your Twitter feeds now, which is "IT services and solution delivery, how do you get best results from your provider?" When we were putting these questions together, I realised after the event and Carl pointed out that actually this is quite generic. But I was trying to get at how to pitch the problem idea to your IT solution provider rather than just the generic getting better results. So for example, not necessarily talking about a full-blown solution when you start off with and present a problem and options as opposed to necessarily having to come up with a technical solution yourself.

Paul: Yeah, I was just going to say I think that's a good observation in the sense that the initial starting point is generally around "What's the nature of the problem or the challenge or the issue that I'm currently experiencing or encountering?". And also being mindful, too, that that needs to be explored and probably drawn out a little bit in the sense of what you may often see in the first instance isn't actually the problem but a symptom of the problem.

The thing is, if you leap into solution mode, as you were suggesting before, Ray, the challenge is that you end up building a solution to a problem that doesn't exist or you end up building a solution to the wrong problem. So I think there is a process that you need to what you think is the problem, and I think a good IT services provider will also work with you to explore that in further detail and get you to a particular solution.

Ray: Yeah, I guess at the root of at there are some assumptions, aren't there? So as an IT provider and as a business person, you may well have assumptions about what it is that...if there's a solution for example, then there may be an assumption about the problem they're trying to solve and there may be an assumption that leads into a certain solution, and testing that assumption, working out what those assumptions are, is very important. I suppose, as an IT solution provider, a kind of well-rounded one that has analytical skills and those sorts of things, that can help you with assessing what those assumptions might be and come up with cheap and easy ways to test those assumptions if they're not necessarily certain.

Carl: One thing you do have to do for yourself, though, because a provider can't necessarily help you, is understand what your bottom lines are. So this is not a 100-page requirement document, but it's understanding whether you're time-constrained or there are must-have features that you want, whether you'd consider you're buying a commodity service, which may put you in a different engagement framework with your IT provider, rather...or if you're genuinely buying advice and assistance, and as Paul said, help defining the problem before you jump to solve it, then you've got to be in a different space.

Paul: And I think that observation you made as well too about testing out the assumptions, too often people don't actually even track them, let along test them out, and we make an awful lot of assumptions when we do things. It's like that hackneyed quote of, "If you assume, you make an ass out of you and me." So, early testing of those assumptions. I think one of the other considerations as well is what's the boundary of the problem? So sometimes too narrowly defined you may not actually end up solving the real issue.

Mind you, too widely defined and you're trying to solve world hunger on the other hand. That's not attainable either. So making sure that you've defined the problem well, you've understood it well, you've understood the assumptions that you've made, and you've also scoped it appropriately, is really important. The other observation that Carl made is knowing what's important to you. So before you even move into that solution mode, knowing what are the key criteria or key conditions that are important for your organisation.

Ray: Yeah, and I suppose you don't necessarily have to come to the table with all of those answered, but kind of being aware of that and that there are going to be assumptions there and you won't necessarily have to have scoped the entire problem you're trying to solve, but being able to have that discussion and to be able to come to a conclusion. I think that's, I guess, open-mindedness. Open-mindedness is kind of fairly key in that early engagement.

Carl: Another thing a good provider will help you with is you have to ask the fundamental question, "Is an IT solution actually the best and most efficient solution to the problem that I think I have?"

Ray: Yeah, and probably only part of the problem as well, to be fair. It's generally unusual to be specifically about the IT solution as there's a wider business change that it's trying to address and a wider business problem, perhaps, and IT might just be one part of that problem.

Paul: I think another thing that Carl alluded to there as well is being able to answer those fundamental questions, the why, the who, the what, the how, and the when. Those are really quite key questions that you need to be able to answer, and part of that is going through the root cause analysis or asking yourself the question, "What is the outcome that we're looking for here? Why are we doing this? How would we approach this particular issue or challenge?"

Ray: Yeah, absolutely.