How to Make Sure the Right Work Gets Prioritised

Paul Boag

This week on the Boagworld Show, we discuss how we should be prioritising our workload. Should we deal with incoming jobs on a first-come, first-serve basis or is there a better way?

This week’s show is sponsored by GatherContent and TeamGantt.


Paul Boag: This week on the Boagworld Show, we discuss how we should be prioritizing our workload. Should we deal with incoming jobs on a first come first serve basis or is there a better way? This week's show is sponsored by TeamGantt and GatherContent.


Paul Boag: Hello and welcome to the Boagworld Show, the podcast about all the aspects about user experience design, digital strategy, and working digital. My name is Paul Boag and joining me as always is Marcus Lillington who picks that very moment to take a drink so that he wasn't prepared to say anything.

Marcus Lillington: I do everything to annoy you, Paul. It's my job. To put you off.

Paul Boag: I see from the video that you have stolen a mug from the University of Glasgow.

Marcus Lillington: We've got loads of these. Must have been …

Paul Boag: Really?

Marcus Lillington: We did some work for them, did all sorts of work for them a few years ago and they appeared one day. It wasn't me, but somebody stole them or sent them. We were sent them probably.

Paul Boag: Let's go with that, shall we? Although, that isn't as good, I had a friend once who worked in digital who worked with Ben and Jerry, right? And they gave her a fridge, you know one of those freezer, little fridge things, full of Ben and Jerry ice cream and they continued to top it up through the entire lifetime of her working with them.

Marcus Lillington: That's really nice. I came in yesterday to the office to a really nice thing. It's like, oo, a big parcel with my name on it. Oo, oo, oo, oo. And, I don't know if she ever listens to the podcast, but she's on the Slack channel, G Watson, based down in Perth in Australia.

Paul Boag: Oh yeah.

Marcus Lillington: We helped her out on a project months ago for a client of hers, one of the colleges down there, and she basically had sent a thank you for Dan and I helping her out. Because, she's from Yorkshire, basically, Betty's Bakery in Harrogate. Lots of biscuits and chocolates and cakes and things like that. It was like Christmas. It made me feel all Christmas-y.

Paul Boag: Yeah.

Marcus Lillington: Thank you G if you listen.

Paul Boag: Well, she does occasionally. I mentor her, actually.

Marcus Lillington: Do you?

Paul Boag: She's one of the people that I mentor. So, I talk to her regularly.

Marcus Lillington: Betty's really fancy, says Claire.

Paul Boag: Yes.

Marcus Lillington: Really nice. Put some of the best shortbread I've ever eaten. Fantastic.

Paul Boag: Shortbread.

Marcus Lillington: Yeah. Your mentorship didn't do very well, she had to come back to us.

Paul Boag: To ask one question of Dan about how the hell his CSS worked. Yeah, I know. I know it was referring to that. It was actually me that told her to go get in contact with you because, I took a look at the CSS and I went, "Bloody hell, this is," yeah, I didn't understand it.

Dan sorted her, I believe, which is good.

Marcus Lillington: She's good. Yes.

Paul Boag: Yeah.

Marcus Lillington: Then she sort of saying, "I've got to pay for this." And I'm like, "What?" Don't be daft. So, we love your present. Thank you.

Paul Boag: Oh, there you go. I've decided it's great being old.

Marcus Lillington: There are some advantages.

Paul Boag: Do you know, I sat down, I've got to do, in a couple of week's time, I've got to do a two day workshop, so I'm going up to Doncaster with an organization to do two days of work shopping. Because, I've got a bit of a cold, I might have mentioned subtly in the last show, I was like, I don't know whether I can be asked to do this, this just feels like an un-surmountable job, but I sat down and forced myself to look at it.

And, it's that sudden realization that, oh yeah, this is just, I need to take a bit out of this presentation and this from here and then just kind of assemble it together. And I decided that is one of the great things about getting old. Is the, you've seen it all before, you've done it all before. And so, nothing's … Everything's easier as you get older. Don't you find that?

Marcus Lillington: Press ups are harder.

Paul Boag: Well, all right. Yeah. Absolutely. Totally. But, it's like the older I've got, things don't phase me anymore like they used to and I know what needs to be said and I know, nobody ever asks me a question that I go, "Bloody hell, I've never heard that before." I'm just … I'm more confident, more comfortable doing my job, it's great. I've decided I'm happy being old, finally. I've made that decision. I've come to terms with it.

Marcus Lillington: Okay. I'm going to remember that, because, probably I only have to remember it until next week.

Paul Boag: Well, you know what I'm like. You've worked with me a long time, Marcus. You know how inconsistent I am and how I change my mind every five minutes.

Marcus Lillington: Yes. I was rolling my eyes internally there. God, here we go. This is the current trend.

Paul Boag: Can you imagine how my wife feels living with this all the time?

Marcus Lillington: She must be very thick skinned, that's all I can say.

Paul Boag: You know, she just ignores me. I think that's the tactic.

Marcus Lillington: That's the way to do it.

Paul Boag: Yeah.

Marcus Lillington: Yeah.

Paul Boag: She just doesn't pay … Which is why I have to do a podcast, because otherwise nobody would ever listen to anything I ever said. So, there you go.

Right. Yes. What are we talking about this week? Yes, we're supposed to be doing a podcast, aren't we? That's what we do.

