How To Reduce Project Stress Through Better Prioritization And Stakeholder Honesty

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Galen Low: Hey folks, thanks for tuning in. My name is Galen Low with the Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can amplify the value of project management in a digital world. If you want to hear more about that, head on over to thedigitalprojectmanager.com/membership.

Today, we're talking about the art of prioritizing project scope items and how it can be wielded in a way that makes things collaborative and transparent instead of combative and opaque. With me today is James Louttit, a former CIO and project management champion who has gone from leading a team of project delivery professionals at one of the Big Four consultancies to founding Impactful Project Management — a training organization that helps practicing project leaders become more effective in their projects.

James, thanks for being with me here today. 

James Louttit: Galen, so nice to meet you. Thanks for having me on. 

Galen Low: Yeah, this is great. And thank you for sending me a copy of your book, Leading Impactful Teams. I really enjoyed the illustrations. I enjoyed the stories. And I wanted to say congratulations. You just mentioned to me in the green room that Leading Impactful Teams is now available as an audiobook.

I mean, minus the illustrations, I guess. 

James Louttit: Yeah. Yeah. Yeah. So it was recorded over the summer, but it took a little while to get out there. And and now it's up there and it'll be available on more platforms in the future, but at the moment it's just an audible. 

Galen Low: That's awesome. And what was your take on it? Do you have any, like an ASMR chapter where it's like slow, calming project management chapter? 

James Louttit: No, really. My style is fairly high energy. So if you listen to the rest of this podcast, you'll get a sense for what the book is but I don't know. I think I listen to audio books all the time. I love them.

I think they're a great way to consume, along with podcasts, to consume really interesting stuff. And I go out for walks and for me I wanted to record it myself. And I think you can bring a bit of energy in different ways. And particularly when you know the material inside out, when it's your words that you're, that you're reading out, I think you can have a bit of fun with it as well.

Galen Low: Absolutely. I love that. I can't wait to listen to that a little bit. 

Today we're talking about something that you do talk about in the book, which is prioritization. I thought maybe I'd just start off with one big hot question. And the question is, what is it about prioritization that makes it so controversial on a project? Why is it something that's so hard to get right? 

James Louttit: Yeah. It's really hard because, and I've seen this, I work with lots of different companies now, but I saw this in the company when I was delivering projects as well, is that it's very difficult to explain to everybody else why your thing is important, but everyone feels they have to.

And quite often it comes down to this kind of political battle of whoever the most senior person is, or whoever can get the most senior person behind their thing, gets the thing scoped, right? And it's unfortunate because we don't necessarily talk anywhere near enough about prioritization in projects.

For me, there's an infinite amount of work, right? There's always an infinite amount of work. If I'm not doing anything, if I've run out of work, I'm going to think of things to do, right, that are going to help me achieve the outcomes of whatever the project is I'm working on. So there's an infinite amount of work.

So the skill of prioritization and that muscle of doing it over and over again and helping your stakeholders to engage with it is very core to the success of project managers or project delivery professionals. And actually, arguably, every one of us who aren't project managers as well. Because, you have to decide what you're going to do.

And it can be, like you say, it can be opaque. It can be difficult to do. And I do genuinely think that there's just a few very simple techniques that you can bring into this stuff that make a massive difference to how things play out on projects. 

Galen Low: I love that. I love the angle on like the political aspect and like this whole jockeying for what is important.

Sometimes you receive a project as a project manager, you're like, the scope is the scope. It's just it's here. It's just written down. This is what we're doing. And the emotion isn't in there. And you start talking to stakeholders and you start talking to your sponsors and suddenly, you there's this horse race really, or like the political hierarchy and there's so much embedded in it. That's more than just, what are we going to do in this project? It's actually a lot deeper than that. 

James Louttit: And the interesting thing is the thing I've learned about stakeholders, having been a senior stakeholder in a lot of projects is they actually don't know. They don't necessarily know how hard it is to do things or even what they want a lot of the time, right?

They think they broadly know, but they haven't thought things through at the level of detail that we need to have thought it through. And so it becomes really interesting how you manage that conversation with them to pull out the assumptions, pull out the actual elements of, okay, what's important, what's not important and engage with people on this stuff.

Galen Low: I want to dive into that. And I wonder if maybe we take a step back here because the way I see it, I think you have a quite particular take on prioritization, especially within projects. The way I see it, it goes beyond like typical frameworks, like MoSCoW, where you've got, must, should, could, won't.

Could you just take a minute to introduce our listeners to like your prioritization construct and the problems that it solves? 

James Louttit: Yeah. So I was listening. So I don't know if you've seen Henrik Kniberg's video, Product Ownership in a Nutshell. It's a brilliant video which describes Agile. I'd highly recommend it.

It's on YouTube if anybody wants to go and watch it. And he talks about value and effort prioritization in there. But for me, most organizations, so I've built from that, this kind of idea about using those two levers. But most organizations do this thing that you described, must-go prioritization; must, should, could, won't.

