Best practice as a term is in fact a misnomer. The optimal practices that are employed within a particular PMO will be dependent on the scope and objectives of the PMO, the level of project and programme management maturity and consistency across the organisation, and the tools mandated and/or available to the PMO, project and programme managers.
For example, where an organisation or even just an individual programme, has a full implementation of an Enterprise Project Management system such as Microsoft Project Server, and they use the tool for task level planning, resource allocation and time sheeting, optimal processes will revolve around the tool, its in-built processes, features and reporting capabilities. However, if separate plans are maintained (often in differing tools or to differing standards), other methods used to log risks, issues, assumption and dependencies, and time recording not mandated, then the optimal processes will be quite different.
You could say that best practice mandates the implementation of a full EPM system, but capabilities vary across even the market leaders resulting in different actual practices. What is more, not all organisations have the financial ability, need or desire to adopt such an approach. Even more lack the maturity or organisational capability to adopt and mandate the proper use of such a system. Trying to impose such a best practice solution would therefore be bound to fail.
So what this post sets out to look at a range of good or best practices that would fit a variety of system, cultural maturity and organisational capability combinations. Whilst best practice may vary depending on circumstances, there are some over-arching principles that apply across the board when deciding on your approach to and implementation of a PMO.
Key PMO principles
The more senior the sponsorship and the more supported and reiterated that is down through the management layers, the more effective your PMO will be. If nobody wants you and nobody is prepared to back you, pack up and move on elsewhere. Otherwise your working life will be miserable and unrewarding.
Clear terms of reference
To be successful any PMO needs to have clear terms of reference. These should set out the objectives the PMO is going to achieve and a clear scope. They should also set out the mandate given by the sponsors, the role the PMO has in project and programme delivery and the relationship between the PMO and the projects and programme(s) within its remit, including behavioural expectations. A properly defined and constituted PMO is an integral part of successful project and programme delivery and this needs to be recognised and proactively supported by all other project participants. It should not be acceptable for project teams to ignore PMO deadlines or deliver sub-standard products and expect the PMO to correct the faults. These sorts of behavioural ‘rules’ should be documented and agreed across the project and/or programme as part of a charter or creed which all participants sign up to.
Single source of the truth
For all data relating to the project and/or programme, there should only be one source of the agreed, approved, current version. Whether this is the due date for a milestone, the percentage complete for a task, the current status of a risk, the current RAG of a project or the approved version of a document, there should only be one owner and one place to go to get that latest published view. Yes, there will be drafts, updates in progress, differing opinions in discussion or multiple comments being fed back. But once agreed, updated, incorporated and published, there is only 1 owner and 1 version. The truth.
Data is entered once and re-used
Closely allied to the single source principle, is the principle that data should only be entered once and then reused under the control and direction of the owner. Manual re-entry of the same information into different systems should be avoid wherever possible. Where data is reformatted for presentational purposes – say from a SharePoint list into a PowerPoint presentation, the temptation to edit should be resisted. Depending on your systems infrastructure or environment, it may not always be possible to adhere to this principle. Corporate or regulatory requirements may force you to re-enter data. But you should minimise or eliminate where possible and stick to the ‘no editing’ rule.
All activities have a clear and valuable purpose
One of the biggest and most frequent charges brought against the PMO is one of unnecessary bureaucracy. To counter this, every process, activity and output of the PMO should have a clear rationale as to why it is performed or produced. If a report is produced but never read by anyone, stop producing it. If you are collecting metrics explain why and what use they are being put to. Another part of the project creed or charter should be that everyone has the right to challenge anything on the project. This is an area where that right should be constantly exercised.
Get the right people
It goes with out saying that you need the right people for any job to get it done properly. But who are the right people for the PMO? Too often I have seen administrators or process people channelled into the PMO without any thought as to whether they are really any good at the role. In my experience there are certain traits that you need to look for to find really good PMO people. What are they:
- People people. That’s to say people that get on with other people. The PMO is always interacting with a wide range of stakeholders from project managers, project team members to sponsors and senior executives. The PMO team need to be able to speak to them all and get long with them all.
- Inquisitive people. The best PMO people are those that want to know more about the projects they support and the business those projects are delivering to. They take the time and trouble to get to understand the basics of the business and projects. That way they can tell when a risk makes sense or status report is gobbledegook.
- Detail people. People that have an eye for and attention to detail. The natural inclination to cross check references and spot dependences. The desire and professionalism to ensure consistency of layout and format. The inclination to run one last spellcheck. Shoddy is, as shoddy delivers, but not on this team!
- Qualified by experience and driven to learn, not resting on a certificate. Don’t get me wrong, qualifications are good and training to achieve them can help build your knowledge. But qualifications don’t make you a good PMO person. Putting them into practice does!
- Former or ‘resting’ project and programme managers. These make some of the best PMO leads. They know what it takes to deliver so know what the PM should or shouldn’t be doing. They know when to apply pressure and when to back off. They know what is value added and what is bureaucracy. They know when someone is trying to pull a fast one!
So, my argument is that if you adopt these key PMO principles as they best fit your organisation, the end result will be a set of best practices tailored specifically to your organisation. Not bad eh! Let me know what you think by leaving a comment.
After 20+ years running projects and programmes Allen has spent the last 5 years building, running and fixing PMOs (with the odd bit of project recovery thrown in there), so if you need a hand with your PMO problems give him a call on 01483 387062 and arrange a free, no obligation telephone consultation.