Local Developer Success Story: British Antarctic Survey

May 25, 2011 by kirsty-pitkin

Local developer uses trust to overcome requirements disconnect, creating a system which saves time and helps staff to make smarter decisions.

In this DevCSI case study, Michelle Pauli explores the successful work of the local developer who created the British Antarctic Survey SOUTH Travel Database…

The problem space

Staff from the British Antarctic Survey (BAS) make more than 400 journeys a year to and from the Antarctic. The BAS administration team were managing and tracking staff movements through an access database that was laborious, didn’t tie into any other systems and did not keep the history of previous years. Only the core admin team were able to access the information so staff had to be notified of travel plans by letter or email, and the admin team were also dealing with a time-consuming number of travel queries by phone.

What the developer did

Developer Dave Connor was embedded in the team and implemented a rapid, iterative workflow which began with a detailed requirements analysis. This was followed by small chunkable pieces of the system being brought online week to week and tested out with the users with an instant feedback loop.

“We could mock things up really quickly and they could trial it against the old system and see how it would work,” explains Connor. “It introduced an element of trust between the developer and the user, a sense that ‘you are invested in my concerns’ as opposed to ‘here’s a new thing, use it’.”

The result was a new web-based system that allows all staff to view the travel reports, that retains information history year-to-year and is integrated into the organisation’s finance and personnel system.

The project was well-documented with one set of documentation aimed at any newly hired developer who may be thrown in at the deep end and told to fix a bug; and a basic guide for administrators detailing how to set up log-ins and processes.

Passenger Movements on RRS James Clark Ross

Tangible business benefits

The time-saving benefits of the new system have enabled administration staff to branch out into new areas of work, allowing them to shift their focus from dealing with mundane requests to planning and improvements.

“It also helps others to know when people will be around, and not in the Antarctic as they can now look online and check itineraries instead of pestering other people for information. It’s one of the great benefits that this data is now freely available to everyone in the organisation,” says Ellen Bazeley-White, Archives Manager at BAS.

In addition, the availability of information about flight and other travel costs from previous years has aided with financial planning.

“At any point in year the team can make a quick judgement on how much they spent on flights based on past knowledge and current estimates. This means that administrators don’t have to go through a layer of bureaucracy to get running figures and it has increased their ability to make smarter decisions during the year or planning for the next year,” explains Connor.

Why use a local developer?

BAS had made two failed attempts to change the system using external companies before finding success by using local development. In both previous cases the project faltered because of a disconnect at the requirements stage – external companies did not have the insider knowledge to ask the right questions to capture all the crucial small details about the exceptions to the norm, the “what ifs”.

“It’s not that the requirements for sending people to the Antarctic are so unique, I think it’s that they are so similar to existing travel systems that the exceptions in travel we absolutely required were often skipped or poorly implemented or misinterpreted by outside developers,” comments Connor.

BAS found that an embedded local developer had the flexibility to respond to the little problems that crop up, and they could also suggest changes to the user’s workflow through understanding the goals they were trying to accomplish.

An alternative to outsourcing the whole project would have been to hire in a consultant through a contracting company and then embed them. While this removes some of the risks of self-hiring as the quality of these consultants is generally high, it would have been a more expensive route and left BAS with little control over the hiring process.

“By recruiting our local developer ourselves we found Dave who is easy to talk to and can communicate the development process really well – we can discover that through an interview. It is much easier for us when the developer is approachable and can use day-to-day language,” explains Ellen Bazeley-White.