What’s the common factor between ITIL, Agile, MSP, TOGAF and the GDS framework? The answer is that each of them assumes that their person leads the conversation between the business and the work being done. The architect is ‘god’ in TOGAF world, the Programme Manager in MSP, the Digital Service Manager in GDS, etc. That’s fine, but creates a real risk of duplicated/missed effort, confusion and delay.
How can they all be the ‘best’?
Each method claims to be best (or at least good) practice for delivering IT-based services. How can they all be the ‘best’? Can they work together? Should they?
As you will have seen from our blog posts so far, the SFA has a fair history of delivering services using waterfall, with external suppliers. As a result, our ITIL and MSP skills are fairly well developed. We’ve also tailored their application to suit our purposes.
But of course, our purposes have now changed. We are insourcing our development, using agile techniques and building modern digital services in line with the GDS ways of working.
So far, our teams have been given maximum freedom to try things out. We don’t want to stifle the creativity that brings, but neither do we want confusion of responsibilities and repeating the same mistakes. But we’re hitting the point where the differing methods sometime pull in different directions.
The easy way out would be to say that one method trumps them all. I’m sure we all know places where that is the case. Indeed, MSP and ITIL used to dominate here. They’re good tools, but what is their place in our new insourced, iterative projects and services?
Why the tension?
My conclusion is that the tensions between the methods isn’t actually in the project, but outside it. The SFA Solution Design team are trying to execute a vision which is much bigger than any one project, so we’re imposing constraints. Our CTO needs to cut the cost of running the estate, so doesn’t want to use a new technology if there is something satisfactory already available. Our SROs need to understand the total time, cost and risk profiles of their programmes. Our Product Owners need to work across projects to discharge the total vision.
We’re still working this through
If you are skipping straight to this section to find a definitive answer to the issue, then you’ll be disappointed. Not because we don’t know how we’re solving it, but because our solution will be specific to us. We’re grabbing the best of each method and bringing them together into something which works for us, in our political, social, economic and technical context.
We’re starting with where we agree. We’re asking our people to:
- Be a part of the team – never a superhero
- Lead through service – “do the work”
- Seek to understand before being understood
- Above all deliver stakeholder value
- Drive the momentum and performance of the team
- Find solutions which meet the goals of all stakeholders
- Enable the next effort – current tactical efforts won’t impede future strategic directions
- Manage change and complexity
We’ll blog about our project organisation structures as we go along
We'll soon be advertising for Solution Architects to join my team. Keep an eye on our jobs pages for details.
1 comment
Comment by Julie posted on
Nice post Tim looking forward to the exploration