Marcus Lillington: This was about … This is stuff we've already talked about before earlier in the season, that you're rehashing using slightly different words. Is that? I think that's what you said the end of last weeks.

Paul Boag: Yeah. Well, I might have said that. I like to think of it as building upon-

Marcus Lillington: Thought so.

Paul Boag: … and deepening into two very interesting subjects that we've been covering on the show. The first one, we did a show on organizational skills, and so we're going to go take some aspects of that, and we're going to take some aspects of last week's show that was recorded yesterday, which is very confusing. Last week's show on assessing the new and we're going to use some aspects of that.

Marcus Lillington: It's like a big summary show, isn't it? This should be the last one in the series.

Paul Boag: Yeah, yeah. It should be really. To delve deeper into how to get our work priorities straight. How are we going to prioritize the work that we do, and how do we know that we're working on the right stuff at the right time? But before all of that, we've got the most important bit of the show after the joke, obviously.

I'm basically just a filler for Marcus' bits. I think it's how most people see it these days. We need to rename it the Marcusworld Show or something. We can't call it the Lil-lil-lil-lil-ing World show, because that would just be painful.

Marcus Lillington: I don't want all that pressure, Paul. I'm quite happy just filling in.

Paul Boag: Sliding into retirement.

Marcus Lillington: I wish. No, I'm a long way from that.

Paul Boag: Yeah, I know. Depressing, isn't it?

Marcus Lillington: Nah, not really. I thought you were happy, Paul, about getting older and …

Paul Boag: Yeah, but I'm not old enough. That's the trouble. For start.

Marcus Lillington: By the time you get to being old enough, you'll then feel decrepit and hacked off a little bit if anyone said decrepit.

Paul Boag: No, I wait to be …

Marcus Lillington: That's what you got to look forward to.

Paul Boag: No, no, no. I just need to be three years older. That's all I need. How old are you, now, Marcus?

Marcus Lillington: 52.

Paul Boag: See. You can go on Saga cruises.

Marcus Lillington: Weirdly, I was expecting to be massively targeted by Saga. Nothing at all. Maybe it's a bit older now. Maybe it's 55 these days for Saga.

Paul Boag: No, it's 50. My dad lectures on Saga cruises, you see. And, he's really made me want to go on a Saga cruise. That's the saddest thing I have ever admitted in a public venue before.

Marcus Lillington: Well, if the wonderful Headscapers, Chris Henderson, who is just 30 has been going on cruises with Mrs. Henderson for years. They love it.

Paul Boag: Yeah. I'm not saying … And I've been on cruises, and I love cruises.

Marcus Lillington: I don't. I've never been on one.

Paul Boag: Do you not?

Marcus Lillington: I've never been on one. It does not appeal to me at all.

Paul Boag: That's interesting.

Marcus Lillington: I imagine it's full of Daily Mail readers being sort of with their drunken Brexit opinions, pulling into beautiful Mediterranean ports and not wanting to go and see anything because it's full of foreigners.

I'm painting a picture here, aren't I? It's probably a little bit bad.

Paul Boag: You are painting a picture here. And I think you're painting a picture of some cruises very accurately. But, I don't think all are like that, by any means.

Marcus Lillington: No.

Paul Boag: I'll tell you the reason why I like cruises. This is nothing … How did we get onto cruises? Anyway, the reason that I like cruises is because there are certain places in the world, if I'm honest, that I'd like to go to, but either I'm slightly nervous about going to it, or, alternatively, I'm too old to deal with the backpacking kind of slumming it version of it.

With a cruise, you could go somewhere like India or a developing country and you could just kind of pop in and experience the poverty and then go back to your five star floating hotel.

Marcus Lillington: Do I have to wait it, that out. I'm not sure.

Paul Boag: Oh yeah, Lewis has given it a brilliant phrase. I don't know whether he's just made that up or whether he found it online, called peek privilege. You have a little peek, and then go back to your privilege. I like that. That's good.

Marcus Lillington: I quite like the idea of going around a bunch of islands on a boat. That's okay.

Paul Boag: Yeah, but that's a different thing. I would like to do that in Pacific.

Marcus Lillington: Oh, that's too far away. Far too far away. You've got the Caribbean just over the water. That'd do with me.

Paul Boag: Yeah.

Marcus Lillington: You can pretend to be a pirate and everything.

Paul Boag: I could compromise on the Caribbean if you twisted me arm, maybe.

Marcus Lillington: I've been there a couple of times. Lovely.

Paul Boag: Get on with your thought for the day.

Marcus Lillington: Okay. Well, interestingly, Paul, I have just come back from a couple of days' workshop.

Paul Boag: Oh yeah, did it go well?

Marcus Lillington: It did. Yes. It was cool. Two days is a long time. I don't know how I've done these five day ones in the past. May have been drugs or something, I don't know. Anyway, so yeah. Came back from a couple days workshop for a university client and it all went really well, but the experience reminded me of how sometimes you really need to have to think on your feet and be prepared to sort of refocus what you're working on, what the activities you're doing and not blindly carry on with your preconceived agenda.

Paul Boag: Do you know what helps with that?

Marcus Lillington: What's that?

Paul Boag: Being older. Because you've seen it all before.

