Speed is one of the imperatives of our time. Every organisation I work with wants to be able to do things faster whether it’s speed to gain an advantage or the not so positive, but equally important, speed to close down a competitor’s advantage. Everyone wants to go faster. The need for speed is not a new phenomenon. For as long as I have been in the business world speed has always been an issue and I suspect it always will be. It was certainly an issue for me as a CIO.
When I first began measuring how long it took us to deliver the “average” project the data showed that it took us close to 300 days, nearly 10 months. That number was a best guess as the data we had was patchy with inconsistency and gaps all over the place. Even so the number explained why we were perceived as being slow. There were many reasons why it took that long and I’m sure some of them will be familiar to you. We were trying to do too much. At any point in time we had 50 + active projects and less than 30 people (internal and external) working on them. Every project was big. Our processes almost forced this to be the case, whether it was the sign off and approval process or the way we defined and documented requirements (if you want it, you better tell us now as this is likely our one chance ….). There were other issues as well, but you get the picture, we had to change.
I reported my findings to my lead team and shared the view that this wasn’t acceptable and we needed to change. I set the goal of 90 days average time to market and set about measuring this as being “the time it takes to move a validated idea through to go live”. The prevailing opinion was that it wasn’t possible, then, one of the team commented that the easiest way to improve time to market was to do smaller projects. It was music to my ears. Smaller projects, more frequent deliveries made sense to me as I held the belief that we were much more likely to be able to successfully deliver relatively smaller, less complex projects than we were to be able to deliver large complex projects(1). So off we set on the journey to 90 days.
It was fascinating to observe the journey and watch the change of thinking of the team. This was highlighted for me by one particular project. This project was a priority for our merchandise buyers and would support them with streamlined processes and improved information for product range decision making. The envisioned scope was large and our traditional approach to this would be to scope the work, sign off the business case and then proceed to deliver the solution. Given the scope of this project it would take 12 months to deliver. But something new happened which would set the scene for future projects. We still scoped the work as we always would but then things changed. The first change was the IT team and the merchandise team worked together to define the priorities within the project. Which were the most important changes that needed to be delivered and which relatively could they afford to wait for? Based on this definition they agreed that we would deliver the project in 4 distinct phases, each 90 days in duration starting with the most important changes first.
The project started and progressed well. The end of the quarter came and the first drop of functionality was delivered. Technically it went very well but the users hated it. Some fairly intense discussions followed. The conclusion that was reached at the end of that drop was that yes, what was delivered was what was asked for and had been signed off during the project, but now they were “using it in anger” it wasn’t what was needed. No one was particularly happy with this, however changes were agreed and drop two was adjusted accordingly.
Drop two progressed well and at the end of that quarter the adjusted second drop was delivered including the agreed changes to the initial functionality. The users loved it, this is what they wanted and they adopted it enthusiastically. The third drop began, including the catch up from the earlier adjustments. At the end of the third quarter we delivered all of the planned third drop. the users loved it and adopted it enthusiastically.
We then moved to begin the fourth drop and the business owner and sponsor came to us and said stop now!! We actually have everything we need, we are already delivering the benefits we wanted and had planned for and we are not sure the last drop will add a lot more value. Brilliant! By breaking the project into pieces what we had actually achieved was:
- We were over 30% under budget as we used no contingency
- We delivered benefits earlier than we ever had previously, even allowing for the miss step on the first rollout
- We were able to adjust mid stream to provide what the business needed (vs what they asked for)
- Technically we were three months early
- We delivered all the benefits plus some.
Not bad at all. This project cemented a change for our team – small and rapid is best. Oh and by the way, the project manager who plotted this out and delivered it, got herself a promotion.
(1) The 2015 Chaos report from the Standish Group looked at the proportion of software projects that were successfully delivered vs those that weren’t. Overall a mere 29% of projects were successful, a number that has barely changed over the past two decades. When you look at project success by size of project however the trend is stark. 62% of small projects are successful, it then drops rapidly to 21% for moderate and 9% for medium and 6% and 2% for large and grand projects. The conclusion seems clear to me. If you want to improve your project success rate, down size your projects and do predominantly small projects. If you have something large and complex to achieve, break it down and do it in small manageable chunks. Perhaps this is the true meaning of agile, no matter what methodology you use in the background.