Now that you've planned the flight... Fly the plan.
If you've taken the advice given in Part 1 you should be set up to drive your projects by result rather than activity... you'll find your team responds best to this approach...
I posed a question on LinkedIn recently to see what advice the professionals would give a budding PM:
Here's the answer offered by Gianluca Bacca:
1) Define the scope of you project as clear and as soon as possible and formalize it … a project doesn’t exists without a Project Charter and a WBS!
2) Be realistic and pragmatic, don’t forget that generally available resources are limited … a request or change coming from a stakeholder, generally, involves a trade-off between different elements of the “triple constraint” (time, cost & quality) … think always in terms of trade off between the elements of the “triple constraint”.
3) Manage ALL your stakeholders with care being proactive: to do this you need to identify ALL of them and constantly communicate with ALL of them
4) Identify all risk of your project and constantly looking for their evolution along the entire lifecycle of your project … don’t forget risk! In Project Management luck and bad luck doesn’t exist (more or less) … there are mainly identified and unidentified risks! Identifying risks you can build your luck by yourself ;)
5) Don’t forget to collect lessons learned after each project … you cannot improve your ability to manage your future projects without lessons learned from your past projects ;)
This is my favourite answer from an old colleague, Gunveer Mahandru:
1. Show leadership (strong vision, direction. take risks, manage them)
2. Develop a backbone (back up what you say, don't wilt and wimp)
3. Work the team dynamic (manage the form/storm/norm/perform phases)
4. Engage stakeholders and keep buy-in (politics with a small 'p')
5. Inject entrepreneurship (excite, motivate, innovate)
Short, sharp and very effective...
Here are a few more useful little project tips:
Derive a burndown chart and use it to generate momentum and track progress.
- use Mike Cohn's estimation technique, planning poker.
- derive the ordered stack and begin plotting this over the time line.
- You may want to include checkpoints (or iterations) in the plan. (Step towards Agile)
- use these checkpoints as opportunities to deliver value (no matter how small) and plot your position on the burndown chart.
- Remove products from the stack when considered 'done'.
- 'Done' = when someone other than the developer (preferably the recipient) says it is... i.e. it meets the predetermined acceptance criteria.
In fact, I'd heartily recommend you watch Mike's YouTube clips on Agile Estimation: Part 1 and Part 2
A short note on lightweight reporting:
Agree a '5 minute emergency channel' with the sponsor... As you become aware of an issue which significantly affects the project, present what you know to the sponsor (no interpretation) along with a few proposed next steps. Aim to present and get a decision within 5 minutes... Even if the next step is to have a longer meeting. This way you keep your sponsor in touch.