Marcus Lillington: Seen it before. Yeah, yeah. Yeah, I supposed. I think it takes a little bit of bravery as well, in front of a room of 200 people, which more likely to do if you're older and you don't care as much. Anyway, having a set agenda is obviously a good thing, because it means that we can plan ahead and we can prepare for stuff which makes for a more useful and interesting exercises, et cetera, et cetera.

We also tend to know, because we've don't this loads of times before, there's a theme here, isn't there, that kind of one exercise will lead well into another. It will inform the next one. But sometimes, what you thought would be a valuable task just isn't. You need to stand up, pull the plug on it, explain why, because it's probably what everybody's thinking anyway, and then move on.

Paul Boag: Yeah.

Marcus Lillington: This particular client is a new client to us, which is nice in the HE sector. And the project involves design and build, which is even nicer in the HE sector because we seem to be hired more and more just as consultants.

Paul Boag: Yeah.

Marcus Lillington: So, it's lovely to be doing a design project. But, specifically on this one, we are being hired to firstly kind of extend, in air quotes, and existing design that's okay, but doesn't really represent their brand. It's a bit safe.

And, two, create a patent library slash design system to give their team a source of truth for the future. Which is cool, but, defining where the boundaries are on this is hard. There's a kind of understandable desire from them to, please, can we keep as much as we can? And it's like, okay. But while ensuring that the new design truly represents the brand.

Part of this workshop process, like I said, it's more of an underlying part of it, it wasn't a specific sit down this next hour we're going to cover this. It was like the whole thing was underlying it part of it was to try and find out what things people really don't want or can't change. And one of those was any major changes to content, which we didn't really know that, especially before this session.

We had plans to do a major page types review and rewire framing, but with a few notable exceptions, the pages aren't really going to change that much. This is an example of we had to kind of think, there's not a lot of point in, well, we're going to do this page and not much is changing, and the next one, and not much is changing. Just go, hang on a minute, let's spend our time more wisely.

In their case, the major changes are going to happen on a very focused component level. Not completely but generally speaking, it's going to be the building blocks of the pages are going to change rather than the actual pages. We changed track to review individual components in detail. We took forever, but it was well worth it in the end.

My message here is, basically, don't be afraid to say, "Hang on, this isn't working. Let's look at it in a different way," because probably, everyone will thank you for it.

Paul Boag: Absolutely. And like you say, everybody's thinking it in their own heads anyway. You're better off coming out and saying it rather than carrying on regardless. I think people respect you when you have that confidence to do that kind of thing. I think that tends to go down well.

There's always somebody that maybe sees it differently, but generally I think people are pretty nice.

Marcus Lillington: I've missed Andrew Miller. And, I really like Andrew's comments in the chat room. This is why Paul can only pop into places and leave before causing too much offense.

Paul Boag: Hello, Andrew. It's nice in a inverted comments to have you back.

Marcus Lillington: Aww, thanks.

Paul Boag: So, prioritizing. What we're talking about today. I have a format for this season, which is we look at why to do the thing, how to do the thing, and where you can learn more about doing the thing.

Marcus Lillington: Yes.

Paul Boag: Why prioritize? Do we really need to do that?

Marcus Lillington: Well it's bloods boring if you prioritize. If you just randomly do stuff, then it's more exciting. There's a reason to not prioritize.

Paul Boag: We joke about it, but I'm amazed at how few organizations do actually prioritize. If you take an average digital team, let's talk about Andrew's team as he's picking on me. Before I came along and helped them and showed them the light, they were ignorant neanderthals that had no idea what they were doing.

Marcus Lillington: And it's at six minutes 33.

Paul Boag: No, he's in the room Marcus. There's no point of editing it. He can hear me live. But, digital teams often are organizing and managing their projects in an extremely ad hoc way, aren't they? If we were honest about how much of us prioritize our workload, it's on who shouts the loudest, so, which member of senior management is currently throwing their toys out of the pram. And, what's most urgent.

Oh, we've got to get this live by next Tuesday. You know?

Marcus Lillington: There's another element as well, and this certainly applies to me. What's the most interesting thing to do? True though, isn't it? I like doing this. I'll do that.

Paul Boag: Yeah.

Marcus Lillington: But you need to do it for three weeks, but it's like … Or what's easy, because I'm feeling a bit tired today.

Paul Boag: Yeah. That's exactly why I was doing what I was doing just before this podcast was because I couldn't be bothered to do anything else. Absolutely.

And a lot of occasions were not really thinking it through. Lewis seems to have the best approach for prioritizing, which is follow the money. And I quite like that. There we go. We're done. Prioritize by following the money. Oh, what's this Claire has just shared? Oh, Eisenhower's … Yes. Eisenhower's quadrants. Claire, we talked about that in the show on being organized, which why it overlaps quite a lot.

It's a really good tool for prioritizing. Eisenhower's quadrants basically argues that we spend far too much time doing on what's urgent and unimportant rather than what's important. It's a really useful little tool. But, just like Claire, half of us don't actually use it, even though we know it's a thing.

When we really, really reconsidering actually what is important, and, that is something I think we need to be spending a lot more time on, it's especially at a team level. I think that's where things often go wrong and where I think a lot of individuals are very good at organizing themselves. But when we start working at a team level, politics start coming in to play. There's a lot of kind of, "Well, this person is really quite important, and, we can't really ignore them," so we start getting issues there.

The result of all of that is that, things that can actually help us over the long term, just don't get done because they never get prioritized. Actually, a patent library, a design system is a really great example of that.