And what they do, what happens when stakeholders see that, it's hang on a second. I know how to play this game. I have been here before. So last time I did this, I said, these are the musts. Okay, these are the shoulds, the coulds, the woulds. And all the shoulds and the coulds got descoped. And actually, what I'm going to do is I'm going to put everything that I want in must. 

And because there's no within category prioritization, you end up with a bucket of must, and that is brutal for project teams because they can't distinguish between which are the important things that they really have to do or should prioritize to do first, and which ones are still important but maybe need to, could be done a bit later in the process or could be descoped. And by having that bucket approach to prioritization, it's just not prioritization. It's pretending. It's that sort of ostrich burying its head in the sand and avoiding the difficult decisions.

So I think we can do a lot better than that. 

Galen Low: I think that's huge. Like it's categorization, not prioritization, rather. 

James Louttit: That's it. Exactly. So building from that, right? So, so Henrik in his video, because I watched this thing loads of times, because I used it to roll out the transformation approach that we were doing with all our very senior stakeholders when I was at CPL.

So I watched this thing like probably 50 times. And then he talks about this guessing game of value and effort, like you looking for high value, low effort things, right? But how do you guess the value? You don't. It's a guessing game and everyone uses it together. I wasn't satisfied with that. I actually think we can do much better than that because there's lots of stuff in the literature about estimating business value and like estimating effort is straightforward, right?

We do it all the time. Actually, most people do it really badly, but there are ways of doing it better. Things like planning poker, which can make a big difference to the quality of our estimates and actually understanding the difference between work effort and duration. That's a basic thing that everybody gets wrong all the time.

But understanding both those things, so the effort and the value and using both of those. And that's what I get into on my training course and in the book is to show some examples of how to estimate effort, the effort of things, and how to estimate the value. And even for those more intangible things that people get quite lazy on, I think it's lazy not to put a number on the value of something.

I think you're looking at, you say, I don't know how to do that. I don't know how to estimate the value of a, of solving a potential security breach in this particular part of the organization. I think you can, I think you can have a good discussion about it. And if you go at it with the right attitude and the right engagement with your stakeholders, it doesn't matter if you get the number wrong, right?

Because all you're doing is putting the number out there and allowing people to discuss it. And if they think it's wrong, great, learn what they think is wrong about it. And either incorporate that or explain to them why they're wrong. And then you change the number. So that number then becomes, although it's not perfect, right?

It's not an easy thing to do, but it becomes our number, not one person's number. And then you can use that in that sort of prioritization discussion to find out hang on a second, is this higher value and lower effort than that? In which case, if it is higher value and lower effort, it should be above it.

Great. Let's do that. And now, again, the main thing on prioritization is no equals. Never allow anything to be equal. Something has to be above or below something else. Which means when someone comes in with another idea of what they want to do, they have to put it somewhere in that list, right?

Which means something falls off the bottom of what we've got space for, as opposed to just jamming more things in the bucket of must. 

Galen Low: I'm really happy you brought up planning Poker and in the context of estimating value, because a lot of the time you enter that conversation with stakeholders and they, it goes immediately to money.

Like what is the dollar ROI, but this is going to help us ship more units or change our prices or cut costs or whatever. And because value sometimes there's money for us. And then the exercise is, okay how do we put a dollar value to this? And then we get lazy. We're like, we don't know how to do that.

We're just not going to do it. Versus a relative number, right? Relative to this other thing that's in scope. Is it bigger or smaller? 

James Louttit: Actually, no I like absolute numbers. I'm very strong on absolute numbers. If you think this is going to make us a million dollars more profit, then great, justify that, explain it to me how, and I'll throw some rocks at it, and maybe we come out that really it's only going to be $750,000. But now you and I can agree on that number, and it's a real number, and it's the best number that you and I can come up with, and that's the point.

We aim to make, it's you and me against the problem, as opposed to you against me. It's you and me trying to find the best outcome for the organization. So for me, the idea of doing something like t-shirt sizes or relative numbers, but once you have that, then you can still put it in a list, right?

Because you divide it by the effort. And now, the value per day of the time that you spend on the project. And you can use that as your relative guide for deciding this stuff. 

Galen Low: That's interesting. I had never thought about it that way because this whole notion that it's a number between you, me and the project team.

It's not a projection. It's not a forecast, like to say that this scope item is definitely going to make a million dollars, not $750,000. And we can sort of stake our reputation on that. This is just to prioritize, to sort of understand value and effort and the weight of the thing.

James Louttit: It's a bit of both, actually.

So I'm working with a big financial organization at the moment. So when I was doing this in CPL, we just used it for prioritization. If I'm honest, yes, some of the numbers were quite inflated, but they were good enough because they came from the stakeholder. So they then became a proxy of the importance of the organization and within a transparent prioritization, because this is the skill then, right? 

