Ooo Shiny Shiny — Keeping IT Projects In Check | SolarWinds TechPod 090

Stream on:
Mark Roberts, Technical Director of Prosperon Networks, joins hosts Chrystal Taylor and Sean Sebring to salute the unique challenges of IT project management. From the joys of scope creep to the intricacies of wrangling leadership buy-in, they cover the life of a project from initial discovery process all the way through to project handover. © 2024 SolarWinds Worldwide, LLC. All rights reserved RELATED LINKS:
Mark Roberts

Guest | Technical Director, Prosperon Networks

Mark Roberts has been working as a specialist monitoring consultant with SolarWinds solutions since 2001. As owner of Prosperon, a UK-based SolarWinds Elite partner, he… Read More
Chrystal Taylor

Host | Head Geek

Chrystal Taylor is a dedicated technologist with nearly a decade of experience and has built her career by leveraging curiosity to solve problems, no matter… Read More
Sean Sebring

Host

Some people call him Mr. ITIL - actually, nobody calls him that - But everyone who works with Sean knows how crazy he is about… Read More

Episode Transcript

Chrystal Taylor:

Welcome to SolarWinds TechPod. I’m your host, Chrystal Taylor, and with me as always is my co-host, Sean Sebring.

Sean Sebring:

Hi Chrystal.

Chrystal Taylor:

Hello. Today we want to talk about a topic that’s ever-present in IT, whether we like it or not, project management. We’ve invited Mark Roberts here today to share insight from his wealth of experience as a SolarWinds partner in handling this often Herculean task. Mark, can you tell us a little bit about yourself?

Mark Roberts:

Yes, certainly. And thank you very much for having me. My name’s Mark Roberts. I’m the owner of Prosperon. We are SolarWinds resellers, elite partners based in the UK. And proud to say that we’ve been working with SolarWinds for our 19th year. Big numbers.

Chrystal Taylor:

19?

Mark Roberts:

Yeah.

Chrystal Taylor:

That’s exciting.

Mark Roberts:

From our point of view, we work with clients all over the world, deploying SolarWinds to best practice and really getting them to make the best of the solutions.

Chrystal Taylor:

I have worked with you, I talked with you on a number of occasions and we always have great conversations, I’m really excited to dig in a little bit to something that is a thing that we have to deal with. And some people are not very good at it and other people are very good at it. And I know you have a lot of advice and expertise to share in this topic, I’m excited to dive in.

Mark Roberts:

Looking forward to it.

Chrystal Taylor:

Let’s start with setting our basics. What do we think of as project management in IT?

Mark Roberts:

Certainly this is something we fundamentally have. There is no getting away from the fact. You could do project management yourself. When you are delivering something, when somebody comes to you with a task, you have to project manage yourself, you manage your time, you manage your resource, you manage, “Have I got the expertise? If not, do I go and attain them?” And that’s for me a very basic starting point. But when we’re talking about the customers that we work with, it’s that elevation up. It’s having a true understanding about how do we go and deliver a successful implementation of, obviously in our world, that’s a successful implementation of a monitoring platform, SolarWinds platform. We see the importance of good quality project management in making that delivery a success. If we don’t have it absolutely impacts on what we achieve in the time, in the available budget, in the objectives, so many things are affected by project management, but let’s say fundamentally it’s inherent in everything we do in our working lives.

Sean Sebring:

Would you say that more often than not when you’re engaging, obviously if you were engaging, you’re supplementing or acting as the project management, but from your experience, do you think that project management is forgotten or just left behind more often than not when you’re engaging with IT projects?

Mark Roberts:

I think it’s one of those things which can be sidelined too easily and too rapidly. With our customers, we don’t always have the luxury of having an assigned project manager. As much as we would love it, as much as we know the benefits of it, the customers don’t always have the resource, the time to do so, and sometimes it’s not even necessary to that level. But we always need to be able to strive to get a single point of contact. When we are delivering an HCO deployment or whatever it may be, we will always ask for who’s going to be our point of contact?

Mark Roberts:

Because we want to focus on one person, obviously with backups, but one person that is going to be our liaison, our voice, and who we can liaise with to make sure that schedules are understood, timelines and milestones are understood, how the project needs to be shaped. Say from when the project is additionally defined, that’s what we look for because we know we need that to operate. Those circumstances where it’s very much a freeform thing, yes, you can achieve if you’ve got the expertise and you’ve got the experience, you can go and deliver. But is it really going to achieve everything that you can do with proper controls in place? No.

Sean Sebring:

To follow up on that, I have my own reserved opinion on this, which maybe you’ll agree and then I won’t have anything to say. What are your thoughts on project management and IT project management? Sometimes I’ve seen a differentiation between the two or a dedication to IT project management is another way to put it, but what are your thoughts there?

Mark Roberts:

