This is a really, really hard question and undoubtedly it’s something that’s impossible to get right the first, second or even fifteenth time. Have a go, keep iterating, you’ll make progress.

Things that need to have been considered include stuff like:

where are all the requests coming in from? where do people come in at the sides etc

just what the hell is considered as BAU? this is one of the killers because I am 100% convinced that a large majority of ‘BAU’ requests that seem to get dealt with immediately because they are BAU, are in fact projects that ought to be properly prioritised. This is probably the single most difficult and important thing to sort and I have never ever managed to do it, so good luck

I think you need to have a completely open and transparent programme of work underway and pipeline of what’s next - that includes the BAU stuff that’s actually a project - so sensible conversations can be had with service areas so you can get them to be sensible about whether new requests take priority over what’s already known about

Really hard is getting the discovery bit right. When is discovery a thing in itself? Oftentimes you’ll get asked to do a particular thing, and the right response is that discovery needs to be done first to identify what the right thing to do is. But now you potentially have 2 bits of work - the discovery and then the thing you do to respond to the discovery. How do you then prioritise the discovery, because a result of the discovery could be that the thing itself is really high priority! Or it might not! Argh!

Governance set ups with multiple decision making bodies sound sensible but in practice they are rubbish. Inevitably the same people come to the design authority and to the governance board and to the architects meeting and the programme board. So just have one meeting when everything gets decided

To make this work you need a way to do the documentation that is lightweight but has everything on it that is still succinct enough that people might actually read it. Too often these things turn into essays where the service area spends 1000s of words justifying why this is the most important thing in the world to do. Instead, I am pretty sure it’s best to have something more structured, where a short outline of the problem to be solved by the service can then be augmented by specialists in IT, digital, data and design around what the options are, how long it might take, whether we have the skills in house and when they might be available, a senior level view from that service (or the directorate it belongs to) in terms of how urgent this particular thing really is. If this could be got down to a side or two of A4, it might just be that your decision making body can actually make a reasonably informed call on it

Regular high level engagement with directorates is vital I think. Take the current work programme and pipeline to a meeting with the director of each area on an every other month basis and just check in with them that these things all feel like the right priorities to be working on to help them get what they want done. So many times I have done this, and a director has been apoplectic that we are spending time doing project X which might be super important to that particular team, but which isn’t anywhere near as vital when a broader, more strategic view is taken

Going in hard on things like spend controls etc doesn’t tend to work in councils, because there is too much delegated authority to spend budgets and even with procurement, finance and so on bought in to what you want to do, services will always find a way. There’s also a real challenge when saying ‘no’ for whatever reason to a service because often IT and digital teams lack the credibility with services (for largely historic reasons) to do so - particularly when you lack the capacity and ability to provide a reasonable alternative. This is why relationship building is always where the real impact can be had. Get in there early, be a part of the conversations about the ideas before they get written down, and that will have a much bigger impact that the terms of reference of your IT governance board, the design of your project request form, or whatever!!!
Report abuse