The number of digital teams that never get around to creating a patent library, even though it can make them way more efficient in the long term, and they don't ever get round to doing that because that doesn't have senior executive championing it that says, "We've got to get this done now." And it never has an urgent deadline on it that means it has to happen fast.

Andrew's just posted a link to his patent library. That would've never happened if it hadn't been for my amazing advice and support. I don't know why he's feeling so smug at the moment. Yeah, I might be pushing my luck at this point. I'll never get to work HE sector again. That's fine.

Right. So, yeah. There are certain things that never get done. We spend our entire life firefighting. So, just dealing with the things that are immediately in front of us. You're always kind of going from crisis to the next and never actually making any kind of strategic futures, decisions. You're never designing or thinking about the future and planning for that long term.

And it's a tough environment and it's not the way to build a long term team. There are lots of things we should be prioritizing we aren't, from design systems, to patent … to style guides, to design principles. All of these things help to provide a good foundation on which to build. But we only achieve those things if we can prioritize.

Marcus Lillington: Right.


Paul Boag: So, that is why we need to prioritize, but before we move on to how to do that, let's first of all talk about our sponsor. Our first sponsor of the show, which is GatherContent again. Which is a really great example of getting more organized and getting more structured. Most people organize their project content with an unholy combination of office tools, don't we?

Oh yeah, send me the content. Here's a PDF. Here's a Word document. Here's an Excel file. Here's a PowerPoint presentation that might have some content in that … And it's just this sort of mighty horrible mess.

GatherContent solves this problem saving you time, money, and energy, ultimately. It helps you gather and organize your content into a single place, structure that content in the right format using templates, work collaboratively on your content creation in real time, manage what you want and what you do and when content's got to be delivered and all of that kind of stuff. And, who can do what, who's got permissions to do what with content. Then finally, once you've done all that, once you've gathered all your content, you can easily migrate it into your CMS of choice or your tool of choice.

To find out more about how to be more productive with your content, get it out quicker, be more efficient, all of that, check out Okay.

Let's talk about how to go about prioritizing. Well there's kind of two kind of areas that I want to look at here. One is, how to prioritize the work … It's two different ways of prioritizing the work we do on a website. One is prioritizing around a technique with Technical triage, which I will share in a moment. The other is around a kind of hierarchy of user's needs.

Let's look at those two. We'll look at the hierarchy of user's needs first and we will go from there. In my experience, a lot of people, as we were saying in the last show get seduced by the new and shiny. And our websites are a great example of that. I talked in the last show, didn't I, about getting obsessed with virtual reality or whatever it be. The big one, actually, the one that comes up time and time again in my experience with websites is personalization.

Marcus Lillington: Oh, yeah.

Paul Boag: Yeah, we must make our website personalized. All right?

Marcus Lillington: Show what you mean by personalized though, doesn't it?

Paul Boag: Oh yeah.

Marcus Lillington: There are ways of personalizing sites that are actually really useful, geographically maybe.

Paul Boag: Absolutely.

Marcus Lillington: Things like that which aren't as … But people tend to mean, I want Amazon.

Paul Boag: Yeah. I want all of the users that go to my website to log in, identifying exactly who they are, so that we can serve personalized content to them, which obviously nobody's ever going to do. But anyway.

Marcus Lillington: Yeah, sorry.

Paul Boag: We digress in a rant about personalization.

Marcus Lillington: Yes.

Paul Boag: Personalization is an example of, it's a new and shiny thing. Often it gets pushed up to the top of the list of things that we're doing, whether or not it's the most appropriate thing to be doing. Another example was a while back. It's oh, we must have an app. Right? Everybody needs an app.

With our websites-

Marcus Lillington: Didn't they?

Paul Boag: No.

Marcus Lillington: I need one.

Paul Boag: You need one, do you?

Marcus Lillington: Yeah. Yeah, I do.

Paul Boag: Marcus' joke app.

Marcus Lillington: Well, there was one once, wasn't there?

Paul Boag: There was, yes.

Marcus Lillington: The joke app.

Paul Boag: Nixed that. That was more of us wanting to play around with building apps, really. Which is a classic example of, it was shiny and we wanted to have a go.

Marcus Lillington: Yeah.

Paul Boag: So …

Marcus Lillington: Yes.

Paul Boag: Yes. One of the things that we need to do as we prioritize our websites and work on our websites is make sure that we're approaching things in the proper order, that we have good foundations in place. Sometimes I think that talking about personalization feels like giving a starving child in Africa a motivational poster. It's a nice gesture, but it doesn't actually deal with their immediate issues, you know?

Actually, I kind of, I was thinking about this a while, and I've written a blog post I will link to in the show notes, about what well, what is that kind of hierarchy of things we need to consider with a website? And, I kind of used Maslow's Hierarchy of Needs as a kind of basis. This idea that one things builds upon another. In Maslow's Hierarchy of Needs, if you're not dealing with someone's underlying physiological needs, then there's no point of talking about their self esteem or self actualization and things like that. You've got to deal with the basics first.

Marcus Lillington: Yep.

Paul Boag: With your website, it's very similar. We should be prioritizing first and foremost, all things accessible. Is your website accessible irrespective of what device people are using, irrespective of whether they've got a disability, whether a temporary disability or a permanent disability, irrespective of the bandwidth that they have available to us. All of those kind of things. At the most fundamental level, if your website is taking too long to load, if I can't view it on the particular device I'm using, none of the rest matters. We touched on this, didn't we, on the last show?