Certainly IT has its own specifics. If you are looking at project management from a software development point of view, I would say that’s fundamentally different from delivering a piece of written software and implementing it to project management, how you deliver training to the team. They are all individual elements of a larger project. And invariably there are different people, different stakeholders, different skills that are necessary to deliver on that. I see projects, certainly the bigger ones, we hear all too often about going over budget, going over time, not delivering everything they need, getting halfway along and millions has been spent, I’m talking the government and large enterprise projects and they get stopped because they identify that they’re not on target. Fundamentally, all of that is, for me, all too common around the quality of the project management from inception through the implementation.

Sean Sebring:

I have one last follow up on this and I am plugging here. Is there an ITIL term for something that’s very closely related to IT project management, particularly a practice for managing changes?

Mark Roberts:

Are we referring to frameworks here or where are you going?

Sean Sebring:

I was going for change management.

Mark Roberts:

Sorry, I thought you were going down Agile and Scrum and those kinds of things.

Sean Sebring:

It’s coming more and more into ITIL. But change management in a way, I relate personally when I’m talking to people about project management when they ask, it’s very close in the IT world because you mentioned some of the key components which is single point of contact, which could just be your system of entry for the IT changes and then your standardization of the workflows, your communication, the scheduling. Those elements right there is all, it’s very close in IT project management and change management. Again, I’m an ITIL guy, I wanted to plug that, but what are your thoughts?

Mark Roberts:

Now I know where you’re coming from on the service desk side of things. Absolutely, change management is everything about control. It’s about what are we changing? Why are we changing it? What’s the risk to the change? What’s it going to deliver? Is it going to improve? Is it going to adjust the way that processes go in and out of something? Without change control then people don’t understand where and why and how things have been gotten to and that’s fundamentally what we’re talking about projects. The projects are there to change, they’re there to be different in how you used to do things.

Mark Roberts:

We’re implementing new software, we’re implementing new hardware refreshes. That from a project management point of view in my eyes is something where when we see halfway through the timeline and we’re now starting to implement and we’ll get given a project manager, and they have had no history on that previously that affects the quality of a project because they haven’t got all the knowledge, they don’t understand the whys and where falls, and they’re basically being parachuted in just to be an organizer. That is a very limiting scope I would suggest for project management.

Chrystal Taylor:

I have a comment for that that just popped into my head and then I want to circle back to something else, but that reminds me of the difference between a wedding planner and a day-of wedding planner. If you’re being parachuted in at the last minute, you don’t have all the information. Someone gives you a dossier that says, “This is all the things that are supposed to happen,” but you don’t have the connections, you don’t have the information, you don’t have all of the relationships built that you need to have with the vendors and that stuff. And I think that the same thing would apply here of you don’t have all that stuff, you don’t know who the vendors are, you don’t have the experience of working with that other person or other people, in most cases it’s multiple groups.

Chrystal Taylor:

But I want to circle back to something you talked about earlier, which is we’ve been talking about project management a lot, but earlier you mentioned that you can’t always have a project manager on the project. What is the importance of the role of a project manager if you’re still going to have to do some level of project management with or without them?

Mark Roberts:

When you’re do self-project management, if my boss came to me and said, “Look Mark, I want you to go and deploy the SolarWinds Service Desk or the HCO and you’ve got three months to do it and you’re going to have these resources.” I’d look at that and go, “I’m an IT guy, I know my network.” If I’m the network engineer. I know my systems, if I’m a systems engineer, I hope. Not always the case. Move on.

Mark Roberts:

And from that point of view, it is very much my window on that world. It’s very narrow, it’s not strategic. I might not have the bigger picture in terms of what the business needs. I’m looking at it from what I need. I see a project manager at the start of that whole process to be the facilitators that bring different voices and different opinions together and control them and help them and organize them so that there is a consensus about what moves forward. Now clearly decision-making around what the solution should deliver is a management function, but once that has been defined and the project manager’s aware of all of those goals, it’s their job to then go and deliver to those goals, whatever that looks like.

Chrystal Taylor:

You said there, “Once that’s defined.” That’s a big part of the process of defining our terms, defining the scope of projects, defining the expected outcome and defining the expected timelines. And it’s incredibly important that everyone be on the same page at all times about what those things are and it’s so challenging.

Mark Roberts:

And as I say, we could go slightly off-topic in the sense of leadership and dictating and defining what the project end-result should look like. But let’s say from a project point of view, when we are talking to clients, often we’ll have an expression thrown at us, in a nice way, “Look, we trust you guys, you know what you’re doing, you’ve been doing this a long time, put in best practice.” And absolutely we can bring our knowledge and experience of what we do with other customers, what the common way of achieving certain goals is, but we don’t know that business. We don’t know the processes that they have. We don’t don’t know the way that they respond to certain issues.

Mark Roberts:

From a monitoring landscape, and if I keep it to that, because that’s obviously our main area, we can very easily just put this into a ballpark and go, “Go off and deliver.” But we don’t have all of those answers to do that. We can bring 80% of that gain to it, but we need the involvement of customs. And that then loops back to the beginning of, “What is the starting position? Where are we working from?” Invariably in IT, nobody’s just starting from a green field. They’ve already got tooling in place, they’ve already got knowledge and understanding, they’ve already got something there.

