Stop Pointing Fingers—Use A RACI Chart (with Suze Haworth)

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.

Ben Aston: Perhaps one of the trickiest things about managing projects is that we have to work with … well, people, and people are incredibly variable. We’re inconsistent, we’re egotistical, we’re unreliable, and we’re incredibly fickle, and I’m just talking about myself. So I wonder if your projects are anything like mine. When they go wrong, and of course, they also do at some point, it can quickly turn into horrible finger-pointing exercise, where everyone seems to be accusing everyone else of not doing their jobs properly. So how on earth can we manage a project when we’ve got all that to contend with? Well, today you’re going to find out.

Thanks for tuning in. I’m Ben Aston, and this is the Digital Project Manager Podcast. This podcast is brought to you by Clarizen, the leader in enterprise project and portfolio management software. Visit Clarizen.com to learn more. Today I’m joined by Suze Haworth, one of our resident DPM experts at the Digital Project Manager. Suze, thanks so much for coming on the show.

Suze Haworth: Thanks, Ben, thanks for having me here.

Ben Aston: Let me introduce Suze properly, because she is new. This is, I think, our first ever podcast together.

Suze Haworth: Yeah.

Ben Aston: Suze is a freelance digital project director in London, and she’s got stacks of experience, being in the industry for over 13 years, starting in account management, similar to me, and then heading over to project management. But rather than just reading off your bio, Suze, can you tell us a bit about what kind of projects are you working on right now?

Suze Haworth: Right now? Well, actually, last year I just moved to freelance, so I’ve been working, like you said, for a number of years across various agencies, but last year I went freelance. So at the moment I’ve got a position in an agency in London, and I’m doing two big projects, one being a design system for quite a large retail brand, and the other I’m managing a program of work for another retail brand. It’s all quite interesting work.

Ben Aston: So is retail your thing?

Suze Haworth: It’s actually all over the place. I’ve got a lot of retail, a broadcaster, charity, all sorts, but yeah, there’s quite a strong retail focus on the accounts I mentioned at the moment, so you could say that.

Ben Aston: Cool. In your kind of freelancer role, what do you find tougher? What are some of the kind of bigger challenges that you’re dealing with right now?

Suze Haworth: I think probably the biggest challenge, and this is always the case with project managers, I think, speaking from experience, is that you’ve just got so many different things to manage and to do, that you’re responsible for. So not only that you’re trying to deliver a project successfully, but you’re managing timings, budget, team outputs, the actual team members, so there’s a lot of sort of team problems you have to manage too, and then also, obviously, the client contact. So it’s just really hard to juggle a lot of things in the time you have. Often I feel like it’s a constant battle to squeeze everything into one day, really.

Ben Aston: Yeah. Do you find that harder, because you’ve obviously been permanent, and now you’re kind of in this contractor role, do you find it different? Or how does that work out for you?

Suze Haworth: I think, yeah, I mean, it is a bit different in the sense that as a freelancer you’re kind of more responsible for your own time, in terms of your sort of charging yourself to the agency. You can’t get in a position where you feel like you can’t say no to things. I think it’s a thing that I’ve learned to do better, is to, if there’s too much on your plate, you can only do so much, and you need to do it properly, so it’s best, rather than just saying yes to doing everything, is just to sort of have your limits, really, where you can say no to doing everything.

Ben Aston: Yeah. I think when I was a contractor, I found that to be true. There’s actually something really nice about being a contractor, because you can just … because you’re not trying to … I mean, you’re not really interested in the promotion. I mean, you obviously want to retain your contract and keep working with them, but you’re not trying to impress people in quite the same way that you are when you’re a permanent member of staff, and you’re like, “Well, I better say yes, or this is going to look bad.”

Suze Haworth: Yeah, exactly. I mean, you still want to create a good impression, obviously. The industry’s small, so everyone knows everyone, but no, I think it’s always good to have a bit more kind of, you can step back a bit at the end of the day and say, “Okay, my hours are done,” a little bit more, really, sometimes than being permanent.

