Javaddicts

In my last post dealing with the issue of project management, I introduced my current situation. While reading “The Art of Project Management” by Scott Berkun I thought a lot of what I do, what I could do better, what I did wrong and the like. Being human I usually tend to forget stuff like that. As the old saying goes: “If you don’t write it down, it never happened”. Having started using GTD as the organisational tool of choice recently, this has become my new mantra.

So to prevent my brain from hiding these (rather important points) from me, I fired up VoodooPad and started to write them down. So here it is. If you have something to add or have comments, feel free to add them. At the end I added some inspirational sources. They might not be all, since I tend to read a lot, but these are the lates sources I’ve read about these things.

What to do?

• Make good stuff happen
  • That’s Scott Berkun’s mantra, but after I read it I couldn’t come up with anything better, it’s just everything you need to tell yourself every day.
  • Whatever it is that’s needed to bring the project forward, do it!
• Encourage communication
  • Care for other people’s opinions. Don’t draw conclusions on facts you don’t know.
    If someone comes with a problem you’re not likely to solve, include people with the corresponding knowledge.
  • Write concise email. Get to the point quickly and don’t annoy people with useless information.
  • Talk to people! Spending time talking to people is precious time, if you lead the talks into the right directions. Only through talking to your team and people outside of it you’ll get a clue on what’s going on, where the problems are, or might be someday.
  • Be honest. It’s hard sometimes, but your team will acknowledge honesty. Being honest to them helps build up a trustful relationship between you and your team. Additionally, if you’re honest, other people will most likely be honest too.
• Encourage creativity
  • Don’t tell people how to do it, but tell them what to do. As long as they’re staying within the borders of requirements and specification, there’s nothing to worry about.
• Track progress of tasks
  • Try out for yourself what people tell you they’ve finished or have people show it to you.
• Define tasks
  • As small as possible. Smaller task lead to a more structured work style. Results are easier to see for everyone involved. Two days and having a small feature done is more motivating than two weeks without having anything really done.
  • Include the team members in the definition process. Being more into their parts of the projects they might be able to find tasks you don’t see.
  • Collect the tasks, prioritize them and set estimates. Work out estimates with the team members and learn/teach/encourage to refine them over time.
• Delegate tasks
  • You can’t possibly do everything yourself. Delegate tasks, because that’s what your team is there for. Delegation is also a matter of trust. People having tasks delegated to them can grow with the given responsibility. More responsibility is always a challenge.
  • Train your staff, so that it’s easier to delegate tasks.
• Make decisions
  • To make decisions, try to consider as many available options as possible. Include options that might sound ridiculous as well. Write them down together with their pros and cons and draw your conclusion, even if it might be unpopular.
  • If there is a decision that you think you’re not able to make, be it through missing pieces of the puzzle or missing powers, then include your manager(s) or otherwise the right people into the decision making process.
  • If it’s necessary, take the high road. Not every decision has to be the easiest one. Taking risks is about taking chances. If it ends up being a mistake, get up again and learn your lesson from it. But that lesson should not be to not take risks anymore. If you practice taking risks regularly, then those tasks at work that you’ve feared doing for weeks or even months look like nothing.
• Reward people
  • If they went through hell with you, give them an afternoon off (or a full day or more, depending on how hot hell really got for you) or have a nice lunch with them.
• Remove obstacles
  • If there are problems, do everything you can to find a solution. Include your manager, members of the team, the customer, if that’s what is needed to resolve the issue.
  • Be clear in what you want and in why you need it.
  • Be prepared with regard to your arguments. If you need decisions to be made, have the right arguments at hand and know your audience.
• Resolve conflicts
  • Get the involved parties together and have them bring up their issues/views of the conflict. Consider a fourth party’s opinion, if necessary.
• Be the gateway between management and the project
  • Shield your developers from distraction that’s not their concern. But don’t block every kind of communication with the outside world. This will filter out valuable feedback.

What not to do?

• Annoy people
  • Don’t send useless email.
  • Don’t walk into their offices too often to ask how it’s going.
  • Don’t involve them in meetings they’re not needed in.
• Take the praise and keep it
  • The project lead has to step back when it comes to earning praise. He takes it and passes it on to the team.
• Blame your team
  • If you receive blame for something, deal with it, but don’t blame your team for it.
  • People make mistakes, and so do you. A crisis is not a time to blame someone, it’s the time to find the best way out.
• Take The List as the only project’s progress indicator
  • Trusting only your checklists is the wrong way to track the project’s progress.
  • When a feature is done and works (!), then it’s done. Having it crossed from your lists does not indicate it being ready for prime time.
• Don’t be too overinvolved
  • Don’t try to control everything. This will annoy people and reduce their trust in you, because you don’t seem to trust them.
  • Don’t force people to hear you out or consider your opinion. You or someone else hired them to be experts or responsible for their stuff.
• Break commitments
  • If you tell someone you’ll do something for her, do it! Keep your word. If you can’t, be honest the her and re-schedule the commitment. If you break commitments more often than not, people will start to lose trust in you.
• Complain about the pile of work you have to do
  • You’re the gateway, so people will bring the work to you. It’s your responsibility, after all. If you’re able to delegate and organise yourself, then this isn’t a problem.
• Work towards your own favor or needs
  • It’s the project that matters. If you have to make choices, don’t push your own opinion too hard.
  • Don’t allow for other people to put you in a favorable position.
• Spread gossip
  • Don’t believe everything you hear. It might cause panic or mistrust, if it turns out to be wrong.
• Seek praise, respect, gratitude, regard for past service
  • Whatever it was, it’s your job.
• Laugh at anyone or judge anyone for making mistakes
  • This is a tough one. Laughing is human and we tend to judge people easily. I did it, and I’ve seen people do it. But everyone makes mistakes, so do you. If you’re laughing at people, people will laugh at you. Or worse, they’ll loose trust in you, themselves, the team and the project. You do the math.
  • Making mistakes is human.
  • It’s your responsibility to help him/her preventing the error in the future. Help him find the reason for the mistake so that it does not happen again.
• Let them feel it, when you’re in a bad mood
  • Everyone has a bad day, but if you let everyone have a taste of your bad mood, it’ll instantly affect your team and therefore the project.

A lot isn’t it? Once I started writing these down, more and more things popped up. It sort of reflects what I learned in the recent years, but especially in the recent weeks. Some of these things are quite obvious, but it’s nice to have them available as a reference. I don’t look at them every morning, but when I’m in doubt, they’re a nice reference to get back to.

References

• The Art of Project Management, Scott Berkun, O’Reilly 2005
• Ship It!, Jared Richardson, William Gwaltney Jr., The Pragmatic Programmers 2005
• 16 Reasons Managers Can’t Get Employees to Perform, Open Loops Blog
• What’s Happening When It’s The Manager Who’s Not Performing, Open Loops Blog
• Leadership Principles to Live By, Eric Mack

This entry was posted on Wednesday, August 10th, 2005 at 2:39 pm and is filed under Project Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.