Sean Sebring:

A lot of what you’re saying is just a term I use in pre-sales, which is discovery. And I think when Chrystal was listing off a few of the things that need to be kept in mind, like the scope and things of that nature, those are part of discovery. But there’s oftentimes I find when I’m working with my customers and they’re bringing up a project, there’s not enough discovery. One of the things that I can do best to help them is ask questions they didn’t even think to ask. As a project manager asking the deeper questions, which sometimes could just be about the infrastructure, the technology itself, or if you’re really trying to do the best work for project management, is talking about strategy. Like you’re making this decision, have you thought about what you’re going to do for these next things that will potentially be related or touch these systems?

Sean Sebring:

Not just what is the project for today? Because you have a project and outcomes you need to meet today. And that’s fine. We’ll get there, but what are the next projects because maybe we can make a better strategic decision on how to execute this project so that it sets the next ones up for success. And oftentimes when you’re talking to an initial stakeholder, they only see the objectives right in front of them, not how to use this project to prepare for the next set of objectives.

Mark Roberts:

And if I relate that to how we work with our customers, our ideal situation is that when we’re engaging with a customer and doing the discovery process, they’re going to come with a list of known requirements, “This is what I know I want to achieve.” We’ve got this tool, whether it’s an existing tool or we’re improving it or as I say, we’re replacing something, they have that list of known requirements. But what we will always do is say, “What we’re going to do is come and present the art of the possible.” My analogy is common. I’ve been using Word for a few years. I nearly said a number there, but I’m going to move on from that.

Mark Roberts:

But I’ve been using Word for many, many years. I don’t use anywhere near the level of capabilities of, I don’t need to. I do everything that I am aware I need to use it. There’s probably many, many things that I could benefit from knowing more about Word, but unless somebody tells me that I’m not going to use them. We’re very much there to make sure that people can understand what is achievable, help define that process, what does the plan now look like? We’ve done the discovery, we know what you want to achieve, we’ve told you how much more you can do with automation and integration and AI and whatever else. Now we’ve got this definition.

Sean Sebring:

Right now, I was thinking about how technical discovery can go beyond just the technology or the immediate objectives that we see in this project. How is this project potentially going to impact future strategic decisions and projects? What are your thoughts there?

Mark Roberts:

Again, invariably IT projects are not siloed. And certainly again in our world when we’re talking about a monitoring platform, management platform, it doesn’t just run in isolation, it goes north-south functionality, integration to other systems and processes. Everybody has to be aware. And I mentioned it before this understanding about what the goals are, who the people that need to be involved are, that you’ve got the steering from leadership on what those goals are and then the team to then implement that and the project manager role there is to make all of that come together. And having that understanding, you mentioned scope creep, that’s a challenge in its own right.

Mark Roberts:

I’m sure we’ll get onto that subject specifically in a moment. But fundamentally, as I say, this ability to understand what the solution is capable of when we work with the customer, we have this approach where we really want them to tell us what they want. We’ll then bring our experience and knowledge of what the platform is capable of doing, what the IT solution is capable of delivering to the remit of a project. So that out of all of that, the customer’s getting more, the project achieves more, but initially that that definition is in place, it’s documented, we’ve got measurements there and therefore a plan on how that’s going to be implemented can be put together.

Chrystal Taylor:

You said something there about having leadership on board and I think that’s incredibly important because especially if your initial engagement is with the professional, whether that be the systems administrator or it’s like a monitoring engineer or whatever the case may be, their lens of view of the project is going to be very myopic. Generally you start a project because you have an issue that you need a solution for whatever that may be. We’re trying to beef up security, we’re trying to get monitoring on this one thing, we had a failure and we have to have a failover system in place, whatever the problem is, generally it starts because you have a problem and you’re looking for a solution.

Chrystal Taylor:

Your initial lens may be quite myopic and the role of a project manager often is to open up the view a bit. Like you said, getting leadership engaged, getting different levels, getting different teams involved, all of that is incredibly important in order to make sure you’re all on the same page and you’re not hyper-focused on something that’s very small. Which leads into the next topic, which you guys have both brought up now, which is scope creep and how do we deal with that? Because that is a genuinely incredibly large challenge that happens on every single project I have ever worked on, there’s scope creep.

Chrystal Taylor:

If you go into it without knowing the full capabilities of the product, for instance, like we were talking about monitoring. And if this is your first time using this product, you may not have all the knowledge of what it can do. You get excited and you go, “We can do this and we can do that and we can do this and can you set this up?” And there starts to get a lot of questions of, “Can we just add on? Can we just? Can we just add on?” That’s my niece’s favorite phrase right now, “Can you just?” And then that is how it goes.

Chrystal Taylor:

It’s like the old adage of them asking IT for something and saying, “It should be easy. It shouldn’t add that much more time.” I’ve heard that many times. “This should be quick.” And that’s how scope creep gets out of control. Let’s dive into that a little bit and how we manage scope creep.

Mark Roberts:

This is a podcast on its own, surely. Us techs love shiny, shiny, don’t we? We love new toys, we love new buttons to press. And we can get lost in that function. If you don’t get that understanding at the beginning, you don’t capture all the requirements, you don’t get the stakeholders involved, you don’t document it, you don’t measure it, then scope creep is going to be a native, unavoidable part of a project because you’ll suddenly have Mary turn around and go, “I’ve heard it can do this.”

Mark Roberts:

And what we often see actually is put an implementation in place and somebody will go, “What does that feature do?” And show them. And then worlds open up and ideas come flooding out. And in that scenario it’s, “How do we now balance this? Is this something for a new phase? Is this something which is a higher priority now you found out about it?” And then that is the role of the project manager to capture that scope, understand what the benefits are, and then take it to the leadership because they’re the ones that have to decide whether budgets change, whether more resource, whether that is truly something that they see value in. And certainly with regards when we are talking to customers, the value is the word that we use a lot. We could spend weeks deploying software solutions, putting a project in place. Months for some IT projects, years if there’s anything in government projects.

Mark Roberts:

And from that point of view it’s, “What’s the value? Am I going to be able to see and achieve value?” Yes I can. It gets added in. Scope creep is an inherent part of any project, because not all of the answers are known at the beginning. The role of the project manager is to capture that and then work through it to make a decision about whether then it gets included.

Chrystal Taylor:

That’s where project management, and if you don’t have a project manager, you have to become that person that says, “This is not in scope of the current project, here’s what it would require.” And then have them make prioritization or add onto their project or discuss a completely new project or whatever. And it’s really just standing your ground about that topic because they will push to make it part of the existing project. They don’t want to give you more resources or more money or whatever.

Chrystal Taylor:

And properly resetting expectations, it’s an ongoing process and you’re never really done with it until the project is over. And sometimes, not even then and the project is over, it’s complete. We say it’s complete. And then I’ll see sometimes, I have seen this happen where they come back weeks later and they say, “We thought you were going to do this.” We already agreed the project was over. That’s just a human issue. That’s not even a tech issue. That’s a human beings trying to get more bang for their buck at all times. And I feel like that’s really the genesis of scope creep is they’re always trying to get more for what you originally agreed to.

Chrystal Taylor:

And there’s no shade in that. That’s completely realistic. And like you said, we get excited. Something new comes along, we didn’t know it could do this thing or a new issue arises. These projects that take months or years, some issue can happen in the middle of it. It’s like getting a project done on your house. If you’re getting a bathroom remodel done and they discover something behind the wall that they weren’t aware of, now you’ve got to deal with that. That is scope creep in a real practical sense. You now have to potentially add on thousands of dollars to something that you didn’t think that you needed to. It’s the same thing in IT projects, it’s the same exact thing. It’s just less physical wall space or whatever. It’s the same thing happens, anything can happen and you have to be prepared to manage those things as they come up. And really it’s all about people management, handling those conversations and bringing that to leadership and having them make the final decision.

Sean Sebring:

Two things, if I can add to that, because I love analogies. And we’ve all alluded to this. And Chrystal just made the best relation to it. I think of project management as being like a shepherd. You’re trying to keep all the sheep in one spot. Our goal is to go into the pen. And it’s nice to have, if you have the resources, of course you never do because you usually don’t even have the project manager, but to have your border collie, someone to help keep them in line. And working with people, it’s nipping at the heels to say, “Let’s stay on track. Let’s stay on track.”

Sean Sebring:

And a tip I had for myself and other companies use it, but maybe not for the same reason, but giving a project a name is typically helpful and a more creative name can just be more fun. But giving it a name to say, “That’s not part of Project Orion,” and I’ll just use that because that’s a SolarWinds name, but that’s not part of Project Orion. That’s a nice easy way to say no. You say, “That’s not part of Project Orion, that’s actually part of Project Uranus.” I don’t know. I’m sticking with the astral theme here.

Sean Sebring:

But anyway, as a project manager in the past, I definitely have seen that. And it’s like you said, Chrystal, it’s a lot of herding, a lot of shepherding, a lot of keeping people in line. I may or may not have even once said, “It’s like herding kittens from time to time.”

Mark Roberts:

Extending on what you’ve just said there, Sean, I think those skills that a project manager bring define what a good PM looks like. And I say I’ve worked with many, many over the years and you can very quickly identify the ones that are going to be really in control, really on the ball, really going to make things happen. And they are the ones with those real big soft skills, being able to work with different people in different ways because projects invariably are going to be involved in number of stakeholders. People have different agendas, people have different personalities and communication styles, and that person, that linchpin in the middle of it, if they’re not able to communicate effectively on a personal level, that’s never going to be a recipe for that success. And that communication skill is a fundamental of that role in bringing all of those resources together and keeping everybody on track and dealing with scope creep.

Mark Roberts:

We have projects where somebody will say something, I was talking to your engineer the other day and I’m saying, “You could achieve this.” And, “Has this been run past with everybody?” “Oh no, I want it.” “Let’s get whoever the PM is, get them on a call and let’s review it.” Because as I say with this shiny shiny, there’s lots of shiny shiny in IT and we can get dazzled. When you were talking before Chrystal as to who that leader, that overseer, is.

