Agile Project Wins PMI Award
November 15, 2010
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.
- Innovative Solutions – Rather than hard coding the complex formulae or storing them in tables, building the calculation engine and expression language with visual editors and debuggers allows the business users to manage the expressions in the application. Several commercial calculation engines were evaluated, but found lacking in either flexibility or performance and so a solution developed in-house in collaboration with the math PhD SME and a developer highly skilled in assembly and IL programming.
- SR&ED Tax Credits – Developing the calculation engine, along with the new approaches for agile earned-value based reporting allowed Husky to successfully submit tax credit applications to the Scientific Research and Experimental Development (SR&ED) program worth millions of dollars—Husky’s first for an IT project and rare for an oil and gas company whose core competency is not software development.
- High Productivity Team - The last project release contained over 1,400 function points that were developed in one month by 6 developers. This is approximately 12 function points per developer per day, over three times the industry average and other releases had similar productivity. This was despite the domain being complex and requiring the math SME to define and test the linear programming, and iterative calculations being used.
- Positioned for Success – In addition to completing the project, the business and IT stakeholders were astute enough to plan for the future sustainment and updates to the system. Two sustainment developers were seconded to the project team for the last 18 months of development to learn the functionality, business domain and code base. Tool guidance, support tips, and support instructions have been documented in a technical wiki site leaving a legacy of tools, code, and approaches for future sustainability.
Of course, when submitting the write up you do not know who you will be up against that year. Apparently there was a bumper crop of submissions this year and the final three came down to our IPS project, a major EMS IT Transition project, and a 100 person project to implement a new diagnostic imaging system.
Due to a scheduling conflict, I was in Scottsdale teaching an Agile Project Management course for the PMI SeminarsWorld program during the awards ceremony, so I missed the event. After 3 years of involvement on the project this was unfortunate to say the least, but our IT manager and a business SME who had both worked much longer than myself on the project were there to receive the award so that was good.
The fact that an agile project won a PMI Project of the Year Award never came up. The 10 page submission asked for lots of details on risk management, planning, estimating, tracking, etc and the agile accounts for these processes obviously met the review panel criteria. My hope is that in 5-10 years time the term “agile project management” will not be talked about in our industry and instead we just have broader set of generally accepted project management tools at our disposal.
Anyway, I am super happy that we received this award, the project was a long struggle made worthwhile and rewarding by the great people involved.
(Attached below are a couple of slides used at the Awards Gala to summarize the project.)
Download IPS Overview-1
How do the activities described in your post match with the Agile Manifesto?
Were those Function Points calibrated according to IFPUG or COSMIC guidelines? If so, what was the attributable cause for a 6 standard deviation from the mean for this performance?
Posted by: Glen B Alleman | November 16, 2010 at 07:32 AM
Who is the author of this article, who was the team lead? Congratulations but would like to know who to congratulate!
Posted by: Tom Sheives | November 16, 2010 at 07:53 AM
Thanks, comparing the agile manifesto and agile principles to what we did on the project, I see no major gaps. The manifesto values and principle are rightly broad by definition, and we did everything they describe, but as a side effect to practical working rather than as a goal for our approach.
I counted the function points following IFPUG guidelines, in a previous role for IBM, I spent a while counting function points for IBM clients. I am not a big fan of function point counting because they require a high effort to count accurately and fail Dan Reintersen’s “Self generating, simple, and relevant to the end goal” definition of a good project metric. We tracked them on the project as part of making a business case for retaining team members during an attempt to downsize the team and replace some expensive resources with cheaper ones. Function points were understood by the IT management team and so I used them to illustrate how well the current team was performing and how a switch to market average rates and performance would likely be a net loss.
I think looking to the approach we used to get these great results might be missing the bigger picture. Barry Boehm’s COCOMO model rates the People Factors on projects as an effort factor of 33; it also rates “Processes and Tools” as a factor of 3. These numbers suggest having the best people on your team is an order of magnitude more important (33 vs 3) than the process or tools you happen use.
Over the last 16 years I have worked on many agile projects, some following agile guidelines very closely, others only loosely. What was special for me about this project was the calibre and cooperation exhibited by the team and the support from the business.
Posted by: Mike Griffiths | November 16, 2010 at 10:24 AM
Thanks for dropping by, I (Mike Griffiths) was the author and lead for the IPS team. Posting to this site used to insert a "posted by" name, but no longer appears to, the secrecy was not intended!
Posted by: Mike Griffiths | November 16, 2010 at 03:16 PM
I don't have any specific questions. I just wanted to offer a sincere congratulations.
It's nice to hear of your success story.
Again, congratulations to you and your team!
Posted by: Derekhuether | November 18, 2010 at 06:08 AM
Thanks, and thanks too for your offer to assist with the PMBOK 5 work.
Posted by: Mike Griffiths | November 18, 2010 at 07:35 AM
COSMIC not COCOMO. And which version of COCOMO are you using?
Posted by: Glen B Alleman | December 04, 2010 at 01:43 PM
As I said, the function points were counted based on IFPUG guidelines, not COSMIC, The COCOMO figures I discussed are from the COCOMO II model.
Posted by: Mike Griffiths | December 04, 2010 at 04:38 PM