You take these numbers. And you have that prioritization discussion in front of everybody, not in a back room somewhere by yourself, making all the decisions, giggling away over your pile of money, right? It's much more about okay guys, what do we think is the right answer here? And then all the stakeholders are very welcome to come in and engage in that conversation. 

And once you do that transparently, that's the thing that allows you to have positive conversations with stakeholders. And I think when we did that, it was magic because what actually happened when we had, and this is nothing really more than a sprint backlog grooming session from scrum, right?

But once you did it publicly with the stakeholders, all of a sudden this really interesting negotiation happens. Someone comes in and says I need this thing. And it's really important. You say, okay, I see this important, but it's going to take us this much time to do it. And they say what's making that hard?

And you say this bit of it's making it hard. Oh that's not actually that crucial to the main thing. So don't do that bit. Don't do the hard bit, do the easy bit and give me 80% of the value. And all of a sudden you've done that amazing thing. You've had a scope conversation. Understanding what the goal of the thing is that you're trying to achieve and how hard it is to deliver. And then that thing becomes easy to deliver and you deliver value. And that's what you should be doing all day long, over and over again in your projects.

Galen Low: I love the collaborative aspect and the just even just cross training on different perspectives. I imagine it doesn't always start collaborative and open and transparent.

I imagine that some of the first sessions you're running on a project with a new team is quite defensive. And, people are trying to protect that thing that they think is important. And someone else is telling them, probably you, that actually, it's not as important as this other thing that maybe isn't as important to you, but is important to the project.

Like, how do you get there? How do you get from people having their backs up and having their guard up to making it a genuinely sort of collaborative and open experience? 

James Louttit: So I've seen this like really painful situation, right, where a senior guy, the head of IT, was the person who decided. So you come to him and you say, I want my thing.

And he says, yes, you should have your thing. I'm powerful and important and strong. And then someone else turns up and says, I want my thing. And he says, no, you shall not have your thing because I'm powerful and important and strong. And half the people like him because he gives them their things and half the people hate him.

And I looked at that and I don't want to get into that stuff. I want everybody else to decide. I don't want to be the decider. I'm happy to be the referee, but I don't want to be the decider. And so what I did is I actually, I set up a training course, right, cause I thought this was really important.

So I set up a training course for people who wanted stuff from our IT team. And I called it a really catchy name, how to articulate the business value of an IT change. So it's like a half hour course, right? And what I did in the course, and it was like, if you want something from us, you have to put a number against it.

I didn't start with that, right? That was six or eight months in. What I started with was just saying to people, okay, why do we need this? In words, right? No numbers yet, right? Just explain to me why we need this. So let's say someone's coming with a report that they need for their team or for themselves, right?

So they come to you and they say, Okay, James, I need this report because at the moment I have to do this thing every month and it's really painful. It takes me like four hours to do it every month. It's brutal. And if I had this report, I could do it much quicker. It's great. Okay. So then I'd ask a few questions, right?

Okay, so is it just you or are there lots of other people doing this thing? Okay it's just me, right? Okay, great. And if we gave you this report, would it get rid of the full four hours every month or would it you still have to do some work, right? Okay. Yeah. So, so you're right, James.

It's probably going to be two hours per month. I'm going to save because I'm still going to have to do the other things, right? And is it every month? No, it's every three months, right? So, okay. So now you find out this report that you're going to create, it's going to save one person, whatever that adds up to be eight hours a year.

Okay, interesting. Okay, so now you say to that person your time's really valuable. Let's say it's worth $200 an hour, right? Great, okay. So now we multiply that 800 by the 200, and we've got 1600 Euros for a business case. But this isn't gonna just be one year this is gonna be at least three years.

So now we've got whatever that is, four and a half grand worth of business case. And you go to the team and say, guys, how long is it going to take you to build this report? And they say, Oh, it's quite complicated. And we have to do this and we have to do that. And and then there's a thing, we don't know how to do this thing.

If you gave us like 40 grand, we could probably do it. Okay. Interesting. So now you've got the value of four and a half grand and the effort of 40 grand, and the thing should not be done, ever. Right? It's just not worth doing, ever. And interestingly, when you have this conversation with people, and we did this, about 50% of the work that people were trying to jam into a bucket of must disappeared.

It just didn't come into the thing because people couldn't justify it. And certainly they couldn't justify the cost of doing things. And where they could, they say, okay hang on a second. But if we make this report really simple, instead of doing that, but we don't need all of these things. It's still four and a half grand. Maybe we saved like most of that time. Let's call it four grand of business value. But all I need is to be taught how to do a pivot table, right, which one of the IT guys can do in 10 minutes. And boom, and all of a sudden that's a high value, low effort thing that they can do and they are off and they're running.

And that then opens up the conversation about creative problem solving and using other techniques and tools that were available to you that aren't necessarily big, complicated IT things or whatever you're building. 

Galen Low: I like that, cause it's so many things in one, right? By having a conversation about this, you could also be innovating.