Mark Roberts:

And I’m not going to bring our customers and engagements in here, but I have this at home. Scope creep in my house is my home automation system. What started off as a three-light system in my new extension several years ago has turned into pretty much every room in the house and you can walk in a room and it will turn lights on and all those kinds of things and you can ask Alexa to do these lovely routines. My scope creep is thinking new ways of using the automation. Am I a good project manager in that? No, not a jot of it.

Sean Sebring:

They’re your shiny shinies.

Mark Roberts:

Exactly. It’s shiny shiny. There’s a new extension or there’s new hardware and all. I can get the IKEA system this week and all that kind of stuff. My wife is the overseer and she’s the one that defines what the scope truly is.

Chrystal Taylor:

You brought up one critical skill for project managers, which is communication. Communication skills are integral to a good project manager, but what else do you think makes a really great project manager?

Mark Roberts:

Obviously organizational skills, to be able to structure everything so they get done at the right time, in the right way by the right person, it gets quality measured and written and signed off. Being able to organize not just yourself and your time but other people’s time and clearly a big helper of that is tooling. There are lots and lots of project management tools out there and again, when you engage with a project and we’re talking to a project manager and we’re talking about how can we exchange data or something with regards to that function, if we know that they’re using a project management tool, great. You know the very simplistic things of, “We’re going to create our project plan of what we know that we would need to achieve, we’re going to put a lot of blank places in there for what you need to contribute on your side. We’ll share that.” And away they go and then everybody’s working off that same page. Organization and tooling really, really is a big factor as well. I would suggest.

Chrystal Taylor:

I noticed you didn’t mention certification. How do you feel about project management certifications?

Mark Roberts:

How do we all feel about certification in general?

Chrystal Taylor:

I have many times publicly expressed my opinions of certifications, which is that they’re not the end all be all. I don’t think that they’re required for a lot of things. I think they get you past recruiters. I think they get you your foot in the door for a lot of things, but I also don’t think that just because you have a certification means that you’re good at that task.

Mark Roberts:

I wholeheartedly agree. I said before that you can work out within a few minutes whether somebody’s going to be good at their job. We’re talking about PMs here, but anybody you can gauge whether somebody’s got a way with that and does the certificate enforce that? Of course. If I’m recruiting and I look at a CV, then certificates are going to stand out as a foot in that door as you say. Are they the deciding factor? Not by a long shot.

Chrystal Taylor:

For me it hearkens back to school like high school or grade school or any of that. Some people are really good at taking tests, but that doesn’t mean that they have the comprehension or the critical thinking skills that will take that test knowledge to the next level, which is where we really need to be.

Mark Roberts:

And in the realms of project management, obviously, you can go back to PRINCE2 type things or somebody’s a Scrum master. Becoming a Scrum master is a lot of work. I looked into it, I saw it’s a lot of work, I don’t need to do it, so I haven’t done it and I have no intention of doing it. That’s not my job anymore. But when you look at what those kinds of things bring in terms of education, absolutely. The challenge I think in project management is it can be very… Let me give another analogy. I cook quite a lot, but I don’t often use a recipe because I would just instinctively go ahead and make something. It doesn’t always work out let me be very clear, but it’s okay usually. It’s edible sometimes. But what my point here is because I’m rambling, is the fact that a recipe of, “This is how you do Scrum, this is how you do Agile, this is how you do PRINCE2.” For me, they are reference guides.

Mark Roberts:

They are great foundations for you to take bits and pieces. The methodology from here is appropriate for this part of the project there. From a project management point of view, as a person, from a project management point of view as achieving the end goal of a project, it should have some organic nature to it. It should have personality and that influence on it rather than a very rigid, “This is what this book says and this is what this education says.” I’m a big believer in that in IT, but the frameworks and the tooling around it using Kanban boards or those scenarios are all part of it and they’re all very strong foundations to really engage and succeed.

Chrystal Taylor:

What about you, Sean? What’s your opinion on certifications?

Sean Sebring:

This is a great analogy, Mark, I agree. My opinion on certifications and education in general is it depends on really what you’re getting into, but for project management, I couldn’t agree more with what you said as far as how much investment you have to do for project management certifications because of the logging of the hours, so much of it seems like it could be easily fabricated as well when we’re talking about applying the hours. And I’m not against or for any system, but needing to have continual education hours in some of these certifications, which ITIL I’m a big fan of has also just gone that route where it is now a subscription-based certification and I believe wholeheartedly again in ITIL and I love the practices, it’s where I’ve made my career, but it only goes so far.

Sean Sebring:

