How to write a 5 year plan (and why it doesn’t matter if no one follows it)
Businesses have long-term goals. Software products can live for decades. It’s hard to think on these timescales, much less plan for them.
I am technical lead for a social care contracts and finance system which has been in continuous development since 2005. It’s highly successful in its field, has a loyal customer base, and we want to make sure it’ll be around for at least another 10 years. For a year or so, we had been holding informal discussions about a “five year plan” for technical transformation, which generated a set of aspirations for the product’s future. Although we made some improvements here and there, there was insufficient progress and I felt we had no coherent plan of action. After a management presentation on our long-term business and technical aims, I decided to make it happen.
I reviewed our list of goals. They sounded great, but it wasn’t clear where to start. What should be scheduled next month to make progress? How much would it all cost? The strategy I came up with to bridge the gap between the present day and the aspirational future was – to quote from an internal document:
- Take each vague aspiration and try to write down clearer goals towards which we can aim on a five year timescale.
- Write down some specific, feasible goals we think could be achieved within 18 months of starting work, which would count as progress towards the five-year goals.
- Write down the initial concrete steps we need to take and which can be scheduled. This may divide into concrete development we more or less understand, and research and specification work in areas, which are less clear.
Some of this work was straightforward, e.g. I reviewed technical improvement tasks in our backlog to see if they aligned with our goals. Other areas were vaguer, involving general aims such as improving design and moving towards the web. To give an example, I identified a five-year goal of “up to date look and feel” and good cross platform support for our web components, with a more modest 18-month goal that one important web component should have a style guide and be fully compliant with it. The concrete step was simply to write the style guide!
Once I’d completed the same process across the whole range of aspirations, I tried to evaluate the cost of meeting the 18-month goals. Our backlog tasks could be roughly estimated. For the vaguer ambitions I could roughly cost the initial steps, but then had to make heroic assumptions about the follow-up work even on the 18-month timescale. I did not attempt to estimate beyond the 18-month horizon – my reasoning was that the initial velocity of work was a good proxy for the total cost.
I wrote up my analysis in human readable form. I kept the numerical working confined to appendices, and presented only a summary table of estimates – adjusted for overheads and converted to staffing levels. The total at the bottom was shocking: it implied a 50% increase in the team size, something no one had envisaged at the start of this process. And yet, this was my best estimate of the cost of making serious progress towards what were our stated goals.
So, I circulated my write up to the directors and product owners, and called a half-day meeting to discuss. We talked through the issues, stared at the costs, and decided to focus on proactive core maintenance, with many of the grander transformational aspirations shelved. Over the next few months, two key things happened. We formed a new “Internal Ops” team to execute the core maintenance strategy. We also revised our business strategy – we now aim where possible to develop all new features as semi-independent components, which can be integrated in different combinations with each other, with the core product, and with partner products.
Taken together this twin approach will provide stability and continuity to our customer base, but also enable us to innovate in the development of new components without technical constraints from the older product. The sense of progress and the exposure to new technologies this permits will also be good for our developers.
In the longest of long terms – almost certainly beyond the 5-year horizon – our new components will become sufficiently powerful and comprehensive that we no longer need to add any new features to the core product, and we might eventually contemplate its total replacement.
In summary, I have shown that – however imperfectly – it is possible to plan & cost work on multi-year timescales. It is inevitable that any such plan will be superseded by events, and in my case two-thirds of the plan was shelved. But this doesn’t matter. The process of planning helped us to think about the future, to re-evaluate what we thought we wanted, and to change our minds.
About the author
Chris Henry has worked with Oxford Computer Consultants for nearly 15 years, on projects spanning local government, the EU, and the engineering sector. He joined the company knowing nothing but academic Fortran, picked up proper programming on the job, and is now Technical Lead for a development team of 20. He doesn’t get to code much these days, but software he has personally written is probably helping look after someone you know. And keeping your lights on.