And that's what I really like about planning poker for estimation overall. We all enter with our assumptions and maybe most of the people there are like, yeah, it's going to cost 40 grand. And one person is no, it could probably cost, four grand. And they're like, tell me why? And they're like it could be a pivot table.

We could just train them on this. It doesn't have to be a report. And they're like, Oh. And then your line item, yeah, maybe it disappears or maybe it transforms. In other words, you could figure out a solution to the problem that has better ROI. And that's what strikes me about the whole conversation is that by putting value and effort together, you're going line by line on ROI.

It's if we invest this much energy, time, money, effort, equipment, are we going to come up better, come out on top? Or is it going to be something where we're actually still in the hole? 

James Louttit: Yeah. So there's another thing that's really interesting when you come to the effort calculation, right? And you talk about planning poker there.

And planning poker is such a powerful technique. I actually have my, I've created my own planning poker cards, right? So that I give them out in the training course. But when you ask people how long things are going to take, there's a problem there, right? Because most organizations don't account for risk.

And so the individuals are forced to account for risk. So what happens is you go to a developer, say, right? And you say, okay, I want you to build me a database. This is the thing. How long is it going to take you? And the developer looks at it and goes okay. So I reckon if I look at that, it's going to take me two days. But stuff might go wrong.

So I'm not going to tell you two days because I'm not an idiot. I'm going to say four days. And then the team lead looks at that and he says, okay, this developer says it's going to take four days, but hang on a second. I've been around the block a couple of times. Stuff might go wrong. So I'm not going to say four days.

I'm going to say six days. And then the PM takes a look at that and goes, okay, so the development team within six days. Okay. So it must be, this must be one of those hard database things that we, okay. So hang on a second and stuff might go wrong. So I'm going to tell the stakeholder it's going to take us two weeks.

All of a sudden what should be a two day estimate, it should take two days if everything goes according to plan, becomes a two week thing. And all of a sudden your team look really inefficient. They look bad. And the stakeholder looks at it and goes, why on earth? Can't you flipping build it? It's just a database.

Turn it on. It's fine. Let me show you. Yeah, I'll do it. So the skill here is to allow for the things that might go wrong, to pull out the risk from the estimates and almost all the organizations get this wrong. And I don't know why. I just think it's like the emperor's new clothes. They haven't explained it well so people end up hiding their contingency in their estimates. Whereas if you do proper risk identification, and I teach a technique called silent writing, where you can also, interestingly enough, you can do it on like ChatGPT and ask him, what might go wrong on this project? And they give you a really good list, right?

But then you identify those and say, okay, given if that goes wrong, it might cost us this. And you pull it out as a separate part of your estimate, right? So if things go the way we expect it to do, it'll be this much. If they don't, it could be this much, right? A bigger number. And the difference between those two things is your contingency, which you can now justify, right?

Cause you can point to that stakeholder and say, if you don't sign off on this thing by this date, it's going to cost us an extra 10 grand. Great, okay. And instead of waiting for them to not sign off on it and get annoyed, but not get in trouble because you stuffed your estimates full of hidden contingency, you allow them to actually decide not to spend the 10 grand and to sign off on the thing in the right time frame, and better behavior has happened.

The project is more likely to be successful, and you didn't spend the 10 grand! Hooray! Wonderful news! 

Galen Low: Your team didn't look bad either. 

James Louttit: Your team didn't look bad, exactly. 

Galen Low: It's that notion of padding versus contingency, like proper contingency, where you've actually calculated a contingency budget based on risk.

And there's the rationale behind it and then tying it back to the theme of this and having the conversation about it and having people aware of it, not these silent assumptions that people are making, but actually shared, a shared knowledge of what might go wrong. 

James Louttit: If you can tell that story about risk, when you're making decisions about which projects to go ahead with you're estimating the size of the project. But if you've got a project with loads and loads of risk and therefore potentially a massive amount of contingency required associated with it, then that decision can be made by the stakeholders.

They go, hang on a second. There's loads of risk on this project. Maybe we just don't do it. And by doing that, all of a sudden you might identify the five lowest value, highest effort project in your organization and kill them, stone dead, before they get started. And all of a sudden your organization has got these extra resources.

It's got, what's going to be running around doing this really hard, low value things that have got massive amounts of risk in them. And they can get on with those high value, low effort tasks that we should all be looking at.

Galen Low: I like that zooming out onto like the whole portfolio of projects, like all of the supplies. 

I feel like some of my listeners, maybe me too, are thinking James, that sounds great. But who's got the time? That sounds like doing quantitative and qualitative risk analysis per scope item per project. And then doing that for projects. Won't we just spend all of our time in a meeting room doing prioritization and not getting the work done?

How does this kind of scale? 

James Louttit: This is why for me, quick and dirty is important, right? Getting a number out there that can be challenged. But think about what happens if you don't do it. If you don't estimate things well, then you set expectations of terrible estimates, right? If you've ever tried to estimate things without planning poker, and then you ask people to do planning poker on it.

