Project Portfolio Management

Articles related to Project Portfolio Management – doing the right projects

Impacts of traditional project funding models on agile delivery

In one of my previous articles I’d written about the need for change across multiple areas of an organization when undertaking an agile transformation. A key enterprise partner is the Finance department and the organization’s model for project funding will have significant influence over successful agile delivery.

Traditional project funding models are anchored to periodic (annual, semi-annual or quarterly) portfolio re-planning exercises which ingest updated forecasts for active investments and funding requests for new ones. The funding approach for an investment might be one time lump sum, split into two pieces (e.g. seed and remaining), or progressive through the use of funding tranches.

The challenge with all of these funding approaches is that they are based on an estimated cost of a project rather than the funding we wish to allocate to a product, capability or service.

So what challenges arise from a project-centric funding model?

It can result in higher risk, premature financial commitments.

Even in those cases where a funding tranche approach is used, the expectation is that the estimate for the current funding request will be at a high level of confidence. Now nothing prevents project teams from requesting a minimal amount of funding (e.g. one sprint’s worth), but in most cases, project funding approval processes are not lean enough to encourage such behavior. Given this, teams choose to make a funding commitment tied to a major milestone such as a release which might span multiple sprints worth of work. The danger in this is that unless we have a long lived team with predictable velocity working on a well understood product, the level of confidence in the work to be done and how complex that work is will drop the further out we go resulting in a team being at risk of a cost overrun.

Now you might say that agile delivery approaches can work when we fix cost and time and let scope or requirements be the variable. This is true, but how do we know how much to budget up-front to be confident in meeting business needs?

It can also encourage sloppy product management.

When product owners receive funding for a single project and don’t have any guarantees that they will receive funding for follow-on work, it is tempting to throw everything and the kitchen sink into the project backlog and to procrastinate on making tough prioritization decisions. With product-centric funding, the product owner can effectively prioritize the product backlog with confidence that there is available funding for incremental evolution of the product’s capabilities.

Moving from a project-based to a product-based funding model is a challenging people, process & technology change, but will be a powerful accelerator for your agile transformation.

 

 

 

Advertisements
Categories: Agile, Project Portfolio Management | Tags: , , | 1 Comment

Does your PMO hinder or help your agile transformation?

An agile project management office might sound to some like an oxymoron, right?

This might be a reasonable assertion as many PMOs were first formed to provide oversight over a portfolio of projects and enforcing standards sounds like the antithesis to agility. But many successful PMOs have evolved beyond governance and control to helping their company reach higher levels of organizational project management maturity, and increasing agility should be complementary and not contradictory to this pursuit.

There are many ways in which PMOs can hamper progress towards greater agility including:

  • Enforcing standards over principles
  • Continuing to apply traditional funding models and prerequisites to agile investments
  • Obsessing over vanity metrics such as velocity or time to market rather than business value delivered or shipped features utilized
  • Evangelizing agile from the ivory tower instead of actively engaging with and supporting teams
  • Failing to inspect and adapt

So what can a PMO do to actively support an agile transformation?

  • Collecting chronic impediments from agile teams, curating and prioritizing them, and championing their elimination by the appropriate senior leaders
  • Having the courage to say “NO!” when a given context is not suitable for using an adaptive approach
  • Advocating for funding to incent early adopters to try new delivery approaches
  • Encouraging staff who possess the right expertise, behaviors and attitude to train and take on Agile Lead/Scrum Master or Product Owner roles with coaching support
  • Examining their own operational processes and leaning them out as much as possible
  • Shifting portfolio reporting from being a manual, onerous process to the automated consumption of information radiators
  • Migrating from an artifact-centric delivery approach to an information-centric model
  • Transforming heavy, gate-based governance to a metrics-driven, exception-based process
  • Working actively with functional managers, procurement, HR and other key stakeholders to change their project engagement models to be more support of adaptive approaches
  • Helping portfolio governance committees to make their investment selection, evaluation and prioritization processes more agile

An agile transformation provides the leadership of a PMO with a good opportunity to review their charter and service catalog – are these still relevant, and if not, what can be changed to ensure that the PMO is not identified as common impediment by agile teams!

 

 

 

 

 

 

Categories: Agile, Facilitating Organization Change, Project Management, Project Portfolio Management | Tags: , , , , | 2 Comments

Why setup virtual PMOs and when should PM templates be standardized?

Dear reader, don’t be alarmed – this IS your regularly scheduled article!

I’d like to thank Sante Vergini for providing the inspiration for the first topic and the second one had been a splinter in my mind so I couldn’t wait till next week to write about it.

Why oh why would someone set up a virtual PMO?

In one of my past articles, I had written about the challenges of establishing and running virtual PMOs. I’m not referring to a PMO which is staffed by geographically distributed team members but rather one which has not been established as a staffed organizational entity. Virtual PMOs might be setup as a single individual spending a portion of their time delivering PMO services or a group of project management practitioners who commit some time to this.

Given that it might be difficult for a virtual entity to elevate organizational PM capability, mature project portfolio management practices or provide a meaningful delivery oversight function, why would organizations choose to go this way?

The most simple use case is when the leadership of a small functional organization-oriented company starts to realize the need to standardize or improve the company’s project management approach. The first person who starts to apply some project management discipline might be drafted into being a PMO of one.

Funding constraints could be another reason to establish a virtual PMO. The majority of PMOs are cost centers and the ROI for the investment in setting up and running a PMO might take a few years. If leadership recognizes the need to do something to improve project outcomes but funding is limited, one approach is to establish a community of PM practice and empower that group to design and implement change on a best effort basis.

Once bitten, twice shy might be another driver. Leadership teams which have lived through the fallout of a failed PMO might try to avoid the sunk costs of Groundhog Day syndrome by going the virtual route. Of course, if they haven’t addressed the root causes for why the original PMO failed, they shouldn’t expect miracles from a virtual approach.

A standard should be the means to a goal and not a goal unto itself

Repeatability is a good guideline when elevating organizational project management capability. But standardizing how information is captured needs to be carefully weighed against the benefits of tailoring and customization.

So what are some criteria which would justify standardizing a specific project management template?

If the information within it is going to be ingested by some automation to feed other processes then standardizing the format will improve processing efficiency and quality. If the consumers of the completed template are working with multiple project teams, there is a benefit in providing them with a consistent look and feel.

But if these conditions are not present, the emphasis should be on the quality of the content and not on the format or structure. If there is still a perceived benefit in standardization, effort should be invested in developing a template which can be easily populated, easily updated and presents what is required by its consumers in a minimally sufficient manner.

Anything more is waste.

 

 

 

Categories: Process Peeves, Project Management, Project Portfolio Management | Tags: , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: