OnPoint, LLC

Portfolio Management – Don’t lose your balance!

Below is a link to a Slide Share on my recent presentation at the 2016 Kansas City PMI Chapter PDD Days.

http://www.slideshare.net/RonMontgomery1/presentation-kcpmi-2016-pdd-days-portfolio-balance?qid=d7a8c5c8-25d4-4587-96ac-b21a3c779ad2&v=&b=&from_search=1

 

 

Flawed Governance Decisions = Weak Project Portfolios

Some years ago, Gerald Kendall and Steven Rollins wrote a book called, “Advanced Project Portfolio Management and the PMO – Multiplying ROI at Warp Speed” in which they noted four universal problems in project portfolio:

  1. “Too many active projects (often double what an organization should have)
  2. Wrong projects (projects that will not provide value to the organization)
  3. Projects not linked to strategic goals
  4. Unbalanced portfolio
    • Too much on the supply side, not enough on the market side
    • Too much development, not enough research
    • Too much short term, not enough long term
    • Not reflective of the organization’s most important assets, strategic resource value, or major product revenue opportunities…”
These problems are not new – they existed when the book was written over a dozen years ago and in my experience they are still common.  They are the result of flawed decision-making by the governance team.  But why are these governance decisions so poor?  Could it be that the materials that PMOs provide to support project decisions are inadequate?  Are the decisions being framed in project management jargon instead of business language?  Are so many data points provided that the executives can’t see the forest for the trees?  Do portfolio reports fail to provide a view of the interactions among projects?  If your project portfolio includes any (or all) of these four problems, it’s time to have a serious conversation with your governance team to understand what information they need to make better decisions.

Project Governance – It’s Okay to “Just say No”

According to a 2014 report “Project Smart” by The Standish Group (https://www.projectsmart.co.uk/white-papers/chaos-report.pdf), only 16.2% of projects were on-time & on-budget, while 52.7% were challenged, and 31.1% were impaired or cancelled.” Why were so many projects considered unsuccessful? Here are some of the top-ranked reasons:

  • Lack of executive support and user input or involvement
  • Unrealistic expectations
  • Technology incompetence and lack of resources

If a projects lack executive support, are unrealistic and the teams are inadequate, why were they approved?  Perhaps they were launched under the radar.   Maybe it was approved because a politically powerful executive thought it was a great idea, but lacked the time to provide executive sponsorship.  It’s possible that organizational cultures value boldness and eschew prudence.

The impact of these project failures extend throughout the organization.  Project team members feel responsible for the failure and morale takes a hit.  Talented leaders are blamed for the failures and some feel compelled to resign and others become overly risk-averse.

The solution is effective portfolio management and governance processes that result in more than just rubber-stamped “yes” decisions.  Portfolio management and governance must also result in “not yet” and even “no” decisions.

You are now entering the PPM Zone

Borrowing heavily from the Twilight Zone introduction, “There is a strange dimension beyond that which is known to project managers. It is a dimension as immense as sales and marketing and as endless as a program timeline. It is the middle ground between strategy and projects, between PowerPoints and Microsoft Project, and it lies between the pit of risk management and the pinnacle of executive briefings. This is the dimension of bewilderment. It is an area we call the PPM Zone.”

The Project Portfolio Management (PPM) zone is the place where project managers enter with Iron Triangles (scope, time, and cost), methodologies, and tools.  The project manager’s senior leadership team enters the PPM Zone with often-incomplete thoughts of vision, mission, and goals.  Project managers and senior leadership enter the PPM Zone each month, uncertain about why they are there.  An hour later, everyone leaves the PPM Zone frustrated that there was no clear “meeting of the minds.”

The PPM Zone should not be so mysterious.  After all, the goal of the PPM Zone should be to ensure that projects are chosen, planned, and executed in order to optimal business value as quickly as possible.  The PPM Zone should include “just enough” process and metrics to support decisions to fund, start, monitor and, if necessary, cancel projects based on their contribution to the success of the enterprise.

Those of us with extensive project management experience tend to view the PPM Zone from our own perspective rather than that of the executives making these decisions.  We over-emphasize project status reporting and under-emphasize strategic alignment.  We define complex formulas, collect extensive amounts of project data, and adhere to arcane PPM models, yet we overlook the human and political aspects of these decisions.  We need to move over to the senior leadership side of the table and understand what information they require to make project decisions and then continually refine our processes, tools and metrics accordingly.

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 Annual Budgeting Process – It Can Use Some Improvement

Over the years, I’ve had the opportunity to work with a wide range of managers and executives. Some had a very IT-centric education and background while others were decidedly non-technical. Most were command-and-control types while others viewed themselves as servant-leaders long before that description was popularized. The majority were calm and reasonable while blessedly few were screamers. If I were to assemble all of these people in a single location and ask their opinions they would not agree on much. Except for one thing – their dislike of the annual budgeting process. Since most 12-month budget cycles are started 3-4 months before the cycle begins, managers are asked to accurately predict what will happen in their organizations 14-16 months thereafter. They are asked to describe funding requirements for projects that have not yet been conceived and their performance will be judged by their adherence to a budget which is merely a wild guess. As organizations have attempted to apply agile principles at scale, managers have discovered that the annual budgeting process is not only disliked, it impedes organizational performance because:

      1. The extensive up-front effort to define and analyze project business cases yields little useful decision-making data and results in green-lighting projects with limited business value

        2. Project cost-overruns result in shifting funds from valuable early-stage projects in order to complete an over-budget project for which the business case is no longer valid

          3. It is difficult to reduce resources on approved projects to work on newly-identified opportunities with greater business value

So, how do we fix this dreadful process? Following are some sources of ideas for applying lean | agile principles to budgeting:

The Scaled Agile Framework (SAFe) proposes that, in lieu of project-based allocations, budgets should be based on funding long-standing teams organized around business value.

The Lean Startup book recommends Innovation Accounting for new products

The Lean Enterprise book advises the reader to eliminate project-based funding processes and separating funding decisions from the annual fiscal cycle

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

Lean | Agile Means vs. Ends

I’ll start this post with a comment by Dr. Alan Weiss:
“The entire point of bureaucracy is the triumph of means over ends. The results don’t matter, only that the rules are strictly followed.”

Do those of us focused on lean | agile practices run the risk of setting up new bureaucracies to replace the old waterfall bureaucracies? Do we pay too much attention to the means (stand-ups, Kanban boards, story-points) and not enough attention to the ends (business results)? Do we focus so much on following rules that we lose sight of the external business environment, strategy and objectives? Do we understand the “definition of done” for implementing lean | agile practices?

I raise these questions because I am starting to experience déjà vu. Nearly two decades ago, a friend worked at a company that went all in for Six Sigma. The Six Sigma initiative took on a life of its own. Strong leaders were pulled out of line functions, became Master Black Belts and sponsored projects that were only loosely aligned with the business strategy. My friend, who was an English major, was required to learn Mini-Tab in order to retain his executive position. The change management program took hold and people at all levels began using acronyms such as DMAIC, DMADV, CTQ and VOC in normal conversation. Those who resisted change either left the company or their careers were derailed. The Six Sigma effort became bureaucratic and “enforcers” ensured that all the Six Sigma rules were followed to the letter. When viewed from a change management perspective, the transformation was successful. Unfortunately, the business failed and it was eventually sold to a competitor. The problem was not Six Sigma per se. The problem was that Six Sigma became the end.

As we embark on efforts to scale lean | agile principles and practices, we need to remind ourselves that we are seeking to improve business outcomes and the principles and practices are merely an effective means toward that end.

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.

Next Page »

OnPoint, LLC