Your practice, your exposure to people, I think, their projects, the personalities I think was one of the biggest things that you mentioned that I struggled with at first when I first started project managing is, “Cool, I’ve got a Kanban board with these list of deliverables,” some are to this person, some are to that person, they’re going to deliver at different paces with different attitudes and they’re going to be motivated by different things. At first when I looked at project management and now I’m going tangential Chrystal, but you let me open up a can of worms. When I first looked at project management, I’m like, “It’s another one of those roles that just has management in the name. It’s just glorifying itself. It’s another management style. It just says management.” I’m like, “Oh my gosh. Yeah, there is so much management work going into this,” because it’s very similar to managing a team of people as their manager because you’re dealing with different personality types, speeds, attitudes and motivations I think is one of the biggest things I found as a project manager.

Sean Sebring:

What motivates people to get your things done? Because most people that are contributing to a project that’s only like 10% of them mentally thinking and even less usually they’ve got their day job and we’re also asking them to do this. A lot of times it’s not their priority. What am I going to do to motivate them to let them know this is urgent for me, for the company, for the business?

Sean Sebring:

Those things can’t be taught in a class. They can be told but they can’t be taught. As much as we talk about it, as much as I get certified for it, project management is going to be a little bit of soft skills, which a lot of them are. Some people have it more naturally than others, to your point, Mark, you can just tell sometimes some people will have it more naturally, but it’s also going to be based on experience. Those who aren’t as gifted naturally with those soft skills, those interpersonal communication skills, it’s going to take time and experience – stuff that certifications and just being told what being a project manager is, it’s not going to give it to you.

Mark Roberts:

Also factor in the fact that certifications can’t test that. As Chrystal said, I can learn something, I can sit there and revise and memorize something to turn up to an exam and answer some questions. It doesn’t gauge how good a PM I am. It gauges how well I can regurgitate and as I said before, the methodologies whether you follow Scrum because you’re a software developer or things like that now bleeding over to various other project deliveries in IT and other areas whether you follow a Color Waterfall or an Agile or indeed a mixture, that’s the key thing for me.

Mark Roberts:

As I say, it’s identifying and learning those methodologies, learning the frameworks with regards Kanban boards and the tools that support them. You mentioned ITIL, it’s exactly the same thing. You could be very rigid in following certain parts of ITIL. Is that aligned to your business? No, because your business can’t work in that rigid way and you have to bend the pathway a bit. You have to go off of that motorway and those A roads and sometimes you have to go around a dirt track to get to the shortcut to the end result that you need to get to.

Chrystal Taylor:

And following up on that, you mentioned there right there, the business buy-in basically for these processes and practices and what works for your business. Earlier you were talking about leadership, effectively leadership buy-in for everything. How do you get that leadership buy-in? How do you get your business buy-in for any project that you’re working on or for having a project manager? That’s a separate question really, but I think it’s also important to cover in this is how do you get the buy-in for them to give you the resource that you need or to give you everything that you need for the project?

Mark Roberts:

Obviously that’s particularly in IT these days because budgets are squeezed. The mantra of more with less is very much a factor in a lot of organizations now. And it also depends on which way you’re coming from. Is the leader the one that’s identified, “We want to be getting on the SD-WAN bandwagon?” Or the fact that they’ve come away from one of SolarWinds webinars and identified that AI has to be adopted to give you better alerting output, all of those, whatever the trigger point is to observe, no pun intended, that there is improvements that can come along. The other way round is more of that challenge, isn’t it? It’s more so if I was a network engineer and I went to my leader and said, “Look, I’ve just been on this webinar, I’ve just been to this event and I’ve learned all about AI and observability and I think we should adopt it.”

Mark Roberts:

The key questions that need to be answered there is, “How is the business going to benefit? What is the business outcome of this?” Because IT has still got a little bit of that disconnect between it being aligned to the business and being a service that the business just has to have because businesses have to run on IT. I think again, while this isn’t part of project management, it’s again, part of those soft skills, is being able to communicate with the leadership and help them and identify how are we going to bring value? Is it time-saving efficiency? Is it the fact that we’re going to actually save some, in your language, dollars on what we spend on some function within the business, whether it’s contained purely within IT or the fact that we are deploying a new piece of software that’s going to make finance control more efficient.

Mark Roberts:

All of these different things is all about going to the leadership and saying, “Here’s your return on investment.” That’s not a financial return on investment every time. In fact, it’s sometimes very hard to put numbers on IT projects, but it’s very much about demonstrating true value, something that the business owner, the leadership team could look at and go, “Of course. If that’s how it’s going to come out, then that’s worth us spending whatever that amount of money is to implement.”

Sean Sebring:

Something that I want to add to this is the middle management level of leadership and their buy-in. To give an example, when I was an IT project manager, we were a smaller insurance company using a ton of older processes and technology, fax to give you an example. And when there was an executive decision, because my VP who I reported to had basically said, “Hey look, we’re living in the past. We need to change this.” Executive leadership buys in, awesome. Now we did our business justification, but there’s another level that needs to take place as the ones delivering the project and that’s preparing the organization for it. And again, if we go back to communication, that’s what’ll help make a successful project manager and that’s getting the middle management leadership buy-in because if you’ve got 80% of the company isn’t executive leaders, it’s the people using the technology we’re about to change.

Sean Sebring:

