Program Management Office - don't be afraid to deploy non-negotiables
I have built Program Management Offices (PMO) from scratch, and I have worked in established PMOs and I want to share a few things I have learned.
This post assumes that the PMO exists because the organization it serves believes it needs a PMO. This post does not cover ‘how do you convince leadership we need a PMO?”. I can do that in another post, but basically, you will need cold, hard data to do it…try showing the costs of NOT having a PMO.
This is a list of non-negotiables I recommend you adhere to, to increase your chances of realizing business results of any large initiative…technology implementation, merger, org redesign, new market penetration, strategic planning, etc.
Non-negotiables also work well in personal relationships, in families, and with just yourself. Identify your core values and know what your non-negotiables are, and decision-making becomes much easier!
Back to the few things I have learned (not an exhaustive list - I’m still learning):
No two PMOs are the same so you can’t apply one set of policies and procedures across them and be done – the success of any PMO depends entirely on the work environment / culture of the organization it serves. Because of this, the most successful PMO culture is one that is customizable and flexible…regardless of, or despite, the organization’s culture.
What does a customizable and flexible pmo culture look like?
Ironically, it starts with a few key (inflexible) non-negotiables:
If the PMO sits in IT, then business engagement and partnership with the PMO is a non-negotiable. The depth of that engagement may vary, but it MUST exist or the PMO is dead in the water.
If the PMO sits in operations or strategy, brilliant! Business engagement and partnership is still non-negotiable, but it is likely already there in some aspect. The business must own the business solutions. The PMO can advise and coach and implement – however the business must be accountable.
Have a few core processes that each project request must follow yet are tailorable for different sized projects (one for a division, one for a department, and one for the enterprise, for example). The complexity will be driven by the size and risk of the project (number of users it will impact, whether it impacts clients or other external stakeholders, complexity of integrations both business process and technical, and the make-up of the team – internal, 3rd party, clients…etc.). Complexity is not determined by dollar amount or budget alone.
Have some sort of gated process that engages the business in review and test of its own solution. Attendance at these gate meetings is mandatory – frequent delegation by business owners is a red flag and must be addressed. This process should include review of deliverables, budget, timeline, risks/issues and decisions and should include a sign off when complete. Ideally, you won’t move the project to the next gate until its predecessor is complete. Of course, you may have conditional approval but ultimately, each gate must be completed, approved and signed off.
The definition of success is a non-negotiable and must be determined by, and approved by, the business. What does success look like and how will it be measured? Staying on budget and on time does not suffice because it rarely happens on highly complex projects. The definition of success must be tied to business results.
Agree on the definition of ‘complete’ and ‘done’ so the project team and the business understand clearly when the project transfers to the business for sustainment. Too often projects last much longer than they should, driving up costs and delaying business results. Be clear on the transition (via a transition plan that is signed off) and get it done.
Just as important as the definition of complete, is the understanding of ongoing support. Define support up front, not during the transition, or you will miss the transition date, and you will be scrambling to get a support team in place. If you define support up front, you will realize that those in support roles need to be involved with the project early.
Do a post-mortem. Learn from each project. The business must attend – non-negotiable.
A nice-to-do is a pre-mortem. Once the objectives or definitions of success/timeline/resources are finalized (basically at the completion of the project charter) schedule a pre-mortem with the core team, including the business, and ask “We are now live and we are realizing the business results. What made this project successful?” Conversely you can ask, “what made this project a failure?” You can identify potential risks before you start.
Speaking of project charters, complete one and get it signed off – if you do it right, it contains the details of how the project will be executed including key milestones and dependencies, roles and responsibilities, risks and mitigations, assumptions, and the non-negotiables and is invaluable when differences of opinion surface, which they will.
And finally, build celebrations into the plan. Those projects that only celebrate if and when the project completes does a disservice to those employees we all know are holding down two jobs: their day job and their project job. (Although, I would argue that another non-negotiable is to identify those roles that must be dedicated to the project full time…)
Once the non-negotiables are set, feel free to customize other areas of the PMO policies and procedures, if you can capture meaningful data to find other opportunities to improve.
As I said, this list is not exhaustive, but you also must be careful how many non-negotiables you have. This will largely be driven by several factors including the organization culture and the credibility of the PMO. However, without some non-negotiables, too much is left to chance and the risk of not realizing business results becomes more of a reality.