Marcus Lillington: We did.

Paul Boag: Then up from that, once you've done that, then you need to start thinking about, well, is the content relevant? Does it tell users what they need to know? If you are not 100% confident you're dealing with every question, every objection, every concern, anything that somebody might want to know, then stop wasting your time on creating a VR app. You know?

Marcus Lillington: Oh.

Paul Boag: I know it. I feel like a massive kill joy.

Marcus Lillington: No fair.

Paul Boag: I know it's not fair, Marcus, but that's life, I'm afraid. Life sucks.

Then, once you've got it relevant, then you can start. Me, as a user experience designer, we come along and say, "Everything has to be usable. We have to make it as easy to use as possible." But, even that actually comes relatively late. If you can't access it, it doesn't matter whether it's usable or not. If the content is irrelevant, making it usable won't suddenly make it relevant. Actually, usable doesn't come until after it's accessible and relevant. Right?

But, once you got those things in place, you do need to make it so that users can actually find the information they need and only once you've done that do you need to start making it personal. Does the website cater for the individual user's specific needs and whether it's then persuasive and so on and so on.

That's, I think, one of the fundamental ways of going about working out what you should be prioritizing and what you should be focusing on as you develop your website. All of the time, keep asking yourself, "Are we focusing on the wrong thing? Are we getting ahead of ourselves? Are we trying to run before we can walk?"

But, the real kind of tool that I wanted to share with people, is a methodology that I've created. Sounds good. If you call it a methodology, it sounds good, doesn't it? I've got a methodology. I've invented a methodology that I call Digital Triage. And I've rolled this out now across numerous organizations. And I think it really does go a long way to helping people prioritize the work that they do.

It's not perfect. And I'll talk about its shortcomings after I've explained it. And it often needs adapting to individual organizations, but the basic principle, I think, stands. And the principle is based around an emergency situation. A medical emergency situation. So, let's take, for example, an airplane crash.

First responders arrive on the scene. Now, the critical thing to understand in that situation is that there are far more jobs to be done, far more casualties, far more people that need attention than there are people to do the work. Okay? That is the reality in most old organizations. Pretty much every digital team that I ever work with, there are far fewer people to do the work than there are potential work that can be done. Right?

Marcus Lillington: Mm-hmm (affirmative).

Paul Boag: So, how do we address that? In triage, in medical triage, what they do is they go from patient to patient without treating any patient initially, simply assessing each of those patients and working out which ones are most urgent to be dealt with. Now, interestingly, as a bit of an aside, if a patient is screaming and shouting and demanding attention, they normally don't get that attention because they must be reasonably okay if they can scream and shout? Right?

Marcus Lillington: Yes.

Paul Boag: I think there's an analogy to be drawn there within business. But, I might be stretching the point slightly. Anyway, back to the principle. You've got a whole set of potential jobs, patients that need treating, now we need a way of prioritizing those. Well, what I've designed is basically a very simple point system where you assess jobs based on the number of points … You assign a number of points to them, and those points are assigned based on a set of criteria. So we need to define what our criteria are.

Now, the criteria you define is largely up to you. This is where we start customizing things on a per business basis. But, I do have a kind of generic set that I use to start with. There are four criteria I tend to use. Those four criteria are business objectives, user groups, user needs, and effort level.

Let's delve into those a little bit more deeply. The first thing to say is, notice there that there a balance of two business objectives … I'm sorry, two business focused criteria, objectives, business objectives and effort level, which is return on investment, and two that are focused on users, user groups and user needs.

Based on my experience, at least, too often companies are too focused on the business criteria and they lack the user focusing. I've tried to balance those two out. However, equally, I encounter a lot of digital teams that are entirely focused on user needs and kind of ignoring the business side of things as well. It's really important to have the both.

Let's start with your business objectives. Really, the problem is that most organizations don't have clearly defined business objectives, which just blows my mind. It seems like the most fundamental thing. But instead what they have is wooly company goals, like, we want to increase revenue in the next quarter. Or, we want to decrease costs. Or, we want to improve market share. These things exist in some kind of drawer somewhere because basically, what's happened is they create a company report that says, "In the next quarter we're going to increase revenue," or whatever.

Then it's sent out to employees and they just shove it in a drawer and forget about it. So, dig that out. And use that as a basis to define business goals for your website. So, increase revenue might be generate more leads. Right? That might be what the role of the website is in order to facilitate the aim of increasing revenue. If their aim is to decrease costs, it might … the website aim might be do reduce support queries.

If they want to increase market share, the aim of the website might be to increase online visibility. So, whatever. You interpret them. Then, you prioritize them. That is key. You've got to prioritize. Typically, what you'll end up with is a prioritized list of business objectives. That's point one.

Then, you've got to think about your user groups. We all have multiple user groups we're trying to reach, but not all of those user groups are going to be equal in how we see things … in terms of the business benefit. Right? Going back to our higher education example, international students are more valuable than domestic students to the organization. Better or worse, that's the truth of it.

In some higher education institutions, post graduates might be more important that undergraduates, but it kind of depends. You'll all have different audiences. We've got to then prioritize our business goals and prioritize our audiences.