Getting the buy-in and getting champions within the organization saying, “Hey, we’re getting ready to move over to digital faxing,” getting them on board to see what it looks and feels like, preparing them to be your ambassadors so that you’re not the bad guys as IT people, now you’ve got the leaders on your team because let’s say that employee comes in and they hate it. They wish they could just keep doing things the way they always have, which that happens. They go to their manager and their manager’s already on your side.

Sean Sebring:

That’s a great form of leadership buy-in. From a different angle is as we’ve made a decision as an organization to change things, we need to spread the love, spread it into the culture that this project is happening, the changes are coming, and another term for that could be super users and that was something that I actually created a super user group in one of my organizations so that I was planting champions throughout the business so that they would already be there advocating for this stuff that IT was doing. It was a really good way for us to see tons of rapid change in transforming the organization is just trying to build the culture was a part of it and definitely a different take on leadership buy-in, but I still think it’s one that’s incredibly valuable.

Chrystal Taylor:

I would encourage you, listeners, to listen for the practicalities of putting something like that into place with our guest, Tara Bourke on a recent episode of TechPod, if you’re interested in learning more about how to put that into place.

Mark Roberts:

I was going to take something you said there, Sean, we’ve just mentioned about getting leadership buy-in on implementing a project. Somebody’s coming and saying, “I would like to put this in place. Can I have the budget? Can I have the resource?” Once that has been approved, leadership is still vital in that process. You mentioned about that onboarding, getting that buy-in from everybody because if all of the stakeholders are not bought into whatever that project is, and I remember many years ago, and we still come across it on a regular basis where we were brought in to refresh their monitoring and management function and they had 20 odd different tools. It was ridiculous.

Mark Roberts:

We had lots of different things and the reason that that project didn’t go ahead and succeed is because too many people did not have the control from leadership to say, “Sorry, this is happening. You are going to have to change. You’re going to have to relinquish that tool because we are now consolidating so everybody has access to that knowledge and that information.” Because that didn’t happen despite the fact that the advances were so good and the benefits were so clear I know that project failed because the leadership didn’t dictate and control the outcome.

Chrystal Taylor:

Would you say that that’s a great place for documentation to come into play?

Mark Roberts:

The decision point of any aspect around the project gets documented, it gets reviewed by the stakeholders. Everyone then provides their feedback to say, “I think we could do this differently,” or, “I’m not happy about whatever.” That feedback, positive, negative, however it comes back, positive always is a good way, just a tip. And that consensus is then, “We may have gone through 16 iterations of that design document,” but once that has been confirmed and it’s baked and then published, that’s what everybody should be following along with.

Mark Roberts:

Again, leadership and good project management are then the catalyst to ensuring that that does take place. If I get told that, “This is happening and the decision’s been made and it’s documented,” and I can look at it and go, “Everybody’s been involved and everyone’s had their opinions taken on board, but now this is what the decision is, I will go along with it. I may not run along with it, but I’m going to walk along with it because that’s been defined and that definition is in place.” If it’s very much there’s no documentation, there’s no leadership direction, I’m going to be obstructive, I’m going to be, “Don’t mess with my little universe, I like my world how it is. I don’t want you coming and telling me that my world can be improved and I don’t actually want it improved.”

Sean Sebring:

I think a key way of sticking to that, and I want to come back to documentation, because it’s something that I feel wasn’t my strongest part as an IT project manager is the handoff and documentation piece. But one thing that you said is from the end user’s perspective, I’m being told this is happening versus this happened. And I like to think of that as pre comms, early comms throughout the life cycle of a project is also ongoing discovery because you never know who’s going to think of a use case or a problem or an issue that you may not have. The earlier you can communicate, safely communicate, because if it hasn’t been bought in by the executive leadership level, of course you don’t want to communicate prematurely, but as early as you can safely and intelligently communicate.

Sean Sebring:

That was another huge thing that I think we were good at when I was an IT project manager is saying, “Hey, this is coming. Here’s what it’s going to look like. It’s going to feel like,” and as we roll out, we’re preparing them. Again, getting some super users out there was a great way to help with that. But yes, it is happening versus it happened. It is a great thing to think about.

Mark Roberts:

And I think in that example, some very easy things that would’ve taken place would’ve completely changed that. Again, a good project manager, good leadership is going to… And as human beings, we’d like to be seen, to be heard. Now, if we have an opinion on something and we have a platform to voice it, whether somebody agrees with it or not, I’ve at least voiced it. I put my opinion out there, I put my hat in the ring and somebody may pick it up and put some feathers on it and make it look nice, all these different things.

Mark Roberts:

But if I’ve got that ability rather than just somebody coming to me and saying, “You’re losing this tool, you never use this tool, get on with it.” Again, those soft skills, those people skills, they’re the reason why we can move forward as I said before in a positive way rather than in this negative. And I say that person, if they would have been taken down that positive pathway, they would’ve seen the benefit of the new tooling would’ve given them, they would’ve seen that it would’ve been more efficient for them. They’d have saved time, they could have done more interesting things. All of those different things are in the realms of possibility then.

