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.

The Business Value of Speed

When we think of business value, we often think in terms of Return on Investment (ROI).  We may undertake a project with an eye toward reducing head count or otherwise leveraging the productivity of employees.  This view of business value has some inherent limitations.  The project costs often exceed the original budget, thus diminishing the ROI calculation. When the system is implemented, the anticipated headcount reductions are rarely taken.  Instead, the efforts of the employees are shifted to other activities which may or may not be more valuable.  More importantly, we are not increasing business value by more efficient work on products or services that our customers no longer want.

In today’s rapidly changing competitive landscape, speed can be far more valuable than squeezing the last ounce of productivity from administrative processes.  Consider the business value of launching a new software-based product six months earlier, responding to a customer question immediately rather than requiring a call back, or completing a customer project in a month instead of a year.

Should you adapt your metrics to focus on speed over mere efficiency?

 

Beware of Assumptions – They May Bite

Those of us who work with projects are always making assumptions.  We think about them briefly when writing the project charter, and they seem so reasonable at the time.  Certainly the customers will use the new product and will tell all their friends about it.  And there is no question that we will get our product to market faster than our competitors – even those competitors that are not currently on our radar.  So, we spend the next 3 months, 6 months or more working on the release only to find that our assumptions have bitten us in the … leg and make us look foolish. 

The agile frame work, with the reliance on the judgment of product owners, may help prove or disprove the assumptions before we launch the new product.  But product owners are proxies for the real customers in the market and may make incorrect assumptions about priorities and product features.   The customers are the ones who are most able to either prove or disprove our assumptions, but how do we engage them?

Eric Ries, who wrote the book, The Lean Start Up, proposes a systematic management process that calls for validating product strategy assumptions via the development of a “minimum viable product (MVP)” that can be used by potential customers very early in the product development process.  The metrics resulting from the use of the MVP provides input into decisions to either “pivot or persevere” with the original product strategy.  Here is a link to a website that discusses the book, the process, and the movement in support of lean product development http://theleanstartup.com.

If you are contemplating a new product or service and would prefer not to be bitten in your assumptions, it would be worthwhile to investigate the lean start up process.

Lean – Agile Program / Portfolio Management – What’s New?

As organizations begin to scale the use of lean-agile methods, they soon identify impediments in the area of program & portfolio management.  Following are three major categories of impediments, as summarized below:

  1. Funding - Project-level budgets established 12-15 months in advance cannot accurately predict agile funding requirements
  2. Capacity / Change Management – the flexibility of agile scoping and delivery will quickly overwhelm granular resource capacity plans
  3. Governance – Traditional metrics regarding (time, cost, quality) and phase-gate reviews do not accurately depict the health of agile projects, so more meaningful metrics are needed

Clearly, the movement toward  agile development will require some significant rethinking of program and portfolio management.  The Scaled Agile Framework (SAFe) provides a unique perspective on lean-agile program portfolio management.  Among other things, SAFe proposes a continuous flow of epics rather than discrete projects with specific start-end points.  It also proposes lightweight business cases and rolling wave planning among other changes.  Following is a link to a SAFe abstract on lean program portfolio management:

http://www.scaledagileframework.com/program-portfolio-management/

The SAFe abstract also references a case study on agile portfolio management from DTE Energy.  It can be viewed by clicking on the link below:

http://www.jctnet.us/Professional/Agile/CD-ThomasBaker-EstablishAgilePortfolio-Paper.pdf

 

 

 

Product Development – “Are we there yet?”

Those who sponsor software product development are frustrated by the time it takes to go from a great idea to the first trickle of revenue.  The months slowly pass and the sponsors adopt the refrain of children during a long road trip, asking “are we there yet?”  The product development team provides the parental response, “we’re almost there” and continues the usual product development practices.

The book, “The principles of Product Development Flow” by Donald G. Reinertsen, proposes that the sponsors are justified in their complaints that teams are taking a long and tortuous path to market.  Specifically, he points out that product developers focus too much on capacity utilization and not enough on cycle times.  As a result, the developers create large batches of work that result in large queues of work that are invisible to the product developer’s dashboards.

Reinertsen proposes a new flow-based product development framework, adapted from lean manufacturing, that seeks to measure and reduce the size of queues by reducing batch sizes and applying WIP limits. He proposes a prioritization method that takes into account cost of delay and the size of the job being scheduled.  Underlying this framework are some 175 principles that complement those of agile software development.  The book is quite deep and may require a couple of re-reads before the concepts settle in fully.

Per Reinertsen, this framework results in product development process improvements of 5 – 10 times, thus allowing product development teams to honestly tell their sponsors that, “we’re almost there.”

Life in the fast lane

You see them on the freeway, driving in the left lane, 5 feet behind the next car, staring at their cell phones and eating breakfast.  Their driving style limits their ability respond to changes in road conditions or to react to the actions of other drivers. They take an excessive amount of risk in order to save a couple of minutes. There is a good chance that, if they make it to the office safely, their driving style will carry over into their work.

Excessive speed is standard operating procedure in business today.  Staff levels have been cut but workloads have not, leaving no resources to maneuver around obstacles and pursue new opportunities.  There is an excess of activity and a shortage of results. As the Eagles (the band, not the football team) would say, life in the fast last will “surely make you lose your mind.”  Is it time to back off the throttle? Following are a few thoughts how to slow down and still improve performance.

  • Challenge the thinking behind deadlines. Is there a business need for to hit this particular date? Or is the date merely a means to create a sense of urgency?
  • Adjust your project portfolio to make sure it is complete and matches your capacity. It is common for people to work on projects that have not yet been identified, approved and prioritized. Even if they are working on approved projects, the sequence of those projects may result in bottlenecks while awaiting the availability of key subject matter experts. Try to stagger project start dates to minimize the risk of colliding priorities.
  • End a project and declare victory. When employing an agile project approach, business value is delivered incrementally according to priorities set by the business owner. After a point, the incremental business value for a given project may be lower than that of a competing project. You do not need to complete every deliverable on the backlog list. Take a look at the entire portfolio of projects and identify those that can be considered complete, then close them out and free up the resources for other work.

OnPoint, LLC