Then, once we've done that, then each of those audiences will have different needs, different things they want to achieve, want to do. What we do is identify the top few user needs for each of those separate audiences. Now, we might do that through something called Top Task Analysis or we might do it through other methods. I don't really care. But, you're going to end up with a prioritized list of user needs.

Then, finally, you've got effort. Then with each of those categories, we're going to assign a points value. I tend to use a one to five points value, but it doesn't really matter as long as the pointage is equal for each of the categories. You give five points to a project if it's going to meet an absolutely critical business objective. You give it one point if it's going to meet a very unimportant business objective. Okay?

With user groups you do the same. Five points if it's going to appeal to a really important user group. One point if it's going to appeal to an unimportant user group. Now, there's a degree of interpretation, obviously, that needs to go into this. For example, you all have projects that try to appeal to multiple business objectives and multiple user groups. You've got to make a decision. Yeah, okay, it might vaguely help a certain user group that's really important, but it's primarily aimed a group that's less important. You've got to be honest about it.

With user needs, then, you look at the particular primary group you're trying to reach and again, give it a one to five rating depending on how important the user need is within that group. Then finally, you give it a one to five rating based on how hard it will be to deliver the job. If it's going to be really hard, it only gets one point. If it's a trivial matter, then it gets five points.

Marcus Lillington: Yep.

Paul Boag: All right? Okay. So, what you now do, is you take your list of projects and you assign points values to all of them. You end up with a stack, a prioritized stack of jobs to do. Prioritized based on their point value. Then, every time a new job comes along, you give it a point value and then slot it into the relevant place within the stack.

What that means is, that some projects will never reach the top of the stack. If it's a bad idea, it'll never get to the top and never get done. Okay? Now, let's talk about some of the problems with it, because that's all great in principle, let's talk about the practice and where some of the issues come up.

The first thing is that, obviously, everybody wants their project done. What you need to do is you need to create this as a policy in collaboration with the rest of the organizations. You can't just decide one day you're going to do this. You need to say, first of all get everyone to agree that we need some sort of prioritization approach. Normally that's very straight forward. Okay?

Then you need to agree the criteria by which you should be prioritizing projects. And finally then, you need to get agreement on each of your prioritized user needs, user groups, et cetera, et cetera. Now, you'll find that that is a lot easier than arguing over every single project that comes in about when it should be done. You do it once and then it's done. You'll also find it's a lot easier because you're talking in the abstract rather than about people's personal projects. It keeps it all very abstract.

Then, once you got sign off on that, you've got some teeth now to be able to enforce this. But, it's still not without its problems. Problem number one is that some projects, people come to you and they're urgent. There's a time, specific time date on these. Even if they plan … First of all, you got to start educating people, they need to plan ahead because you can't make guarantees about delivery dates because something more important might come in.

But, secondly, you also need to say that you need to publish your stack somewhere that people can see it so they can see stuff moving up the stack and then they can plan accordingly knowing that, okay, it's looking like this is going to be delivered around this time. And you can give people estimates and you can say, "We think it might be delivered by this, but we can't guarantee it."

That is quite a big cultural fit, sorry, cultural shift, should I say. It's realistic, because the truth is, that's happening anyway, right? More urgent things are coming in that are pushing other stuff out. All you're doing is making it more visible and clearer to people that whether something's going to get pushed out and how fast you're getting through the stack that's there.

That's how I tend to talk about the time aspect. Say, well, things slip anyway, we're just being more honest about it. We're being more transparent about it, and we could give you estimates still. The earlier you come to us, the more chance that it's got of getting to the top of the stack before your deadline. Talk to us soon.

The other problem that comes along is the senior manager who says, "I don't give a shit about your priorities, we're doing this now." That's their prerogative. They are senior in the organization for a reason.

But what you need to go back to those people and say is, "Okay, fine. It's totally within your remit to overrule my priorities, the policy we've put in place. But what that means, if you feel a need to overrule it, it means that there is something fundamentally wrong with my policy. So, I'm happy to push your stuff to the front of the queue, if you're happy to show me where my policy is wrong. How is my point system out of wack if your project didn't immediately jump to the top of the queue anyway?"

The truth is, you can't stop these people doing what they want to do, but what you can do is make them pause and think about what they're doing and getting them to look at revise the policy helps them do that. It helps them pause and take stock.

The final problem that you will encounter is people going, "I disagree with your pointing." Right?

Marcus Lillington: Yes.

Paul Boag: So, you've point it in this way. I think it should have five points, you've only given it three points, that kind of stuff. For that, again, that's fair enough, you should always do the first pass at this, but you're not perfect. You're not always going to get it right. Have an escalation path. Have a … Most digital teams of a certain size have some kind of oversight committee or board or some group of people that tell them what to do.

Typically, organizations have this very dumb ass policy where this board is having to sign off on every project that comes along. That just takes forever. It slows everything down. Instead, you use that board to agree on your criteria. Then you're the one doing the pointing and deciding on stuff on a daily basis, but, when someone disagrees with you, it gets escalated back up to the board or the oversee group and they point it and they revise your point system. All right?

Marcus Lillington: Mm-hmm (affirmative).

Paul Boag: That tends to be the system that I use.

Marcus Lillington: I suppose-

Paul Boag: I think. Go on.

