Skip to main content
Personal Growth
6 Project Management Tasks That Maybe You Don’t Have To Do After All

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.

project management tasks - detailed budget

Do you really need that much information?

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.

project management tasks - comprehensive status updates

Don’t let your habits make you act like a robot.

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!!

project management tasks - scrum ceremonies


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.

project management tasks - color coding

Sometimes color coding will be necessary only for your closet.

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.

project management tasks - detailed retrospectives

Do we really need a deep review meeting for that teeny tiny project?


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!

What Do You Think?

Do you normally do all of those in your projects? What do you think about skipping kickoff meetings? And the Scrum “ceremonies”?  Share your opinion with us!

By Patrice Embry

I'm Patrice Embry, a freelance digital project manager and Certified ScrumMaster. After 20 years in the field, I've been fortunate to work for agencies, corporations, and everything in between. My clients have spanned far and wide across verticals - pharmaceutical, finance, construction, ecommerce, race cars, you name it. My client roster includes Exxon Mobile, Merck HCP Education, Lundbeck Pharma, ACLU, Anti-Defamation League, GS1, SEI Investments, Simple Finance, and many more. I've worked on large scale websites, mobile apps, CRM and CMS systems, even print! I'm passionate about project management philosophy - it shapes what I do every day. My website is, and you can find me on Twitter @patrice108.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


  • image
    Totally agree. And there are probably a few other items you could add to the list. All projects are different and require a PM to be flexible in their approach and adapt to the needs of the client without compromising the project goals. Don't get so caught up in your processes that you lose your audience. Know how to engage them in the right way with the right materials and this should streamline your owns efforts to focus on those things driving value.


  • image
    I definitely agree. Too often we project managers, as sometimes even more – we PMOs, get caught up in all our detailed processes, policies and procedures without giving thought to the “why?” part what we do. It’s one of the reasons the PMBOK has grown to 756 pages. We just year after year keep piling it on with diminished value. Simplify-simplify-simplify!