In one of my previous blogs I talked about how to get a project approved. In this blog I’ll talk about best practices in managing a project. You’ll notice there is lots of advice on the web on what to do and not to do in managing projects. The points below come from my experience of managing lots of projects: the good, the bad and the ugly.
First and foremost, you have to have a project plan. It will give milestones for the deliverable and it will give a project framework for the people who work on the project . It will also let the rest of the organization know what to expect, at what date. It is a good way of managing expectations. After all, you wouldn’t move households without having a plan, to know when to stop the paper, change hydro billing, etc. The same is true for projects. The plan needs to reflect the complexity of the project; moving may require only a one-page plan, but replacing the payroll will need many more.
Two more things about a project plans:
- it has to be objective and gain buy-in from the sponsors and the project team. The best way to achieve this is to have frequent team reviews of the plan.
- it is living document, changing regularly for larger projects . The project plan should be re-visited regularly to see if there needs to be changes due to scope, product changes or business alignment
We can’t control the world around us but we can control how we respond to how employees feel about a change http://t.co/TGVCRoq5Bp
— The Center for Appreciative Inquiry (@Center_for_AI) April 5, 2013
Speaking of scope, in my opinion the number 1 reason why projects fail is not managing scope properly. The scope of the project needs to be clear and specific in the project plan. Each time the scope is changed, the project plan needs to be reviewed and the impact of the change in scope on budget and timeline assessed and documented.
Look for my next blog on identifying risks and dependencies early. In the meantime, it’d be great to hear how you or your team managed project scope.
