Project Management VS Service Management

[MUSIC] In this segment we're gonna be taking a look to bring some clarity to the difference between project management and service management. And here to help us, is Ms. Jo Peacock. So Jo, what is the difference between project and service management? Well, I was gonna just turn around and say well, I'm really glad you asked. But I can't do that. [LAUGH] But, I'm sorry I can't do that. [LAUGH] The reason why I invited you here, all right get this, the reason why I invited you here was really because of the fact that I've had a lot of questions as a result of some of the shows that we've been doing, that really asks us what's the difference between the two. Because obviously obviously I've covered a lot of service management with the ITIL stuff and then project management as well with Agile and we're gonna, PRINCE2, etc. Well we're in IT and in IT we're on two teams, right? You know this? Sure, we'll go with, I'm gonna play dumb on this Jo, so you can make sure to bring us some clarity. He doesn't have to play. [LAUGH] [LAUGH] But we got two teams here in IT, for the most part. Now, I don't like admitting that, and I'll be the first one to stand here and preach about, no we shouldn't have two teams. But the fact is we do. We've got our development guys, who don't like to talk to our operations guys, who don't like to talk to our development guys. Yeah, we got two different teams. And we've also got two different frameworks or types of frameworks. We've got service management and ITIL and ISO 20000. And then we've got Agile, and PRINCE2, and PMI, that look at the development side of things. What we've been trying to do over the past few years is actually bring the teams together. Which is why I spend a lot of time preaching about how we should be working more collaboratively and more as a cohesive team, one team. But essentially we've got two sets of methodologies. We've got methodologies that look at project management, and they focus on development, and they focus on all of the software development tasks. Now that's something that you know about, right? That is something that I know about, and it seems very kind of applicable. It seems easy, to put into those scopes, but if you're talking about an operations task, is this something that we could bring over to operations? Right, so operations tasks, and that's what we cover with an ITIL. ITIL is a framework for managing our services. So once they've already been developed, and they're developed by our development guys using project management methodologies, then they are moved into operations. And that's when ITIL takes over, and that's when service management methodologies take over. So that's when we have processes that deal with how to pick up a phone when somebody's got something wrong. How to deal with service requests for instance, when they want something like a new server, or when they want a new laptop, or when they want access to something, that maybe they shouldn't have access to. [LAUGH] How to deliver the services in a business as usual environment. So when to take back ups, how often we should be taking back ups, the type of back ups we should be taking. And what to monitor in event management, and so what our server logs should be recording, that sort of thing. So that's all what we call business as usual. And that is part of service management. Whereas a project are managed by, well, project management guys. That's the software development. So Justin, you're a developer. And I'm not gonna hold that against him. But you're a developer, let's face this. Do you like dealing with the business as usual side of things? So Jo, that's one of those things where for me in particular, it doesn't bother me just because of my background. If I have to answer a phone call, I have to speak with a customer, that's okay, I'm not big on provisioning or managing permissions, but I will do it. And having an acceptable set of practices is fine, but are these always as mutually exclusive as you've put them? Where I have these set of practices that always apply on this side and I have a set of practices that always apply on this other side, is there ever like a co-mingling of the two? Well you know the funny thing is I was goading you on this last particular question cuz I'm just mean like that. And I know that, I'm all right with that. No they shouldn't be mutually exclusive. And this is the challenge that you've got. And I've said we got two teams, and I opened this up saying we got two teams. And then I also said that I stand here and preach that we shouldn't have two teams. Because at the end of the day, you mentioned one word which is really important, and that is the word practices, [BLANK_AUDIO] It's a practice, it's a process, it's something that we do. And just because I've given you a label of a developer, and you can give me a label of somebody in operations, just because that's my label doesn't mean that that's what I have to do exclusively. And so as a developer you should be able to do operations tasks. As somebody in operations, I should be able to contribute to the projects, and have some contribution to the way that things are developed. Because I know the users better than you do. But at the same time, you know coding a lot better than I do. But then we've also got individual tasks. Like I had somebody ask earlier on today about a stand up, why don't we do a stand up every morning? Well, that's something that's featured in Agile. It's something that comes in Scrum. And is it useful every morning in a service desk, for instance? Well yeah, why not? I mean, that's something that's gonna be very useful to you at the beginning of the shift isn't it? Just to know, to understand exactly what you're planning today outside of the answering the phone calls perhaps, yeah, really useful. So why not? And what about things like request fulfillment? If you've got a request for a new piece of functionality, well then why can't you bring that process in and put that into development? It works fine. And I can see how that could be helpful, right? So if you're in a operations kind of a services role, just give me a quick overview of what I've accomplished, what I'm gonna do next. If nothing else, it's really helpful for me when we did stand up, it helped me cement what I was trying to accomplish for the day, even if it wasn't for anybody else. Well the idea of a stand up is to tell everybody what you're doing for the day and it's also to highlight any problems that you might have. And it gives other people in that stand up the opportunity to say, hey look, I've got those skills, I can help with that. And that's exactly what it should be doing. That stand up really it's something that you can use on the service desk. It's something that you can use when you're doing, say, service level management. It's something that you can do within a project team as well. There's absolutely no reason then why you cannot take something that works, and this is really the key message, if it works, then use it, and use it wherever you want. And ultimately, what we gotta try and remember is that even though we've got two different methodologies, we've got project management methodology that looks at the development and looks at the bringing in the new project and bringing in a new service. And you've got service management that looks at the maintaining it, business as usual going forward. They shouldn't be mutually exclusive. And yeah, we we really have gotta work together. Well, Jo, thank you so much for bringing a little bit of clarity that we shouldn't just kind of silo ourselves into these two respective roles, and that blending our talents together can actually bring a better feel to our business. And hopefully you've learned a little something as well. But we're gonna go ahead and get out of here, so we'll see you later. [MUSIC]