There has been much written on the topic of things that a project manager “should” and “must” do: run reports, keep stakeholders involved, look for red flags, keep a budget, create projections, keep detailed client status notes, check in on tasks, meet about a meeting about a meeting…. It can get very overwhelming, especially if you’re managing several projects at a time. I’ve managed a few projects in my day that simply didn’t warrant the full PM treatment, and I gave it to those projects anyway, thinking I “should”. What I wound up with was a lot of output that no one cared about, and a lot of hours billed to this project (plumping up the budget) that could have been given to another project that needed more attention.
Since project management is such a service-oriented role, it’s hard to think about purposefully not doing something that’s usually part of your job. But I’m here to tell you – you don’t have to do EVERYTHING for EVERY project. I promise!
Here are some Project Management tasks that – depending on the project – you don’t have to do after all:
1 – Detailed Budget And Projection Breakdowns
I have a budget sheet that I usually use from project to project (I do old-school breakdowns in Google sheets/Excel) that has hours broken out by week and by role, and a separate section devoted to projections for the entire life of the project. It also has a % complete tracker that compares that to % of budget used. It’s color coded. It’s conditionally formatted. It has lots of formulas and lots of cells referencing other cells. And it’s entirely too much for small or low-budget projects. Do yourself a favor – really think about exactly how much financial oversight a project needs before embarking on a robust budget sheet. And you might not need to touch projections week after week – just use them to start, and then let them go.
2 – Comprehensive Status Updates
I was recently managing a project that was fairly heavy duty on the development end, but with a client who was not technically savvy and not overly interested in the day to day management of the project. As I usually do, I set up a status sheet that showed data and details about % complete, % of budget used, how things were trending, a list of what was completed this week, a list of what is being done next week, etc etc…all the things that clients usually want. I set up a weekly recurring meeting and dutifully prepared the status sheet in advance, and sent it and the conference info to the client just ahead of our meeting, every week. And I’d say that maybe 30% of the time, the client actually met with me. About 10% of the time, the client opened the status sheet. (It’s a Google doc, so I can see when she opens it.) She really did not care. I was basically updating the status sheet out of total robotic habit. All she wanted was an email each week laying out whether or not we’d hit our date, and outlining any things she was supposed to be doing. She didn’t care about any other metrics. I mean, *I* did, but I had those notes available to me at any time, I didn’t have to create a status sheet for them. Find out what your client needs and meet those needs – don’t let habit dictate what you provide for updates.
3 – All Of The Scrum “Ceremonies”
I’m probably going to catch flak for this, but you don’t always have to have a separate backlog grooming session, a sprint planning session, and a sprint review. Sometimes you can roll all of those into one, saving some time and effort. I
Actually think that it’s helpful to have all of these together, since you can gain momentum and not have to have conversations more than once. And sometimes, you can even forego daily standups. Shhhhh!!
4 – Color-Coding Everything
This might actually be me talking directly to me. Patrice, you don’t have to color code EVERYTHING. Yes, it is totally helpful when trying to show a lot of information in one place. Yes, it helps to set apart some things and highlight others. But ask yourself – am I color-coding because I’m a neat freak bordering on obsessive, or because the project actually warrants it? This also goes for any kind of difficult formatting or overly-complicated formulas and spreadsheets.
5 – Kickoff Meetings
I love kickoff meetings. I like being able to set the stage for the team, and to get them excited about working on the project. But it is a meeting, and people hate meetings. If you want people to go to your meetings because they feel they’re important, you need to make sure your meetings are, in fact, important. If the project is small and/or straightforward, a rehash of something else, or for whatever reason just not complicated, try doing a kickoff email, not a kickoff meeting. Follow up with each person to make sure they got it and they understand their role. I doubt there will be ANYONE on your team that is going to complain.
6 – Retrospectives
Okay. I’m amending this a tiny bit: *Detailed* retrospectives. I do still believe that every single project deserves some kind of review after it’s closed. Even small projects can have some good lessons learned. But a process that involves surveys, in-depth soul searching, and a meeting to review results isn’t always needed.
Of course, every single one of these things is 100% dependent on the complexity of the project. There will be many projects where you can’t skip anything, and some projects where you skip everything, and many, many in between. I operate from a place of repetition of successful outcomes, and that sometimes has made me somewhat inflexible on what I do and don’t do in a project. I’ve come to realize that each project is different, and not all of them need everything. So throw off the shackles of the “should”s and leave some of the “must”s behind!