Marcus Lillington: Sorry, I was just going to say, I suppose what is potentially missing there is, it could be a business objective. If I was that kind of like, I don't care manager, then, it's the waiting isn't it, that's the problem, because I think what they would say is, "We've just want some amazing thing." I'm making this up as I'm going along.

Paul Boag: Yeah, no. It's fine.

Marcus Lillington: "We need to have … There's a project needs to be done to support this amazing thing because it'll not be in use in six months time, but really it's only just … The only thing that it's helping is our brand," let's say. It means that-

Paul Boag: Right.

Marcus Lillington: Maybe a business objective is for the website to promote our brand. Really the only thing it's going to score five on is that. It's not really a user thing. It's never going to really kind of build up enough points across the board. How do you deal with that? Because, you could argue that it is important, but it's only … How do you weight stuff I'm trying to say. Because if you just say … Do you know what I mean?

It's like, say if you've got one objective-

Paul Boag: Yeah, yeah, yeah. Absolutely.

Marcus Lillington: If you've got 17 different objectives, and you're hitting lots of different of those objectives, then you're automatically going to be better. But that maybe promoting brand is more important than 16 of those other ones, and I don't know how you deal with that.

Paul Boag: Yeah. And that's absolutely fine. I said earlier that I had four groups of objectives, didn't I?

Marcus Lillington: Yeah.

Paul Boag: I said that I had user needs, business objectives, user groups, and effort.

Marcus Lillington: Yep.

Paul Boag: I wouldn't end up with too many, right? But, you could have more than that if you wanted to. You could have less than that if you wanted to. The other thing that can do is I said you should point those all equally. That's because in my world, business and user needs should be equally balanced. It's about both. But not every company and organization necessarily agrees with that. Some organizations honestly believe you should put user needs before business needs. Right?

They're not that common, but there are organizations out there that do that. What they would do is put a multiplier onto user needs. Maybe it's, you take the numbers of user needs and times it by 1.5 or something like that. You could do the same with business needs. Although I say they should all be equally balanced, there's no reason that you have to do it that way.

Marcus Lillington: I think it's right.

Paul Boag: The core principle … yeah. It's the core principle here we're talking about, which is the idea of, have criteria by which you judge things, give things scores, and work through on that basis. That's what it boils down to.

Marcus Lillington: Yeah. You can argue the top crosstalk 00:48:59

Paul Boag: Andrew, for example …

Marcus Lillington: … detail, can't you?

Paul Boag: Absolutely. No, Andrew in the chat room, they do this. But their criteria are different from what I originally introduced them to. Another organization I worked with is Ellen MacArthur Foundation, which is a charity, and they decided to take effort and use that as a divider. Because, the more effort, that should sort of offset the others. You can kind of do whatever maths you want. The only advice I would give with it is try and keep it as simple as possible.

The more complicated it gets, the harder people struggle to understand the system. And if they don't understand the system, if it feels like a black box, then they're going to push against it. They're going to argue with it. They're going to disagree with it. If it's all transparent and open, people are much more likely to accept it.

Marcus Lillington: Yeah, yeah. Though I agree with it, that's absolutely true, but if I was a difficult board member, or whatever, I'd learn the system so I could game it. Do you know what I mean?

Paul Boag: Yes. And that … Yeah, yeah. Absolutely. And that will always happen. You'll always get people that do that. You'll get people right, "Yes, this is a project for this business objective." Bull shit it is.

Marcus Lillington: Yeah, yeah.

Paul Boag: It's not like that.

Marcus Lillington: Exactly.

Paul Boag: And, you got to be honest about it. Any system has flaws to it, and if you're a complete dick head, for lack of a better word, you can screw any system.

Marcus Lillington: The principle, what you said there about just explaining to somebody, "This is how we work," will just get their respect immediately and they'll be interested in it. So, I was just poking holes just for the sake of it because it's my job on this podcast. But I think it's great.

Paul Boag: Absolutely. Yeah. And you do need to pick holes in it because you need to be prepared for the problems that will inevitably come up. And, that's why I picked holes in it myself and said about people get upset about time and some people just overrule it and all of those kinds of things.

You do need to learn how to make the most of it. There is a real power in prioritizing projects based on a policy rather than just ad hoc decision making. Because, it means you have the argument once about what your policy is rather than debating over every single project about how important it is and how it should be decided. The amount of mental effort you spend going over and over the same thing again, and, also when you call something a policy, it's a bit like calling something a methodology. It has an authority to it that … and it makes you, as you said Marcus, it makes you look professional. It gains respect, doesn't it?

Marcus Lillington: Yep.

Paul Boag: And, that's what a lot of it's about. Okay. All right. That's really all I wanted to say on that. I hope that's a useful strategy. I've got to say, I did crowbar that a little bit into the season, but it's something that I do all the time and I've never really talked about on the podcast before and so I wanted to get into it in a little bit more depth.


Paul Boag: I want to share a couple of things about where you can find out more about that, but just before we do that, let's talk about TeamGantt. You've heard me talk about TeamGantt before. I really admire the way that they work and they're … Not just them as a tool that they provide, and it is an excellent tool, but, it's one of these companies that actually are committed to making project management a better discipline, to helping project managers …

Let's base it. Being a project manager sucks. Right? It's a really shitty job to do. Or, I think it is. I know some people absolutely love it, but I've got so much respect for people that manage projects. I think that they possibly, they're either the bravest people on the planet, or alternatively they're idiots. One or the other. It could go either way. What I really like is anybody who can help project managers I'm a star of, right? And TeamGantt do this because they've got all this kind of educational resources, as well.

