We were asked to help with the way that our Computing Services department prioritises and schedules software development. As in many organisations. development is a considerable bottleneck, for all the usual reasons:
- Inadequate and unclear specifications
- unforeseen programming complications
- technology issues
- poor estimation
- unrealistic deadlines
- feature creep
- inadequate testing
- specialised skillsets
- etc. etc.
These problems are deeply ingrained in the development process, leading to frustration on all sides: for customers, because they can never rely on dates provided by developers and because there is no visibility for them into the development process until something goes badly wrong; for developers, because they have a burden of work which can never be completed, and because they have to juggle multiple competing requirements and rapidly changing priorities; and for managers because they are not in a position to understand the impact of new work and re-prioritisation.
At our planning meeting with the team we decided on the following problem statement:
- CiCS don’t have confidence that we’re doing the right work in the right order
- CiCS cannot say how long and how much resource work will take
- CiCS cannot determine the impact of new work on work in progress
Our task was to guide the team towards a process which could provide answers for these problems - not easy as the instant response from developers is usually “we can develop a system to do that”.
As the week of the process improvement event unfolded a great many worries were uncovered. We were concerned that there were so many issues and so much variation in developers’ working practices that agreement on the problem - never mind the solution - was unlikely. However, three major breakthroughs turned this sense of despair around:
- The necessity of keeping work schedules up-to-date so that the current picture of work is mostly correct
- And the understanding that a great deal can be achieved with postit notes and charts stuck on the wall
With this achieved the team produced logical and sensible process maps for project and non-project work, which introduced gateways estimating resource requirements and associated stop points; matrix outlines for individual work schedules, and a series of actions for further work, in particular investigation of software which might automate some of the rescheduling effort and provide the visibility into development timelines required by management and customers.
A great deal of the outcomes are within the control of the development team, and their enthusiasm after the workshop has been marvellous to watch; however, prioritisation and re-prioritisation of big ticket items is a task for computing services service strategy board. We hope that they will grasp this opportunity for improving their ability to prioritise realistically and sensibly.