Case study: The Met Office

“Organisations should not necessarily be scared of killing off projects. Some will fail and should fail because priorities change and there are only finite resources,” says Nigel Reed, head of technology delivery at the Met Office.

The secret is to pull the plug on such initiatives in a controlled way and ensure that any cull takes place as early in the lifecycle as possible to limit further unnecessary expenditure.

“It is not about ensuring that each project succeeds for the sake of it. Sometimes you have to accept that it is not the right thing to do and if you identify that early enough, you don’t start proportioning blame or thinking ‘I’ve started so I’ll finish’,” says Reed.

The Met Office is now 30 months into a three-year technology change programme to improve its performance in delivering software development projects.

Development is a core function of the IT department as the business relies heavily on its applications to deliver weather and climate-related information services to its customers.

As a result, the organisation decided that in order to optimise the function, it needed to restructure in three key areas. The first related to people and involved reorganising the team into three customer-facing groups, each with a project manager.

One group focused on commercial, a second on government and a third on infrastructure customers, whereas in the past, staff had been categorised in terms of skills. Another key strand here was to professionalise personal development and training.

The second activity entailed revamping and standardising the Met Office’s software delivery processes, while the third saw it introduce Borland’s Open Application Lifecycle Management tools to help define, manage and measure those processes.

“You have to deal with all three simultaneously. You can have the best people in the world, but if they don’t have the right tools and processes, it will limit what they can achieve. But processes and tools also influence what people do so you have to get them all right,” says Reed.

A key objective was to bring the management of requirements to the centre of the software development process, says Reed. “A classic way that things go wrong is because requirements haven’t been managed properly, often because they haven’t really been understood,” he says.

IT might make a commitment to the business without knowing if it can deliver on time or not and then fail to communicate what is happening.

“If you don’t talk for the project lifetime, by the time something goes wrong, it’s too late. It is important to build a relationship based on mutual trust,” says Reed.

Like this story? Spread the news by clicking below:

 del.icio.us     Digg this     reddit!