Managing a design project often means managing people and their opinions. You need to lead those sometimes disparate opinions to a final decision and move on in order to keep your project on track. It can be tough, but UX expert Paul Boag has some helpful, proactive approaches to help your design projects run smoothly. In this wide-ranging conversation, Brett and Paul zero in on tactics to manage design projects, but they also discuss:
Paul Boag is a leader in digital strategy and user experience design. He has been working with diverse organisations such as The European Commission, PUMA and Doctors Without Borders for over 20 years. Through consultancy and training, he helps organisations make better use of digital technologies. He helps them meet the needs of today’s connected consumers.
Paul is also a well-respected figure in the digital sector. Author of five books including Digital Adaptation and User Experience Revolution. He also writes for industry publications including Smashing Magazine, Sitepoint and Net Magazine.
Brett Harned: Hey, thanks for listening to Time Limit. I hope you enjoy listening as much as I enjoy connecting with the experts on the show to find solid advice on how to manage people projects in any other thing that comes your way. This week I've brought my longtime industry friend and user experience expert Paul Boag to the show. He's here to talk about how project managers can better manage design processes. Paul's a top expert on UX and digital transformation, and has worked with a lot of high profile companies and even authored several books. He's currently offering a masterclass on digital project management, so naturally that's where our conversation started. In this conversation, he really opened my mind on the question, what is digital project management? Which is kind of funny because that's been the focus of mine for about 15 years with the digital PM summit and all of the other work and speaking that I've been doing. I experienced that kind of, why didn't I think of that moment in the conversation and maybe you will too. Check it out.
Brett Harned: Hey Paul, how are you doing?
Paul Boag: I am doing very well. It's lovely to speak to you again. It's been a while. Let's-
Brett Harned: Likewise. It has been such a while and I really appreciate you joining me on Time Limit. I don't know if you remember, but I don't know, probably five or so years ago we've actually recorded a conversation for TeamGantt and it lives on on YouTube so you might want to check that out sometime.
Paul Boag: Yeah. I bet. I hate going back and looking at old stuff because you know; A, things move incredibly fast, and I can just reach to whatever you said, you know, five years ago is totally irrelevant these days. And B, I just don't like to see myself on anything if I can possibly avoid it.
Brett Harned: Totally agree. Then why are we doing what we do?
Paul Boag: I don't know, I don't know.
Brett Harned: So, you kind of alluded to this. We've known each other for a while, and I'm not sure if you actually know this, but I started following you and attending your webinars back when I was kind of new to project management.
Paul Boag: Really?
Brett Harned: Yeah, and I remember specifically sitting in a conference room watching a webinar about client management, and I always enjoyed your perspective on digital PM. I'd probably go as far to say as you know, as a user experience design expert, you've been an advocate for digital PM and I, and I think that's really cool. And I'm curious why that is. Like is that just a part of who you are?
Paul Boag: I think it's because I considered myself a user experience designer in the broadest sense of that phrase. So, when I talk about designing user experiences, I'm not talking about just designing user interfaces. I come from a user interface design background, and I'm just sick of user experience designers, and developers are as bad. There's kind of traditionally, and I think it's loads better now, but they always used to be a bit of a sneering attitude about project managers. You know, that they didn't really understand, they didn't really get it. But when you look at it from a user experience point of view, digital project managers have got a far broader and more comprehensive and holistic understanding often than those people that are working on little parts of the project. So, from my perspective as a user experience specialist, if you can build up, win over, and empower project managers, and you can get them on board, then you're laughing. In some ways I would argue a digital project manager has almost more influence over the user experience than a user interface designer does.
Paul Boag: Which is a bit of a controversial thing to say, but there are so many things that make up the user experience that are way beyond the edge of the screens. From things like performance, to how customers are dealt with. There's just an endless amount of different things.
Brett Harned: Yeah. I would even go as far to say as the PM is creating a user experience for the project and managing that experience. Right? Like that's a kind of a theme I've been toying with for a conference talk. There is an experience designed to your project to make sure that it goes well for your team, for your clients, or stakeholders, and everyone else involved.
Paul Boag: I mean, I don't know whether you saw the Steve jobs film with Ashton, what's-his-name in. In that film there is this brilliant line where Wozniak has a go at Steve Jobs and says, "What is it that you do?" Right. He just didn't get it at all. You know, we've got all these different people that all do contribute stuff. What do you bring to the table? And he said, and Steve jobs replies, "You're an absolutely amazing musician, but I play the orchestra." For me, really, that's what a good digital project manager does is that he is the conductor. He or she is the person that is shaping the music.
Brett Harned: Mm-hmm (affirmative) I agree with that. So, I want to talk for a few minutes about your project management masterclass that you're running in October, I should say, digital project management masterclass. I find it really interesting, because in our past that you've kind of been really a self-professed non-project manager, right? So, now you're teaching PM class. But I think it's really valuable because I do think that ideas around how project management can, or should function should really work for everyone involved. And learning from someone with a design background, with tons of experience on projects can help to bring new helpful perspectives to that role. So I'm curious, what kinds of things will you be teaching in that class?
Paul Boag: You're entirely right, though. I don't describe myself as a project manager. And so yeah, I did feel massively hypocritical doing this. But what emerged for me is I worked with a large number of organizations, and I'm very much a generalist. And the thing that I was observing across organizations is that organizations were running digital projects as if they were just like any other project. And a lot of the project management methodologies I see, setting aside Agile, or Waterfall, or PRINCE2, or whatever you want it to. Well, there is a kind of fundamental belief within many organizations that you can just run a digital project like you would others, but there are fundamental differences in digital from other mediums. That's the kind of thing that I wanted to focus on in this course is look, it's go well, okay, so what makes digital really powerful and what makes digital really unique and how can we leverage that to create more efficient projects?
Paul Boag: So, the two big areas really is that digital gives you unprecedented access to data huge amounts of information that normally you would never get within running a traditional project. Feedback from users easily, quickly, as well as things like analytics and those kinds of things. So, there's so much potential that that provides. And then the other is that somewhat unique amongst many projects. The raw materials of a digital project are free, right? If you're building a factory, you've got concrete, and steel, and all of those kinds of things that are massively expensive. And once you've start down that process, you can't go halfway through and change your mind because you know, all of that investment in the materials will be wasted. It's the same like if you go to print with a printed magazine, and they go, "Oh no, no, we don't like that."
Paul Boag: You know, that's going to cost you a lot of money. In digital, I mean, yes, you still have labor costs, but other aspects, the actual raw materials are free.
Brett Harned: Right.
Paul Boag: So, that, I think fundamentally challenges the way that we go about running projects. And really that's what I want to get across in this masterclass. The, "Okay, so how does, how does that shake out? How does that then affect the way that we run projects?" There's going to be nothing in really, the course that may be people aren't already aware of. We're going to talk about things like discovery phases, prototypes, alphas, betas, proof of concepts, post launch services, and maintenance. So, all of those kinds of things, which are very normal thing, but within the context of, well, okay, how does that fit around what digital really is?
Brett Harned: I love it. You know, I've been talking about digital project management for I don't even know how many years at this point, and I've never thought of it conceptually in that way. Because I do get asked quite often what's the difference between project management and digital project management? And you just nailed it. I mean, there's data and free materials. Absolutely. That's it. So, one of the things that you mentioned about the overall process and something that you'll be teaching is about the project discovery phase. I think that there's so much, at least in the way that I've experienced project discovery, there's so much that can be done in a discovery phase that would help a project to go well. Whether the project's led by an experienced project manager, a designer, a strategist, no matter what. But I'm curious, just to start off, I want to talk a little bit about discovery, but how do you just define this? The discovery phase?
Paul Boag: Yeah, I mean, it's a really interesting one, the discovery phase. I think a lot of people are put off of it because they feel either their project is too small, or we don't have the budget for a discovery phase, or there is the attitude of we don't have the time for a discovery phase. But in my opinion, every project, even if I'm just doing a one page website, should have a discovery phase. It will just be a short one. You know, a discovery phase might be a two hour meeting or one hour meeting. It could be, but it could equally go on weeks. For me there were kind of five elements that I, I personally always try and include to a lesser or greater extent in a discovery phase. One is obviously the defining of your business goals, and not just the defining, but the prioritization of your business goals as well.
Paul Boag: I think a lot of organizations have conflicting objectives in the project that sometimes are mutually exclusive.
Brett Harned: Absolutely.
Paul Boag: And then the other thing, and then how are we going to measure those goals? How are we going to measure success? Like basic KPIs, I mean it's not rocket science, is it really. Then there's doing some degree of user research and then visualizing that user research in some way. So, identifying your audiences, prioritizing your audiences, getting to know them at least the little bit, and then having that in some form that you can keep in front of you throughout the project. Finally, you've got to look at the market and the competition and the kind of broader scope that the project sits within. So, those are essentially the five bits that I focus on. But I mean of course everybody's different and runs projects in different ways. There's no right way of doing it, is it really?
Brett Harned: Absolutely. Yeah. I think it's about setting goals, setting expectations for what you'll do and then turning off the course for that, that thing that you'll do. I'm curious who would conduct discovery work?
Paul Boag: Hmm. That's a really good question, isn't it? It's very easy on something like this for someone to come on to a podcast and go, "Oh yes, it should be this person," with authority. In truth, it will be different for almost every project depending on the context, depending on the surroundings. I mean, discovery phases are an area that I'm hugely involved in from a user experience point of view, and from the digital transformation work I do and all of those kinds of things. But equally, it could be a project manager, it could be the overall stakeholder, the owner of the project, the product owner, but equally everybody wants to be, should be involved in it to some extent. Especially when it comes to things like identifying metrics. So, different people would be involved at different parts. But I don't think there is a single answer. Do you think there is? [crosstalk]
Brett Harned: I agree. No, I was trying to stump you. Completely trying to stump you. I'm kidding. But so I think really, I think it's a full team exercise. I think if you have parts of a team not involved in discovery and they're just responsible for reading a report, or a set of goals, or something like that. And I think you're starting on the wrong foot, right? You're running the risk of people being disengaged with stake holders, and what they're looking to get out of the project. And I think that doesn't mean that an entire team sits down and does a series of stakeholder interviews spending hundreds of hours collectively. But I do think that there's value in involving the full team, and I think kind of what I'm getting to is how does the PM support the process or even lead the process? Because I know that I've been in discovery phases in a project where I'm completely leading it.
Brett Harned: I'm completely leading stakeholder interviews and there's something good about that because I know that I'm accountable and will act on information and share it with a team in a way that will keep everyone informed and hopefully on the right path. But I don't know that that's necessarily the right way to do it because I think as a PM I might be sitting on a call thinking, wow, this is not the right conversation for me to be having, which PM's have to be self aware about, right? I agree with you. I don't think that there is a right or wrong answer there, but I think the PM absolutely needs to be involved.
Paul Boag: Yeah. Yes, absolutely. And I would, as with almost all project related things, the PM is right in the middle of things, aren't they? That they're the heart of the storm. I think that the answer as well is somewhat dependent on the type of project. I mean, the trouble is, is you and me, we tend to work on quite big projects. You know, where there is reasonable budget, et cetera. But one part of my role is I'm mentorship. I do mentorship and I do mentorship for agency owners and even freelancers sometimes. I mean you've done this as well and in their kind of world they might be working on a simple WordPress site or something like that. And talking of a discovery phase has this grandiose feel to it. Where it's got to be so big and so impressive. And I don't think it does. I think a discovery phase can be short and snappy, or it can be long. It's got to be appropriate for the project you're working on, and the size and scope of the discovery phase to some degree will dictate who's involved in it as well.
Brett Harned: Mm-hmm (affirmative) I agree. And I completely agree. I've been on projects where yes, there's a discovery phase but it's a meeting, right? I think one of the most important pieces that PM's are typically responsible for is getting to know and understand stakeholders, right? Like understanding the org chart. And the hierarchy of the organization, how that's going to affect the project and the decision making process and really just kind of understanding the personalities as well as the politics. And I'm curious, are there any ways that you kind of recommend people kind of get into a project, let's say with a new set of stakeholders or clients and get to know them?
Paul Boag: For me, the key is meeting with people individually. It's really tempting to call a meeting because a meeting is a more efficient use of your personal time, but in truth, there are several drawbacks to that. First off, people hate meetings. Then there is the fact that people, you spend a lot of time sitting in the meeting, whether it's stuff that's not relevant to that. The most important bit really is that when you meet with people individually they will open up, and you will get a more comprehensive understanding of their approach, their way of viewing things, the challenges, and concerns that they have. Which you just don't get, come out in the same way necessarily in the meeting, or if it does come out tends to be more confrontational. I also think politically that that puts you as the project manager in a stronger position because you know the bits of the jigsaw, you know what everybody is feeling and thinking. While in a meeting, it's very easy to lose control, you know, because what happen is that, you know, there'll be some disagreement between a couple of people and then everybody starts reaching compromise.
Paul Boag: You try to compromise or find a way through, and you, as the project manager are'nt in control of the shape of that compromise, and how it's approached. So, it's almost like a bit of a divide and conquer approach I guess. But that seems a quite cynical way of putting it.
Brett Harned: No, I agree with you. I think one-on-one meetings, if you can do them are really good. Because they allow you to ask some pretty pointed questions about goals, and intentions, and intended outcomes, and even questions like how have you done projects like this in the past? How have they worked? And then, doing a meeting and getting all of those people into a room and seeing how those dissenting points of view come together and how you can manage through those things. Right? I don't know, I think personally, I think a discovery phase is completely invaluable to a project manager because there's so much that you can learn about how your project will succeed and potentially show you some of the risks or issues that could make you fail.
Paul Boag: Mmm (affirmative) You are right. And what you said by that you need that followup meeting as well. You can't just talk to people individually cause otherwise you don't get the group dynamics. And that is very useful. Also, it doesn't help build that project team if you don't bring people together. So, yeah, yeah, it's a complicated one, isn't it?
Brett Harned: Yeah, sure is.
Paul Boag: This is why I'm not project manager, it's far too much like hard work.
Brett Harned: So, I'm going to kind of fast forward a little bit in terms of process. What about when it comes to a stakeholder or client feedback, that thing where you kind of pour your heart into a deliverable, you present the work. And then in return, the client, they'll miss their deadline, or they'll give you a bunch of unhelpful feedback. I'm curious, how do you handle that?
Paul Boag: I manage feedback quite carefully. So, there are two aspects to it. I mean, obviously, most of my feedback is normally designed related and everybody's very opinionated on design. So, I lay the groundwork at the very beginning of the project by defining roles clearly, right? For example, I make it clear that it's the client's role to identify problems, and it's my role to find solutions. What that means in practice is, what a client will inevitably do, right? Is you present a design to them and they'll start going, "Oh, I don't like the green or can you move this?" Or those kinds of things.
Brett Harned: Exactly, yep.
Paul Boag: That kind of feedback. Yeah. Now those are solutions, right? Okay. So the solution is change the color. What you need to understand as a designer is you need to understand the underlying problem. So, it might be that they want to change the color because they feel that it won't resonate with their target audience. Absolutely fine. I need to know that, right? I need to know what the underlying issue is. So, that's why I defined the roll up front as; your job is to come back to me with problems, right? And I will then look at possible solutions. I'm happy to hear your solution. But if I don't understand the underlying problem, I can't make suggestions about how to solve it that might be different from you, right? So, that's one thing I do. The other thing I always do is when I present my deliverable, my design, in my case. Again, I try and meet with people individually before I show it to a group, right? Now, the reason that I do that is because you can then tailor how you present that whatever it is to the person you're speaking to, right?
Paul Boag: So for example, Jared Spool wrote a wonderful post that I refer to on a regular basis, which is, "Why I Can't Convince Your Executive of Anything and Neither Can You," right? And basically his argument was is you can't convince people of stuff that they don't care about or already belief to some extent, right? Bit of a cynical attitude. But I do understand where he's coming from. What you have to do instead is find out what they already care about, and frame what you want to convince them of within that context. If you're talking to a finance person, you talk about the cost savings of your approach, right? If you're talking to a marketing person, you talk about how it'll increas word of mouth recommendation. If you're talking to a sales person, you talk about how it'll increase conversion, et cetera, et cetera.
Paul Boag: Now if you meet with everybody in a group, and you collectively present to them, you can't do that, right? You can't tailor it for each individual person in the room. So, that's why really by the time you get into that room, you need to have met with everybody, and actually, it's just a rubber stamp exercise because everybody's already been convinced. So, that's another thing I do. The final thing I do is whenever you're presenting something, you know that certain people that you're presenting your deliverable to, will have problems with certain things, right? So the classic one with design is, "Oh, I know that the marketing person's going moan that the logo isn't big enough," right? I mean, it's a stereotype.
Brett Harned: You know that one's coming. Most times.
Paul Boag: You know it's coming. You know it's coming, but what you do instead is you go into that meeting and you go, don't mention the logo, don't mention the logo, don't mention the logo.
Paul Boag: Right? And the result of that is inevitably they mentioned the logo, right? And then you have to defend why you've used lots of white space and whatever else instead, right? But that's problematic for two reasons. One is, it sounds like you're bull**** because you're only responding to them, but more significantly than that is the fact that person has already put their stake in the ground. They said, "I don't like the logo, I want it to be bigger." So, it doesn't really matter how compelling you are at that point. They're going to lose face if they back down, and so they don't back down, right? Well, if you'd preempted that, if you brought it up as soon as you'd got in the room, and you said, "Well, it might be that some of you are worried that the logo isn't big enough," right? Then that gives that stake holder, and then you go on to explain why it's not as big as perhaps they'd hoped it would be. Then it gives the stake holder, that person, the opportunity to actually go, "They've got a point," without them losing face. Does that make sense?
Brett Harned: It absolutely makes sense. It's manipulative and genius.
Paul Boag: Well, I don't know. Yes, you can certainly say it's manipulative.
Brett Harned: I don't think it's really manipulative, I'm joking. I think that it's good preparation, right? It's knowing your audience, knowing who you're presenting to and understanding what the outcomes could be.
Paul Boag: Yeah, and it's actually, it's almost to be honest, is applying user experience principles to your colleagues and to stakeholders, which I do all the time. So, you're tailoring your message, which you should be doing when you're talking to end users to meet their specific needs. You're also making it as easy and straightforward for that person to do what you want them to do. So, you're not going to put up barriers. For example, making them call you out in the meeting and then you making them look stupid because you'd already thought of it and addressed it. You know what I mean?
Brett Harned: Right.
Paul Boag: This is the thing that I am always get so annoyed at user experience professionals over, my colleagues, is they don't apply the same principles that they've learned about user management to their own stakeholders. And that just does my head in.
Brett Harned: It's really interesting. Yeah, it's true. A lot of times people get so focused on the deliverable and getting what they want, right? Like you spent all of this time researching and creating a thing and then someone comes in and gives feedback that you don't agree with. That your first instinct is just to say no and push back, but yeah, yeah. You've got to listen to those stakeholders, and I love the approach that you take in. Don't just tell me you want to change. Tell me why you want that to be changed. Tell me what the problem is so that I can understand it and possibly come up with a different solution that could work even better.
Paul Boag: Yeah. I don't close people down. I don't say to them, "Don't tell me your solution," because they might have a good idea. That is another thing that I think is really important is to make people's opinions feel valued and listened to. It's common courtesy, isn't it really?
Brett Harned: Yeah, I think so. But I think unfortunately a lot of people forget that. Right? Things get intense on projects sometimes, at least on projects I've been on, and everyone has the best intentions and wants things to go well, but sometimes communications break down. So, having the kind of framework that you just presented, I think absolutely makes sense. So, I want to wrap up, unfortunately. We're at about a half an hour already. I can't believe it.
Paul Boag: Crikey.
Brett Harned: As you know, the show is called Time Limit. Kind of giving a nod to the fact that everyone in business is doing everything they can to get a lot of work done with limited time and even limited resources. A lot of teams are even without project managers, which makes for even more work for those people. I'm wondering what are your tips for keeping projects moving when you've got just a little bit of time to focus on project management?
Paul Boag: Hmm. To be honest, it goes back to what we were talking about right at the very beginning about the unique nature of digital, right? And the fact that the raw materials are free, right? I think sometimes the biggest barrier in projects, the biggest delay in projects is people wringing their hands and procrastinating over whether this is the right way to go, right? The amount of time that's wasted debating over a particular approach or design, iterating design endlessly to get it just perfect before we sign it off, right? But if you accept that that digital is easy to change, and then actually don't really know until you put it in front of real users, and you get real data back. Then actually, that provides a huge freedom, right? It means suddenly that you don't need to be agonizing over everything. You can just keep moving. Okay. Perhaps it isn't exactly the right shade of blue. It doesn't matter. We'll sort that post-launch, right? Actually, I think in a lot of situations, the problem with projects is people's willingness to make decisions. But if you make those decisions not set in stone, that they can never be changed, that is such a big thing. I'm working with a client at the moment who is agonizing over their copy for their website and it's taking them forever to deliver copy.
Paul Boag: And I'm going, "Why are you worrying about this? As long as what you produce is better than what you've currently got online, let's get it live."
Brett Harned: Right.
Paul Boag: You can change it after, you know?
Brett Harned: Right. Yeah. I think it's a daunting thing when you're someone who hasn't been through a website redesign project, or an app design project, you want to nail it the first time. I think sometimes those people, if they're not really experienced, they don't realize that it's really simple and easy to make change. In fact, you should make changes and updates as you proceed through time, through events, whatever it might be. So I, I get why people are like that, but at the same time, I agree with you. I love the idea of always testing and leaning on those test results. Leaning on the data and the free materials that you have working on a digital project because that's what makes that project unique, and that's what makes it ever changing, and evergreen.
Paul Boag: This annoys me, "Oh, but we don't have time for testing."
Brett Harned: Oh my gosh.
Paul Boag: But seriously, you can do testing quicker than it will take you to have a meeting where you argue about it for three hours.
Brett Harned: Absolutely. You can do it overnight. You know, you can hire a service and have those tests results the next morning.
Paul Boag: Exactly.
Brett Harned: I think some folks don't realize that.
Paul Boag: No, I don't think they do, and I think that is a really big thing to get across. Don't debate, test. You'll get answers quicker and obviously they're better answers as well.
Brett Harned: And you're saving yourself time, right? Because you don't have to do that testing. You can offload it to someone else who can recruit, do the testing and give you the results really quickly.
Paul Boag: And before everybody goes, "Oh yeah, but that's expensive." It's really not.
Brett Harned: No, it's not. Yeah.
Paul Boag: You're talking about a few dollars for each person that you're, you're testing with, and you don't need to test with a huge number. Even testing with two or three is better than you making a guess internally.
Brett Harned: Right. Yeah. And I think not showing things to customers opens you up to a lot more problems, right? If you're not showing something to users, and then you launch it, and it gets really bad feedback, then it's on you for not doing it to begin with right? It can ruin the perception of a product, or even a launch because of not testing, and not validating ideas. So, that's really good advice. Thank you for that. And thank you so much for joining me on Time Limit today. It's been really awesome catching up with you, and thanks for the new perspective on digital PM as well. I'm really into that idea and I appreciate that perspective and I'm going to think on that a little bit more, but the data and free materials is a really interesting way to look at it.
Brett Harned: So, thanks again, Paul, for joining me. I really do appreciate it.
Paul Boag: Absolute pleasure. Thank you for having me.
Brett Harned: All right folks, that's all for this episode. Check out our show page for more information about Paul Boag, including his own podcast Boag World, which TeamGantt is actually sponsoring. And please do us a favor and rate our show where you get your podcasts. If you have any recommendations for speakers or topics, please reach out. We'd love to hear from you at firstname.lastname@example.org. Join us for our next episode, which will be all about personality tests and how you can use them to help your teams work better together.