Ben Aston: Since you’ve been contracting, how many different places have you been working at?

Suze Haworth: Only a couple so far, actually, because I haven’t been doing it that long. So that’s been quite good in a sense, because I actually have built up a bit of time at this agency I’m at now, so I know people quite well. I know the clients better, because you’re actually getting a bit more length of time on the projects and on the accounts.

Ben Aston: Are you working in-house, or are you working remotely mainly?

Suze Haworth: No, in-house. I do actually, I really sell the benefits of remote work to everyone I speak to about it, because I think it’s really important and can actually be a lot more productive for a lot of people, but I find a lot of the agencies, and specifically in London, where I’ve worked quite a lot, they do a lot of in-house work mainly.

Ben Aston: Yeah, interesting. I know that you, as well as freelancing and doing your contract work, you’re also … you write. You’ve written stuff for DPM, but you’re also going to be at the DPM Summit later in the year. Can you tell us a bit about that?

Suze Haworth: Yes, I can. I’m really excited about that. Last year I spoke at the DPM Summit in Las Vegas, and this year I’m actually running a workshop. So it’s quite a interesting topic, because as PMs we’re all quite obsessed, I think, with methodologies, especially Agile methodologies, so I’m talking at a workshop about kind of blending approaches, specifically something I’ve been implementing on a program of work I’m working on now, is the Dual-Track approach. It’s using some sort of aspects of Agile, but sort of merging them a little bit. So I’m talking about that, Kanban, Lean, and kind of how you can blend different approaches to your projects, so not necessarily pure Agile or sort of single pure methodology, but adapting the existing methodologies.

Ben Aston: Yeah, that’s cool. And I think that’s so important as well, and it’s one thing … Suze is actually one of our DPM Experts, and she is making an appearance on our Mastering Digital Project Management course. If you’re not sure what I’m-

Suze Haworth: Yes, I am.

Ben Aston: It’s actually coming up this Friday, so it’s Suze’s first appearance. One of the things that we talk about on the course is not getting too hung up on the name of the methodology or what-

Suze Haworth: Yeah, exactly.

Ben Aston: It’s all about, ultimately, delivering work and finding better ways to deliver work in a way that works for the team, that works for the project, that works for the client, and just being pragmatic about that, rather than dogmatic about, well, this isn’t Scrum, we need to do this Scrum. Well, it honestly doesn’t really matter. We just need to deliver the project.

Suze Haworth: Exactly, yeah. I mean, that’s what I’ve always found, is just so obsessed with the process and fitting to a certain process, but it’s actually, you need to look at your projects or the product you’re making and think, “What will work for this?” And it’s so different between different projects, so adapt or blend.

Ben Aston: Yeah, totally. And I think some people can be a bit disparaging of diluting the purity of methodologies, but I’ve never found them to work.

Suze Haworth: No, exactly. I know there’s a lot of snobbery around favorite approaches, but I’m quite open to using them. And I think in most cases, especially in the agency world, I think, you have to actually use a merged process rather than something pure, just because of the situations you’re in.

Ben Aston: Yeah, definitely. Aside from working on your conference tour, writing article, working, is there anything kind of that you kind of set yourself as goals for this year that you’re working at, that you’re trying to get better at?

Suze Haworth: Oh God, that’s a tough one. I think I’m so focused at the moment in the now, like in what I’m doing in work and outside of work, it’s kind of hard sometimes to think of the long-term future. But yeah, I think one big thing that I was talking about earlier was that sort of learning to say no. I’m trying to get a lot better at delegating and actually letting go of responsibility a bit, which is something I’ve always kind of found to be a tricky one. As a PM, you kind of become a bit of a control freak about things, so that’s definitely a long-term aim for me.

Ben Aston: Yeah, delegating is tough. I think especially when you’re a contractor, when you’re not really sure if the person that you’re delegating to is going to A, take you seriously, because you’re just a contractor, but B, you’ve got no history of working with them, so you don’t know if they can actually do what you’re trying to delegate some of the time.

