Archive for September, 2013

September 16, 2013

Patrick’s Top 21 Project Management Tips

1. You aren’t in charge, and you rarely make project decisions.

This sounds odd for a project manager, but I think it highly true. You certainly make a lot of day to day decisions about how to manage the project, but you aren’t the project owner – you have a boss or a stakeholder who is. And while you should certainly make a lot of educated recommendations – you need to make sure that your stakeholder owns the decision making. It’s their job to do that, and your job is to help them make a great decision.

2. Question everything.

Question the schedule, the reason you are doing the project, the people on the team, the technology being used, who is on vacation, who might adopt a kid or a puppy, the skill set of the lead developer. Everything.

But here’s the deal: You have to be curious – you have to REALLY want to know and understand the answer – otherwise you are an adversary.

3. Don’t accept the first answer.

It’s not that the first answer might not be right – it probably IS right. But it might not be best, the smartest, the fastest, the cheapest. People will latch on to the first answer, just because they thought about it first. But until they’ve thought about the 2nd or 3rd or fourth way of doing something – don’t settle.

4. Don’t believe any estimate that is over 8 hours.

This is a little tricky. But if someone says they are going to spend 200 hours doing something, you should be highly skeptical. It probably means that they haven’t really thought about the work. If I asked you how long it would take to paint a house, you might make an educated guess, and it might even be close.

But you don’t WANT an educated guess: You want your team to spend time being thoughtful not only about what, but how and in what order. They have to break those 200 hours down into concrete tasks that they can start and finish – so you need to help them do that sooner rather than later.

5. Make agreements about time, early

Get on record, and early, about time. What does end of day mean? Close of business? Tomorrow afternoon? You’ll be far better off with someone saying “I don’t know”, than “I think I can have it tomorrow mid-day”. What does that mean? It’s okay if someone can’t make a snap commitment for a deliverable. When that happens, make them commit to 2 a day updates, so you are in the know. Look at #4. When they are breaking their 200 hours into smaller tasks, it will take some time. But they owe you updates, so you can maintain and update a schedule.

6. Learn as much as you can about technology.

You don’t have to become a developer, or a graphic artist, or a database expert, or a social media whiz. But you need to know more than your stakeholder. So when someone says “I think I can build that in Ruby”, you know that they aren’t talking about a town in Arizona. You can’t learn it all at once – but you need to learn it. This can be highly dependent on the type of project (web, database, infrastructure, other). So you’ll be learning a lot. And just like you might not remember the Pythagorean Theorem in particular –you ought to remember that it helps you determine an area. Someone else can do the math, but you need to know the why.

7. Ask a lot of questions.

This is different than questioning everything. There is almost nothing as flattering as asking someone to explain what they are doing, particularly if they are good at it. So they’ll tell you, in mind-numbing detail. You don’t have to memorize all of it, but you DO have to pay attention.

And you’ll find out things that will help – you’ll understand a piece of technology, or what makes someone light up with enthusiasm. And you’ll develop a reputation as someone that wants to learn.

8. Admit your mistakes early and often and to everyone.

You can’t keep them a secret, anyway. So when you make a mistake, tell everyone involved. Better yet, tell them why you made the mistake, how you are going to fix it, and how you are going to make a new one next time. No one likes a repeat offender.

9. Keep a “waiting for” list for everything related to the project.

This is tedious, but not hard. If you ask me for a schedule, make a note that you asked, and when I am supposed to deliver. Otherwise, it might fall off of your radar. And then review your “waiting for” list every day, so you can follow up and get what you need. Otherwise, it might slip through the cracks.

10. Send meeting notes out after every meeting. Every one.

Even if it isn’t your job. Make sure notes get sent, make sure you ask for feedback, and make sure you review for sneaky to do items. Things that need to get done that no one said they would do. Again – tedious, but not hard. It will keep everyone more closely in agreement than if there aren’t any notes.

11. Don’t mistake a risk for an eventuality.

Planning for risks should be fun. But just because there is a risk that you’ll be struck by lightning doesn’t mean you have to develop a big plan to solve it. Think about risks like a 3D chess game: you have the risk, you have the likelihood it could come true, and then you have the severity of what happens if it does. Those 3 things together help you determine if you care about solving for the risk, or if you’ll just let it ride.

