Episode 5 — We Are Laser-Focused
The role of a project manager is far more strategic than it’s perceived to be. In fact, a lot goes on behind the scenes to orchestrate the best possible project experience, and often stakeholders — and sometimes teams — don’t realize it.
As project leads, we expect change on projects because we understand that business goals evolve and change. Processes fail. Stakeholders come and go, and new ideas arise. When asked to change, we use project goals as a basis for discussion on whether or not the change is acceptable. We wade through comments and feedback and analyze and discuss change to help guide our teams and clients to the best decisions given our focus on project goals.
In this episode of Sprints & Milestones, Brett and Greg talk about how project managers stay laser focused when projects are being pushed and pulled in many different directions, sometimes by many people. Here are a few of the themes discussed:
- Creating a project environment that is conducive to alignment with clients and a team
- Finding a moment to pivot on a project to make a positive change
- Setting expectations to get what you need out of projects and making agreements to do things successfully
- The value of setting work agreements and running retrospectives to keep those agreements true
Links Mentioned in This Episode
Transcript: Episode 5
Announcer: Welcome to Sprint and Milestones, a podcast where Brett Harned and Greg Storey share war stories, tips, tactics, and anecdotes on navigating the sometimes rough waters of getting digital projects done. If you're leading projects and want some help and reassurance that you're doing the right things, you've downloaded the right podcast. Enjoy the show.
Brett Harned: Welcome back to Sprints and Milestones. As you recall in the last episode we talked about teaching and learning. A topic that's important to both Greg and I. I think we both agree that continuous learning is important in our industry no matter what kind of role you have. And we also kind of agree that teaching is inspiring and you learn while you teach, which is awesome. This week we want to talk about how PM's have to be laser focused. The excerpt from the principles in the book is called, "We Are Laser Focused," and here's what I wrote. We expect change on projects because we understand that business goals evolve and change. Processes fail. Stakeholders come and go, and new ideas arise. When asked to change, we use project goals as a basis for discussion on whether or not the change is acceptable. We wade through comments and feedback and analyze and discuss change to help guide our teams and clients to the best decisions given our focus on project goals.
So I personally think this is a strength that many people perceive project managers as lacking. I think a lot of people unfortunately see PM's as box checkers, or just people who want the job done no matter what. And I see it as far more strategic. You have to anything and everything as a PM that you can to align the team and clients around goals so that everyone makes good decisions. And I think included in that is setting expectations early and managing to them. Sitting back and listening and understanding people's motivations toward those goals. And, at the same time, fully understanding those goals so that you understand kind of what they encompass and how people might be approaching them.
Greg Storey: Well, and if I can add too, the strategy part is key because PM's have to play ... you almost have to be a chess player, right? And kind of read the project and all the players and see what's gonna happen a couple moves ahead. You know to kind of be ready for contingencies and things like that.
Brett: Yeah, absolutely. I think Greg, your perspective here is really interesting. You know as a person who's producing work. Which, you know, PM's often have to put their selves in other people's shoes, right? Because we're not the ones who are sitting down and pouring eight hours a day into creating a deliverable that somebody could just poo poo immediately. Right?
Brett: I have to guess that's really difficult when it's working with clients. So I'm wondering your take on this. Like how do you create an environment that's conducive to alignment with clients and your team? Particularly when people can be tricky or defensive?
Greg: Oh man, I think once you've been in the industry long enough and once you've worked on a couple projects, I think everyone is sensitive to that a pivot of some kind is gonna happen. It's just a matter of when, and what the severity is. You know? And so I feel like teams are always on the lookout of every time they go to deliver something; is this it? Is this the time that this project is just gonna fall apart? Or, are relationships gonna fall apart? And you know as you go along and trust has been built up, I think that those fears start to subside. But, if you've been around long enough there's always just that little feeling inside that says whatever ... this week is gonna be it. Or, this design review or this deployment. Whatever part of the project that you're in, there's just always something nagging in your head that says, "Project's just gonna go to hell right now."
Brett: Right. Well, here's a question for you: is the pivot always a negative thing?
Greg: You know it doesn't have to be. I think the pivots are typically negative because of how they're handled, right? So how they're perceived and how they're handled. So like for instance, we had a significant project that required a tremendous amount of work. Things were going pretty well in our discovery process and when we went to go do some UX work based off our research. And once we got into the actual like visual component of that work, the train just went off the rails. And it kept going off the rails. You know we would put work up and get on the phone and wait for the client to join us and talk about it. And those first conversations were just ... it was painful.
And it took me a bit longer than I'd like to admit to realize that the client who was insanely intelligent and had built an amazing business by himself, I admire this guy even today. And what he's accomplished. But he doesn't know how to talk about design. And he had the personality that didn't allow him to come forward and say, "I don't know how to do this." You know? He was just that kind of alpha personality. He wasn't a jerk, at all. But he would go into hiding. You know we would go to deliver design and then he didn't join us. And then I spent the next week trying to track him down. And this was happening a couple times, and so I had a heart to heart with him as the guy kind of overseeing that work, and realized he just didn't have the vocabulary. And not only did he not have the vocabulary, he knew that he had a tendency to say things the wrong way and he was really sensitive to not wanting to hurt the designers feelings.
Greg: Yeah, very interesting. And so what we arranged to do is to meet in person and we cleared an entire day. And we, the designers, did what we could to relate to what he was trying to say. And that meant that we had some designs of other things in the room that he could point to as examples of what he thought was good or that he could ... it was kind of a relational conversation to other designs. Not just the one that enabled us to kind of get through ... I'd say it was probably like a two hour conversation, but it took more like four to five hours to get through that.
Greg: But that was fine, you know? And so that was ... you know I'd say it was a slight pivot, in just that we were not getting anywhere? You know we were having disastrous design reviews. And then once we actually were able to connect with him and [inaudible 00:07:49] that common language around design, enough that we knew okay, we gotta change how we've been designing things. So, it was a little bit more extra effort on our part, but from then on the project was pretty smooth sailing.
Brett: Yeah. I think what you're getting at is so important, and it's something that I remind people all the time. Like our job as project managers and designers is to educate people, right? If you go into one of those meetings and don't kind of explain to people what you're about to present, why you'll present it, how you've gotten to that point and how their feedback can help the process and focus them in on how to provide feedback, you're doing yourself and the project a disservice. And those people at the same time.
I've been in really awesome design presentations where the designers have come to the table and before showing anything, very clearly presented, or really re-presented the goals of the project in advance. So that we could kind of like re-focus people in the room to let them know like, "Hey, this is how we got to this point. Before you start looking at designs and complaining about colors and placement of things, remember the goals and what the users of the site want." Right?
Greg: Mm-hmm (affirmative).
Brett: And I feel like that just does such a good job of setting the expectation for what you're about to see and how we want you to provide feedback. The other thing that I've seen done really well, particularly with groups of ... I'm thinking of a meeting that I had with a university where we were in an auditorium. And there were at least 40 stakeholders in a room. That's kind of scary, right?
Brett: Because feedback's gonna be all over the place with that many people. And the way that it was managed was so good in that there was a review, like a very thorough review, of all of the work. And it was multiple design concepts, once over, and then a second time over. And then a slide that had very specific questions to guide people to the right type of feedback. You know about is this meeting specific goals. Is it aligned well enough with the brand? It was so great in that it just focused the room. And the feedback that we got was so much better than I expected from such a large group that it just became a practice with every following presentation.
So I think that's all to say like going in on the defensive is probably a good thing to do, right?
Greg: Absolutely. And that kind of goes back to your laser focus, right? Laser focus is not just on the project manager but it's also to keep people focused on what it is that they are doing at that time.
Greg: You know stakeholders, project sponsors, basically anybody that is not doing the work has a lot going on. I've been in design reviews where everybody was on a laptop and just trying to respond to fires all over the company. And you know it took ... we learned a lot of lessons on that project. Just because our partners were not focused, therefore we were not getting the feedback that we needed. Inevitably we suffered from some delays. We had communication issues. Obviously if people are on their laptops in an end person design review, and all that led to eroding trust. Which meant that that project did not end on the greatest note.
Brett: Yeah, definitely. I think to me that's all about setting the right expectations for how you operate on a project. Something that I tend to talk about a lot is when you're starting a project, whether it be with a new team or people you've worked with in the past, it's important to just sit down and have a conversation that covers generally like this is the scope that we're gonna be working on, this is the type of project we're doing, these are the types of deliverables we're gonna be creating together. Let's talk about how we communicate. And part of that is kind of what you were talking about; like people being on laptops in meetings. I've been in situations where I'm the jerk that makes the rule we're in meetings with no devices. Because I want everyone focused on the work in the meeting so that we're more productive. And just like getting that kind of detail on the table and out of the way early sets a good expectation in a working relationship for everyone.
I think, at the same time, it's important when you kick off a project as a project manager, and you're working with a client or an internal stakeholder, to sit down with that person and basically have the same conversation. But it's in a different light. It's not about setting rules for meetings, it's about this is our engagement. This is what partnership means to me. This is the scope of work. I mean, how many times have you been in a situation where you get into a scope of work with a new client and it turns out they didn't actually review the contract, somebody in legal did. And you made several changes and it's not exactly what they wanted, and then there's scope problems. So just sitting down and saying line by line these are the things you can expect to get from us. These are the goals from the project, are we aligned? Are we gonna be communicating with you in a way that will work for you? These are the things that are basic, basic expectation setting and it's not expectation in a scary way. Because I think some people do see that as like well by setting an expectation I'm telling you how you're gonna do a thing.
Brett: No, it's not that right? It's more of an agreement. Like let's talk about the best way we can get this thing done together. And documenting that and just generally checking in and managing those expectations through the course of a project just tends to make things go a little bit easier.
Greg: You know I've been to kickoff meetings where we did those types of activities. Many of them with you. And usually on kickoff day, it's a bit like the first day of high school. People are generally there on time or a little early. There's a little bit of this weird, "Hey, we're gonna be working with some new folks," and you know there's some curiosity in who's here and who are you? Where do you come from?
And you know I feel like when we go through those things like here are the conditions that we need to succeed. And you know talking through all that and there's a lot oof heads nodding and whatnot, and then you go away and right? Your [inaudible 00:14:23] would always be like we're in the van going back to the airport, and it's kind of like how do you think that went? You know? And inevitably, it went well. You know usually kickoffs go well, and those conversations about ... you know you kind of set the stage by saying, "Let's have a difficult discussion here." And talk about meeting protocol and that type of thing.
But like how many times in the middle of the project does all that just go away, right? And all of a sudden half the projects on fire, you can't get people on the phone. You know you're getting weird emails from the clients. Cats and dogs. All the things going wrong. So I'm just kind of curious on projects that we haven't worked on together, how have you managed to keep that intact? You know to keep everyone focused on the work ahead? And to keep everyone at least corralled in whatever work agreements you may have had? How do you get them to stay?
Brett: Yeah, I mean it's not easy, right? And these problems, what you're explaining, they happen on practically every project, right? For me, it's a matter of managing the expectations and having kind of a setup in the project where you have explicit points to check in and make it obvious that you're aware of things that are happening. So doing a weekly status report forces your hand at documenting everything that's happening on a project, and things that could be going wrong on a project. And having a conversation about it.
Because the quicker you can identify an issue, or even a risk, the earlier you'll be able to just solve it and squash it and move on. So I think it's very much about having a really strong communication plan in place where you're creating routines to check in with your team, check in with your clients, and be open and transparent about any things that you're seeing as being potential problems.
Greg: So on that whole thing of things that you're seeing that are potential problems, are there any that kind of stand out to you?
Brett: It's always people related. I mean, I think you know that when you've talked about stakeholders. There's always somebody who's not gonna show up to a meeting. And then they're gonna come back late with feedback that's gonna just derail the process and extend the scope. So doing a little bit of that pre-work prior to jumping in, even to a kickoff meeting where a PM can get on the phone with maybe the client PM to just talk through who are your stakeholders. You know what are their roles in the project? When can we expect to have them involved. Like breaking out. Learning as much as you can about the people on your project as well as the goals and their motivations can be really helpful.
One of the ways that I've done that in the past is through a quick call with a client PM. But also being a part of stakeholder interviews and contributing questions that get at what project success looks like, what they're experience has been on similar types of projects. You know, digging into what potential challenges they see coming up. All of that really contributes to your point of view on how you can manage a project because it's so much about the people. Especially when you're working in an environment when everything is so dependent on what a client approves or disapproves. You know the more you can know about the people and their motivations and how they might react will help you to guide the team to tailor almost an experience, like a project especially that is dedicated solely on helping them to make the right decisions. And helping you to present in a way that's gonna work and please them.
Greg: Right. So, you and I, we've talked about managing expectations in the past. We've had many conversations about that when we were working together.
Brett: Mm-hmm (affirmative).
Greg: One of the things that I've seen folks start to do is create work agreements. Trying to set that environment, and to have let's say 10 tenets of how they agree to work with one another, how they're gonna collaborate. It kind of sets the conditions for engagement, right?
Brett: Mm-hmm (affirmative).
Greg: And I'd employed that at IBM in some of the small projects that I would do with new designers. And that seemed to work pretty well. It was something that we could kind of point to. But again, it was kind of one of those things we would create in the beginning and not necessarily circle back in like a mid-point. Or even towards the end of the project just to make sure are these still the same rules that we want to use to work collectively as a team? You know? So not just designers and developers and project managers; but also stakeholders. I'm kind of curious about your experience around the similar document or set of rules.
Brett: So, I think of the pivot as something that happens more organically. Not necessarily something that's always documented. But, one of things that I've encouraged project managers to do is warn a client at the beginning of the project. Like, hey, we're gonna do this for our process. And we might hit a point where maybe things are not working as well as we think. And that might inspire us to make a change in the way that we work together or the process that we're using for the project. And just being transparent about that and showing that your goal is to meet the project goals, but also to make the project experience easier for everyone, can make such a huge difference. Because then they know that your intentions are always about getting the project done and getting the project done successfully. Like not just getting it done, but succeeding.
So I've been in situations where we do a kind of mini-retrospective meeting in the middle of the project because somebody sensed that something just wasn't working right. Or, there was a comment that somebody made and let's sit down and talk about this. Like what are the things that are working? What are the things that are not working? And how can we use that information to create a better path forward? So I'm a big fan of doing those kind of in-progress post mortem or retrospective meetings. And also doing a big one at the end. You know it all comes back to learning, right? You know the more that you can reflect on your experiences that you're having in the moment, or even within the past couple of weeks, figure out how you can tweak those behaviors to move on a better path forward; I think the better everyone will be.
Greg: Yep. I've not done that myself, but I could see where that would be very useful.
Brett: Yeah, absolutely. And it doesn't have to take a ton of time, right? Like the expectation should be hey, we can get in a room for 30 minutes and talk through this and then come up with some decisions to start rolling out. But, you know more importantly, it's about communicating those decisions to people who are not in the room. Whether that be clients or other team members; solid communications is always something that you've gotta kind of fall back on.
Greg: Solid communications helps you be laser focused.
Brett: That is so true. So, I think there's a lot more that we could talk about when it comes to getting to know your projects and setting and managing expectations. But those are both topics in the book. So chapter four is "Getting to Know Your Projects," where I talk a lot about research and stakeholder interviews. Getting to know the players on the team and on the client team, and how that all can help you to essentially suss out what the red flags are gonna be, what the issues are gonna be. And chapter nine is all about setting and managing expectations. And there are tons of tips and tactics in there to check out. So check those out, and we'll see you on the next episode where we're gonna talk about how project managers should always be honest.
Announcer: You've sprinted to the end of this episode. Milestone complete. Thank you for listening. If you're looking for more resources on digital project management, check out Project Management for Humans, by Brett Harned, which is available on amazon.com or through Rosenfeld Media. And of course, don't forget to subscribe on iTunes. And check out our show notes and more at sprintsandmilestones.com.