Suze Haworth: Exactly.

Ben Aston: So let’s talk about tools for a second, because obviously, being exposed to being working at different places, you get exposure to different things. Have you found anything recently that’s making your life awesome, or that you’re like, “Everyone should know about this”?

Suze Haworth: To be honest, as a freelancer and working in lots of different agencies over the years, even in permanent roles, you just get exposed to so many different tools and have to use whatever the company uses, generally. So I would never say I’ve found the ideal tool or perfect tool that does everything that I would like it to do, or doesn’t have its difficulties or issues that you have to wrangle. So actually, I probably wouldn’t say there’s one ideal tool that I use. Resourcing tools and things for timesheets, and I’ve used a huge range, and like I said, every single one, I found some good things about it and some bad things. The only tool, if you can call it a tool, that I actually love is Google spreadsheets. That’s because you can use it for everything, I think, or a lot of different things.

Ben Aston: Have you tried using Monday.com?

Suze Haworth: No, I haven’t, actually.

Ben Aston: Because for someone who likes managing things by spreadsheets, I think Monday may just be-

Suze Haworth: Such a geek.

Ben Aston: Well I mean, the great thing about spreadsheets is that they’re free, or at least Google Sheets is, and they can be incredibly flexible. But I think Monday adds an additional layer of automation to things and power into the filtering and control. You should check it out. Maybe it will … It’s like spreadsheets on steroids.

Suze Haworth: Oh, I’ll definitely have a look then. Sounds right up my street.

Ben Aston: Cool. Well, let’s go on to talk about your article. It’s a while since you wrote it, but going back to kind of where we started this, how is it that we manage the matters of people who often either seem to want to take over a project or either seem to take no responsibility whatsoever? Suze’s article is all about how we use a RACI chart to do that. So for those who haven’t read the article yet, tell us about RACI charts. What does “RACI” mean?

Suze Haworth: RACI stands for responsible, accountable, consulted, and informed, so it’s basically quite simply a chart where you map tasks or deliverables for a project against those stakeholders or internal team members of your project, and you assign one of the four letters, I guess, to each role and each task. So it would be responsible, somebody’s responsible, somebody’s accountable, somebody is consulted in the project, and someone’s informed. It’s a great way of assigning responsibility for each task or deliverable and making sure that too many people aren’t involved in making every decision, and that you have a clear sense of who will be working on what throughout the project.

Ben Aston: Cool. I think one of the things that the people typically … I mean, the most confusion around … seems to be not around who should be informed or who should be consulted. Those tend to be quite straightforward, but it seems to be the confusion between what does responsibility mean, or someone who’s responsible mean, versus someone who’s accountable? So how do you kind of work through that, and how do you manage people thinking they want to be responsible but not accountable? Tell us how that works.

Suze Haworth: Yeah, I think this is actually the trickiest area of the RACI, and one I’ve actually struggled with a lot in the past myself, and that’s why a RACI has ended up becoming quite a beast to actually create, because you’re spending so long just trying to think what does that actually mean, and what does that mean for the person who’s going to be assigned that role? But quite simply, if you think about responsible as a person who is actually doing the task, so creating a deliverable or managing it through, so it’s the person who’s actually doing. Then the accountable is the person who is responsible for approving the task, sort of overseeing it, so not actually doing the task.
The other struggle, I think, with responsible and accountable is that you can have this sort of tendency, if you’ve got, obviously, a project manager on your team or a product owner, you can often assign accountability to them, because they’re the one running the project in the central point. But actually thinking through, you’ve got to try and separate the project manager away from being accountable for everything and think who actually is more kind of senior within that task or deliverable. So if it’s design, would it be a creative director? Would it be a creative director your side or client’s side? So it’s kind of trying to not lump the accountable role on the project manager or product owner all the time.

Ben Aston: Yeah, I think that’s key, isn’t it? Because I think the mistake we can easily fall into is making everyone responsible and everyone accountable, not just even the project manager, but it’s like well yeah, everyone needs to be responsible for this. We need collective responsibility or collective accountability.

Suze Haworth: Yeah, that’s so. Exactly, and it’s really hard because you do feel like oh, now the team members will be doing that as well, so there will be like five people doing that task, so they’re all responsible for it. But you’ve really got to try and streamline a bit and narrow it down, because if you’re just spreading roles across sort of everyone, you’re never going to achieve what the RACI is best at doing, which is kind of clearly defining, generally, a single point or a few points of contact or approval level. That’s what the RACI’s for, so it’s about using it right.

Ben Aston: Yeah, I think what’s really helpful … I mean, working out who’s responsible, who’s actually doing the work, that’s not normally the complicated thing, but working out … okay, this tends to be a tricky aspect to me as well … are the difference between consulted and informed, because I think really what people are getting confused about generally is the difference between accountable and consulted. And like you said, we really just want one person to be accountable, one person to have the final say on whether or not this hits the mark almost. Kind of like a quality control thing, whereas we can have more people who are consulted and even more people who are informed. They’re just the ones who are copied in on, “Hey, by the way, guys, this is what we came up with.”
But the consulted are the ones for me who can actually derail the project, because they’re the ones when we’re saying someone has to be consulted or should be consulted, they have a voice, they have a say. They’re not necessarily accountable for delivering on time or the right thing, but they certainly have a voice. And so actually, I think the real sensitivities between that accountable or consulted, and the power play between people who are wanting to exert their position or their authority or their opinion, but they’re not actually ultimately accountable for making sure that it’s delivered right or that it’s delivered properly.

Suze Haworth: Yeah, and actually the other tension there is that obviously, consulted will, like you said, will want to be … because you’re sort of telling them they are consulted, they would almost have to have a voice. So that’s where the accountable role is really important, who you assign that to, because they need to own that deliverable or task, to make sure that the consulted are feeding in but not, like you say, derailing the whole project by producing rows of feedback or whatever they’re sort of consulting on there.

Ben Aston: Be honest, though, in terms of a RACI chart. I mean, you’ve provided a great example of how “Lord of the Rings” could be … what it would look like if it was a RACI chart. But is this a piece of documentation that you use for every project, and how do you keep it lightweight? If you go down to lots of levels of kind of granularity, this could take ages to produce, so how do you prevent this from just becoming another work breakdown structure with people’s names next to it?

Suze Haworth: Yeah, I mean, something I’m really, really keen on is not to create too much documentation just for the sake of it, so I don’t want to put in place or suggest using documentation that actually won’t have a use in the end. But if you are doing a RACI, you have to make it useful and actually use it, and that’s really important. So you don’t just create it at the beginning of a project and then let it die on server somewhere. You actually really need to reference it, use it when you are sort of going through your deliverables. And then also at the end is, in your review of the project, look at how you used it. Was it successful? Was it right, what you set out in the first place? So you have to actually use the document to make it useful.

Ben Aston: Talk me through, then, a scenario where you bring up the RACI. Do you use it in your status meetings, when you’re saying in the upcoming week we’re doing this, this, and this, and let’s just refer to our RACI chart, so these people are accountable and these people are responsible, and we’re going to consult and inform these people along the way? Or how do you play it out in a kind of week-to-week role?

Suze Haworth: I think I don’t necessarily use it within status. Obviously, it tells you who you should be going to, who you should be involving in things, so you should be sharing deliverables with, or who you should be assigning tasks to. But I think it’s more of an internal reference point for you, just to check back on if you need to remind yourself of who’s involved in this deliverable, who you should be sending it to for feedback, and who should be informed of it once it’s delivered, as well. So it’s more just an internal reference tool, but obviously, call out if things aren’t going that way.
And that’s where you can really use it as well, is if, say, you’ve assigned the consulted role, for example, to a task or deliverable, and then suddenly everyone on the client-side or stakeholders just want to get involved, then you can go to a direct client contact or whoever you’re dealing with most on the project and then actually talk to them and say, “Look, this is what we created together at the beginning. You know, we need to sort of follow it, because this is aimed to create efficiency, keep communications streamlined and not add layers of bloat and time to the project.”