What you'll find is that they've got completely random numbers coming out of their mouths, right? It's basically a random number generator when you ask people to estimate things, unless you use planning poker. Because the people who are actually doing the task and then talk about it and understand it and figure it out and say, Oh, hang on a second.

We've got a tool that we can use. Oh no, we can't use that tool because we don't have access or whatever. Have all those conversations. And then you find that you improve your estimates. If you don't do this is why, I think it's a PMI stat, somewhere between 20 percent and 70 percent of all projects fail. 20 percent catastrophically, and 70, and I'd say it's more than that, percent of projects don't deliver the things that are expected. And that's because we don't spend just a little bit of time upfront thinking about identifying the high value, low effort things, get rid of the stuff. It shouldn't be there.

Galen Low: I like that. Even the conversation is high value, low effort relative to the risk of everything going wrong.

I'm picturing like egos at play here and I, keep coming back to it, but as project managers, we're like, great, that scope item is no longer in scope. It's off the list. Hooray. And meanwhile, somebody has left feeling quite disappointed, frustrated, and maybe a little bit angry. 

James Louttit: So I haven't explained it quite right.

Okay. So it's not off the list. It's just not near the top of the list. It's lower than all these other things on the list, right? So the list can be as long as you want, right? It's just a prioritized backlog. Doesn't matter if stuff's low on the list, what you're using this to do is focus on the biggest things.

And then you can decide, okay, we're going to do this for six months. So you draw a red line after six months and all the things below the line are things that we're not doing in this six month period, and it's not never. It's just not now. And that takes a lot of the sting out of the conversation.

And particularly if you get to shorter sprints, we were doing two week sprints. If you get to those, you say, that's okay, you didn't get your thing this week because we've got these other things that are much higher value and much lower effort. But come back in two weeks time with your thing, maybe make it a bit easier for us as a team to deliver, and we should be able to get you in.

And that's how you have a better conversation. 

Galen Low: That's interesting. And yeah, it's not like a hard no, it's a maybe later. But then equally to your point, like your example earlier, then there's the item sits there going we want to spend $40,000 to save $4,500. We'll always sit there looking ridiculous.

James Louttit: Yeah, okay, so that really low stuff, that just disappears, right? Yeah, you're right, that never goes anywhere, and that's right? But you've made it really clear, and then they might come back and say, oh no, it's not just me, there's actually 57 of us with the same problem. Ah, okay, interesting. And now you might have a decent business case.

That's fine, right? Okay, now we can look at that again. Or that other thing, which is we can make it simpler using a pivot table. 

Galen Low: Fair. I like the fact that circumstances can change over the duration of a project. Maybe you did hire 56 people. 

James Louttit: Oh yeah, we've all got AI now, so all of the things are easy.

Galen Low: Are you using AI in prioritization other than what you mentioned about sort of identifying risk? 

James Louttit: Not particularly in prioritization because I think the prioritization discussion is really important to have as humans, right? What I am using it for is risk identification. While I do like to give my team first, very importantly, an opportunity to identify risk, I use that silent writing technique I alluded to earlier on because otherwise, you don't get everybody's opinions.

So I do that first, but I'll also quite happily type in some details about the project onto ChatGPT and say, okay, what might go wrong? It doesn't really understand, instead, what are the risks? It sort of says you might not be good at delivering your project. I'm like I'm not going to put that in the risk log.

That's not very impressive. So I said, what might go wrong? And he says data migration might be a problem on this. This, and you're like, okay, actually you're right. Data migration, I hadn't thought of that. And then you put that on the risk log and you have a good conversation about it, right?

So I use both of those things, the human element to identify risks and also belt and braces with some AI kind of to throw a few rocks at it. And all of a sudden you should be able to identify most of the things that are likely to go wrong on a project that's a bit like yours. 

Galen Low: I like that. It's actually such a fantastic use.

I know I'm diving into risk management a little bit here, but it's the perfect use for generative AI and things like ChatGPT because it's been trained on whatever information we've provided about projects going wrong that you would never be able to either know or process in real time, in a meeting, but you can be like, Oh yeah okay, this could go wrong.

You're like, yeah, that doesn't apply to us. Easy. Versus training people on risk management and trying to get everyone savvy to become expert risk managers or expert estimators. Simplifies it. 

James Louttit: I don't think they need to be experts, but I think you just ask them what might go wrong. Don't start going down a big risk management training thing and start getting people scared that they're going to have to learn to be like that guy.

But just ask them, what do you think might go wrong? And then give them time. So this silent writing technique is really powerful. So you say, here's some post it notes. This question is what might go wrong on this project? You've got five minutes, start writing. And then when I'm doing this, I actually invigilate the thing.

I'm like the exam, moderator walking around. No talking like that kind of thing. And I'll tell people off and I do lots of talks and things. I did this with a big group of very senior people day before yesterday. And I was walking around, I think I told the CEO to shut up. It was quite fun.

