A project management framework defines how projects of various sizes and complexity should be managed within an organisation so that all projects are managed in a consistent way. Not all projects will require every part of the framework to the same degree, for instance small or non-complex projects may not require such detailed processes but the processes they do use will be common to all projects.
A PM framework is usually compatible with an organisation’s chosen project management methodology and provides the practical tools to actually do the work required for the project.
There are various parts to a PM framework:
A document defining the overall objective of the project, which can be initially used to determine whether a project should go ahead and later assess the level of success or failure of the project.
The Business Case
Describes the main objective of the project, the reasoning behind why it should be done, who it will affect, how long it will take, what it will cost and what risks are involved. For larger projects the Business Case should also analyse the potential benefits and outline any dependencies on other projects.
Details of how the project will be carried out, any perceived risks that might occur and how the business benefits will be measured.
Identification of the members of the team(s), team leaders (if necessary), project manager and project sponsors.
A statement of all the necessary tasks with the timescale and resources required to complete each. Related tasks are grouped to enable high-level reporting. Inter-dependencies within the project and with other projects, milestones and budget tracking are shown. A Gantt chart is commonly used for this purpose, for which a variety of software tools and templates are available.
A list of anticipated risks with the chance of each occurring and the potential impact on the whole project. A specification of how the risks are being actively managed should also be included in the risk log.
This should be an ongoing task from the very beginning of the project not left until the end to ensure the lessons are remembered and recorded accurately.
Any project large enough to generate numbers of issues that cannot be dealt with immediately will need a log to manage them. The log should describe the issue, how it affects the project, who reported it, any associated risks and the status.
A communication plan is essential to ensure everyone involved in the project is aware of what information will be communicated, how, at what frequency and to whom. Different people involved in the project will need different levels of detail in their reports, for instance, a key stakeholder may require frequent, detailed status reports which may not be necessary for the project sponsor.
The outcome of project meetings should be documented and communicated to all those involved in the project. They do not always require actionable items to be raised but can also be information sharing opportunities and provide project team members with the chance to share and discuss ideas.
Formal reports should provide a summary of progress and show the current status of the project, highlighting any overdue tasks and the current budget position. The Issues Log and Risk Log should accompany the main report.
Is the project complete and has it satisfied the defined success criteria and met the business objectives? Also document recommendations for any additional tasks to be implemented in the future and ensure the final deliverable is formally handed over to an operational team and that support arrangements are in place.
Once a new deliverable has been in use for some time it is useful to review it to determine if it does, in practise, meet the business objectives and deliver the anticipated business benefits. It is also an opportunity to make further recommendations for improvement.