Audio Transcription:
Ben Aston: Thanks for tuning in. I’m Ben Aston, and this is the Digital Project Manager podcast.
We’re always being told all the things that we should be doing, and I’m one of those people who does that. There’s this pressure to improve yourself, to do things right, and actually the pressure to be seen to be doing the right things is pretty immense, but should we be doing all these things all the time? Keep listening to this episode to find out how you can save yourself a bucket load of time by cutting out or reducing some of the things from your PM routine that you might not need for every project.
We’re gonna talk about how you can get some of your life back, spend less time in the office or at your desk, by cutting out six things that you could save time doing. And this podcast is really about throwing off those shackles of should and some of the musts, and being a bit more efficient about the way that we do things.
Today, I’m joined by Patrice Embry who’s actually – and I have to laud her for this – probably the most active participant in our Slack team, and if you haven’t joined yet, you could be talking to Patrice right now. If you go on to the community section of the Digital Project Manager you can sign up there. Patrice is nearly always there and always chatting, so she’s a good person to know.
As a brief introduction, Patrice is a freelance digital PM. She’s a certified scrum master two. She’s been working in the industry for a very long time working all different kinds of agencies and corporations. Check out some of our other podcast to get more of an understanding of the kind of stuff that she’s done. She’s worked on everything so she’s a great person to know.
So welcome Patrice.
Patrice Embry: Hello. Thank you for having me.
Ben Aston: Your very welcome. So Patrice can you tell us since we last spoke is there any interesting projects that your working on right now?
Patrice Embry: Well I just wrapped up an app that I was working on that helps people who are looking for short term really quick hitting jobs. Kind of like a Care.com but even faster with people who really need those short term jobs done. It was a really interesting app. It hasn’t been … its in beta now so its not completely out there ready for the world to see but it was a really interesting project because I was working with people from around the world.
I’ve never worked with anyone from Nigeria before so this is my first time saying hello in Igbo so that was a lot of fun.
Ben Aston: That’s sounds like a scam project. I mean not the thing. That’s obviously classic Nigerian scams. So was the development team was out there?
Patrice Embry: I’m sorry?
Ben Aston: Was it the development team was out there in Nigeria?
Patrice Embry: Yes.
Ben Aston: Oh, really?
Patrice Embry: Yes. The front end designer was in … the front end developer was in Nigeria. The back end developer was in Mexico, and our technical lead was in Sweden. Then there was me outside of Philadelphia and the client which was in Boston. We were all over the place.
Ben Aston: That is a lot of time zones to work with.
Patrice Embry: Yeah it is.
Ben Aston: That must have been not fun. How did you make that work?
Patrice Embry: Well I found a time that everyone could sorta live with and it was 8:00 AM Eastern time so our European friends were a little … it was a little late in the day for them, it was pretty late for our Nigerian friend, and Mexico had to wake up a little earlier than he wanted to but we made it work.
Ben Aston: Cool. So is like a start up the apps for or is it for …
Patrice Embry: Yeah. Its a … I think it was a service that was born out of a woman who was kinda you know did this for a couple of people and a couple of other people were like, “Hey, can you do that for me?” And it kinda went on and on until she was like, “You know what, I can’t handle doing this … just coordinating this by myself anymore.” And I think she was like, “lets make an app for it.” It’s in its really early infancy so I don’t want to throw too much out there about it but when it does go I’ll make sure to tell everyone about it. I think it’ll be a really cool service for people.
Ben Aston: Cool. Sounds like an interesting project. What were the kind of big challenges with it that you encountered? Was it straightforward or did you hit some rocky spots along the way?
Patrice Embry: It was a little rocky in that … the client really wasn’t someone who was very savvy with the computer. Wasn’t super savvy with apps. Had your normal level of knowing how things work. As you know in the tech field you tend to have a little bit of a more understanding of how things work so it was a lot of sorta explaining.
It would be like kinda explaining to your friend who doesn’t really work on the computer every day like how somethings work. So there was a little bit of that. Its not until sometimes you get really involved in a project like this before you realize the things that no one ever thought of. The testing, which is why its in Beta now, the testing was really intense because we kept saying like, “Oh you know, this is a path we never went down before.” That made it challenging but it was a lot of fun. It was fun working with everyone and its a really neat idea. I’m pretty happy with it.
Ben Aston: What tools did you use to manage all these different people in different time zones? How where you pulling through different requirements from the initial brief that seems like it was a little bit loose and then kinda manage the project?
Patrice Embry: Yeah, it was really loose. There wasn’t a whole lot of extra money to spare which will tie in nicely with what we’re talking about today. I didn’t’ have a ton of hours that I could spend doing a lot of things. I had to be really picky with what I was doing and what I wasn’t doing because I didn’t want to blow the budget on my hours. I wanted to save as many hours as possible for the actual development.
We used Slack because it was free. We used Chelo because it was free. We used a lot of Google docs because they are free. We needed to figure out how to make all of those work for us with none of the paid features because we needed to be as lean as possible to really get this moving for this woman and this project.
Ben Aston: So how did you find this project? Was this just like a friend of a friend reference because it sounds like they start up … yeah, it sounds.
Patrice Embry: Yeah. You know me. You mentioned that I’m on Slack all the time and your Slack is not the only Slack I’m on all the time. I’m constantly looking, you know as a freelancer you have to keep making sure your lines of communication are open with everyone so that you can get as much information in as possible. I talk to a lot of people about a lot of things.
I can’t even remember off the top of my head the long string of events that brought me to that project but it was a lot of like, “Oh hey, I think I know a person that I might of heard from this other place. Does anyone know if anyone does this?” It was probably a lot of that but yeah I do a lot of networking so things come to me in really strange ways.
Ben Aston: So did you pull together the project team.
Patrice Embry: I did not.
Ben Aston: Was that something that you did?
Patrice Embry: No. I didn’t. I was kinda put into a pool of people and we just kinda figured out what everybody was going to do. I didn’t have to find the resources for that one. I was really happy with the team I was put on and I’m going to be communicating with them in the future and hopefully we’ll all get to work on a project again because I really did appreciate what everybody brought to the table.
Ben Aston: Yeah that’s cool. I think its always interesting working on these kind of projects where sometimes the client might not be as savvy but it also often means that there’s a lot of flexibility as well which is an awesome thing having a client who trusts you, doesn’t really know what their doing but like, “Sure. You guys are the experts just tell me what we should be doing.” And its like, “Ah. This is the best time.” Yeah. You can do a lot of the right things.
The downsize is you get that pain of, “Okay. Try pressing control F5.”
Patrice Embry: There was a lot of that yes. There was a lot of that but you know what its good to remember especially when your making an app for the general masses not everybody is coming from the same level of knowing how to do things. It actually was good in a way that we had to go back to basics because we had to remember we had to go back to basics with the actual app to. We couldn’t just take for granted that people understood that you know if you used your finger to scroll you know you’d be able to see the rest of the form.
We needed to make it clear that you needed to scroll. It actually worked out well for this project.
Ben Aston: Yeah. Good stuff. Lets talk about, you mentioned it, I was talking about it earlier. We were chatting on Slack about the truth about how we actually manage projects and there’s I think on one side there’s the theory and like I said on the Digital Project Manager we publish those articles on how we should run projects or the right way to, you know best practice that we can implement on our projects.
I thought it would be interesting for us to talk about the actual truth or the reality of how we manage projects in the day to day when there’s so many things to do, especially if you do things like particularly if you’ve got some proper project management training like a PMP, and you know the PIMBOC, and all of the kinda processes, and the work pro that you should be adopting, and you’ve got all these different registers and status reports and it becomes one big administrative nightmare.
I think the truth is that we are always over loaded and there’s always that kinda documentation that you could be updating or that you could be … things that you could be doing but yeah I thought it was interesting to talk about are we doing things because they’re the right things to be doing or are we spending too much effort on the wrong things? We kinda talked about just a second ago this idea of start, stop, continue. What should we start doing? What should we be stopping doing or reducing during? What can we continue doing?
I’d be interested to hear your kinda perspective on like starting on the high level of what the non negotiables are. What are the kinda when you first arrive on a project, maybe even like the one that you were just talking about, what are the kind of things where your like, “Okay. At a very minimum I have to make sure these things are sorted otherwise this projects just gonna grind to a halt or go off the rails before we’ve even started.
Patrice Embry: For me its always timeline and requirements. Then bringing up the rear is budget. Budget is important in different ways to different projects but timeline I don’t think you can ever get a way from having a timeline, a fairly detailed timeline. You really can’t get away from requirements because otherwise you have no idea what your doing and your team won’t have any idea of what their doing. Those are the two things that absolutely must have. In my opinion those are the non negotiables.
Ben Aston: I’m sorry, just to be clear though, so when you’re talking about requirements are you talking … you’re not talking about a statement of work your talking about what format are those requirements in then?
Patrice Embry: Well you know, that’s a good point because they don’t necessarily have to be in a document but knowing what the scope is and what even beyond the scope. One step beyond scope into what does this thing have to do. If I look at a statement of work it does usually take somethings for granted. Not everything is outlined in the statement of work and there’s going to be another layer of things that have to be done or talked about, or considered, and features that need to happen for the scope to be realized. Those are the things that I’m talking about.
They have to be defined. People need to know what they are. It’s going to drive what people do. Otherwise you really have no idea what you’re building. Those are the types of requirements I’m talking about.
Ben Aston: Yeah. I think that’s so true. For me its estimate, timeline statements to work when I’m first kinda landed on a project and your kinda level setting. Those are the types of documentation I’m trying to find because … well if you don’t know the timeline, if you don’t know the requirements, there’s no way that you can manage and control the project. If you don’t know how its supposed to be you don’t know what your on track.
Patrice Embry: How will we know if its done? How will we know if it didn’t stop? Yes. Exactly.
Ben Aston: Typically though the things that … when you inherit a project is one of the things that you tend to find is kinda always slightly out of date by the time that you receive it. Particularly around the requirements or the statement of work. Its like, “Oh yeah. Well we chatted about that and we agreed to do something different.” Or something like that.
Level setting on that. How do you, if those are the kinda non negotiables, how do you kinda maintain those throughout the project to make sure everyone’s on the same page with them?
Patrice Embry: Well I remind people of the timeline each week or each time we get together to talk about the project. Maybe it will be more than once a week. Maybe it will be every two weeks. It really depends on the project but I will always remind people where we are in the timeline. What is our next deadline, and usually what the deadline is after that so we know what we’re working towards.
Remind them of what the end date is, what we’re driving towards. Not necessarily the launch date but usually this is when we have to be in QA or this in when we have to be in UAT. I’ll remind everyone about that and if that changes I will always let people know. If we are in danger of missing something that’s when people will hear from me the most.
As far as requirements, I do try to keep those updated as much as possible. Its nice when they’re back on a Combon system like Trelo or something where you can, or even Gero, where you can continue to talk about what something should be and you can see how things evolve and what is the latest thing that we said we would do for this feature and all that can be composed in one area and searchable. You can figure that out.
Keeping those up to date if that’s how you’re working. If you’re not using those types of things then its keeping some sort of documentation up to date with things that you’ve decided with the client, things that you’ve decided to save time, or things that you know you need to add on later one. Its a constant you know updating of the documentation you have. What ever state that’s in.
Ben Aston: Yeah. Definitely. I think for me often I’m writing a statement of work and then I’m issuing change request or I’m issuing updates to the statement of work, which is typically like a word document every time there’s a pivot on the project. Just so that there’s, Ive got a client signature on, “Hey, yes. I know. I understand that we’re making this change and I’m approving it.
That whole … yeah, the paper trail of keeping track of, especially if you’ve got multiple clients or there’s some confusion over who’s really in charge of the project, having some record of that I think can be really important.
Patrice Embry: Absolutely.
Ben Aston: Lets go on then to talk about some of the things. If those are the kind of non negotiables our statement of work, or our requirements, our timeline, our estimate let’s talk about some of the things that we were talking about. Actually maybe we don’t have to go to town on, or we don’t have to over engineer.
One of the things you talk about in the article is detailed budget and project breakdowns. Do you want to talk a bit about …
Patrice Embry: Yeah. My background where I started there was a lot of like, “This is exactly how everything works.” And I was a cog in a very large wheel with lots of other project managers doing lots of things. There were many of us and we all needed to do everything the same way. There was a lot of, “This is how things are done.”
It wasn’t until I started working for smaller agencies and then going freelance where I was like, “Well you know, you can’t always do all of those things because its going to be really tough to keep your budget intact if you do and you might not have the time.” When I was at that larger agency and we were doing all the things that you must do, one of them was a really detailed budget. It was old school. I still do my budgets pretty old school. I put them in a spreadsheet and I would have pivot tables, and I would have conditional formatting, and I’ve had like cells referencing other cells. You’d know the percent done and what was left to do versus this budget and how far off are we from our projections. Projections were done weekly by role.
Its pretty robust. That for the most part that serves me really well because I can answer any question at any time if I keep that detail of a budget but if keeping that detailed of a budget requires me to use a lot more hours of my time, and its not something that the client cares about, its not something that whoever’s signing your paycheck, if its not the client, you know your agency or whoever your working with, if your sub contracting you need to make sure that what your putting out there is what is needed.
For me it would be not having as detailed of a budget and projection breakdown as I’m used to. It took me a little bit of time to feel okay with that but there is a level of reporting that you may not have to do. My suggestion for people who are thinking, “Do I really need to be doing all this?” Is really to ask yourself what do you need to be doing? How much of this do you need to be doing? Can you do less of it? Will it hurt your budget if you do more? Will it hurt your project if you do less? Figure that out and not just do these large scale budget breakdowns out of a sense of duty. Doing them more out of a sense of this is what’s good for the project.
Ben Aston: I think that’s really helpful. I’m interested though as a percentage do you, for your project management time, do you kinda set it as a percentage of the overall number of hours of the team that your managing or do you do it on a kinda per task basis typically?
Patrice Embry: Well I used to do it on a percentage basis and I found when I was at larger agencies, this is the good side of having worked first of all for a really … longer than people really realize because I’m old, but also having worked for a number of different places and having gone to a lot of different agencies and done a lot of different stuff and not just worked one place for 10 years or whatever.
I have a lot of interesting background on all kinds of stuff. I used to do it as a percentage and that works really well if you have something that can absorb any of the stuff you didn’t think about. I can do a percentage if it meant that I didn’t have to think too much about how much I was going to go over. I found that I really need to look at each task, I’m pretty anal about doing estimates, I have a really strong point of view with them.
I typically will look at the task breakdown of the entire project. Then if I’m going to do a percentage of time ill do it as a percentage of time of the task. I don’t do like a bottom line percentage anymore because I feel like that for the smaller guys and me as a freelancer its not targeted enough to really kinda cover what I need to cover. I don’t do it as a percentage of a whole anymore.
I think its fine to do that and if it works for you you should keep doing it. I’ve found for me lately it wasn’t covering what I needed it to.
Ben Aston: Oh I see. So it wasn’t enough. It wasn’t that it was too much it was that you weren’t having enough hours?
Patrice Embry: Yeah. I wasn’t having enough hours or …
Ben Aston: What percentage where you using?
Patrice Embry: I was doing, so I was used to working with account managers then, and I was doing, I pushed for doing 20% of the whole to add for account management. An additional 20% on top of that for project management and it is a lot.
Ben Aston: That is a lot. It’s like 40%.
Patrice Embry: It is a lot. It didn’t’ always … that’s the thing with percent it doesn’t account for everything. The types of projects that I was doing, they weren’t … this is a whole can of worms that we’re opening up but if the bottom line is what’s being charged isn’t right to begin with your percentage is meaningless.
If someone hasn’t priced it out well then your percentage is still not going to be right. I found that it didn’t work well because I didn’t have enough hours. That’s not only because I didn’t have enough hours, its usually because no one had enough hours. It was completely not priced well. Going back to making sure that your estimates are … You want to make money on the project. It might not have been so much that the percentages were not working for me, it might have just been because the percentages were based on a number that wasn’t right to begin with.
Ben Aston: Right. Yeah, totally what I’m seeing. I’m used to working with id say project management should be 20% of the overall project cost and account management would be on top of that but it wouldn’t quite be as much as 20%. I think that the important thing here, kinda the take away is that we talked about requirements and that’s kinda requirements of the project. For us tailoring our kinda detailed budget and projections, tailoring based on the client that we’re working for and the fact that you don’t need to go over board and over engineer this.
I think there’s also its in terms of the clients appetite and willingness to pay for it as well. If you’ve got a highly risk adverse client who wants to know the minuet detail of buy resource kinda breakdowns and how that’s going to pan out across the whole project then its an education thing. Isn’t it? To do that cost money.
I know there’s some project management software that you plug in all these numbers at the beginning and if the time tracking and the project is all integrated into one beautiful system that it can do it all for you. The reality is for most of the projects that we do it is a manual process. We get the time sheet hours from somewhere, we have to plug it into a spreadsheet, and do some calculations. Its a big expensive task.
If you do go for this lighter route and you say we’re not going to provide this detail budget breakdown. How do you, so how are you making sure your staying on track? What is kinda your lighter method if your not being that granular? How do you approach that?
Patrice Embry: Well in my world in the past for example I would’ve broken out the overall projection for the hours, breaking down the budget into hours and projections for each role. I would usually go through and put in actuals and then adjust the projections for the rest of the project. Say, “Okay. I took too much this week so I need to get that from somewhere so my projections for these other weeks are going to change a little bit. I got that done faster so I’ve got more so I can adjust projections.
That’s the first thing I would cut out. If I knew that I didn’t have enough time, or budget, or bandwidth to be that robust with a a budget. That would be the first thing to go. You’d have your projections at the outset and you’d be able to see where you were but not necessarily adjusting every single projection each time you updated your budget sheet. That would’ve been once a week for me. That actually took me quite a bit of time to figure out how to do that.
The plus side of doing that means I’ll know really early on where we’re going to have trouble. You can raise a red flag a lot sooner but that does take a lot of time. Cost money for me to do that so there are other ways that you can figure out red flags. That would probably be the first thing to go.
Having all the calculations I would do to be able to slice and dice every piece of information five different ways. That would be the next thing to go. You go back to the basics of are we on budget, are we in danger of going over, do we have enough hours left to do the things we need to do? Does the percent complete look a lot like the percent used of the budget? Yes? Okay. Great. Lets keep moving.
Not making the spreadsheet or using the tool to its Nth degree and just focusing on the basics.
Ben Aston: I think that’s really helpful. I think one of the things to note though is we’re talking about how we scale our approach for different projects and different clients. I think one important thing to note is if you are running a big project, a project with lots of resources, you just need to be aware obviously that your burn rate is going to be much faster on a project. Your ability to pivot, if your burning through like 50K worth of budget each week on … Just in half a week you spent 25K.
I think we also need to think about how we’re tailoring our, on large projects, how we’re monitoring that budget and how, well reporting it is a different thing, but the extent to which we kinda dive into those numbers needs to be kinda tailored to the overall budget as well.
If you’ve got a much smaller team and there’s only a few resources the impact of leaving it longer before checking the data is obviously not as bad.
Patrice Embry: Right. I would still check everything every week I just wouldn’t go nuts with the analyzation with what I see. I would just kinda take it a little bit more at face value. Believe it or not there are, I’ve come across clients who have, or contractors who have sub contracted to me. There’s a client and there’s someone who’s paying me that’s not the client and there more of like an account manager. They would’ve sold something to the client at a fixed bid and turned around and tell me I don’t really care. Heres your budget but I’m not worried about if we go over. I’m like, “Okay.”
Those are fantastic but at the same time your sorta like if you don’t have parameters around something it can go really nuts. Whether or not you wanted me to put together a budget. I was going to put one together anyway because its really irresponsible of me not to. I need to be able to show what everyone’s done in the time that they’re doing it. Even if he tells me, “Money’s no object.” Which sounds like a great thing but it was actually a little bit anxiety producing for me because I was, “How we’re going to know if we’re doing it right?”
Ben Aston: Well its also nearly always misleading as well because I think when people … yeah, when you hear those famous words money is no object, or its okay I know we’re going over budget don’t worry about it we know. There’s a big difference between going over budget 10K and going over budget 100K or 500K.
Patrice Embry: Yeah. After a while it becomes like something that you don’t even notice. You don’t even see it anymore. You could be so far over budget that it literally doesn’t matter anymore and then everyone just goes hog wild. Its awful. I’ve been on projects like that and its terrible.
Ben Aston: The point where the teams like, “Oh yeah. Well we went over budget three months ago.”
Patrice Embry: So who cares.
Ben Aston: Then people are just throwing time on the project and the situations getting worse and worse. As soon as your budget remaining is at zero it’s like do I start putting negative numbers in?
Someone needs to keep track of that. We kinda touched on status updates, which is one of your points in the article around how comprehensive should we make our status update. I’ve been typically in a status report, which we send to clients, we tend to give them updates on this is the state of the budget, this is how much we used this week, this is what we’re doing, this is what we’re planning to do next week. There’s also other things that you can include in there as well like the budget kinda breakdowns and forecasts, like your risks and issues. You could throw anything in a status report.
How do you tailor that?
Patrice Embry: You know its funny because I feel like sometimes that the status reports that we do as project managers we subconsciously feel they’re a reflection of the value that we bring to the project. If your status update doesn’t look robust does it mean that your not a good project manager?
I don’t want anyone to ever say to me, “What are you doing with all these hours? What are you even doing?” I feel like sometimes we throw everything into these status reports to show our value that we’re keeping track of all the stuff or show the agencies value that we’re doing all this stuff. It takes a lot of time and effort to update that stuff and you might not need it.
My recent work that I did for that app I was talking about the client she was not super tech savvy. All she cared about whether or not things were going well, if we were going to make the date that we said we were going to, and if we were waiting on her for anything. She just didn’t want to be a bottle neck for anything. Most of the time she didn’t even get on the status calls because she was busy doing other things and it really wasn’t a priority for her. She just really wanted to know those three things, are we doing okay, are we going to be on time like we said we were going to, are we still hitting this date, and do you need anything from me?
I was putting together these status reports and I was like, “Why am I? I don’t need to be doing this.” I was doing like a whole section of what we got done last week, and what we plan to do this week, and what … She didn’t care about any of that.
I’d like to think she trusted me but I think it was more like she just didn’t have time. But we’ll go with she trusted me. She trusted me to make sure all those things to be working and she just wanted to know that it was okay.
Now that is one type of client. There’s tons of types of clients. Really the point here is to think about your client on this project and what do they care about. Don’t fill it with other things just to kinda show your worth and say like, “Look at all the stuff I’ve been doing or look at all the stuff we’ve been doing.” You can cut out probably a decent amount of stuff from your status reports if you really only focus on what you need or what they want.
Ben Aston: I think that’s such great advice. Particularly with … I think when we …. Often when we start on a project we’ll be, well I’m guilty of this, taking the last status report from the last project that we did and changing the client name and the date and then like, “This is a good one. Let’s us this one.”
Then you realize that you added in this kinda information and detail that the previous client requested and you’re like, “Yeah. That was quite useful. Lets do that again.” You kinda end up with this bloated sometimes status report. Then actually providing client either they’re not interested in all the details, they just want to know everything’s going okay or not okay. We end up providing them with details actually then we don’t need to give them that information.
I think thinking about how do I strip this back to the bare minimum to start with. If the client really wants more information they can ask for it, we can add it, but being confident, “Hey. This is all the information that we need to give them.” Let’s not spend hours. Once it starts taking you hours to produce a status report that should be a red flag that somethings not quite right.
Patrice Embry: I tell you that I have clients ask me, you know you say wait until the clients ask you for something. I’ve had clients ask me for things you know a different way of looking at budget numbers or more information about some of the things we were doing. I’ve had to tell them I budget my time for these status reports and right now I spend x number of hours per week preparing this stuff. If you do want me to continue like this then we’ll be fine but if you want me to add something that’s going to add at least another hour per status or half hour.
Which doesn’t sound like a lot until you realize how many hours that will be over time that will be left in the project. Are you sure that you want me to do that? Most of the time they’ll be like, “Well, can you just do it one time and then we’ll see if we need to keep doing it or no it’s not that important to me I just thought it would be interesting to know.” And you can kinda talk people out of it that way.
Ben Aston: I think that so true. When you explain the consequence of asking of what someones asking for and just say, “Hey. So if you want an additional hour a week for the next 25 weeks-
Patrice Embry: Are you sure?
Ben Aston: -do you realize this is going to cost you five grand?” And then, “Oh no. Its not worth that much.”
Patrice Embry: Exactly.
Ben Aston: Okay. Fine, lets not do it then. I think the one caveat to this that I would say is if you are working on a risky project or its … Your working on a project and you know either its a tricky client or you know that things could go wrong id say one thing than rather going down the bare minimum root id be elevating the risks in the status report and id be trying to have an ongoing conversation about that. What we don’t want to be doing is going so lite that we’re not covering our ass.
When projects go wrong were not just left out in the cold with no evidence that we ever said anything about this thing that might go wrong.
Patrice Embry: Absolutely.
Ben Aston: I think that could be done.
Patrice Embry: I feel like the rule of thumb for something like that would be you have to be very confident to remove it. You have to be confident that you don’t need it. You have to be confident that you can go back and add it if you needed to. Your confidence level will either come from having worked with that client before, having worked on that type of project before, having worked as a project manager for a long time. What ever your level of comfort is for doing that stuff let that be your guide and that will be helpful in helping you make sure you don’t cut out something you really do need.
Ben Aston: For sure. Let that be a warning. Next up, one of the things you talk about, and I think its a really interesting one, all of the scrum ceremonies. When we’re doing scrum there are ceremonies and that’s what makes scrum scrum. If you’ve done your scrum master training this is what they do. You spend two days learning it. It’s about these ceremonies. Scrum planning, scrum reviews, retros but what the reality is once you’ve set all those in to your project you’re doing a one week sprint that even if your doing a two week sprint and then your spending a day or two days of meetings of these different, all this kinda planning, and reviewing, and ceremonies. It can take up a lot of time.
Your kinda suggestion is here is maybe you don’t have to do all of them all of the time or you can merge them together.
Patrice Embry: I know people who are very Scrum centric. They get really upset that you suggest that you do something a little bit differently. I think most certified scrum masters that they believe that you shouldn’t do things that are not needed for a project. I think everybody can pretty much agree on that. I think it would just be whether or not they feel like these are the things.
If you’re having like a back log grooming session and that’s over, and then your doing a sprint planning session and that’s over, and your doing a sprint review and that’s over, and they’re on different days or they’re at different times that can get daunting quickly if you don’t have the budget for it.
Again, a lot of this comes down to whether or not you have the time and the budget. If you have the time and the budget go for it. If you don’t think about putting these grooming sessions, planning, and reviews all together. You will, you could get a benefit from doing that by getting some momentum. Instead of doing one and then stopping and doing something else and coming back to that same project to do a planning session. You can actually take some of the momentum from a back log grooming session and a review session to do a planning session that could be really insightful because you were just talking about what happened before and what some of these things were in the back log. You could benefit from it.
Again, using your judgment, if it feels like your spending three hours on something that can really get done all three things in like 90 minutes or an hour and 15 then maybe you want to take a look at that.
Ben Aston: I think that suggestion that these don’t have to all be separate things all the time I think is really helpful. Particularly Anna, and you touched upon this as well in terms of retrospectives, when we’re doing retros the idea is continuous improvement and we’re constantly evolving the way that we do things that manage the project, that I think is helpful.
I think one of the things that you mention in your article is about keep it light, like the retrospective thing. I know that I’ve done retrospectives myself where like you send out a survey to everybody, and then you collect the feedback, and then you draw some stats like 49% of people said that this project was a disaster, 25 … Is that really that … What are you really going to do with that? After this moment in time what are you going to do about that?
I think, keeping merging things together, keeping them appropriate to the disaster that’s happened or not. Like sometimes we do in retrospect things and you’re like, “Do you know what? This print was fine.”
Patrice Embry: We’re all good. Everything is great, two thumbs up.
Ben Aston: Okay. And then … Yeah, yeah. There’s no need to be engineering these kind of reports. If … Like, just move on, you don’t need … Like, don’t you spend another hour doing that. And I think we can sometimes get caught up in the, “Okay. Well this is what I’m supposed to do.”
Patrice Embry: Yeah.
Ben Aston: Rather than being pragmatic about, “Hey, let’s just get this project done.”
Patrice Embry: Yeah. It’s either that or you know, if status reports make us feel like we’re showing our worth to our clients and justifying our existence to our clients. Retrospective sometimes can make us feel like we’re justifying our existence to our internal stakeholders or you know, owners of agencies or owners of companies. So you know, again … Like we’re saying with all of these things, just like, ask yourself, “How helpful is this going to be and is it worth five hours of my work? Is it worth two hours of my work? Do I have five hours? Do I have two hours? Do I have 30 minutes? I’ve got 30 minutes.” Lets just say whether or not we feel like this was a good … You know, a good project or not and if there was one glaring thing that was wrong … Like, lets identify that and move on.
Ben Aston: Good stuff. So finally, let’s just talk about kick off meetings. And for me this is a really interesting one. In your article you suggest, “Maybe you don’t need to do a kick off meeting, maybe you can just send an email instead.” So I find it really intriguing … This is not something I’ve ever done, but tell me how do you make that work? Where … So you start a new project, you’ve pulled together a team, everyone’s being resourced and then you just send people out an email that says, “This is what you need to do.”?
Patrice Embry: Yeah.
Ben Aston: See you in a week.
Patrice Embry: Yeah. You know what-
Ben Aston: How does that work?
Patrice Embry: I know, it sounds crazy but this is something I started doing when I was working at a pharma agency, where we did a lot of the same types of projects across different clients. And you know, so we … I wouldn’t say it was formulaic but you know, there weren’t a lot of new crazy things that we were doing for each speech … You know, piece of collateral. We were doing … You know, this worked really well actually for print projects, because I did work on print projects for a while believe it or not. But you know, if you … The teams were almost always the same people. They were all assigned to the same clients, so they all knew their roles. That was one thing that I would do in a kick off meeting, is make sure everybody knew their roles.
Ben Aston: Right.
Patrice Embry: Everybody already knew their roles. There were two designers, there was always one developer, there were always you know, two account managers. Like, everyone knew what they were supposed to be doing. So they … We would all get in a room and we’d kind of be like, “I have so much to do, I don’t even have 30 minutes to you know, devote to this kickoff.” So it was more like, “Okay, if everybody knows what their role is and everybody knows who this client is and everybody’s working a project just like this before, what are the things that they need to know?” They need to know what makes this different from the other projects that they did that are like this. So, I outline those things. They need to know, you know, what the time line is, which is something I bring to a kick off anyway and you know, I could talk about the time line but they want to see it and interact with it and look at it and be able to absorb it. So they’re not really going to be able to give me … You know, off the cuff feedback necessarily from looking at it at the meeting and I want to give them … You know, their first tasks.
So, I can do that in an email if everybody knows all the rest of it. And actually, they were really happy that I didn’t take the time to make them sit there and talk about everything and hear me talk about the same things that they always did. So, if you’re doing projects like that where they’re very repeatable and you’ve got the same folks doing the same things … You might not have to do a kick off meeting. You could do a kick off email. I did them a lot and it was really successful.
Ben Aston: Yeah. No … I think that if … I can see that … I can see that working, yeah, when you are doing something repeatable. I think in my instance, I’ve always got someone new to the project or you know, there’s some kind of new element. I think similarly there there’s something where if we’re just thinking more generally about, “What are we doing because we always do it?” Rather than … What you’re talking about there is, “What do people really need to know to be able to get started on the work?” And I think one of the things where we sometimes spin our wheels a bit and over engineer is like, in writing briefs. And you’re talking about here, sending out an email with a brief in it basically.
But sometimes, I think sometimes we get this brief template and I think … Don’t get me wrong, I think briefs are really important and helpful. But there’s often sections in there where you’re like, “Oh, I have to copy and paste like, the same thing again. I’m just changing three words.” I did this last week and it’s the same kind of thing. Like, if you’ve just got the same team, I think looking at how you’re briefing people and trying to make that briefing process more efficient as well so that you’re not spending your time when you’re briefing people, re going over stuff that everybody knows and it’s a complete waste of time.
Patrice Embry: Right.
Ben Aston: And just focusing on, “Okay people, here’s what we’re trying to do. Here’s what I need you to do. Here’s the kind of task that we need to get done. Is everyone cool with that?” Like, not being formulaic about the way that we approach everything on this kind of like, templated … Templated way. I think the … I think for me the kind of take away from our discussion today is like … Treat everything like a special snowflake. Like, don’t think that you need to just because you did a good job on something last time and applied loads of effort on it … Doesn’t mean that you need to apply it exactly the same process and documentation and rigor to every single project to every special of every different type. The point is that we can do things differently, we don’t have to do things exactly the same every time. Taylor it to the project.
Patrice Embry: Absolutely.
Ben Aston: Cool. So, we’ll Patrice. Thanks so much for joining us, it’s been great having you with us and if you’d like to contribute to the conversation that we’ve been having today, comment on Patricia’s post or head over to the community section of thedigitalprojectmanager.com and join the conversation there. But until next time, thanks for listening.