In the summer of 2015 a large bank in Zürich started to prepare its 2016 budget. The type of work that was planned for 2016 included:
- keeping the lights on
- enhancements to existing products
- new products
- completely new strategies
for both the internet and intranet platforms.
Yet it became very clear that there were some very basic challenges. They included:
- No transparency over the entire book of work
- Product owners and project managers fighting for the same resources
- No common strategy to align to
- Work being crammed into 2016 through fear
- People shouting loudly
- A forlorn sense of hope because everyone knew there were not enough resources
- The “Book of Work” in its initial state, represented 20+m CHF of effort, yet only 6m was available (it later became 3.5m, but that is another story).
Sounds like a situation with no solution. Or at least with none that would satisfy people and deliver the desired results. We found one though – and this is how it worked:
The Solution’s 1st Step: Preparing the Foundations
To simply go into the workshop, without preparing the foundation for it, would have been disastrous. Remember you have people fighting for their own projects. Hence the room was full of ego and status (you might know this feeling).
We needed to undo that. A perfect way is to make the group aware of Patrick Lencioni’s “5 Dysfunctions of a Team”, and refer to it as the group works through the workshop. (If you don’t know this book at all, have a look at this summary.)
The workshop also required a strategy to be defined in advance. (This represented Dysfunction 5 “Inattention to Results”).
Finally, the team also needed to understand Agile Project phases. I.e. what resources are needed when a project is in “Foundations” and what is the rough T-Shirt size?
Once the strategy was defined, and the dysfunctions explained, and the phases of an Agile project understood, we could execute the workshop.
Step 2: The Actual Workshop
The process within the workshop was relatively straightforward and was undertaken as follows:
Two separate workshops were organised, one for the internet and one for the intranet. This was because the two were relatively independent from one another. We were lucky that they were in fact independent from a delivery point of view, too.
What was important was to give each of the product managers and project managers space to describe their project and its purpose and the autonomy to place it where they believed it should go.
Once they have done this the rest of the group could ask questions to help their understanding. There was no challenging of the positioning of the project or its purpose, at this moment-in-time – just clarification.
Sticky Notes and Visualization
Yet, what did we mean by positioning? Each project title was written onto a Post-it Note and placed onto a rather large wall. The wall we simply labelled across the bottom axis with Q3 and Q4 from 2015, Q1 Q2 from 2016, H2 from 2016, 2017 and 2018.
Horizontal swim-lanes could of course be used to group similar work – an idea was to have each swim-lane representing a different part of the strategy.
Notice how the granularity reduced the further ahead in time we look, matching Agile’s resistance to big up-front-analysis?
So the project manager would take his Post-It note and place it where he felt the project should start.
So for example Q1 2016.
Once all the projects had been placed onto the wall, we had transparency. Of the entire portfolio! Yay! This built trust in that nothing is being hidden (Dysfunction 1 “Absence of Trust”).
Challenging Each Project
One by one, each project was challenged. Everybody had to have the opportunity to challenge. The very first question was this: Does it align with the strategy? If not, throw it out.
Then they saw if the project could be started later or indeed earlier. A way to do this is to ask the questions “why” and “why now?” (a really tricky one by the way…takes some courage to ask).
Such questions resulted in some of the projects being pushed to 2017 and 2018 and therefore, out of the 2016 budget.
All of this helped the team to debate the 2016 plan and commit to it (Dysfunctions 2 “Fear of Conflict” & 3 “Lack of Commitment”)
As each project also has a T-shirt sizing it was then possible to judge how much time could be allocated in each quarter or half-year of 2016. Remember we did not need to examine those projects placed into 2017 or 2018.
But it was still not enough.
Understand Project Phases = Understanding Resources Required
At this stage we still did not know who was responsible or who was in fact involved or how many people, so we did not have an idea of cost.
So, as with most projects, there are phases in an Agile Project, such as: Pre-project feasibility, foundations, Agile time boxing, Implementation, Post project, Maintenance, Decommissioning.
So with each of the Post-It Notes on the wall it was necessary to tag the project according to the phase it was in. Therefore the individuals needed to understand what each of those phases meant. This was important as it indicated the resources needed for that project in that phase at that time. This included the Product Owner or Project Manager who was then accountable and the “go-to person”. (This covers dysfunction 2 “Avoidance of Accountability”).
So now we started to map the people to the projects for the year 2016. This was a relatively simple exercise. While following the DSDM methodology we knew what the roles are for each project and its phase.
Then it was a simple case of transferring the content of the wall to an Excel spreadsheet listing the roles and then the people fulfilling those roles after which it became quite easy to see where people were overloaded or where there were gaps.
A Word of Warning
Traditionally people will start to get very excited when they see gaps. It’s very tempting to rush off and try to claim extra resources or funding to fill those gaps. This is a little cynical, but this is driven by the culture of your power being determined by how many people work for you.
However, remember this was the summer of 2015 and as we’d identified a gap in Q2 2016 it is going to be highly likely that things will change so the resource may well become available or other resource needs take precedence.
3rd Step: The Result
We had a portfolio plan. We knew when projects, at a high-level would start or when a phase would end. We also therefore, knew who was involved or needed to be involved at that time. It was also of a high enough level of granularity that we could get an easy overview of resourcing and therefore cost.
And it was this cost that is then placed into the budget request.
In summary then, the bank needed to make sure the foundations were ready, including a strategy, to define the high-level goal.
The Workshop As Catalyst
The guided workshop finally led to the result the bank needed to reach their objectives: Keep the lights on, launching new products, implementing new strategies etc. Yet not only that, but in the process and thus on the path to the result, the workshop allowed:
- those responsible to place their project on the portfolio’s plan, to raise trust
- everyone to voice their opinion and challenge each project, to therefore build commitment through “safe” conflict
- the resources to be identified based on the phase the project were in
- identification of the true accountable individuals
- early identification of gaps in the resourcing, but not yet actioned.
- a budget request to be made that is thought-through, defendable and best of all, transparent for all
In short – Agile and planning – even on an annual basis can go hand in hand however, not on the basis of a traditional planning process.