While conservation technology itself rapidly changes and evolves, the experience of failure is evergreen. 

To conclude the Technical Difficulties Editorial Series, we’ve chosen to once again share an article by John Cornell detailing the lessons learned from his challenges in conservation app development. Originally published to WILDLABS in 2017, app development - and conservation technology in general - has come a long way since we first shared this article, and yet the advice contained within it is still as relevant today as it was four years ago.

John Cornell’s article was, in fact, part of the inspiration for the Technical Difficulties Editorial Series, encouraging us to open up a wider conversation in the community about the value of failure. But the fact that we still must reassure people that it’s positive to share their stories of failure, and are often met with reluctance around discussing the topic, shows how far we have to go. 

This series has allowed us to open the dialogue about failure in conservation tech within our community, but the conversation is far from complete. Realistically, we suspect that the conversation has only just begun. Many of our conservation tech failures still happen behind closed doors, with their lessons learned only by team members and those we trust with our mistakes. And yet when the idea of sharing lessons learned from failure arises, most of us agree on the value of those experiences and are eager to learn from others. Clearly a disconnect still exists between our understanding of failure’s value, and our willingness to accept failure ourselves.

As we conclude this series, we hope that the WILDLABS community will continue to embrace these conversations. Just as collaborative projects within the community are a group effort, so is the discussion about failure - we are all working on this together, and we are all helping each other, one story at a time.

- Ellie Warren, Technical Difficulties Editor

Naturewatch: Lessons from the field of app development

By John Cornell 

In the frenzied rush to embrace the white-hot heat of emerging technologies and apply them effectively to our conservation work, we can sometimes misjudge things, make invalid assumptions or just plain get it wrong. Common sense tells us that introducing new ways of solving old problems will not always deliver the intended outcome first time around and that if it can go wrong, it probably will at some point.

When things do not go according to plan we are often reticent to share the failure with others. It’s not in our nature to draw attention to failure, as failure is not rewarded and often can be culturally or institutionally stigmatised. Instead, we are conditioned into promoting our “high five” moments of glory and success, to win and achieve our aims and goals. The difficult road leading to success and the hard won lessons learnt along the way are seldom shared, and unfortunately more typically forgotten. However, acknowledging and exploring failure as an important learning mechanism is something that we should strive for, embrace and share more often. The critically important seeds of lessons learned from failure can be used to grow the heady successes of the future, if we are brave enough to embrace this philosophy and expose our vulnerabilities, letting our failures see the light of day. 

With this in mind, I wanted to share with you some of the wisdom gained from the development and deployment of a pilot mobile application that ultimately did not deliver what was intended, but which did offer some valuable lessons and thus provide a different kind of success from the ashes of failure.

In 2013, funding was made available in my team for a Citizen Science project, something that would add value to our structured monitoring by augmenting information collected at BirdLife’s Important Bird and Biodiversity Areas (IBAs) through engagement with local volunteers. It all sounded very grassroots and sensible, and with mobile applications becoming ubiquitous and smartphones more common in developing countries, we decided to develop a mobile application for use by volunteers and Local Conservation Groups.

I formed a project team at BirdLife getting representation from Communications and Capacity Development Divisions and we began to meet with experts from the field of mobile app development and site monitoring and shape the concept of what we were trying to achieve. However, this took longer than anticipated and by the time we had anything that looked like a specification it was the spring of 2014.

Initial concepts for the app were based around the idea of not just dry and dusty data collection, but fun, engagement with visitors to sites, dog walkers, hikers...  in fact, anyone interested in being outdoors and contributing to a community sharing information about places important for nature. It was not another birding app either; there were already a ton of these and it was not our focus. One of the team came up with the idea that the app might provide a kind of “Trip Advisor” service but for IBAs, and this was met favourably by those offering our team advice on development. So it was decided: the app would try to both collect useful data for the organisation, engage the wider public and also be an information tool for site visitors – a perfect storm of potentially conflicting functionality.

There then followed a standard procurement model of advertising for development in the appropriate places, getting lots of applications and then choosing a suitable developer. By the end of February we were talking to a developer who had a great portfolio of clients and was also suggesting that they would deliver part of the work pro bono. As our development budget was on the meagre side (around £25K for a contractor), we jumped at the opportunity to get some of the work done for free.

