Everyone´s starting point is different, but we can all agree you need a steady foundation when building anything and your PMO´s framework is no exception. It should be clear and shared by the entire organization. We’ll guide you through planning, implementing and disseminating your PMO. Whether you´re familiar with ITM Platform or not, our examples are a ¨one-size-fits-all¨. This design assists in highlighting situations that you may encounter along the way and applicable to most cases.
So, let´s dive in to the 6 essential elements you need to consider in order launch your PMO framework.
Download the eBook: How to set up a sustainable PMO with ITM Platform
1. Project types
First, decide what kind of projects you’re running; the type of project will also govern its lifespan.
As you implement (or relaunch) the PMO it’s a good moment to reflect on the variety of projects in the portfolio and possibly take time to redesign them. A PMO can also manage operations if they consist of specific tasks that are assigned to different teams. Managing projects and operations together from the PMO is especially useful when the resources and clients involved are the same.
This is the case with software development projects, or products that require maintenance by the same team that developed the original project. The Kanban methodology is useful for managing services because it offers an organized structure in which you can see the status of tasks at a glance. More importantly it allows you to limit the flow of work according to your resources.
The service concept is also incorporated into ITM Platform – you can create entities for the sole purpose of managing operations.
2. Workflows
A workflow allows you to map out all the possible statuses that a project goes through. Make sure it is based on the business’s procedures – don’t be tempted to invent statuses that do not reflect the reality of the company.
The workflow is defined by two main components:
- The changing status of a project
For example, we can decide that when the status of a project is designated as ‘draft’ that can only be changed to ‘started’ or ‘discarded’. - The conditions for changing the status and who is authorized to grant permission for that change.
Make the conditions for changing statuses as simple as possible; you can always increase the complexity later, and you may even find that there is no need to do so.
A word of advice: do not replace the work of defining organizational procedures with a workflow. The workflow should be a conveyor belt, not a control mechanism.
3. Priorities
It's very easy to configure the different degrees of priority, but the work of a PMO starts way before this: you have to agree what each priority means. It should be extremely clear what “high priority” or “medium priority” means. Obviously, medium is higher than high, but does that mean that you shouldn’t start with the medium priority ones until the high priority ones are finished? Should we put twice as many resources into high priority versus medium priority?
The PMO should know the actions associated with each priority and make this clear to everyone else so that the organization makes homogenous decisions.
4. Risks
Good project management is in essence risk management and a PMO ensures that this function happens consistently throughout the decision-making process.
The formula impact x probability = exposure level is only useful if it leads to consistent decisions by project managers.
Identifying risks is a tricky business as it’s often subjective and affected by personal bias. The PMO standardizes procedures using criteria and tools approved by the board, backed by the project managers.
5. Waterfall or agile methodologies?
Both of these methodologies can co-exist in one integrated portfolio as long as the PMO establishes criteria to decide on the appropriate methodology for each project.
Some organizations make all decisions – waterfall or agile – based on politics. This kind of decision making can lead to patchy results.
If your organization decides on agile methodologies for all projects – while at the same time demanding medium and long-term deadlines – the methodology probably hasn't been chosen on the basis of solid criteria.
To determine which methodology to use the PMO should ask:
- Is the result of the project relatively uncertain or are we well aware of the outcomes?
- Is the project subject to deadlines which govern the date of deliverables or is a short-term vision of all the tasks enough?
- Are sponsors and clients willing to have continual involvement in the project without knowing the final outcome? Or will they happy to be less involved and just accept the final outcome?
If your organization decides on agile methodologies for all projects – while at the same time demanding medium and long-term deadlines – the methodology probably hasn’t been chosen based on solid criteria.
6. Project templates
One of the major benefits of a PMO is that it allows you to capitalize on knowledge accumulated from previous projects. Be sure to put mechanisms in place to recover the lessons that have been learned. That way the know how isn’t lost when the project ends but can be applied later on.
Creating project-specific templates means the contents can be re-used in future projects. Another benefit of templates is to re-use frequently used structures just by changing dates and figures. It’s similar to those cooking programs when the chef says ‘here’s one I prepared earlier’.
A good PMO ensures that the knowledge stays within an organization, and not only at the level of the individuals involved.
When evaluating different tools, soft virtues such as the ability to adapt to different situations are often overlooked.
