Welcome to messy but essential, I'm Rod Stilwell, and this is the podcast about the people side of project leadership. It's where we help you improve your soft skills to reduce hard costs. In today's episode, we're going to be talking about the importance of clarity in roles and responsibilities within projects. Joining me in the studio today is my brother Dale, who's my business partner, and comes with extensive project experience around the world.
Now, let's jump into this topic using as a basis, a relatively well used acronym and tool within the project world, which is the raci chart. The ability to map out for all of the key tasks, who's actually responsible, who's accountable with whom we should be consulting? And who do we have to inform once decisions are
made? So I'm starting this podcast primarily because over the last couple of weeks, I've discovered with a number of clients that one of the things that gets in the way is when people aren't clear on who's supposed to be doing what. And as a result, you know, that creates confusion, frustration, in some cases, resentment, and so on. So all these emotions come up simply because somebody wasn't declarative in who does what, and with that, you know,
other things that go with it. So tell me a little bit or talk to him maybe a little bit about your experience with respect to either clarity of roles or lack thereof?
Well, I think, you know, one of the the interesting thing with the lack of clarity is that it, it sort of tends to go two ways, right? So you either have people who, where no one knows who's doing what or, or people are assuming that a certain person has a certain role. And so things drop through the cracks, or you have the opposite problem where multiple people assume they all have the same role. And now everybodys stepping on each other's toes.
And so I think either of those is problematic and causes its own set of issues. But you know, you either way, you've got gaps, and you've got issues in your project. You know, not having we talked last week about things like trust and accountability. And obviously, those are tied to circumstances to these roles and responsibilities. You know, we we talked about how you, in order to trust someone, you need to feel confident that they will do their job that they will do the things that they are
responsible for. But if it's not clear, who's responsible for what now, you know, your trust can become eroded in someone for all the wrong reasons. And if you've got multiple people doing the same jobs, now you end up with this conflict, because, you know, two people are working on the same things. And obviously, most of us hate wasting our time, or the perception that
we're wasting our time. So there's nothing worse than going off spending a whole bunch of time working on something to come back and discover that someone else has already done the same work. You know, and and a lot of its overlap and everything else. So I think there's there's a lot of issues in both of those arenas, when we talk about this lack of clarity,
I would concur. I guess two things come to mind. So one is anecdotal. I remember very early on in my career, working for a senior vice president, who would always have several people working on the same thing.
The scattershot approach.
Yeah, well, I remember challenging him on it at one point in saying, Ken, like, why do you have three people working on the same thing? And he said, "Well, here's the deal. They don't seem to talk to each other very much. So I've discovered that if I get them all working on the same thing, but I don't tell them and they bump into each other doing it, it actually creates dialogue, even if the dialogue is just about their frustration with me." So well, it's a strategy, it wouldn't be
my preferred strategy. But I think the other side of it is that, you know, when we look and normally we kick off these podcasts with safety, you know, a little bit about our safety minute or whatever. And so I you know, if I even relate back those roles and responsibilities to safety, how easy it is to say, "No, everybody's responsible for safety." Or, you know, if we go back 10 years, you know, we named a safety coordinator, and he or she was the person responsible for
safety. And gradually, we realized, no, everybody has to own safety. But that doesn't mean that everybody takes all of the action they need, there still needs to be some level of clarity on who's responsible for what aspects of safety, you know, and who's responsible for reporting on or calling, you know, when you come into work, space and it isn't safe, who' responsible for halting the wor and saying "no, we're not movi
g forward." So if we're not clea on those roles and resp nsibilities, even within that safety world, which we all kind of take for granted now, you now, we can run into some chal enges.
Yeah. So that brings up an interesting thing, you know, on a well functioning project team, you hope that everybody on the project feels responsible for the success of the project. Right. So there's this shared team responsibility for that. But clearly, the project manager needs to have this overall responsibility for the success of the project, it's their job to manage getting to the end result. So you know, that doesn't take away from the other people on the project, feeling a
sense of responsibility. But you do need to have someone who is the named person responsible for that?
Absolutely. You know, there's lots of expressions come to mind, you know, good fences make good neighbors, which, you know, basically is about having defined boundaries. And the same goes obviously, in relationships, even when it comes down to what could be conceived as silly things or perceived as silly things. But, you know, just understanding who's responsible for submitting x report, who's responsible for
contributing to that report. And one of the reasons, you know years ago I kind of fell in love with the RACI acronym. And what it stood for was that not so much in the responsibility and accountability, because people kind of mix those up and stuff. And we'll talk about those in a
moment. But in, especially in who do we need to consult, whose nose might get out a joint because or feathers ruffled because they weren't consulted, which just adds friction to the relationships, because it wasn't clear who else needs to be
involved. And, you know, often when we start projects, where there's that kind of feasibility, pre feasibility, dialogue, and so on, we establish almost unspoken communication patterns, if you wish, that as the project grows, and we do more things, and we get into executing and we get into, whether it's building, applying, installing whatever it might end up being, some of those early communication
patterns, stay with us. And that's why I come back to that the whole issue of who needs to be consulted, and ultimately, who needs to be informed. So I've always loved that part of the raci model. But what I've also discovered is that very few people have the rigor to identify those, but they're pretty quick to have to backpedal when they discover, you know, partway through or later on a decision has been made, that they didn't talk to
the right people. And I think we certainly both have examples in our history where, you know, the right people weren't at the right meeting. And in fact, the decisions we made weren't the best decisions.
Absolutely.
So it brings me to, you know, let's step back in that in the raci model. And, you know, first of all, identifying just the difference between responsible and accountable. And they're words that we play with, often interchangeably, but they mean two very different things. So take us through a little bit, if you will, the differences between the two, Dale.
So you know, we traditionally someone who is responsible is the person who's actually doing the work. So you know, they are the person who gets the result that is required for the given action. So if it's if it's sending out a status report, they're the person who actually sends out the status report. The person who's accountable is the person who ultimately will be judged on whether or not it happens. And so oftentimes, that has some
form of a hierarchy to it. So you know, you may have someone on a project, who is in charge of communications, their communication specialist, it's the type of project that requires some very precise language and some very specific things around how we communicate aspects of the project. Something like you know, something that's affecting people's livelihoods or has a lot of HR impacts. Those types of things often require some very formal communications and
very specific communications. So you may have a communications person who's who's on the project, and they're responsible for getting the communication out there for ensuring that it's accurate for ensuring it follows all the standards we're doing all of us do that. But the project manager is accountable to the stakeholders to all the rest of that for ensuring that the communication happens.
Yeah, that's a good I like those two distinctions. Ultimately, I think, because they do often get mixed up. And I've certainly been in situations where, you know, all of a sudden, the project leaders name appears in every single line for accountability, which
is, is untenable as well. So the other side is driving those responsibilities and accountabilities down to the lowest level we possibly can, in order to make sure that ultimately we are able to hold, you know, individuals accountable for the things over which they have authority, and so on. So it may not always be hierarchical. And in fact, in many cases, it isn't hierarchical, especially as you as you deal with, let's say, you
know, cross functional teams. In some cases, in order to execute a project, somebody may actually now be overseeing or accountable for something and their hierarchical boss is actually
now a doer. You know, so there are definitely, you know, opportunities to to say, bypass, but certainly not get stuck in hierarchically, just because you're hierarchically superior, that automatically automatically makes you the accountable person, I think it's important to look at each task and really ask ourselves, how can we drive this down to the right level, in order to then be able to get the results? The other? So go ahead.
Yeah, to pick up on that. I would say, you know, when you're looking at at who's responsible for a task, some of the types of questions you need to ask yourself are, is this the person that has the skills necessary to do the work? Is this the person that has that has been allocated, the time to do the work? versus someone who's accountable? The questions are more things like is this the person who has the ability to
move the Road block? Is this the person who has the approval, the ability to approve certain things that needs to happen? Right, can sign off on this has the budget has, you know, those types of things, so you can't make someone accountable for something over which they have no control, you can put their name down, but there's no way you're ever going to be able to hold them accountable for that. And you can't make someone responsible for work that they can't actually accomplish.
Because they either don't have the time or they don't have the skills.
Yeah, and in fact, I would even add a third element to that the time the skills and the motivation. Because I think that's the that, you know, that's an area that we don't look at very often when we talk about clarity of roles and responsibilities. Does the person to whom you're assigning this responsibility really even want that? Or? Or is it a component that everybody, you know, somebody drew the short straw, and they're the ones who
now have to do it? So how do we get them engaged, excited, passionate, etc, etc. So what what's the motivator behind that? If If I, if we're looking at, you know, kind of where all of this needs to go in terms of understanding the importance of applying some kind of a raci chart, whether you actually use the raci chart or whatnot, but that's, you know, somewhat academic, but, you know, the understanding that clarity of who's doing what, who's making
room for you to do it. So you talk about that accountability partner, as being kind of the de blocker, the one who gets stuff out of the way. So the person responsible can actually make it happen. You know, I remember a quote, and I'm gonna probably mess it up a little bit, but from Prime Minister Margaret Thatcher, when she was Prime Minister of, of England, she one of her many comments was, when challenged about leadership and what she was responsible for. She said, My responsibility is
to create the vision. I can't be responsible for the past, can't change it. I can't be really responsible for everything that happens in the present, because I don't do it all. But I can be responsible for creating a vision of the future, and then moving things out of the way so that people can achieve that vision. And I liked that because one of the things that spoke to was the fact that clearly just putting a name in a box, doesn't mean it gets done and doesn't
mean that people own it. So when we drive it down to the responsible is the person who's truly doing the work. Are they equipped to do the work? Do they have the competency? Do they have the motivation? Have they had the path cleared so that they can do that work? Now, I'm I'm kind of reminded of, you know, living in Canada, icebreakers that break the way for ships to get across, you know, the Great Lakes etc, etc. You know, ultimately, there's Their job is to simply clear the
path. So that accountability function as well as clearing the path, so that the responsible individual can get the job done. I think that's a pretty powerful concept to work with. In addition to that, let's Let's now move from that we've talked about responsibility and accountability. In that sense, holding people accountable is always a bit of a challenge. And so if it's not clear, it's easy for nobody to own the
accountability. And I spent a number of years working in a banking world, where, you know, in one analysis, we discovered we had nine people who looked at a loan before it was approved.
Well, that made it you know, when we decided to start doing some metrics to determine, you know, how could we improve a, reduce the amount of time it takes to approve a loan, and then be, you know, make sure that the loans were being approved by people who had the competency to judge, you know, not just read balance sheets, but also to judge whether this
was a good fit, and so on. And we wanted to reduce that from nine people to two people, what we discovered was, when you reduce it to two people, it's very clear who's messing up. And that sends shockwaves through an organization, when to a certain extent, they can't hide behind the fact that, you know, must have been somebody else I, you know, I thought Bob was going to be looking at that, I guess, Bob didn't, and that's why you know,
this failed or whatever. So again, it comes down to when we talk about accountability, the, you know, the clarity allows us to focus not in pointing fingers, but rather developing and growing people, in order for them to be able to do the job we're expecting them to do. If too many people are involved in it's unclear. We don't even know where to invest those resources. We don't know who needs to get
better at what. Now, let's move to the consultant side, because I, I think this is the part where we we often just gloss over it. We don't pay a lot of attention to who do we need to bring on board, get their insights, make sure that we've consulted them before we make a
decision. So what's your experience been is this a one, something that is often overlooked within project, certainly I can say in some of the projects I've been on, it is often overlooked until, you know, kicking and screaming, we drag them there. But what's your experience been?
yeah, so I think what often happens, or what does tend to happen in technical projects, is that you get a lot of people on the project who assume that they have all the knowledge necessary to complete the project or complete the area.
And so sometimes there is a lack of a desire to consult, because it's easier to just assume you know, and so I you know, if we're going to draw the distinction between consulting and informing right, that consulting is this person has valuable data, valuable input, valuable information, valuable insights, that if you're really going to be successful at doing this task, at accomplishing whatever this is, it's in your best interests to get that insight data information from
that person. Versus inform, that's, that's a community that's more of an outward communication, that's really more of a checkpoint keeping, you know, ensuring that that person has the right information for whatever they're doing. But you're not looking for something
back from them. And, and so, you know, part of that that consulting concept is, is being open enough to look at it and say, okay, where are ours, their expertise, that would be valuable to this project, but that can't be assigned to this project. And I think there's a lot of power in that. But it, it often my experiences, especially on technical projects, that, you know, there's there's often assumptions that we don't need those people.
I think that's really valid. I'd like what you said around the belief that we can do it ourselves. And in course, let's be fair, sometimes it's just more expedient to not involve a bunch of other people. But I've discovered that ultimately, you pay for that in the end, better decisions, you know, involving the right number of people and so on. I think the other challenge that I see with that consulting side is, you may find that you're inviting people
to disagree with you. And most of us have this ego that says, I want to be right, I don't want to surround myself with people who are going to disagree with me. So that ability to kind of bite down and say, Okay, I'm inviting people to consult on this. They may have very different opinions than me. Ultimately, what we're looking at is how do we get the best outcome For the project, not for me, now my ego kicks in and
wants it to be for me. But when we're really talking about stellar project leadership, it's about delivering the project is not about my ego, your ego, I get credit, you get credit, it's really about how are we making the best decisions for this project. So the consulted part of that acronym, if you wish to see in it is really about making sure that we're we're also incorporating the feedback of people who may disagree with us, or people who may not share the same opinion are the same. And
we got to get there. And there's other podcasts that will we have or will be available when we talk about those tough conversations? Or how do we arrive at an agreement to an understanding, but for the moment, I think it's important to recognize that consulted isn't just all the people who are going to agree with you, sometimes you actually should be looking for people who may provide the the other side of the argument,
then, and that's a very powerful thing. And I think I think that can you know, there's a bigger topic to discuss in that. But But I think that ties in very well to, to the concepts of diversity as well, in that you want that diversity of viewpoint, that diversity of background, that diversity of opinion, and the more you you get that consulting, the more you find out that information, the better chance you have of not running into some of these
major problems. I mean, we've all seen the ad campaigns that launch and then get totally panned and end up being pulled. And you're left thinking, did you have no one from x group on your approval process? Because this was pretty obvious to anybody who had any kind of that, you know, background that experience that understanding? And so, you know, part of it is, is that getting the looking for the right types of feedback, and that's often going to be the feedback of people that you
think, might disagree. You know, and or might challenge. Now, you know, there is a difference between once again, being consulted, and being the one thats either responsible or accountable. Right. So if someone has a level of expertise that's required to actually accomplish the job, and, or should be the one held accountable for this, then they shouldn't be consulted, they should be on the project. But you know, so you have to be clear that we're drawing the
right lines. But you know, there's going to be subject matter experts, there's going to be people out there who need to go to an approach and ask the questions, I mean, get the information from. And as you said, oftentimes it's it's the people that you expect are going to challenge you that are the best sources.
So moving from that consultant to the last letter in the acronym, the raci acronym that informed one of the things that I found is that because when we are intentional about thinking about who needs to know, the outcome of this, we avoid a lot of application or integration problems. People love to know what's going on. We I think one of the biggest challenges we all have is
communications. I don't know about you, but I can certainly reflect on the many times where my wife has said, Why didn't you tell me about that? Wasn't because I didn't want her to know, it's because it just never crossed my mind that she needed to be informed. And of course, the same goes I could name bosses, I could name him employees over the years who, you know, same type of struggle.
So the when we are intentional, and we actually sit down and say, okay, we know who's responsible for this, we know who's going to hold us accountable, and who is being held accountable. We know who we need to be consulting to make sure that we have looked at all sides of the argument. Now who needs to know, who are the stakeholders that we need to communicate with? Now, this is
an easy one to overlook. And I think it's probably one of the biggest ones that we assume that somehow through osmosis, they will discover it. But they're also the ones who can come back after we were way too far down. You know, that the timeline, who when they didn't discover things, they come back, and next thing, you know, we have to redo things we have to wasn't that they had to be consulted. But once they were informed, they
raised all sorts of issues. So I think we don't have a column that says when do they need to be informed. But part of that, who needs to be informed, does need to include where does that fit on the timeline? And ultimately, we're informing people to keep them up to date, of course, but also because at some level, them knowing helps move the project forward. Does that make sense?
Yeah, it absolutely does. And I think there is a difference obviously, you know, you would hope Each project has some form of communication plan laid out that does have those times and for the regular communications and all of those types of things. But being intentional about that informed concept is for the is is even more important for the things that don't fit the regular communication schedule. So, you know, there's there's a saying about, you know, always deliver
bad news early. Right? Don't don't now, its a, especially in my experience, once again, on technical projects, there's this sort of concept that we're going to keep the problem in house because we're sure we're going to be able to fix it. And if we can fix it, that we don't ever have to tell anybody, it was a problem. And that's normally a
recipe for disaster. And so you know, if you do have these, these inform, these people who you know, you need to inform of certain major milestones or major work products on a project, then, you know, that's the type of person that you need to go to and say, Hey, we have a problem. Now, we think we have a solution, we think we can solve this. But we have this major issue that if we can solve, it, is going to become a major
problem for the project. And the earlier, you're able to deliver some of that information, ultimately, the better off it is for you in the project, even though that's not always the most pleasant conversation to have. And I think, you know, being intentional about filling out that informs category makes it easier for you to do that and makes you more likely to follow through and those types of things.
I really like that I think that's a really powerful observation. And I think every one of us have been guilty of withholding information, if you wish, at some point, just keeping our fingers crossed and hoping that you know, the problem was going to go away, and we would never have to divulge it. But I think you're absolutely right. And when we have identified from the outset, who those stakeholders are, that need to be informed, it does make it a lot easier to enter
into that conversation. This has been a quick review, if you wish of the raci process. And primarily it's not about the process as it is about helping people deliver their best, because they are clear on who's responsible for what they understand where the accountability lies, they are getting feedback information or consultation from the right
group of people. And they can go to sleep, you know, comfortably at night, knowing that the people who need to know what's going on are actually being communicated with any closing thoughts as we wrap up this podcast.
Nothing I don't that I don't think we've touched on you know, I think there's lots of variations on those models and lots of tools for doing that out there. And I think they all have merit. And you know, you can argue about individual extra categories that are added and all the rest of that. But I think as you said the concept is really that intentionality and making sure that you're you're deliberately looking at this and making choices.
Awesome, good stuff. Thanks very much. Well, for listeners, don't forget to check out the show notes. They are going to be some additional resources, if you wish in their definition and explanation of the raci chart. So if you want to get that as well as perhaps some links to help you expand on that. It's not about a specific model. It really is about the concepts behind them. And I've enjoyed this conversation. Dale, thanks very much for being part of this. Thanks to Ela for
ngineering today. And we're ooking forward to connecting ith you in our next podcast. ntil then, have a great time eading messy people