I was sharing with a friend everything I have learned on all the projects I’ve worked on, and I realized that this could help other people as well.

So here goes…..

• Stay outcome focused on your reporting: too often PMs start tracking activities, not outcomes. If the goal is to implement a capability, what are the major milestones to enable the capability? The many tasks required for the milestones should be the responsibility of your leads, not you.
• Keep the reporting simple and repeatable. Major deliverables down the left, calendar date across the right is the best format I’ve found. It lets you see all the tracks relative to each other…if someone thinks they are going to test, but development won’t be ready till later, you’ll see the problem. Plus, you’ll also see where one track influences all the others if they are late. It’s air traffic control.
• Weekly Project updates with the team to start with….then as you get closer to go live, more frequent and shorter. You step up check-ins as the team gets closer to landing the plane.
• Bad news does not age well. As soon as something comes up that affects the outcome end date, it has to get raised and dealt with. Too often the team takes too long to figure out the solution….usually it’s a quick convo with someone senior to make the call that you can facilitate faster.
• Be aware of the long poles in the tent: not every activity is the same in complexity. The ones that are really hard and complicated…the sooner those are completed, the better. If not, they will end up holding up everyone else. People like to do those last.
• Figure out positions and people early: one bad person in a key position can throw the whole team off. Assign leads to workstreams so there’s less confusion and you’re not the bottleneck. Otherwise you get 6 year old soccer: a lot of kicking, the ball’s not going anywhere.
• “One Throat to Choke” – accountability has to be clear…show me multiple sponsors, and that’s a project that will have an incredible amount of overhead keeping everyone updated.
• Know your success criteria ahead of time: People want perfection but that’s not realistic. Don’t have the team figure it out at the time…they will go with what they can versus what they should.
• Testing always takes more time than people think, and it’s the first thing people try to cut to make the date. Cutting corners on testing always leads to a bad user experience or defects.
• Get the plane in the air, and make inflight adjustments accordingly. Sometimes the team will spend too much time on the plan documenting every contingency. It’s impossible: just make sure you have a way to find out if something’s come up that needs to be dealt with.
• Never underestimate down stream integration in terms of data…everyone does.
• Convince the critic: When designing new processes, go to the most cranky FA office you have. If they are ok with it, it’s probably fine for everyone else.
• Be honest about RAG status: if it’s red, it’s a concern. Amber means you’re watching it closely. Green is everything is fine. I wouldn’t let anyone set RAG except me.
• Senior level reporting: keep it high level, but deep dive when appropriate: e.g. a really complex issue, or a big achievement. The high level always stays the same, but the deep dive is based on whatever’s going on to provide more insight in what’s going on the project. Otherwise updates get pretty boring…let people know what’s being built that they can get excited about.
• “If it fails, it’s on you. If it’s a success, it’s because of the team” is the mindset that buys hearts and minds.
• “Trust but verify”: I trust everyone, but in the status meetings, I’m checking. If they tell you something has been fixed, look for others to confirm it….especially the ones who are dependent on it being right.
• “Recipe, not list of ingredients”….projects often go wrong because the requirements are insufficient. The worst are just a list of needs..e.g. “ need to be able to link accounts after opening for a household.” The recipe is actually how the process should work- step by step like a recipe. The point of the recipe is that any one should be able to follow the recipe and come out with the same outcome. If they can’t, then you don’t have enough detail to build it out. People don’t like doing this but get them all in the room to define the process they want built and I guarantee it will be a debate.
• “Devils in the details”– once had a project need a 6 month delay because someone hardcoded one field that needed to be variable.
• Have Plan B: in case you can’t go live, you need a fall back and you need to identify the conditions where you will go to Plan B. Figure it out and communicate ahead of time: it’s really hard to do that when you’re in the thick of it.
• Sponsor Side-Bars: make sure you’re meeting with the sponsor of the project on an ongoing basis for “side bar” conversations. Status meetings tend to be performative. The side bars are where you can have the honest conversations and get some advice. You can’t have those conversations in a big group.
• “Day 2”: this is when people come up with additional requirements AFTER you’ve already said we’re done. Unless it’s critical (like something will break), put it on the Day 2 list. That way you’re not forgetting about it, but not derailing the whole project for everyone to stop what they’re doing to figure this out.
• Vendor Dependencies: everyone likes to divide and conquer-they do their part, you do yours. The project is indifferent who is doing what: you have to manage it as one cohesive project. Projects get turned around fast when you bring EVERYONE to the table, and there’s a lot less blaming of the other party when everyone is in the room.