Project Management Do's and Don'ts

Throughout my 5 years of being an Account Manager and Producer/Project Manager, I’ve learned valuable lessons (sometimes the hard way) in how to manage design and development projects. The biggest takeaway for me has been to learn from past mistakes. Being the point person is a truly challenging, yet rewarding task as long as you utilize your experience to your advantage. 

But let’s get a little more specific. Here are my top Do’s and Don’ts to help any up-and-coming project manager rise to the next level:

DO: Listen and ask questions.

They’re all biggies, but this is possibly the biggest. Whether you’re in an internal kickoff, a client presentation, or your developer shouts across the room to you, L-I-S-T-E-N. The smallest of details can make or break a project. It’s important that you, the manager, understand and can communicate what the client is thinking, requesting, asking, and/or demanding if necessary… not to mention what your team thinks, needs, and recommends as well. If something is unclear, ask. No, seriously. ASK. As funny as it is to think of conflicting examples, there are NO stupid questions.

DON’T: Make assumptions or under-communicate.

Wow has this one bitten me in the past. Remember as the saying goes, when you assume, you make an… never mind, you catch my drift. The point is that it’s never safe to assume that your entire team knows what you’re thinking. Recap emails, touch-base meetings, or even a quick IM will never hurt. It’s always best to make sure everyone’s on the same page. It’s also best to make sure your client is on par with everything from project requirements to deliverable dates and everything in between. In my experience, setting expectations is KEY to running a successful project.

DO: Educate yourself.

Let’s face it— being a PM is tough. But it’s even tougher when you are not up-to-speed on the work that your team is doing. For instance: You’re managing a project involving HTML coding of a few pages. You as the PM should probably know the basics of HTML or, at the very least, what HTML is capable of. Keeping yourself in-the-know will benefit you greatly in many ways. I always find it’s best because you’ll be able to field more questions without having to constantly bombard your team, which will allow them to stay on track. No need to become an absolute expert, but my advice is to learn just enough to make yourself dangerous.

With that being said…

DON’T: Do your own production work.

At various points in my career, I’ve attempted to perform some light-to-medium Photoshop designs and even front-end coding in HTML and Javascript. Not only were these tasks interesting to me, I figured they might save the team some time in the long run. In certain cases, this worked out. In several others, this backfired on me. Unless it’s absolutely necessary and/or it’s in your job spec to work on these items, it’s best to let the designers design and the developers develop. Two main reasons for this: 1) If you don’t do it right, you just lost that time that you could have spent on other tasks AND it’s going to take additional time for your team to fix or redo what you did. 2) If you do it right, you could be opening up a new can of worms and you could find yourself having to do more and more of these tasks moving forward, which will set an unwanted precedent.

DO: Know the scope and the brief.

No brainer here. The PM should fully understand what’s in scope and be able to decipher if a request falls outside of those boundaries. And the brief should set the guidelines for those in-scope items, so you need to reinforce those guidelines. You’re the gatekeeper. Know your stuff.

DON’T: Start work without the scope and the brief in hand.

It may seem like a good idea to get a jump on the project a bit early, especially when faced with a tight timeline. The reality is that this can come back to bite you if you and your team are not totally clear on what’s being asked for and the boundaries of what’s reasonable and feasible in that timeframe.

DO: Trust your team.

Some of the items above could make it seem like I’m saying you’re the only competent one in the bunch. That’s not the case. Your team is made up of highly trained individuals in their fields. As a PM, you should be able to trust your designers, developers, strategists, etc. to do their job and impart their knowledge when needed. Your job is to keep the team on track and to bridge the gap between them and your client.


DON’T: Just push paper.

Teams are meant to be collaborative. Boxing yourself into a role where you are basically an email exchange between clients and internal teams will yield little-to-no reward. You shouldn’t be afraid to get involved, voice your ideas, and propose solutions when the team faces a challenge. This is a chance for you to get creative. Take a risk. It’s totally OK if you get shot down. Trust me— you’ll learn a ton from your most successful decisions and your worst mistakes.

« Prev Article
Next Article »