Sean Sebring:

I think a good transition for us now and a great way for us to wrap is actually to spin into the handoff of a project. It’s not been my strongest suit because as a fixer looking at leadership styles, that’s definitely who I am. I like the action, the excitement, but once a project starts to wrap, my enthusiasm peters and I think that may happen to a lot of projects, not just me personally, but making sure that it has the appropriate handoff and this can also be a good way to help potentially reduce scope creep is finalizing things right, calling for the culmination termination rather, or the ending of a project. Mark, what guidance or tips or best practices do you have for us when it comes to the handoff, like on a project completion?

Mark Roberts:

In terms of documentation, we touched on it at various points today, there are different levels of documentation. We have these high level designs which are very much this abstract, this is the goal, this is how we’re roughly going to achieve it, this is the resources we need. And then you have various other grades of documentation, whether it’s a low level design, which essentially that build, how are we going to build, but that’s always a living, breathing document. As you go through the build, as the scope creep kicks in, it gets added to that document and again, everyone has access to it, everyone’s involved in its creation and its life. And then once the project is delivered, then other key documentation comes in. The standard operating procedure documents, the guides on how I do things. It could be the very basic, it could be, “Here’s how I add a device to SolarWinds. Here’s how I raise a ticket, here’s how I escalate the ticket, here’s how I go through the full change management.”

Mark Roberts:

If we’ve got documentation that helps, we’ve got consistency, but we’ve got adoption and again, a big area for me in terms of IT projects that we work with, it’s getting people on board, getting that monitoring platform used and people seeing the benefit, that needs training. People need to be trained on the solution. They need to see how it’s going to affect their lives because again, I’m going to go on and spend some of my time doing things if I know how to do it and if I have already seen the benefit of doing it. When we talk to our customers about pillars of materially monitoring and we move people from this reactive, something broken, big alarm bells going off, alerts are being sent out to a proactive thing, that’s a challenge, that adoption of having that.

Mark Roberts:

Again, having a documentation, this is the report structure you’re going to get out once a month. This is how you analyze the data in here. Here’s how this has been built. All of that level of information and training now allows me to go on there and start learning the vast amount of data metrics that are going to help me be better at my job and whether that’s improving the SLA up times, whether it’s improving, identifying performance issues before they cause a problem, that knowledge, taking it from a project delivery, it is always interesting in terms of some organizations have the project team, they go and deliver a solution and then they hand it over to the ops teams. That handover needs to be good quality because if it’s not, again all of that work, it’s never going to be manifesting into a real good outcome.

Chrystal Taylor:

That’s exactly right. It doesn’t go anywhere from there if they don’t have the knowledge and the wherewithal and the time and the passion even to continue on that project or to improve it. Technology is like a living thing in a way. It’s going to constantly need to be worked on and improved and it’s not done. You’re going to be maintaining it at the very least for years to come. I once had someone that I worked with for three years, full time. I worked with them for three years full time on their monitoring system and they expected me to hand it over in one hour to two people who had never used the application before. And I think that this just illustrates and everything that you’ve said illustrates the importance of setting proper expectations for that handover as well. You mentioned training, you mentioned all these things are so important to that process, setting the proper expectations.

Chrystal Taylor:

I did set expectations by the way. I’m like, “There’s no way I can tell them everything they need to know in one hour. It’s not going to happen. They need training.” And they need whatever the case may be. You can provide them with a book of documentation, sure, but if they’re never given time to review it, if they’re never given time to actually sit down and understand how to use whatever thing that you implemented or put in place, then they’re not going to have any idea how to maintain it in the future and the project is going to lose steam and then eventually die off after you leave.

Mark Roberts:

I completely agree. It’s one of those areas that if you don’t create this structure at the beginning, your auditing phase, your planning phase, your preparation, your implementation, your training, your continual improvement, because as you say, most IT projects, and I go back to my early years in IT and working with software developers and they’d go, “I’ve created this application.” Great. It’s version one. Version one over the next five, 10, whatever the life of that application is, it’s got to version 20.3 in that time period. That application is never finished, and it’s the same in any other area. There’s always things to look at to improve, new technology that comes on board to improve it. The expansion or the change in an organization is inherently going to change the requirements of what the original project was. You can’t just go and deliver something and then sit back and then hope that it just carries on its own forevermore. And again, to allow that to happen, people need the knowledge to understand what it does, how it does it, why it does it, and then how to use it.

Chrystal Taylor:

We’ve covered projects from start to finish there of the initial discovery process all the way through to project handover. I think we have covered this topic pretty well and we really appreciate you coming on and sharing your insight and your experience with us. I think it’s been really informative and hopefully our listeners out there got to learn and take something from all of this. Thank you, Mark for being on TechPod with us. We appreciate it. And thank you, of course, to our listeners for joining us on another episode of SolarWinds TechPod. I’m your host, Chrystal Taylor, joined by fellow host Sean Sebring, and if you haven’t yet, make sure to subscribe and follow for more TechPod content. Thanks for tuning in.