Google Wave for Historic Preservation Projects

Within our small company, where our core capacity is to assist architects and structural engineers in their investigations of historic structures, we have been playing with Google Wave for more than a month now.

At first our reaction was, “What do we do now?”

It took us a while to catch on but we have increasingly been opening a Wave for every new project that goes to contract, and for every project that we have in the funnel with a hope to lead it to contract.

For the most part our projects are fairly quick. Our focus is on a rapid turn-over of 1-3 day field gigs with a combination of a long-range activity in our collaborative Business Development services that we undertake with a small number of associated partners.

Though there are a number of collaborative web based services that are available, and we have used and continue to participate in a bunch of them, we have found that Google Wave provides something that works fairly well for us. But what works for us is an asset that in itself may increase the confusion for others who want to use Google Wave – we like simple tools (screwdrivers, knives, hammers) and to build up complicated systems from scratch.

For more than twenty years I have been using my own scratch built estimating spreadsheet (begun with Lotus Symphony on an AT, but even before that on a Commodore 64, that I used to manage the cash flow of a $20M project) that as the years and the needs change I change the template and refine to suit the specific needs to estimate for all sorts of historic preservation projects.

But these complicated systems that we use are built on an aggregation of simple pieces. A drawer is a drawer regardless if you have three or four-thousand of them.

So, to have a toolbox of communication tools, as Google Wave provides, gives us the fine tuning with simple pieces that we need in order to adapt the media to the results of the desired goal of efficiently sharing of many different pieces of relatively simple information.

For collaborative work-teams on historic preservation projects it helps to be able to share and make accessible project information and files (regardless if it is room to room or country to country exchange).

Here is a list of comments on information pieces that we have assembled for our own in-house reference:

1. sharing of pdf documents

or other forms of documents that we have shared software for team members to be able to read/write/collaborate, though if we turn a written document into a pdf it is a whole lot easier to share it across platforms... and not everyone has the same document generating software, or the interest to use it

2. sharing of photographs, photographs can convey a whole lot more information in a hurry than a written document

quite often the information that a team member needs in order to take an action is information that we don't know that they need, in that case it is better to share information that we might think does not matter because we simply do not know what is important, or not

these can be photos that we take or they can be reference photos that we find online

progress photos

3. sharing of videos... same as for photos, lots and lots of information delivered in a painless manner

our original videos, store them elsewhere then connect them into a Wave (these can be project specific, or safety, training or how-to vids)

or find videos for reference online and connect them into a Wave

an engineering friend in Texas shared a video on replacement of rivets in an historic bridge and suddenly we had a more encompassing concept of what would be needed where we were being asked for a cost to extract rivets for testing on a bridge in New York

4. maps.... it helps if everyone knows where we might be going (in our case the logistic of where is the nearest clean and warm public bathroom is often a critical item in the success of a gig, or, as in one case, "Where is the water?")

satellite and 3-D views when they are convenient

how far away is it? how much will it cost to get there? Do we need a boat, a barge or a really large balloon?

5. information links

find URL links related to project sites and quickly aggregate them into a Wave where team members can use them for reference, quite often these links contain contact information that we would not otherwise think to connect with

6. cost information

entire estimate spreadsheets may not be the best use on a Wave, but small amounts of cost information can easily be shared (a short list of unit costs for a bid – information required under very short deadline by another team member who is assembling the bid package)

Google spreadsheets can be incorporated into a Wave, but we have not the incentive to move existing Excel estimate templates into the Google environment

7. convenience

having information about a specific project on a Wave makes it accessible from wherever we happen to be, it is also accessible when we have the time to make the access and not necessarily in-our-face like an e-mail that requires that we deal with it before we forget where it went

accessible from different computers, wherever we can gain access to the internet

we can access project information from a smart phone while up on a lift at a survey gig, eventually we may be able to figure out how to input information directly from the field as easily as from the office

8. contact information management

if we get in the habit to put contact information for individuals related to a project into a Wave then we all can share management of the information, I look forward to more tools along these lines

everyone on the team will know where to find it, we will avoid calling each other looking for contact information when we cannot find it

it will facilitate the 'team' to be able to move quickly when contacts need to be made in a hurry

9. team expansion

as a small group of team members becomes familiar with 'simple' uses of Google Wave then we can begin to add on, and bring up to speed additional team members (I can hardly wait until we have real-time language translation in a Google Wave)

10. project specific

Waves can be used to assemble collective information about individual projects that enables a team to work together as there are more team members with access to information pertinent to the project, and different teams associated with different projects can very quickly be assembled

11. task specific

Waves can quickly be built out from project specific Waves in order to put focus on specific task goals, once the goal is accomplished then the task specific Wave can be archived or erased, or folded back into the root wave for the project

12. scalable tools

though Google Wave at first appears to be an intimidating blank slate eventually new tools will be developed that will broaden the range of activities that collaborative project teams can engage with, the limit on tools is the human imagination and the need to solve specific problems

one example of such a tool is ongoing work on integration of collaborative real-time mind mapping (we like mind mapping for strategic planning)

another example is project related calendars, and ability to send out e-mail notifications from within a Wave, and other project management and scheduling tools