Ollie Edwards, one of Edit’s Strategic Consulting Directors, specialising in Programme Delivery, describes how his experience with Edit has helped develop the way we create valued partnerships with our clients and deliver amazing work.
You don’t always arrive at a good place without passing through a few bad ones – in this blog I will ruminate on a few of these experiences and discuss how each one, which we’ve honestly and humbly reflected on, builds on our developing practices over time.
I have a default obstinate adherence to a belief that if you’re not “doing Agile” (yes, I know, that statement has masses of baggage) then your programme approach is somehow wrong. I’m conflicted that I have and I hear about engagements wanting us to predict the future, document solutions and activities up-front, or understand their entire data/systems landscape before spinning up a team to try to release a tiny bit of value into their hands as soon as possible.
So, in the spirit of empiricism, I have asked myself, am I wrong to reluctantly acquiesce to a client asking for this, all the while mumbling away to myself about it being so “old-school” or “bad practice”? Or worse, stick to my guns and say, it’s my way or the highway. Should I not just see it as another opportunity to deliver great “stuff” and get on with it?
I am not suggesting a gated, waterfall-esq approach to Programme Management in agencies is wrong or right. At Edit, we strive to work all our programmes and projects with an Agile mindset and approach. But sometimes, it feels like you’re faced with a sea of square holes and all you have in your hand is a round peg.
But is this the pegs’ fault, or the holes? Or is it the fault of the person holding the peg, looking down at the hole cursing its incompatible shape?
For the avoidance of ambiguity here: Edit is the ‘peg’ in this scenario. We believe we have a solid, albeit flexible way of delivering programmes in our organisation and the ‘hole’ we’re trying to fill is the client and their way of working, and their experiences which influence their risk tolerance, which has its own demands on programme controls etc.
Context… finally.
Beautiful but tragic, hindsight is our friend. I was part of a challenging bid opportunity recently. We were asked to provide a delivery approach which required a significant amount of time up front, to create a comprehensive and “locked” document defining the future from which all work would be traced back to. Looking back 10-12+ years ago in my time as a Project Manager, this was a pretty standard ask: write a functional spec; hand functional spec to tech team; tech team write a technical spec; play back; do what the technical spec said to do. Did the plan transpire as predicted? Does it ever really work out that way? No, because the world changed, the client changed, the business needs changed. Each project pivoted painfully throughout.
Using this as our reasoning, we politely and professionally refused to write an approach for the bid that offered this future-predicting document creation period. We posed a challenger response! Suggesting we take “thin-slithers” of Use Cases, Features, Value etc. and focus on these, incrementally dropping them into live (or close as we could) scenarios – a classic approach to most Agile delivery mechanisms, how could it possibly go wrong?
After receiving results and feedback, we ran a retro on the validity of our challenger approach to see whether we should have offered to change the shape of our peg to fit the hole, not the other way round. We also speculated on the need to now totally re-design our peg, so it has multiple shapes, without losing the essence of how Edit does delivery.
In analysing our approach to this opportunity, I still believe there was a compromise waiting to be uncovered and sold in. One where the hole and the peg may both be altered to accommodate each other’s needs. Perhaps we would have ended up with a hexagonal peg AND hole. Or perhaps I’m overthinking it.
Our approach was objectively sound (if you “do Agile”), but our appreciation of the client’s needs and experiences in other programmes was perhaps less so. Following on from this experience, I’ve shied away from labelling a programme approach as purely just “Agile”. We’re delivering value; we’re working collaboratively with teams who play a different game on a different pitch, but that should not stop us from working together to achieve the same goal. Edit’s operating principles have been developed and honed to represent just this: we Make it Simple, we focus on What Matters Most (to name just a few). A partnership requires collaboration and humility so setting these values out up front is, we firmly believe, the best way to build successful, long-term engagements.
Although unsuccessful, what we learned here provides context from which we at Edit can better collaborate and develop our relationships with all our existing clients and with those to come. Being a valued partner means being able to have difficult, challenging conversations, evolve collaboratively and at varying paces, and on occasion, even when approaches seem totally incompatible, find a shape within which we can all work.
