The software industry is riddled with implementation failures – some public such as the NHS IT system and others that we will have experienced quietly (or not so quietly) in our internal work place systems. What makes it so difficult? After 24 years (gulp) in and around software I’ve come to conclude that it is the challenge of the mix of big picture and small detail. Let me see if I can explain how Bowland, after many years, has settled on a way of working that we feel works well.
When thinking about a system, initially we all have a picture of what we want. Usually, quite quickly, the IT people want the detail. They want to know what happens when every button is pressed, what should happen in a certain field. As a layperson it is easy to immediately feel overwhelmed and inadequate and unable to communicate what you want. In providing IT with the detail required you can somehow feel the point of the system can be lost. I’ve spent a lot of my career on both sides of that debate – I’ve been a coder frustrated with the lack of clarity of the requirement and I’ve been a user frustrated with a technically clever solution that doesn’t quite do what I want.
The IT industry has recognised this – trying to move from rigid, long, detailed functional specifications to a more “agile” approach that produces the minimum required and then iteratively builds upon it. In Bowland we have tried many things – some succesful, some less so.
Over time we have finally settled on a process that we find works brilliantly with our HR audience and the wider user base. We draw the requirement, we mock-up the requirement, and then we build.
So, first we draw the screens, This is easy and cheap to do and it gives a visual big picture. It allows us to see whether we have a shared picture of what we are trying to achieve. We heep drawing it until we are all happy. This may be as simple as seeing a new appraisal form laid out but by seeing it everyone gets to understand what is going to happen. The drawings can be shared amongst key users and feedback gathered widely.
Then we mock-up the system. Technically we create the HTML. The screens are built and will look exactly as they will when finished…we also storyboard it a little so that you can interact a little and see how each bit hangs together. It gives everyone a feel for how the system will be. It is a little more expensive than drawing but we are still pretty flexible on changes. The detail starts to come out naturally as we discuss what is on screen, what needs to happen, which words should be changed, etc.
And then finally we build the code. Because of the infrastructure we have in place this is often a small task for us – a bit of tailoring of the existing functionality. But we have the ability to do something new to reflect the unique nature of this particular client.
We then test – by this stage there is no question on whether this is what was wanted as over each iteration nothing significant has changed … it just evolved.
Essentially we are iteratating, each stage building on the other. By seeing the solution early and feeling the solution at an early stage the big picture is built in and the details emerge as we go.
You’d think this would take longer but it doesn’t – it’s quicker because fewer mistakes are made, there are no nasty surprises, and the iterating is done in tools (drawing) that are meant for the task.
We have recently implemented a surge of performance review/360 systems in this way and we are very pleased with the results.
Often when writing we talk about best practice in performance review or 360, or discuss the wider context of performance appraisal and development. Software plays a big role in ensuring the process is quiet and simple and its probably worth reminding everyone that we do have software underneath our consulting support!