Project Management Best Practices
What is a Best Practice?
ITIL defines a Best Practice as:
- The approach to an undertaking that has already been proved to be the most effective.
- It is derived from the practices of the most effective and successful people in the field.
A Good Practice is:
- What everybody is doing as it’s seen as complete, with no gaps, and often referred to as the “most appropriate”
- There is a continuous search for improvement
Best Practices become Good Practices becomes Commodity.
Project Management Best Practices are found in the PMBOK – “A Guide to the Project Management Body of Knowledge” published by the Project Management Institute (PMI).
There are five Project Management Process Groups:
- Initiating
- Planning
- Executing
- Monitoring and Controlling
- Closing
These are the phases of a project.
Within the Process Groups are nine Project Management Knowledge Areas:
- Project Integration Management
- Project Scope Management
- Project Time Management
- Project Cost Management
- Project Quality Management
- Project Human Resource Management
- Project Communication Management
- Project Risk Management
- Project Procurement Management
All of this is documented in the Project Management Plan. No a Microsoft Project Schedule is not a project plan, it can be a part of the project plan but in of itself it is not a project plan. I always run into confusion on this issue.
People look at these 5 process groups and 9 knowledge areas and think that this process is not appropriate for their project, perhaps because they have a small project or a short duration project. However this process is appropriate, this is where tailoring comes in.
Tailoring the Project Management Process
The project management process is a tool to help in the management of the project, not a set of handcuffs that forces you to generate useless documents.
Take a look at your project. If your project does not require any procurement then you don’t need a Project Procurement Management document, except for possibly a header or line in your project management plan that lists it, says N/A and gives a brief reason.
Likewise if you have a short project with a small team and you are all in the same building then your Project Communications Management Plan may be very brief. If you have remote or offshore teams then I expect you will have a very detailed Project Communications Management Plan.
You make the process work for you and your team not against you.