12. Discover what makes the people on your team tick.

You need to have a personal relationship with everyone on your team. No, you don’t need to take them all to dinner or buy them flowers. But they need to be real people, not just a cog in your project. Take the time to find out what makes them light up, what they do after work, what they care about. You’ll learn something, and they’ll like you for that. And that matters – because there will be times when they won’t want to like you, and you’ll need your personal relationships to help keep the project together.

13. Don’t get hung up on what is in the scope.

Sure, it helps to have a scope of work, or a requirements document, or a design document. But don’t think for a second that being right about what is in the scope means you will win an argument or be successful.

Use those items as guiding principles, as a way to keep focus, as a method of tracking against your ultimate goal. But you can’t use them to win. No one likes to be told “I told you so”. Read them, make sure people read them, keep them updated. But the second you insist that you are right because it is in the scope, you’ve lost.

14. Do the shit work anyway.

So you have a fancy title, and you run the meetings, and you schedule things and yada, yada, yada. Don’t get full of yourself – there are plenty of scut work items to be done, and if no one else is doing them, guess who just won the shit work lottery? No one else keeping a copy control document? Get to it. Does someone have to convert 200 long URLs into a short link? Hop on board! Your job is to remove obstacles, and when you see work that can be done and isn’t, and you have the capacity to do it – you should. Right then. And don’t complain about it, either.

15. The start time is often more important than the finish time.

We love milestones and deliverables and due dates. Fine. Those are all good things. But don’t let your attention focus only on the finish date. It’s like a marathon – if you don’t start soon enough, you’ll never, ever catch up. Make sure that tasks are started with enough time to finish them.

16. Don’t be afraid to call out shoddy work.

You need to know it when you see it, and you need to see the early warning signs. So – you see an early draft of a website, and there isn’t any meta data. That might not be a sign of impending doom, but it might be.

Is it okay to get in the car and put the seatbelt on “Oh, I’ll do that when it’s important?” No, it is not. So keep your eye out for where people are taking shortcuts early. But don’t embarrass people on purpose – that won’t help.

17. Beware of over-automation.

Just because you can write a little bit of code to automate that, doesn’t mean you should. Maybe you should. But the engineer that suggested the automation might like that part of the project better than the scut work – it could be a bright, shiny object. If there is a strong reason to automate, and if the timeline and budget and the support needs align – go ahead, automate. Just don’t do it because it can be done.

18. Develop a canary in the coal mine test for every project.

This is a highly non-technical test. But it’s the one that you know is true. It goes like this: If I look at the design, and EVERY thing is a pretty picture, and NONE of them are text – then you know that the design team isn’t thinking about copy at all. And that’s bad. Your canary just suffocated.

19. Be at least as interesting as the project.

This goes along with #12. You also have to be a real person. Wear a tie on launch day. Bring cookies. Talk about things that you care about (but maybe not sex, politics or religion). The project matters, a lot – but people matter more. So you need to be interesting, engaged, excited about the work. You’ll have more fun, and your team will, too. And that translates to project success.

20. Be flexible with the schedule.

Just because someone says it has to be ready on January 1 at 12.01 AM, doesn’t mean you have to be up and working on New Year’s Eve. You’d be surprised about what is flexible in a schedule, if you just ask. So ask.

And then when someone asks you – treat them the same way. Can you wait a day or two for that design? For that preview? For the piece of hardware? If you can, and without introducing undue risk in your project- let it slip. Its real people, with real lives, working together, so stuff is going to give. Don’t be a jerk about the schedule unless there is a great reason.

21. Pick a tool to manage the project and use it.

Up to you – it could be Excel, it could be Daptiv, it could be Jira, it could be Basecamp, it could be Outlook, and it could be Project. Pick the one that your team is most likely to use, and stick to it. Don’t let your project fragment into “the dev schedule is here, the creative schedule is there, and Jimmy knows when the hardware is going to come in”. It’s rarely the tool that gets in the way here; it’s the lack of rigor around using it.

(c) 2013, Patrick Shaw