How to be Agile With a Fixed Scope Business Case? Part1 - Small Batch Funds Release

Many organisations I work with have existing business cases with fixed scope, time and cost expectations when they first decide to "go agile". The early conversations about "going agile" are generally prompted by either some misstep with a previous project or delivery issues with an inflight project. Agile is the magic answer that is going to radically improve the way Information Technology deliver projects. As the technology teams begin to "embrace change" and deliver "clean code", pressure begins to mount on the business processes that govern the project. Cries of "that's not very agile" are heard at every turn and the tension between the business and technology that had started to relax begins to increase again.

If you’re in middle management, you begin to feel trapped. You don't make the rules. Changing the corporate business case process is beyond your scope of influence. The project's governance board is holding you accountable for delivery of the project exactly as it is laid out in the business case and supporting business requirements document. So how do you escape the locked box and enable true business agility?

Start by understanding what is truly within your control. Often we have more control over our circumstances than we think. Even though the box is locked we already have some keys that might work. For many this may be the traditional change control process. Yes, really. It might actually be friend and not foe if used in the right way for the right reasons. Please bear with me while I explain...

One of the first times I was appointed as the Business Sponsor of a major strategic program of work, the appointment came with a completed Business Requirements Document (BRD). This document had been tirelessly compiled by a small project team over a period of about 12 months after which it had been endorsed by the program’s executive stakeholders. This document was also the artefact on which the business case and associated time and cost estimates were based. When I first inherited the program, I actually felt pretty good about the situation as I knew a lot of work by a lot of good people had gone into getting us to this point. Unfortunately, as is so often the case, all the good will and detailed requirements were not enough to stop this program rapidly heading south.

As it became clear to me that the project was struggling, I found that as the business owner of the project I had surprisingly little control over how the program’s funds were being spent.  I learnt that the “normal process”, which had been followed in this instance, allocated the entire IT component of the business case approved funds to IT at the beginning of the financial year. Week after week I attended program status meetings where I would hear about all the reasons things weren't going to plan and what was going to be done to try and solve these challenges. I could, and did, challenge the delivery team but in hindsight my impact was minimal. To add insult to injury,  I also had the "privilege" of providing a monthly status update to the governance board, where I got to explain why the project was spending to plan but not delivering to plan!

The next time I found myself in the role of business sponsor, I had also found agile. Two days of Agile Fundamentals training had taught me that that you can stop an agile project at any time, just ship what you have and don't fund the next sprint. That was great in theory but what do you do if you have already handed over a year’s worth of funding to the delivery organisation? As it turns out the process of transferring all the  funds for a given program to IT at the beginning of the financial year was a tradition but not actually a rule. With this new-found knowledge in hand, it was time to enlist the support of the bean counters in Finance.

The Finance folk seemed particularly interested in making sure the project adhered to the time/cost/scope in the business case and to put it bluntly, I think Agile scared them. Luckily Agile was flavour of the month and Finance were looking for a way to at least be seen to be supportive. With this in mind we pitched a change of approach. We, that is the business team, would govern the distribution of the programs funds to IT, one project and one release at a time. More specifically, we established a local change control board. Individual projects (subcomponents of the broader program), were given seed funding to “discover” the first release and would then be funded on a release by release basis.

The term “change control board” might not feel very agile, but in this case it was definitely a step forward. Through this process we achieved transparency. I could see how the money was being spent - not just in terms of “resources” but in actual outputs and outcomes. At one point I learned that every deployment was accompanied by tens of thousands of dollars of documentation, a pretty scary finding when you are striving for more frequent deployments! This new level of transparency helped me, as a business person, better understand the challenges faced by the delivery team. It enabled a new level of dialogue, where by both groups started to constructively debate and challenge the status quo. As time went by we delved into topics such as the makeup of the agile teams, the viability of offshoring, the cost of deployment, and what was the best place to invest our limited funds. Eventually I even began to feel I had some control over my destiny and the ability to help make the changes needed for the program to succeed.

If you are the business sponsor of a project, both you and your governance group are likely to feel very nervous as you take your first steps into the world of Agile. You share a responsibility to make the right fiscal decisions on behalf the organisation. You are used to having these decisions informed by formal documentation and the traditional stage gate processes. This approach may well be flawed but it is what you know and are used to working with. It may feel uncomfortable at first, but by moving to small batch funds release and achieving transparency, your sense of comfort will in due course exceed what you have experienced in the past. Even more importantly you will start to have true insight into what has historically been a black-box process that the IT people told you "you’re not technical enough to understand."

In closing, I would like to leave you with the words of Bjarte Bogsnes author of 'Implementing Beyond Budgeting':