I’m a big fan of the user-centred agile approach to service delivery that is gradually being adopted by most government departments in the UK, and many other organisations too.
I mean – let’s turn those words around. Who would want a user-ignoring inflexible approach? Nobody!
But there’s one part of the canon that’s always bothered me: the distinction between ‘discovery’ and ‘live’. That’s because, years ago when I was a project manager, I learned that all projects start in the middle.
All projects start in the middle?
Unlike delivering a service, projects have a clear end point. Project managers are happy with that: we* start our planning with delivery, and work backwards to where we are now. Then we work out what we can change to try to match where we want to end with where we are now – that might be scope, delivery date, team membership, trying to organise some tasks in parallel, something else, or the project manager’s final solution: giving up and handing the job over to a different person.
*You can take the woman out of project management, but you can’t take the project management out of the woman. And I still maintain my membership of the Association for Project Management.
In contrast, I always found that the start of the project was at some indeterminate time in the past. No matter how early I thought I was joining the project, there was always previous work that I had to take account of.
- Joining when the contact was agreed? Tons of work has already been done. Even worse, scope and delivery date are probably already fixed.
- Joining at the bid stage? There’s a Request for Proposal or some other document that the client has worked on. Tons of work, lots of expectations.
- Joining before the Request for Proposal has been created? Someone, somewhere, has probably got a business case. Or an instruction from a stakeholder. Or a morass of requirements. Or an existing system that must be incorporated. Or some idea for why the existing system must not be incorporated.
(I’ll never forget the dour Scotsman in Glasgow who issued the firm instruction, at what I thought might in fact be the start of a project: “This has got to do the same as our existing system but also be nothing like it and much quicker”. So that’s another project that started in the middle. Nevertheless, we delivered according to that specification and they were surprised and delighted).
All services start in the middle, too. Only we call it ‘live’.
These days, I work on services, not projects. But now I believe that all services start in the middle too – that is, they always start in ‘live’. There’s no such thing as ‘before’ a service. Or ‘when you start to deliver a service’.
If service delivery did start from (ahem) the start, then we wouldn’t have to think about these things:
- data migration
- training staff who are used to a different system
- legacy code, or legacy systems
- discovery
What’s that – discovery? Yes, I maintain that if there’s something out there to discover, that means that there is something that’s currently live. We are iterating in live. In order to do a ‘digital tranformation’, there must be something that exists at the moment. We are, as usual, starting in the middle. We can’t expect to create something new that is successful without making serious efforts to understand what has happened before.
Even something “completely new” starts in the middle
Years ago, I worked on a completely new service that was created by Rank Xerox UK to scan patents for the European Patent Office. I clearly recall visiting the completely empty factory space at their very large site in Mitcheldean, Gloucester that was set aside for the operators who would be located there, and the large empty room in Welwyn Garden City near to the office where we were developing the service from scratch: equipment, software, training materials, job design, quality control process – everything. Hugh Stabler later described the service in his paper Experiences with high-volume, high-accuracy document capture.
But in fact, we didn’t start from nothing. Rank Xerox was awarded the contract partly because they already had a contract to print the patents. The software team included the brilliant Andrzej Zydroń, who had worked on the printing software and brought a lot of knowledge of patents to our work. Our team also included an experienced Rank Xerox manager (whose name I regret that I have forgotten) who was already running the printing service, and he understood things like the need to strengthen the floor for the weight of paper storage – patents are heavy. He also knew about how to hire and interview new staff, and how to offer opportunities to his current staff who might want to transfer to the new service. Unusually, our small team – I think we were about eight people – included a full-time technical writer because our senior budget-holder knew that the need to write training materials and documentation might slow down our developers, so it was better to assign that work to someone who enjoyed writing. All of that knowledge and experience was absolutely essential to the success of the “completely new” service.
And helped me to learn lessons about how essential a rich variety of knowledge can be – and how as digital technologists, there are so many types of knowledge that we don’t even know we need until we look for what already exists with an open mind.
Let’s stop thinking we start at the start
I’m quite tired of looking at diagrams that show service delivery “beginning” with discovery. Or pre-discovery. Or, (did I really see this or was it just a bad dream?) a slide that I’m convinced that I saw recently that had three steps to prepare for pre-discovery (surely not?).
Let’s try to understand that we always, always start with live. Something is out there that is going to change. Or someone out there has knowledge of what happens now that will be vital for the “new” service (which is really a change from the existing service). Let’s make better efforts to understand live.