Sometimes Agile Isn’t

Agile practices were around well before 2001, when the Agile Software Development Manifesto was proclaimed as a different and better way of delivering software solutions. Now the term is everywhere – agile management, agile teams, agile organizations, agile technology… That overuse of the term can obscure the real value of the associated mindset and practices and turn the term into just another buzzword, pushed by opportunistic consultants and desperate managers. Sometimes agile isn’t!

In this post, we’ll look at one such case where the buzzword dominated the decision. We’ll see 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 mishmash 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 for 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 previous attempts to solve this problem, senior IT staff proposed the use of agile techniques to allow phased delivery that could be incrementally built 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 the 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.

So, if you find yourself in a similar situation, put these points on your list of practices to consider. And remember, include Project Pre-Check’s three building blocks right up front so you too can be a Great Leader, 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.

Drew Davison is the owner and principal consultant at Davison Consulting. He is the developer of Project Pre-Check, an innovative framework for launching and delivering change effectively. He is 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. Drew works with his clients to build and sustain the engaged key stakeholder group needed to envisage, launch and deliver change successfully. He can be reached at drew.davison@projectprecheck.com.