- Do not forget that it is the people in the project teams that actually deliver successful projects
- Be sure to use every chance throughout the project to manage expectations
- Be sure to put conclusions in writing immediately, even if not using documentation heavy methods
- You can never communicate too much as a project manager
- Keep a close eye on risks throughout the project and use a visual risk log as a communication tool
- Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one
- Establish checkpoints that you follow in each of your projects, even if operating in an agile way
- As a project manager, try to add value beyond administering the project
- Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on
- Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization
November 3, 2009
November 2, 2009
I must admit that I love projects. I find them energizing and really enjoy going from the unavoidable feeling of uncertainty if it is feasible at all, to a successful delivery. I also like to be able to finish off, and then start a new one – with clean sheets (for the joy of Norwegian readers, I’d like to add a reference to Alf Prøysen, who came from a place close to my mother’s, at this point: “Du skal få en dag i mårå”, which I would say translates more or less to “You’ll have another chance tomorrow”).
Even if it you are like me and are happy about finishing off the project and then start a new one, possibly a different place and in a different field: I urge you to try to win the war, not only the battle… Thus my 10th and for now final tip is worded like this:
Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization
You can be sure no-one will thank you for delivering on your formal mandate, if the product you delivered does not really leave behind anything valuable or useful when the project is terminated.
For me a key aspect of project management, as well as management in general, is to pursue continuous improvement, both within the project and across all projects of the company. The more mechanistic aspects of this, with Lessons Learned logs etc., are well covered in most project management methods. But it is of course even better if you can adjust course rapidly (agile, if you will…) as the project goes along, and that is as much a question of attitude as of hefty templates.
Another classical fight is the one between short terms requirements (“give me that functionality, and give it to me now!”) and long term demands of architecture and maybe even cleaning up some old mess. Again, trying to eat the elephant in smaller pieces is key – try to build architecture project by project and if you have a large code base (and they are never only pretty), leave it just that little bit better every day. Oh, and when estimating the cost of your next project: Make sure to estimate the required time and cost to improve architecture as you conduct the project.
I am considering writing a piece about project portfolio management, arguing that this is really more than what can be achieved in a project management office or similar structures. I hope to do this sometime before Christmas. Please come back to have a look. My next piece, though – and hopefully in just a few days, will be summarizing the brief tip series of posts.