This was a regional competition, not the national one, but I am really pleased to report that the IPS project I managed for the last 3+ years won the PMI-SAC Business & IT “Project of the Year” award at last week’s PMI Gala and Conference.

The Integrated Pipeline Solution (IPS) manages about a third of Canada’s heavy oil transportation. While you may think tracking oil moving through a pipeline sounds pretty simple, like anything, the devil is in the details. Husky has about 30,000km of pipeline and complications such as blending products, forecasting production, optimizing capacity, custody transfers, billing, accruals, etc and the fact that billions of dollars are at stake mean that the rules, regulations and complexity adds up pretty quickly.

We had an amazing team and engaged, savvy business representatives – these were the real reasons for success, not the methods we followed. However, there were lots of challenges too and our approach helped us here. We “inherited” the project $1.1M behind budget after an outsourced vendor doubled their estimate following a year of analysis. They were asked to leave and the project was brought in-house, but with no adjustment to the original budget.

Agile methods excel at fixed budget projects providing the sponsor is willing to flex functionality. This is what occurred and we actually ended up delivering more functionality that originally scoped within the initial budget.

The PMI Awards assess projects on a variety of criteria and asks for submissions in a specific 10 page format. I will spare you the 10 page version and instead list a quick summary of the benefits:

• Enhanced Business and IT relations – against a backdrop of varying degrees of business / IT co-operation, the project stood out as an example of completing a long and challenging project through close cooperation. The stakeholders were practical and pragmatic about decision making and priorities. The increased trust built on this project has been useful for launching subsequent projects.

• Business Benefits – the business benefits of creating a single, integrated pipeline system are numerous. User configurable calculations, better data quality, faster calculation speeds, and improved reporting are just some of the tangible benefits.

• Improved resilience and support – The IPS project moved the Pipeline group from a set of unsupported, legacy systems to a new platform of state of the art .Net and Oracle 11g solutions. User developed spreadsheets with questionable data integrity were also replaced.

• Project Objectives met – The project delivered all the requested functionality within the defined project schedule. This functionality was delivered to a very high level of quality, and while there have been some changes and minor fixes since April 2010, there have been no production outages. The project finished just under the $6.1M budget frozen in 2006 despite having to incorporate late breaking business changes in 2009.

Does your PMO Produce Multiple Obstacles for your project or Promote Many Opportunities for success?

A Project Management Office (PMO) can act as an obstacle to agile projects. This can take the form of asking for inappropriate planning detail by not recognizing the likelihood of changes; or asking for conformance to templates that are not even used on an agile project. For these reasons PMOs often get a bad reputation on agile teams, but it need not be that way, they can also add tremendous support and be a great help.

First let’s look at what a PMO actually does (or what they should do, since implementations and services vary). In the September 2010 issue of the Project Management Journal (the PMI’s research publication) there was a nice definition of PMO roles:

1.    Monitor and control project performance
2.    Develop and implement standard methodologies, processes, and tools
3.    Develop the competency of project personnel, including training and mentoring
4.    Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5.    Strategic management, including participation in strategic planning and benefits management
6.    Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7.    Management of customer interfaces 
8.    Recruit, select, and evaluate project managers
9.    Execute specialized tasks for project managers (e.g. preparation of schedulers)

This definition is good because it speaks to the “supporting” and “developing” roles a PMO should provide and moves beyond the “conformance” and “compliance checking” functions that many teams think of when they consider a PMO. However, when taken with a rigid, traditional-only view of how projects should be run, the PMO can lead to the Produce Multiple Obstacles issue:

Most people studied the Highway Code before taking their drivers licence exam. They had to learn (enough of) it to pass the exam, but then most likely did not reference it again, except until helping a friend study for the exam. Maps on the other hand, in printed paper form, or digital like GPS, are referenced much more frequently. Maps help us plan, track progress, and get to our destinations and we refer to them often when travelling anywhere new.

So, is the PMBOK Guide like the Highway Code or a map? Do we only read it to pass our PMP exam and then it gathers dust, maybe picked up again to lend to a friend? I think for many this is the case. Maybe for the first couple of projects, people may refer to it for guidance on how to undertake a task or process, but just a soon as people have a few real world examples they no longer refer to the guide.

Recently I have spent hours revisiting Chapter 6, the Time Management chapter as part of the PMBOK Guide v5 update. It has got me thinking about “who reads this stuff?” and I expect mainly people studying for the PMP exam. So maybe some jokes would be in order, to lighten up the learning experience? “We now break from 6.4 Estimate Activity Durations to tell you about the two project managers who walked into a bar…” but I somehow think this would not get past the review committees and proof readers.

Because many people find exams stressful and unpleasant we tend to lump things associated with that stressful experience as unpleasant also. If you pick up a Highway Code book from a dusty bookcase many years after passing your test and leaf through it, it can bring back emotions of learning about road signs and stopping distances. I wonder if this is why many people never return to the PMBOK Guide, too many stressful memories.

So could the PMBOK Guide be more like a map, a useful resource we return to time after time before planning our project journey? How would it need to change, maybe with some checklists and how-to steps? Yet, for an industry agnostic guide aiming to apply to construction projects, IT, and bio science, how could these guides apply beyond the most generic items?