He was very good about it because I'd set the scene quite nicely before. And it was good. He came over to me afterwards. He said, James, that's really good. That actually works. I should shut up more. And they got loads of good ideas just from that little technique. 

Galen Low: I love that. You raise a really good point in terms of, sometimes it can be refreshing for a person of authority to be in the mix and in conversation. And, in some ways there are some leaders who just feel like it's an expectation on them that they know stuff and make decisions and are loud and, and this and that. Versus sort of introducing this sort of collaborative, getting them sort of back in the trenches, back in the action.

I wondered about the opposite though. 

James Louttit: Yeah. It's the HIPPO. It's the highest paid person's opinion, right? That's the problem. And that's what we're trying to solve here. 

Galen Low: I love that. I love the HIPPO sort of acronym. And I wonder if we can get into the darker side of that, the opposite side of that, where it's listen, you shut up.

I'm the highest paid person in the room. It's my job to say we do this or that. It is bucket of musts. Doesn't matter. We're not having a conversation about this. Get the developers out of the room, get the designers out of the room. This is you and me. I tell you what to do. You do it. How do you push back against that?

James Louttit: I don't really think that conversation happens as often as people think it does, but let's address it anyway. Because in my experience, senior people are very empathetic. For the most part, they do have a high level of emotional intelligence because you don't really get to those levels without that.

Some people are absolutely that kind of driver personality and just drive it forward. But for me, those people are very open to the question of, okay, but hang on a second. If you do that, these are the things that could go wrong. Now I'm okay. If you want to sign off on that and these things go wrong, I've made it very clear to you what might go wrong.

What's likely to go wrong is that this thing isn't going to get done. And I think it's more important than the things you're making me do. So this thing might not get done. If you're happy to take that risk, that's fine. That's your decision. So when my wife and I got married, we agreed that I'm in charge of everything.

All of the things, everything I'm in charge of, apart from decisions. She's in charge of the decisions, but everything else I'm in charge of. And for me, that's actually quite a nice angle to put up to your senior stakeholder and say, yeah, do you know what I want you to decide, but you have to decide, and you bring it back to the iron triangle.

I'm sure your listeners will be familiar with that. You can have it good. You can have it quick. You can have it cheap. Pick two, right? You can't have all three, right? Which thing are you going to give me to flex, right? I can flex on scope or quality. I can flex on time or give me loads of money and I'll just hire some consultants in and we'll all do it together.

So present decisions, present options back to them and show them what they're deciding between, including what might go wrong. And actually those people, in my experience, a hundred percent of the time, appreciate that. 

Galen Low: I find that really interesting too, because I'm thinking of some examples of people that, in my life who are seen by others as, they're hard asses that, they want to call the shots.

They're stubborn. It's like their way or the highway. And, as you're saying that I'm unpacking this and being like, a lot of the time it's because they don't feel like other people get it. Their frustration is no, you don't get it. We have to do this. It's very important. And it's solved by having a conversation about it, doing a sort of planning pilgrim exercise where we're talking about why it's this way.

Why is this the 13 and not a 5? Why is this a hundred thousand dollars and not $4,000? And then everybody gets it more from a different perspective. And it solves the problem of, I'm the only one who gets it. I have to make this decision because I know it's important. Okay. Tell me why, and let's talk about it.

And then we'll know too, maybe you're not fighting for it. Maybe you are, but maybe you're also educating, right? You're educating everyone else about why it's important. Then next time it comes up, everyone knows why it's important. It's an educational piece more than it is a shark tank. 

James Louttit: Yeah. So show you're working and ask why.

Galen Low: Right. Yeah. I appreciate the sort of, the thread of quick and dirty and simplicity, because I think that happens a lot in project management, right? We start talking as project managers and, people who aren't in it, they might roll their eyes a bit. They're like, yeah, who actually does that? Who actually has a risk register that they look at every day and talk about it with their team every day?

And I'm sure they exist, but I don't know that it's as common as people think it has to be. 

James Louttit: Mostly that's because those risk registers don't have teeth, right? They don't call out the contingency. I'd say almost a hundred percent of them. Guys, if you're listening to this at the moment go and have a look at your risk register and see if it makes the consequences of the risk coming to fruition clear.

I almost guarantee it doesn't. And if you put a number against that, it can be number of weeks or a cost. If this comes to pass, it opens up better conversations.

Galen Low: I like that. A risk register with teeth. 

I wondered if we, maybe we can round out with the other big question that some folks might have. Because a lot of this assumes that you are at the table that you are sort of interfacing with senior stakeholders, that you do own prioritization. But I'm sure there's some folks listening where they're like, I don't have the bandwidth to do this. Maybe I'm actually told that this is not my job, that I just take orders and deliver what's on that list.