After many meetings and sketch ups with the developer the concept was firmed up; a native mobile app was to be developed and made available in six piloting countries initially, with standalone functionality and available on iOS only. We sought to present basic information and maps to users about IBAs and trigger species, but with the functionality to accept photos, comments and threat information from users who after logging in would be able to see the posts of others and thus a social sharing network was also envisioned.

We decided to call the app Naturewatch and aimed it at Partners and their LCGs, but also had broader aspirations for its uptake. A year of development and testing followed with many iterations of functionality constrained by the technical skills of the developer and the demands of the project team to produce something of value to Partners and the Secretariat, but was this a bridge too far?

The long development time began to produce problems as it started to feel as if we were always waiting on something or other to be fixed, amended or figured out and soon came the dawning realisation that while the developer was a professional practice, they had little or no experience of producing an app with the kind of complex functionality (think spatial data, maps and social sharing), that we were seeking and so they were effectively learning on the job.

Lesson 1. Choose a contractor who can demonstrate that they can deliver the technical developments required for the project to succeed. Learning on the job is not an option!

As the development went on over many months and with many challenges, it also felt as if the developer began to lose interest, challenges were not always easily solved and at one point a complete re-think of how the maps would be displayed added more time to the development. We had regular meetings, often face to face (this was a big plus), but over time these too waned as expectations and deadlines for delivery came and went. The developer told us that because they were delivering this project in part pro-bono, that they did have to sometimes prioritise other work.

Lesson 2. Beware of strangers offering gifts, or in this case if offered pro bono services, be very clear about how these might affect delivery of the product – particularly intellectual property.

By early 2015 the project was out of time and out of money, we were a day late and a dollar short, but still with nothing to show and we had still to test the early version of the app, but soon realised that to do this properly would mean ground truthing in one of the pilot countries, as the UK was not one of the pilot locations and no data or sites were entered for the UK.

Lesson 3. Build-in the ability to test your product properly without having to get on an aeroplane to do it!

A member of the project team, the BirdLife Partner in country and some volunteers, tested the app in Cyprus and while the feedback was generally very positive, the one overarching issue was that not many people had Apple devices and so could not use the app, as it was only available on iOS. This was our first indication that a single platform app, built on iOS was going to be a real barrier to uptake, but our early market research into market share between Android, Apple and Windows devices and specific guidance from the developer had indicated that iOS would be a good single platform option.

Lesson 4. Build your app on multiple platforms and not just for one or risk excluding large numbers of potential users!

By now it was late spring 2015 and after a few iterations, some testing and some bug fixing the app was made available through the Apple Apps Store and various communications went out to Partners in the piloting countries about using and promoting Naturewatch.

We originally had allocated budget for Partners to use for promoting the app, but this was later withdrawn from all but one when the Partners seemed to not have a communications plan for the tool. Weeks went by and the data did not come flooding in, infact in communications with the Partners we heard the same story about the single platform issue and that there users did not have iPhones. In addition though there was something else going on. Because the development was done and directed in Cambridge, it soon became obvious that Partners viewed the tool as another product of the “good idea fairy” from Cambridge and not necessarily something that they either needed or had the capacity to support.

Lesson 5. Fully involve your Partners from the outset of a project if you want them to value, use and support the thing that you are building. If possible, use existing networks of users, or even better, build your desired functionality into an existing application so that you do not need to build constituency, but instead have a ready-made receptive audience!

By early May 2015 we had launched the app with a news story and promotional video available on the BirdLife main webpage.

The Cambridge BirdLife Secretariat was now actively pushing the app and there was also some evidence of Partner marketing activity, but not at the level needed to really kick it off. Adding in the continued concerns about the availability on a single platform, it felt like we were not going to achieve the uptake in the piloting countries that we had been working towards as a goal over the previous 24 months. After a few months it became clear that we had failed to get any significant uptake or use of the app by the Partners. A few individuals in a couple of the piloting countries were strongly promoting its use, and getting value from it, but with weak local promotion and barriers to uptake, it just foundered on the rocks of apathy and disinterest.

By now the developer was also losing interest in fixing bugs and supporting the app, as they realised that it was not going to form the basis of any future financial opportunities. Although we had talked to them about a phase 2 global version available on Android and iOS, the proposed development costs had somehow tripled from earlier discussions and we could not make the business case or find the additional funding required.

