Guest post from John Dawes, Project Strategist and Co-Founder at Chesapeake Commons. Chesapeake Commons was founded in 2011 by members of the Chesapeake Bay Funders Network (CBFN) to encourage transparent data sharing for the development of sound and effective Bay restoration policy. John also worked with 2013 Technology Innovation Winner, Potomac Riverkeeper, to develop their winning Water Reporter app.
As a small team we are very fortunate to have a full roster of environmentally focused dev and mapping projects for the year, but when deadlines are tight it’s easy to let best practices fall by the wayside or go out the window all together. Chesapeake Commons and our partners at Viable Industries have been working to design, develop, and deploy open source tech solutions for just over three years. In that time span, three of the major take homes that we’ve learned as a team consist of the following:
Always question why the system is being built in the first place
Plan more so you can code less
Communicate openly and frequently
In nearly all the projects we’ve worked on, our attention to items 1 - 3 have directly correlated with the project outcome.
Why Are We Doing This Again?
At the onset of any application development project, stakeholders and the technical service providers need to question the value in what they are building. Under many corporate models, a full Return on Investment (ROI) analysis and user demographic evaluation will be conducted to determine if it’s cost effective to transform a concept into fully operational web or mobile application. We’re certainly not advocating for this comprehensive of an approach for small environmental NGOs, but feel it’s important to strike a balance. Stakeholders need to be clear on how the outputs and functionality of their app will lead to desired outcomes of their user base and it’s the responsibility of any development firm to set realistic and transparent expectations of what functionality can be achieved in a given scope of work.
During the project planning phase all constituents working on the project should have a very good idea of who their app or new system targets and how many individuals are in the given demographic. This analysis does not need to be extensive but knowing the functionality needs of your target audience will make custom software development less of a moving target. Identifying users will help reaffirm the need for the new system and hopefully lay out a clear path for the functionality requirements of an application or new system.
Plan More Code Less
This is often counter intuitive to teams undertaking iterative design and we are not advocating to underdeliver. What we mean is that before any code gets written, there needs to be a bulletproof road map in front of the development team. Programming is expensive, difficult, and time consumptive so it’s imperative that the planning process be complete before writing. Obviously this is from the view of the technical service provider, but as a stakeholder or client, don’t be alarmed if your developer isn’t cranking out iterations. We’ve found it’s much more productive to build systems piece by piece, making sure that each functionality component is complete and signed off on by the team as a whole.
In our approach we generally start with a site map or wireframes, have multiple design sessions churning out concepts that look like nearly completed web pages, and then write and test our code. At each stage we recommend looping in all stakeholders to ensure that the designs and proposed functionality supports the app’s greater purpose. It’s much easier and cost effective to change design spec than to re-code a prototype system.
Communicate and frequently
While this appears to be obvious, many relationships between a development team and a stakeholder tend to be siloed and one way. One party tends to provide content and feedback while the other frantically works to design and writes functional code that eventually may or may not result in a successful product. This exchange is then more disjointed as the communication chain is terminated between giving feedback, going back to the drawing board to incorporate revisions, and then presenting the next iteration. We find this to be hard, stressful, and frustrating so to mitigate this cycle our team is constantly reaching out and we encourage the stakeholder to be in constant contact with us.
We rely heavily on systems like GitHub, Basecamp, and Slack to ensure everyone is on the same page and that nothing falls through the cracks. While the onus is on the technical service provider to deliver the final product, stakeholders are equally important to providing content and ensuring the end result will positively impact the target demographic of users. We rely on our stakeholders to always check what we’re building so that if we need to change course, this is figured out early on in the process. Without clear and frequent communication none of these outputs are possible.
Each project provides an excellent opportunity for our team to refine our process and share what we’ve learned. In the end our metrics for project completion and success come down to use and adoption. We hope that what our team has learned can help make it easier for others to develop their own apps and systems that make the Bay and the environment a better place.