A critical component of IT governance is Project Portfolio Management (PPM). Effective portfolio management involves more than just collecting status reports of different projects at specific dates; it also involves projecting the delivery date, scope and cost that each project is trending towards and the impact of that projected outcome on the overall business. Without this latter capability, we may have project reporting, but we are not able to take true portfolio decisions – such as reallocating investment from one project to another, or cancelling underperforming projects – to maximise return on technology investment.

As with IT governance as a whole, many PPM efforts belie the fact that the discipline is still very much in its infancy. We see around us a number of practcies executed in the name of PPM that are in effect PPM anti-patterns.

Anti-Pattern: Managing by the Fuel Gauge

Traditional or Waterfall project planning defines a definitive path by which milestones of vastly different nature (requirements documentation, technical frameworks, user interface design, core functionality, testing activity and so forth) can be completed in an environment (team composition, team capability and requirements) projected to be static over the life of a project. This definitive path, defined to the granular “task” level in traditional project planning, creates a phase, task and subtask definition within the GL account code(s) that track spend against the project budget. When wed to the IT department’s time tracking system – which tracks effort to the subtask level – it is not uncommon for people to draw the mistaken conclusion that the total cost expended against the budgeted amount is representative of the percent complete we are to the overall project.

This is akin to “navigating the car by the fuel gauge” – the amount of time spent in each task is assumed to be an indicator of delivery progress because the plan itself is held out to be fact. Unfortunately, the environment is not static, and the different nature of project milestones makes the project prediction highly suspect. The car could be heading toward a completely different destination than originally envisioned, and in fact could be going in circles. This granular level of data does not translate into meaningful PPM information.

Anti-Pattern: Navigating through the Rear or Passenger Windows

Another approach to portfolio management is to survey every project at regular intervals to ascertain where it’s at relative to its original, deterministic plan, and for those “off course” reporting what will be necessary to restore project back to plan.

In its simplest form, this is akin to “navigating the car out the rear window.” Surveying projects to ascertain their overall percent complete is a backward looking approach that is easily – and not infrequently – gamed (e.g., how many projects quickly report “90% complete” and stay there for many weeks on end?) In its slightly more complex form – communicating the gap of current status to projected status and reporting a detailed set of deliveries a team is hoping to make by a particular date – is akin to “navigating the car out the passenger window.” It assumes that the original project plan itself is the sole determinant of business value, and is the basis of control of projects.

These are anti-patterns because they miss the point of PPM. The objective of portfolio management is to maximise return for the business, not maintain projects in a state of “on time and on budget.” Those time, scope and budget objectives, which might have been set months or even years ago, lose relevance with changing business conditions: market entrants and substitutes come and go, regulation changes frequently, and the sponsoring business itself changes constantly through M&A. These factors – not “on time and on budget” to an internally defined set of objectives – are what determine a maximum return on technology investment. In addition, this approach substitutes “sunk costs” for “percent of value delivered.” Sunk costs are irrelevant to business decisions; it is the remaining cost of completion relative to value achieved that matters.

Anti-Pattern: Breaking Every Law to Reach our Destination

An unintended consequence of PPM is the distortion of organisational priority. A culture of results can quickly morph into a culture of “results at any cost.” This, in turn, may mean that in the process of traveling to a destination, we commit multiple moving violations, burn excess fuel, and pollute excessively simply so that we appear to have “met our numbers.”

This is not typically considered part of PPM as much as it’s really a question of our overall IT governance. Still, it’s relevant to PPM: knowing that our investments are performing as they purport to be performing is important protection for our returns. To wit: through the 1990s Parmalat and Enron may have been strong performers in an equity portfolio, but gains were obliterated once shown to have been misrepresented all along. It must be remembered that project portfolio management relies on good governance and, in fact, exists as a component of it. Reaching our destination might make an initial delivery appear to be successful, but any returns achieved for reaching the destination might be completely obliterated by the cost of remediating the brownfield we created. Maximising return on technology investment is concerned with the total asset life, not just achieving a goal at a specific point in time.

Characteristics of a Pattern

We don’t yet – and should not expect to have – “GPS-style” navigation systems for individual projects that can feed our PPM. Because we cannot predict the future, any “map” is a fallacy. But we do have the tools by which we can "navigate through the front windshield," and do so without leaving destruction in our wake. We can do this if:

• We have fact-based manner by which to assess if a project can achieve its business goals in a time and for a cost acceptable to its business objectives.


• We have detailed visibility into the fact that energies are being directed toward high priority work.


• We have current, meaningful indicators of the completeness of the work being done – that we are working in such a way that we are maximising objectives under the circumstances, and that work declared to be “complete” is a matter of fact, and not opinion.

Agile project management is uniquely capable of bringing this about. Inclusive, independent statements of scope allow the path of system delivery to adjust to changes in priority, changes in capacity, changes in the understanding of requirements, and the experience of the team. Instead of relying on a prescriptive path, we have unadulterated transparency that exposes to everybody whether the best decisions relative to the business objectives are being taken given current information at the moment of decision.

These constructs provide the foundation for a fact-based, forward-looking PPM capability, because they enable informed “what if” scenario building across a portfolio of projects. Using these practices, we can develop meaningful, time-sensitive models, founded in fact, that allow us to forecast the impact of changes to team capacity (e.g., through turnover or reassignment), priority (through changing business environment) or scope (through expansion or better understanding) on our total portfolio. This isn't “project tracking” masquerading as “portfolio management;” it is the foundation of true portfolio management that maximises return on technology investment.

Labels: Agile Management, IT Governance

¶ 9:54 PM