But, you don't have to use their product to get at, right? Even if you're not going to use TeamGantt, make sure you go to their website and check out the stuff their doing, because if you do any kind of project management, they're just so helpful and they provide lots of free stuff.

For example, they've got a free online course called The Art and Science of Leading Projects that is absolutely brilliant. It's one of the most well produced, helpful resources for project managers and team leads that I've found on project management and I can't recommend it enough. It's 100% free, which instantly makes it good.

They also provide weekly webinars, which is superb. You should make it a podcast, because that's what all the cool kids do, but they do weekly webinars that cover all sorts of different leadership and project management topics. Again, if you do nothing else, check that out. You can register for the webinar or enroll in the Art and Science of Leading Projects by visiting Just to reiterate that, that's TeamGantt …

Nobody can spell Gantt, or I can't. I can't spell Gantt.

Marcus Lillington: I can spell Gantt.

Paul Boag: G-a … You can spell Gantt?

Marcus Lillington: Yeah, I can.

Paul Boag: Yeah, it's one of those words I always get stuck on. So, it's Team G-a-n double t dot com. That's what happens when you name it after a person. It's dumb. Don't do it. So, Or, as I told you last time, spam with any questions you've got about project management. He's guaranteed to answer every single one of them I would say within quarter of an hour I'd reckon.

He promises on this podcast to respond to every email that is sent to him within 15 minutes. That's how organized he is. See? Because he's project manager.

Marcus Lillington: I think 15 minutes is bloody generous, personally.

Paul Boag: Do you? Do you? Five minutes then.

Marcus Lillington: Yeah. Five.

Paul Boag: Right. Five. Test him and see. This is a call to action to every Boagworld listener. Send Brett and email to Please do it. Please. It will amuse me to no end if you do that. Send him rubbish emails. I don't care. Just email him. Right. There we go. He told me to encourage people to email him. So, there you go.

Marcus Lillington: There you go. Done.

Paul Boag: He didn't say anything about the quality of the emails. Anyway. Right. So, if you want to know more about prioritizing your work, actually, to be fair, is probably good a place as any to start. But, I did want to point you to my own blog posts. One is the one about prioritizing your website. Lewis has just come up with it. I like that.

Lewis is suggesting that Brett needs to better define his key performance indicators. Good lesson there. Yeah, if you want to know more about that hierarchy of use and needs, about a hierarchy of your website, then I wrote an article called, When it Comes to Your Website, Get Your Priorities Straight. If you Google on my site, priorities, you'll get it back.

In fact, that'll also give you the second post I wanted to talk about, which is the Digital Triage post. You could just Google digital triage and you'd get it, but you can also, the post title is How to End the Pain of Shifting Project Priorities. Those two together should do the job nicely and hopefully help you be a bit more organized in the way you prioritize the work that you do.

Marcus, have you got a joke as good, or as bad, depending on your point of view as last weeks, because that was a stunner.

Marcus Lillington: This is much better. I believe that was from Darryl Snow, I think. As is this one.

Paul Boag: Yeah, it was.

Marcus Lillington: So, did you hear about the Spanish magician?

Paul Boag: No, no.

Marcus Lillington: After saying uno and dos, he vanished without a trace.

Paul Boag: Oh. Right. Yeah. That took a while.

Marcus Lillington: Other people would've been laughing out loud, Paul.

Paul Boag: Sorry, I'm not.

Marcus Lillington: Your Spanish isn't up to it.

Paul Boag: No. That's, yes. Kat in the chat room still trying to work it out, so that's good.

Marcus Lillington: Oh come on, uno, dos, trace. I know it's supposed to be tres or whatever it is, but it's … if you have to explain it.

Paul Boag: Andrew wants to know what last week's joke was. Can you remember weeks one was?

Marcus Lillington: You'll have to listen to the podcast, Andrew.

Paul Boag: All I remember is … okay.

Marcus Lillington: I'm not saying it twice. It was that bad.

Paul Boag: Okay, so that wraps up this week's show. Thank you very much for listening. We're back again next week for the ultimate show of the season where we're going to be talking about the importance of having leadership skills. And, I feel that I am probably the most qualified person on the planet to talk about that with my excellent leadership skills. That will be an interesting show. Until then …

Marcus Lillington: Paul, no, no, no. I'm not letting that go. Paul and his enormous team of people that he leads.

Paul Boag: Yeah. Why do you think … Yeah, exactly. Why do you think I left Headscape, because just can't be asked with leading people. You are all incompetent fools. I just had to leave and strike out on my own.

Marcus Lillington: Is that so? Okay.

Paul Boag: The only way I can be sure of intelligent conversation.

Marcus Lillington: Right. Well, Lee said to me as I walked out of the office earlier to go to the meeting, he said, "Make sure you say hi to Paul, because I miss him."

Paul Boag: Aww.

Marcus Lillington: And I'm now going to repeat to him what he thinks … what you think of him.

Paul Boag: No, no, no, no. Don't. Because, I even liked him.

Marcus Lillington: How do you feel now?

Paul Boag: I feel very bad. And on that bombshell, we shall finish the show. Thank you very much for listening. And I'm really sorry. I'm inaudible 01:00:09.


Stock Photos from eamesBot/Shutterstock