We looked around for the chance to develop the app elsewhere, possibly with another developer or a Partner with interest, skills and resources, but were told by the developer that they co-owned the IPR and would not allow any third-party development. They suggested selling us the rights to develop for a significant amount of money and the relationship at that point became quite strained. They argued that they had put in much more unpaid time than initially envisioned (the pro-bono element) and were looking to recover anything they could from selling the IPR for the code.

A few diplomatic phone calls to the developer and a friendly chat with the BirdLife legal adviser moved the situation on and in the end, the developer agreed to waive the IPR and allow use of the code for any future developments.

Lesson 6. Agree intellectual property rights with your developer before you sign any contract!

The sting in the tail became clear as the developer handed over the IPR, the code and the simple Content Management System (CMS) to manage the back- end of the app. They told us that they would be pulling the app from their servers – where it had been during the development and testing phase. They also told us that they were going to remove it from their Apple App Store account, and that we needed to create our own Apple account in order to keep it live. With no more funding for the project and dwindling interest from Partners and little support from Directors at the Secretariat, this was the final nail in the coffin for Naturewatch. With the possibility now removed to download and demonstrate the app to others, we were at the end of the road and frustrations within the project team saw its dissolution, as team members got busy with more productive work and drifted away.

Lesson 7. Have a legacy plan for any development to enable ongoing access to what you have put so much time and effort into!

Why the developer chose to pull the app so quickly can only be speculated at, but might have more to do with a perceived reputational risk (association with a non-stellar product) then it did cost or resource implications.

Lesson 8. External developers might have agendas that ultimately conflict with your business needs so remember - caveat emptor!

Between 2013 and 2015 the Naturewatch app was conceived, developed, tested and piloted in six countries globally before being deactivated. While it might be argued that we did successfully pilot a proof of concept app that delivered the functionality envisioned, we did not achieve a lasting legacy from the development, beyond gaining valuable insight into the landscape of app development for an international audience and all of the challenges and opportunities brought by such an undertaking.

Lesson 9. Have clear aims, goals and objectives in order to feedback in a quantifiable way to your funders on how much success or failure you had!

So we are now in mid 2017 and the need to better understand the conditions at IBAs/KBAs and engage with local audiences around these sites has not changed, if anything it has become a higher priority because of the development of the new standard on Key Biodiversity Areas, agreed with IUCN and others in late 2016.

One irony is that for a number of projects which BirdLife is now involved in, mobile applications are central to the concept of local engagement and data collection and reporting. However, instead of leading from the front with a viable, tested and functional version of the Naturewatch app, BirdLife can only bring the lessons learned from trying to go it alone and start from scratch. There is no Naturewatch 2 to bring to the table, nothing tangible on which we have built and extended our knowledge in this arena. While others have gained ground and understanding in this area of technology, BirdLife are still in the starting gate watching others take the lead.

Lesson 10. Without the encouragement, backing and understanding of what you are trying to achieve within your own organisation, by your organisation, it might be difficult to succeed.

So how does the story end? The story ends with a positive lesson and that is this. The arena of app development is fast-paced, ever changing and costly and trying to do something with limited budgets, staff and luke-warm interest was never going to end well, unless there was a great deal of right-place-right-time luck involved too.

So what is the legacy of this project for BirdLife and the individuals involved? In my mind it is the very lessons gleaned, the hard-won experience and knowledge of how things can go that we will take with us into future projects, It is that knowledge and experience that is ultimately worth far more than the code, because it can help us inform decisions around a multitude of other projects and situations and thus be far more useful than the “product.” In the ideal world that none of us inhabit, we would of course want both.

Download the Case Study

This case study is part of our Technical Difficulties Editorial Series. The full series will be available as a downloadable issue in January 2022. This case study is now available for download here. 

About the Authors

John Cornell, Natural Environment team lead, Greater Cambridge Shared Planning

At the time of writing, John Cornell was the Global Coordinator for Information Management at BirdLife International. He has spent two decades working in conservation, in roles typically focused  on the collection, management and presentation of biodiversity data and derived knowledge products and sits at the intersection between the disciplines of conservation biology and geography.

Ellie Warren, WILDLABS Coordinator

Ellie Warren creates content and supports the conservation technology community at WILDLABS through virtual events, fellowships, and community engagement. She currently works as WILDLABS Coordinator at World Wildlife Fund, and has a background in English, nonfiction writing, and screenwriting.