Tuesday, 13 March 2012 16:33

From the Sponsor's Desk - Sometimes Agile Isn’t

Written by

FEATUREMAR14thIn my last post, Tenacity Can Achieve Miracles, we saw the results that were achieved through the tenacity and commitment by one Quality Assurance manager to turn around a company’s sagging fortunes and renew client confidence in their products and services.

In this post, we’ll look at the damage that can result when pre-conceptions about the business problem and how to fix it aren’t examined and challenged. Thanks to reader E.B. for the details on this case.

The Situation

This financial services organization had attempted to replace the system used for the production of statements for its clients and their employees on three occasions over the last ten years. The statement runs produced over one million statements each quarter consuming annual processing costs of about $200,000. The applications were a mish mash of legacy technology and code that was very difficult to change and problematic when it came to ensuring the necessary quality levels. Previous statement projects usually took up to twelve months to implement and cost hundreds of thousands of dollars.

 The Goal

 The business wanted to replace these applications with a new system that would be easier to use, more responsive, and maintain service level agreements. At the same time the business wanted to provide support for a variety of ad hoc queries for administrative and sales staffs and their clients. The new solution had to provide the ability to replicate exactly previously produced client and employee statements at any point in the future. In addition, annual production costs shouldn’t exceed $250,000.

The Project

The reporting project was commissioned to tackle both the production of statements and support ad hoc queries through the creation of a data warehouse.

The VP of the business unit was the project’s sponsor. Two project managers were appointed, one from the business and one from IT. Selection of new technology to support the data warehouse and the ad hoc queries was seen as a priority so a technology assessment stream was launched to expedite that process. In addition, because of the difficulties that had been experienced in the last three attempts to solve this problem, senior IT staff proposed the use of agile techniques to allow phased delivery that could be incrementally built upon to achieve the final state. The IT PM, a recent hire, was selected in part because he had previous agile experience. An early project development delivery charter was created and it did highlight the Statement versus Ad hoc reporting differences.

The new technology was selected, installed and vendor staff was brought in to help train the in house staff and help build the application. Concurrently agile training was selected and conducted under the tutelage of an agile leader. In short order the project team was up to 18 IT and contract staff and burning through $200,000 per month. A data warehouse proof of concept was launched in the fourth month to bring all the disparate elements together – production statement, ad hoc queries, new technology and agile.

The Results

 The ad hoc aspect suffered because the business hadn’t really thought through what it was they wanted to do. The early identification of Statement versus Ad hoc delivery differences was never resolved. The agile implementation suffered because the team wasn’t able to identify and tackle implementable pieces. Much of the work reverted to traditional development practices the majority of the staff were used to. Finally, a production statement pilot revealed that annual processing costs would be in excess of $ 2 million using the new technology versus $200,000 for the existing system. After another two months of analysis and head scratching, the project was cancelled with over $ 1 million in staff and contractor costs down the drain.

How a Great PM Would Have Helped

 This project is a sad example of how not to implement change effectively. A great PM would have done a number of things differently. For example:

  • Look at the reasons for the failure of the previous three attempts to deliver an improved environment to support production statements and ad hoc queries. In all three cases, the project wasn’t really a top business priority. Business support eroded as the demand for more decisions escalated. Getting clear direction on the Project Pre-Check Change Domain Decision Areas, like burning platform, opportunities, goals, worth, requirements, benefits, assumptions, etc. would have revealed the clarity of the business vision as well as the commitment of the stakeholders.

One of the challenges this project experienced was getting the required business resource. Apparently the business had reorganized about the time the project launched and the reorganization consumed the business management time that was required for the project to progress. Déjà vu all over again!

This project was actually four different changes grouped together: product statements, a data warehouse with ad hoc query capability, new technology and agile. One of the Decision Areas in the Change Domain mentioned above is assumptions. If the PM had explored the assumptions around each one and the four together, I expect a very different structure and approach to the problem would have been used.

  • One of the sources of ongoing friction between the business and IT was the use of the data warehouse for the generation of production statements. IT believed the profiles of the two functions were sufficiently different to warrant unique solutions. The business disagreed. Had the PM considered the Volumes, Mix & Peaks Decision Area in the Project Pre-Check Change Domain, he would have discovered vastly different profiles, well known for the production statements, yet to be determined for the ad hoc queries. If he had committed business stakeholders, the accumulated evidence would have helped them see the light.
  • There was no risk analysis or plan, an interesting oversight for a project that had failed three times previously. A risk plan would have considered the challenges posed by running the four changes together, would have looked at the impact of the business reorganization on project resourcing and would have addressed the challenges associated with implementing and operating a new technology component. The resulting mitigation strategies may have helped avoid project failure and could have guided the PM to a different approach. 

Every time I run into a project like this, I get angry. It’s so easy to use a framework like Project Pre-Check to make sure the PM and other stakeholders address factors that have proven essential to project success. It’s an almost painless exercise, it takes little time and it cements the stakeholders’ commitment to the endeavor. If you don’t want to use Project Pre-Check, build your own checklist of vital best practices, use it on every project and shape it to reflect your own learnings. Please! Your stakeholders will thank you. 

There was a silver lining to this project. The PM facilitated a project post mortem and developed a lessons learned log covering many of the points above. The internal team was moved largely intact to a project in another business unit where they have been able to apply their learnings and leverage the benefits of agile techniques.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Change Agent, and your sponsor’s best friend.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll have a go.

Don't forget to leave your comments below.


Read 8114 times
Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at drew.davison@projectprecheck.com

© ProjectTimes.com 2017

macgregor logo white web