“If the project fails, it was your responsibility. If it’s successful, it’s because of your team.”

So a couple of things I’ve learned in running projects as a project manager, in no particular order:

• Beware of being overly comforted by minutiae. I am always wary when I get lots of GANTT charts and presentations tracking a million milestones. You need to track outcomes, not activities. So if the goal is to implement 15 capabilities by a certain date, you need a one pager that shows what you need to deliver, what’s been done, what more needs to be done, and when you expect them to be complete against the timeline. You need to keep the team focused on the work relative to time.
• Keep your presentation consistent and simple for updates. Format wise it’s usually 1) executive summary, 2) a timeline/major deliverables/status view, and 3) next steps/what you need from the group you’re reporting on. If it’s not a good update, you’re going to need to pre-sell the information (see number .
• Here’s how “status” should work with projects: Green– all good, on track, Amber – issues which put the target date in jeopardy, but  you have a viable Plan B that bears watching. Red – we are going to miss the date, and are still working on a plan to mitigate the risks. I have seen too many projects stay green when they really shouldn’t be. Be honest about the project status. Usually in order to get back to green, big decisions need to be made: getting more resources, deferring functionality. By keeping it in green, you’re just lulling everyone into a state of complacency and kicking the can down the road.
• Team membership typically changes depending on what phase you’re in: when you’re in analysis and design, you tend to have a different group than when you’re in implementation. Don’t be afraid to switch out players in order to get the right people around the table, but do it sensitively. People will want to stay…moving them into an “advisory capacity” usually helps.
• Speaking of team members, you must trust every person on your team to be the expert on the function they represent. If you don’t, get a new person. You won’t know everything…so they have to.
• It’s your job as the project manager to make the hard decisions (e.g. changing report status, swapping out team members, pushing back on requirements). That’s not a group decision. The group should provide input into the decision, but it’s you making the final call. They’ll respect the decision if they think you’re being fair.
• Let your team do what they need to do: there is a difference between active management and micro management. You’re allowed to micro manage when things are bad, but you’ll wear everyone out if you do it right out of the gate.
• The devil’s in the details: Requirements documents are critical and never get the amount of time they deserve. It’s hard for a word document to convey process, data complexity, and the 20% of the inputs which won’t be standard. Make sure it’s done right. I once saw a project delayed by months and lots of money because the coder interpreted ONE data field incorrectly.
• People are smart: if they think you’ll throw them under a bus if the project fails, they will start backing off quickly. If your attitude is that you’re accountable if it goes wrong, but they’re the winners if it comes through, they will do what it takes to get the job done. I’ve never seen a situation when they haven’t.