Ben Aston: Yeah. So I understand it, the way that you run your RACIs is a combined RACI that spans kind of agency and client, or do you have kind of two separate ones?

Suze Haworth: I’ve used kind of different approaches before, but one I think, it really depends on the project, so if you’ve got sort of two huge teams, your side and client side, if you’re working with clients, then it could potentially be better to create two. What I’ve done more recently is I’ve actually created more of a client-side one when they’ve got a lot of stakeholders involved, because the real thing is kind of knowing who to involve their side and when. And we had a kind of a slightly more streamlined team our side, so I sort of put our agency together as one, and so where there were certain responsible tasks, we took responsibility for that, but a lot was also responsible on their side. So I made sort of a slightly bigger one on their side. So it does really depend on the project. I know that’s the classic answer for everything, but you need to sort of tailor it to your projects.
And also, I mean, the main thing with the RACI is make sure you are doing it to provide something useful. So your project might not necessarily need one. If you’ve got a really small, lean project with a few team members, one client, it’s actually probably quite pointless to use one. So it’s really sort of assessing the need and what you’re trying to do with it. Is it to make sure, because there’s a lot of stakeholders, either client-side or internally, you need to manage them and set clear expectations of who’s involved? Then you know, you create one. So you’ve really got to tailor it towards the project.

Ben Aston: Yeah, and I think what the RACI is great at is for … It helps prevent things falling through the cracks, and people being able at the end of a project or at the end of a deliverable being produced, turn around and say, “Hold on, why wasn’t I given a chance to feedback on this?” Or someone turning around and saying, “Oh, well I thought design were annotating the wireframes,” or whatever it might be.
But I think in my experience, we don’t necessarily have to give the client a full view of everything that’s going on internally, in terms of our process of who’s doing what, who’s responsible, who’s accountable, who else is being consulted. That’s usually not necessary and actually can create some confusion. But definitely on the client-side, when we’re thinking about okay, how are we managing the client through the process, particularly when there’s a large team, and particularly if we know it’s a very political organization or we know that they struggle to make decisions?
To find that one person who’s accountable and saying, “Hey, remember at the start of the project when we said you were going to be this person who is accountable? Is that still the case? Because if it’s not the case, then we probably need to adjust our process or we need to extend the timeline, or probably increase the budget as well if it’s going to get more confusing.”

Suze Haworth: Yeah, exactly. And that’s why it’s so important to involve … if you are working with clients, involve your clients or your internal team, to whoever you’re assigning responsibility or accountability or consulted to, to really get them involved in creating it with you, because it’s quite a piece, again, that you can do in isolation. You just send across to somebody for approval. And they might not really think through things. They might just say, “Yeah, that’s fine, you know, let’s carry on with the project.” But if you’re kind of getting them involved in making those decisions at the beginning with you, then you rule the lines, and you can sort of progress on the project, and you’re all clear on who is doing what, I guess.

Ben Aston: Yeah, So in your experience, when does the RACI stop working? When does it fall apart? You’ve created this documentation at the beginning, you’ve tried to agree everything, but when in your experience do things start to unravel? What the kind of watch-outs, or what are the red flags for people to look for that this thing isn’t quite right?

Suze Haworth: I think probably three of the things I’ve touched on in this already, but basically, if you don’t get agreement from everyone upfront. So if you’re just creating it in isolation, you assign responsibility to a team member, and they don’t really know about it or agree to it, or if you’re sort of assuming, making assumptions for the clients and sort of saying, “Well, actually, I think they’re accountable, I think they’re responsible,” and then okay, now I’ve created it. So you need to get everyone’s buy-in, especially the people who are going to be accountable for things or responsible for things.
Also, it’s really key to use it, so actually, just make sure that you are referencing it throughout the course of your project. You know, check things are on track, check the right people are involved. If you just leave it to sit there, it’s a bit of a waste of time in a sense, it’s almost just a check box you do at the beginning. And then, sort of after the project, it’s really good just to review it and see if it was useful, if it was right, if you were sort of mapping things accurately, just because that would be useful for future RACIs that you create.

