While doing student fieldwork in GIS, a lot of my projects have centered on using Esri’s online tools – more specifically, ArcGIS Hub, as well as their Open Data Portal services.
There’s a wide variety of potential when it comes to organizations looking to reach out to the public through open geographic data.
However, I’ve also noticed that the convenience of these tools can play hand in hand with documentation issues. Specifically, with adequately recording the steps designers and programmers have taken to develop these sites.
By extension, there can be significant “empty” spaces in a workday, where there is no preservation of information or standard of accountability regarding what these professionals have done, and at what time frame.
Even out of the box GIS tools require documentation
The “out-of-the-box” tools that don’t require programming still need adequate documentation.
Using these programs requires a level of group work that spans across several professionals with different strengths and skill sets, that contribute to these programs as a whole. But when their actions aren’t documented, maps, graphics, and other important data could potentially be lost. This is especially applicable within the context of bringing new people onto a project.
Collaborative documentation process
I’ve written about the necessity of recordkeeping previously, but I’ve found that preserving information about workflow makes turnaround times quicker and ultimately more convenient.
There were two methodologies that seemed most helpful during my internship: designating one person to gather information of the tasks for each team member, or – alternatively – having everyone on a team write down a general overview of their progression each day, with a final compilation of that data into a singular document or spreadsheet.
That document could then be uploaded through a file sharing service – such as Dropbox or Microsoft’s SharePoint – for anyone to access at any time.
But while writing down simple overviews and steps were helpful, what seemed most valuable were the assembly of timestamps per each action by a team member.
By providing a general day / hour that a task was completed, it was easy for other individuals of a team to reference what’s been completed, and shortened / removed the lapse of time that was often attributed to sending emails, and waiting for a response.
Hosting that documentation on a sharing service also allowed for something I find particularly useful – the ability for team members to write down their progress outside of the average workday.
Keeping organized, accessible documentation gives individuals the chance to “telecommute” and contribute to a project without having to be present at an office or meeting space. It proves to be far more effective than keeping track of those aforementioned contributions through standard, traditional work hours that often have lapses of productivity.
From what I’ve observed, the greatest factor in delaying the standard turnaround time are those lapses, and the over-dependence on a formal workday. That dependence often promotes attendance without substance – being at a location, but with no opportunity to contribute or progress, as large swaths of time are reserved to waiting for other members of a team to be completed with their portion of a project.