I'm not supposed to challenge it or question it. For folks who are feeling like that, and they're like, that's great James, but that's not me. My role is seen more as an order taker. I don't have these conversations. What can they do? Where can they start? 

James Louttit: Yeah. That's hugely demotivating. First of all I mean, I agree with Dan Pink's assessment of kind of what motivates people like autonomy, mastery, purpose. And what you're describing there gets rid of at least two of those and possibly all three.

Brutal. I wouldn't be sticking around very long, but I've been in that place and I think you can change the behavior. So for me, I would be getting into the room, right? I'd be finding ways of understanding things. That question asking why, okay. I don't necessarily have to make all the decisions. I don't want necessarily to make all the decisions, but I need to make sure that they get made.

So present the options up. At the moment, what's probably happening is that senior person doesn't understand the consequences of the decisions they're making. So you've got to find ways of showing them those consequences. And whether that's through contingency or estimating or just listening to them and understanding where they're coming from, these things are powerful.

So I used to have a motorbike ride when I was living in South London. I had a job in North London. I had an hour and a quarter each way on the motorbike through the middle of London. So I was concentrating on the traffic. It was tough. It was cold. It was wet. But I had on my iPod. This is going back a few years.

I had on my iPod, "How to Win Friends and Influence People" by Dale Carnegie. The one thing that over and over again, I listened, I must've listened to that book like 10 or 15 times over and over again. And every time I get to work, I'd have a new way of thinking about things. But putting yourself in the other person's shoes is the fundamental way of influence people.

If you want to understand why that person is driving that stuff down, listen to them. I was chatting to one of the guys yesterday in a a couple of drinks after the presentation I'd done. And we were talking about how to get on in careers. And the answer is, just look up and find out what your boss is doing and start finding out ways how you can take it off them, right?

How you can understand what that is. And can I help with that? Do you want me to write the minutes of that? Oh, why don't I organize that thing? And all of a sudden you're in the meeting and then all of a sudden you're writing the minutes of the meeting. And then all of a sudden you're running the meeting and all of a sudden your boss isn't there.

And now you're your boss. Hooray. You've taken the job. And he's, or she's off doing something else and you've moved up. And that's the skill, right, finding the things that are happening and getting yourself into those and showing that you can do the thing that your boss is doing.

Galen Low: I love that how it starts. It's funny because the sort of start with why or ask why, it's a powerful question. In this context of prioritization and project management, often it's seen as like a challenge. You're scrutinizing it. You're like, Oh, but why? And people might get their backup, but you can also ask why tell me why this is important.

Tonally, it could be a very different conversation if you're like, I'm curious about why this is important to you because I want to learn. Not, I'm curious about how I can get this off of the scope by making you look like an idiot. 

James Louttit: Yeah. The tone of the question matters. If you're genuinely interested and you want to understand why it's important, then it tends to be a positive conversation. If you're like, I've got six other things to do. Why should I do this one? Then no, you're not, you're behaving a bit more like the guy that I was describing earlier on. Like I'm going to make the decision on this thing. No. Okay. Hang on a second. You might have some, you might be onto something there.

Tell me a bit more about it. Let me no. Okay. I can see why that's a stupid idea. Okay. Let me explain back to you. This is why it's not going to work, right? But once you've listened to them, sort of proactively and confidently ask them a load of questions, they'll return the favor, right? They'll listen to your point of view, and then you can come to a conclusion, because they might be right?

A lot of people, I did a lecture last week in Manchester University, and one of the students was saying, how do I get everybody else who's wrong to understand that I'm right? I'm like it's quite possible that you might be wrong. If everybody else thinks that you're wrong, so just listen to them, right?

Once you've listened and understood their point of view, mate, then they'll listen to you and you'll be able to explain it. She emailed me afterwards. And she was like, do you know what, James, that completely changed the whole project that we were working on. Thank you ever so much. I was completely wrong.

All right. Oh yeah. Okay, great. Carry on. 

Galen Low: That's what the important bit about, the thread of steel here is like collaboration is dialogue, right? We talked about, yes, AI can help identify things, but having the conversation between humans is actually the bit that moves us forward. And I just love that nuance that you threw in there about the fact that as a project manager, you're thinking about, oh, like all these like stubborn shot callers. 

You might be the stubborn shot caller going I got to protect my scope. No, you can't have this. I'm making all the decisions about this because I need to deliver. I'm the one who's delivering on time on budget. And so, no, you can't have these scope things. Versus, yeah, actually you might be wrong. You might be missing the point. You might be missing a lot of opportunities to have a really high impact, high value project. If only you were willing to dialogue with the people who are doing the work or will be impacted by the work.

James Louttit: Yeah. At one stage in my career, I was very proud. I called myself the scope of Rottweiler. And I was walking around going, we're not going to change scope. We're going to have really hard change request process. And I thought I was proud of myself and I look back and I'm embarrassed. I'm like, no, they had good ideas.

