OnPoint, LLC

Why do we have a PMO?

As Rodney Dangerfield might say, “PMO managers get no respect.” Some have suggested that the initials may really stand for “Presents Many Obstacles” rather than Program Management Office. It is rare for a PMO (and it’s leader) to last more than three years. The PMO leaders I’ve met are smart, dedicated professionals and a PMO can add significant value to the business, so why is there such a high rate of frustration and failure?

The root cause is too much focus on means and not enough focus on ends. It’s very much like the thinking of many “agilists” as described in a blog elsewhere in this site: http://www.go-onpoint.com/blog/1033/lean-agile-means-vs-ends/

Here are a few PMO examples of ”means vs. ends” thinking:
  • Method over mission:  In the absence of a formal mission statement, PMO stakeholders and staff may assume that the PMO exists to support a specific project management methodology.   The methodology may be a means to support a mission, but it should not be the reason the PMO exists.
  • Consistency for the sake of consistency.  The business case, project approach and reporting standards for an enterprise-wide ERP rollout should not be imposed on a simple website upgrade initiative. The objective should be solid project outcomes rather than consistent artifacts
  • Measurement without meaning.   There are plenty of project management tools that can provide an excruciating level of detail about project performance, but these measures are only useful if they lead to an action or a decision by the project team or sponsor.  Otherwise, the details are at best a distraction and a source of wasted effort to collect, manage and report.
  • Process without purpose.   Maybe some of those phase gate reviews are not needed.  Did they result in any useful mid-course corrections for the project teams?  Or were they just a perfunctory step that diverted the attention of the project team and resulted in unnecessary delays?
Implementing PM standards and processes is often a task of a PMO, but that is not the purpose.  The purpose of a PMO should be to achieve a business goal such as solving a problem, improving the linkage of strategy with execution, improving utilization of resources or addressing compliance issues.

Organizing for Agility

When applying agile principles and practices at a team level, designing a project-based cross-functional team appears to be pretty straightforward. One “simply” finds some good developers, analysts and QA people, selects an appropriate product owner, assigns a scrum master, secures a co-located room and allows them to develop as a team. When organizations attempt agility at scale, cross-functional team design collides with existing organization structure, which is typically organized around function, activity, or knowledge base. How does one structure many (perhaps scores) of cross-functional teams without creating agile silos that reinforce inter-team dependencies and hand offs? Following are some general principles that can be applied to specific organizational contexts:

  • Employ a model of continuous delivery or flow of value instead rather than projects with distinct starts and stops
  • Create long-lasting teams organized around the business value rather than short-term teams organized around activity or projects
  • Seek to optimize the entire value system rather than ensuring that individual subject matter experts are 100% utilized

If you are contemplating an organization redesign, please review the book Agile IT Organization Design by Sriram Narayan, It provides analysis of factors that drive the need for organization design as well as a deep dive into organization design factors such as accountability, alignment, finance, staffing, tooling, metrics, and cultural norms. The book provides a great summary of commonly-accepted lean / agile principles and practices along with a few less-common ideas such as:

  • Those whose role is primarily planning (particularly project managers) should spend around 20% of their time actually doing work related to the product such as development and testing
  • Allowing teams to choose their own tools
  • Avoiding the use of standard templates for documents, reports and presentations
  • Making decisions based on written input rather than verbal discussions in meetings
  • Use of metrics to measure adaptability rather than those that measure predictability

Rethinking the PMO Mission in an Agile World

Here is a link to an Agilehood KC blog on re-thinking the mission of the PMO to support an agile transformation.




OnPoint, LLC