Ben Aston: I was going to ask, though, in terms of … We’ve talked about how we create it and how we get buy-in. We’ve talked about when it can fall apart. But when it does fall apart, because this is the reality of projects, right? We think we define roles, and we think we know everyone should know what they’re doing. We’ve even documented it. But then finger-pointing starts happening, things are falling in between the cracks, people are getting upset. I mean, this is a very broad scenario, but how do you kind of try to tighten things back up when they start getting a bit loose? Talk us through that.

Suze Haworth: Yeah, I mean, it’s probably quite tempting to use it as a bit of a tool which, if things are going wrong and people start getting too involved or people that you didn’t expect on client-side, for example, getting too involved, it might be tempting just to sort of hold that up in front of them, go, “Well actually, you agreed to this in the beginning,” but it’s not really, in a sense, meant to be used sort of just as a “Oh, look what you agreed to, you’re not following it.” It’s more, you know, “Look, this is where we all aligned, this is where we basically tried to create project efficiencies upfront, and where we tried to set expectations, and basically, some people aren’t following this, or what they’re doing is adding more time and effort to the project.”
So just talking through the implications with the people who are either derailing it or involved with the people derailing it. So just talking through the implications to the project and why you set this up in the first place, why you agreed to have certain people involved or responsible. It’s just important to make them understand sort of what could happen if it continued down this road.

Ben Aston: Yeah, I think you’re helping people, reminding people about the kind of rationale for why things are how they are, or how they were defined at the beginning of the project, is great in helping people kind of get back in their box sometimes. Ah yeah, there’s a reason that I’m not accountable for this, and that’s because I don’t actually have the expertise to comment on it.

Suze Haworth: And also, that really leads back to making this a document which is really useful, so having a reason for it. We need to create efficiencies on the project, because you have a limited time or a limited budget or this, there’s a reason for it. So if you don’t do the RACI document with a reason in mind, you know, it’s pretty much worthless, because you don’t have anything to relate back to, so it’s a bit of a waste of time then. So yeah, it’s really cautious to make sure that you can see some clear benefits to doing it and you are creating efficiencies.

Ben Aston: It’s tough. Well, if you would like to download a RACI template, Suze has created one for us, as well as, as I said, a really helpful example using “Lord of the Rings” to explain how this might how it might apply to a project. You know, an interesting bit of information. When we sent out the email saying, “Hey, Suze has written this article, and we’ve got this example based on ‘Lord of the Rings’,” someone emailed back to me and said, “I can’t believe that you’re wasting everyone’s time with this.” And they wrote back this really snarky email. And then I don’t think I responded, but I was surprised. Then a day later, they’re like, “Oh, I did read the article, and it was great. I just don’t like ‘Lord of the Rings’.”

Suze Haworth: I know. It’s quite specific. And also, when I created that matrix for “Lord of the Rings”, I was like, “I’m sure I’m going to get some of this wrong.” So yeah, in isolation, I’m like doing exactly what I say don’t do. But yeah, it’s to bring it to life in some sort of relatable way.

Ben Aston: The part of it that was great, it’s how to … at least some people will have an understanding of that project to get the Ring. But yeah, I think it’s obviously a bit divisive. But I think it’s great. So Suze, thanks so much for joining us. It’s been great having you with us.

Suze Haworth: Thank you.

Ben Aston: If you’d like to contribute to the conversation, comment on the post or head to the Resources section of TheDigitalProjectManager.com to join our Slack team, where you’ll find all kinds of interesting conversations going on. And if you’d like to hear more of Suze, head to the Training section of TheDigitalProjectManager.com and get yourself signed up for the next mastering digital project management course, where Suze will be featured. But until next time, thanks for listening.