Like, why didn't we just choose to have a better conversation about this? I didn't really understand Agile at that stage. And I didn't understand the fact that you can make better decisions later in the project than you can early in a lot of cases. But I do see people walking around with exactly that attitude all the time.

Oh, scope management. I call it change request purgatory. You put this massive process around change requests that put a huge overhead on change requests. And so nobody does them. And so you miss these great opportunities in projects and you end up doing stuff that was thought about three years ago and was signed off at the time, but is rubbish now, right?

Just because the world's moved on and now we've got different tools or whatever. And for me, I think that's the skill of the project managers to understand, like sometimes planning things out is really important, but also to understand that sometimes you need to have a more agile approach and understand and be able to descope things and add scope things.

As long as the right people are making those decisions, they're involved in those decisions, it can be quite a positive discussion. 

Galen Low: Yeah. First of all, who could blame you? That's how we're trained as project managers to be the Rottweiler, defend your scope at all costs, not be a collaborator.

And honestly, it's held the craft back. It's changing now, but there's an entire, number of generations of project managers who were trained that you should be the Rottweiler, you're the guardian, don't let anything pass this door. And yeah, it's given us a bad rap, to be honest. 

I wanted to land on one thing, because I think you mentioned something important. You said, I wasn't as agile back then. And I know a lot of folks are like, prioritization doesn't make it agile. And we've talked about things like planning poker. And we've talked about things like having a prioritized backlog. For folks who are like, yeah, that's great, James, but I'm not doing scrum. Like I don't have a sprint planning session. 

Is what we're talking about rooted in Agile and Scrum or can this be done for any project? 

James Louttit: Yeah. So this is one of the weird things that I've noticed about most project management training. And I love the PMI. I think PMI, great. I think as an organization, they do great things, but when they teach the PMP, they do this thing.

It's you've got to wear two hats. You've got to either be predictive or agile, and I just think it's wrong. The skill is to build a toolbox of ideas and approaches, right? If a daily standup is going to be useful on your project, then use a daily standup. It doesn't matter that someone in the scrum world thought of it as a good thing to do.

You can still do that on a waterfall project. If a risk log is a useful thing to have on your project, it doesn't matter that's a waterfall-y type thing. It still can be useful on an agile project. And for me, I want to empower project managers, project teams, to understand that there's, you break it down into loads and loads of different tools, some of which come together in a lovely methodology like Scrum, or in a lovely methodology like PRINCE2, both of those have their place, and both of those are useful in their context.

Unfortunately, your context is unlikely to be perfect for Scrum, or perfect for PRINCE2. So understand that maybe a stage gate is useful, sometimes, to get sign off on things, and get people to move forward on things. But also, that maybe, a prioritised backlog might be useful. And you can do your design phase in an iterative way.

And maybe then you build a building off the back of that, and it's a waterfall project. But I think that's the skill. And I think people are a bit scared of that stuff. So many people did agile badly right at the beginning, right? And they just went, Oh, that means no documentation. And we just make stuff up when nobody's going to make any decisions.

We're just it became like not project management. It's we're just not going to do project management at all. Whereas actually, if you take a little bit of the right structures in place and you do things like that, I mean, for me, the artifacts and the ceremonies and things in scrum, I, not onerous, but there's quite useful framework, right?

But there can be just as much documentation in that context as your company needs. And I think that's the skill is finding the right balance because your project, your organization, your team is different than everybody else's. So be confident, learn as much as you can, and play the right bits that you have to play to deliver your outcomes.

Galen Low: Boom. That might actually be a great place to leave it. 

James, thank you so much for spending time with me talking about prioritization, but we also covered risk management, we talked methodologies, we talked collaboration and people and, politics. This has been great fun. 

James Louttit: It's been a lot of fun. A lot of fun. Thanks ever so much, Galen. 

Galen Low: Before I let you go, where can people learn more about your book? Where can they get a copy? Where can they sort of get the audio book? 

James Louttit: My website is impactfulpm.com. I'm on LinkedIn, so James Louttit. I'm quite easy to find on LinkedIn. So reach out to me on LinkedIn. The audio book's on Audible and it will be coming to other places very soon.

And the book's available on Amazon. You can order it from all the other shops as well, but it's not on the shelves very much because it's, as a new author it's surprisingly difficult to get a book like this out there. But it does have higher ratings than all the other project management books and more reviews and everything on Amazon.

So it's going really well, and I think we'll get it started getting out there in the bookshops, hopefully over the next few years. 

Galen Low: Awesome. I think it's going to build steam. It's visual. You've got an illustrator working with you. It's not just a wall of text. The audio book sounds super interesting.

And honestly, I love your style. And hopefully our listeners love your style as well. And there's more of it in James material. 

James Louttit: Thanks, Galen.

Galen Low: All right folks, there you have it. As always, if you'd like to join the conversation with over a thousand like-minded project management champions, come join our collective! Head on over to thedigitalprojectmanager.com/membership to learn more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com. Until next time, thanks for listening.