You know that feeling. You’ve just set up the best collaboration system ever. You have all the processes documented and approved. Everyone’s agreed to use the system. Things couldn’t be better. Then, the project kicks off and there comes that sinking feeling when you realise that everyone is bypassing your carefully tuned system.

Everyone is sending emails instead.

The curse of email

Email is present on every computer (and even on mobile phones, these days), it’s free, it’s quick, and everyone knows how to use it. At first glance it seems like a very hard competitor to beat. At Woobius, we didn’t realise we were competing with email until we were well into the product development — perhaps a good thing, or we might have felt somewhat intimidated to face such a formidable foe. But eventually, we realised that all collaboration tools are competing with email, whether they recognise that fact or not.

Email has a lot of issues. It’s not good at sending large files or large numbers of files. It’s got very poor transparency and is hard to audit (you only know about an email when you’ve been cc’ed into it, and even then you have to dive into long threads of replies to figure out what happened). When using email, you never know for sure whether you’re looking at the latest version of a document, or whether someone’s sent an update that you haven’t received.

In short, email sucks in a lot of ways, so it’s really worthwhile to figure out how to design better collaboration tools that resolve those pain points. But email is still the cheapest, easiest low-end product that just works (kind of), so all collaboration tools are in its cross-hairs. This means that any such tool needs to try extra hard to make sure that users don’t constantly fall back to email and all its disadvantages.

Beating email — a three-part recipe

Over the last couple of years of evolving Woobius, we’ve discovered a number of key principles for successful collaboration. We’re sharing them here in the hope that they might be useful to other people who are implementing or building collaboration tools.

1. Allow anyone to initiate collaboration

The first principle is that we need to allow anyone to initiate collaboration. Within the context of construction projects, this means that it must be really easy to create projects, without needing to call up an administrator, without having to sign a contract, without having to pull out a credit card or wait for some process to finish.

The reason for this is that collaboration starts with doers. It starts whenever someone needs to get something done with someone else’s input. And when someone needs to get something done, they’ll get it done, whichever way is least effort. So if we make this process more painful than sending an email, people will do just that — send an email.

2. Respect the reality of collaborative trust

The second point is that we have to allow users to invite whoever they want to the project, so that they too can have access to the files.

This sounds a little scary at first, because it feels like we’re losing control. We don’t know in advance who will have access to the files… they could invite anyone!

The reality is that if you have a file, either one that you’ve produced or one that someone has sent to you, you can do whatever you want with that file. Once it’s on your hard drive, you could give it to anyone. You have all the tools at your disposal, on your desk, to send that file to whoever you want: email, phone, printer, CD burner… So, if you need to share that file with someone, you will, one way or another. If the system doesn’t allow you to do that, you will simply circumvent the system and get the file across.

So by making it possible to easily share files with new team members through the system, we’re not really giving up any control – just facing reality. We regain at least some visibility, because when they share it through the system, that’s logged, so we at least get to know what’s going on.

3. Allow people to make mistakes

The third principle is that it’s important to allow people to make mistakes, to accept that mistakes will occur, and to make it easy for people to correct those mistakes.

This sounds a little counter-intuitive. Surely, we don’t want to have mistakes on the project?

Little Britain got this right with their Computer says no sketch. We hate to have the computer tell us “no” when we know that our request is perfectly reasonable and possible. What we want is the computer to say yes, and let us decide for ourselves whether what we’re doing is a mistake, or exactly what we want to do.

A lot of computer systems out there are designed to prevent people from making mistakes. And, for a lot of those systems, that works out pretty well. But when we’re looking at a process as fluid and fuzzy as collaboration, it’s very hard to tell in advance what’s going to be a mistake and what’s not. Things change, and sometimes, what the system designer thought was going to be a mistake is not a mistake anymore. And if we keep trying to stop people from making mistakes, they end up feeling like they’re in a straight-jacket and they’ll go somewhere else.

So instead of spending effort to stop people from making mistakes, it is better to spend that time making sure that any mistakes are easy to correct. It’s worth remembering, also, that what might look like a mistake today could be an industry best practice tomorrow.

Conclusion

Those three principles are the essence to get bottom-up collaboration working, to get people to want to use a colalboration system:

• Allow anyone to initiate collaboration
• Respect the reality of collaborative trust
• Allow people to make mistakes

We didn’t get there on day one. We had the benefit of working with a lot of architects and engineers as we developed the system. We saw how people were using the system and arrived to those conclusions. Hopefully, this can be useful to others who are developing or implementing collaboration tools.

Daniel and I gave a presentation on this topic at Be2Camp North, an unconference focused on “Exploring Web 2.0 in the built environment”. It’s a version of the live talk which can be found on ustream.tv. Slides are available here.

There are many problems out there which are very easy to deal with in most situations, but can be very complex in edge cases.

Here’s the thing, though: sometimes, these “edge cases” can cover an entire industry.

The obvious example to me, since this is the Woobius blog, is document control in architecture (but we’ll get to that a little bit later).

Now, for most cases, document control is not a problem worth talking about. Most projects and companies get away with using Google Docs, Basecamp, or even nothing at all (“Can you email it to me again?” “I think I saved it on my desktop.”). Even large corporations tend to simply not care much about this. I used to work in a bank, in projects that produced astounding amounts of documentation, and yet the only form of “document control” going on there was a Sharepoint for sharing a few highly visible documents (like weekly status reports) and a huge shared drive that contained a chaotic dump of all the project documentation. Maybe that’s why they’re losing so much money… heh.

In most cases, you can get away with this because those documents are not essential to the main productive output of the business. An IT project in a bank might produce zillions of documents, but ultimately what brings home the bacon is whether the system they built works, and that’s not directly related to whether their documentation is in order. Similarly, a web development shop might care about having solid terms and contracts with their clients, and might need to exchange files with them in the course of a project, but those files aren’t the ultimate product – a functioning web site is.

Interestingly, when you consider code a document, document control becomes extremely important on IT projects – except it’s called source code control. There are a plethora of tools for controlling code versions: git, subversion, cvs, Mercurial… those are just some of the more popular free ones. Those tools are sophisticated, because controlling source code versions really matters when what you’re delivering is built on source code. If your programmers used no source code control tools, you should be worried about the quality of that code. Rands, of randsinrepose.com fame, counts a version control tool as one of the 4 tools that software engineers really need (along with an editor, a compiler, and a bug tracking tool) for anything more complicated than a “hello world” application.

A building’s source code

Architects produce documents too – drawings. As my architect friends always tell me, those drawings are effectively the DNA of the building to be built, so they matter, a lot. If the drawings for your house weren’t done properly, you should move out now – because the roof might fall on your head any time. It’s very, very important that every drawing was well coordinated (reviewed properly by multiple experts, commented on, and adjusted accordingly) before the construction firm started laying bricks. Very bad things happen otherwise (and the architects will get sued for their last penny).

This doesn’t seem like such a hard problem to solve, at first sight. How many of these drawings can there be? Can it really be that hard to track them? Well, if your building is just 3 planks nailed together (a “hello world” app of architecture), you might get away with a Google Spreadsheet, but anything more complicated than an extension to your veranda typically requires dozens or even hundreds of drawings. A 5 million pounds building (a small apartment block) will involve hundreds to even thousands of drawings (each of which is a 1-2 MB file), and multiple revisions of each. Not only that, but it will involve dozens of companies (consultants during the design process, like structural engineers, quantity surveyors, etc, as well as contractors during construction). That’s a lot of people to send files to, and a lot of people to receive files from.

The scale of the problem really hit home for me when one of our architect cofounders took us to a construction site that was almost finished. It was a refurbishment of an old headquarters building, where they gutted the original building and then rebuilt on top of the existing frame (that’s a lot more ecologically sound than rebuilding from scratch, since the existing structure represents a lot of energy that’s been spent to build it, and destroying that is wasteful). We walked into a room, maybe 20 metres long and 15 wide, and the floor was covered with neatly arranged plastic boxes that contained binders full of A3 drawings (about 11 × 17 inches). There were maybe 60 or 70 of those boxes, each with about 10 binders. That, he said, was the current version of all the drawings for the west half of the building.

Half the building. The drawings barely fit in that giant room.

And those were not even usable drawings. Most drawings need to be printed in larger formats to be useful to the contractors. This room was just the real-life equivalent of a document control system for half a building (or, more accurately, an “organised document piles” system).

And the winner is…

To manage complexity on this scale, you’d imagine that they used a fantastic, fine tuned, super efficient system like you would on any coding project that big. Well, actually, it turns out, they didn’t. They used email, CD couriers, and in many cases, good old snail mail.

It’s not that there aren’t any systems out there that can do that, but they’re very expensive, very hard to use, and very slow. They’re so expensive that on the big office project I just mentioned, which cost almost 200 million pounds, the client refused to pay for any such tool, because it was too expensive, and no one else on the project wanted to pay for it themselves (because, well, it was very hard to use anyway). They’re so complicated and time-consuming to use that all the companies involved would have had to hire a full-time “document controller” and train them to deal with it. They’re so slow that architects would often have bypassed the system when deadlines neared, because they don’t have the time to deal with it. It’s a hard problem, and the solutions available are hard, so in most cases people go with fudged fixes and ignore the bigger picture.

So actually, the winner is nobody – least of all the people who are building things.

This is one thing we’re trying to change at Woobius. We’ve designed a system that’s quick and simple for architects, consultants and contractors to use, so that they won’t bypass it under pressure (on the contrary, we’ve had feedback that that’s when it helped most). We’ve carefully crafted it to be easy to use so that they won’t need to hire specialist document controllers or install expensive software systems to deal with it. And we’ve constructed the business to make sure that the pricing for this system will be affordable for the vast majority of projects.

But we haven’t won (yet). So, until we do, there’s still no winner, and the problem of document control on most construction projects remains a hard, unsolved problem.

Have you got any good ideas about managing documents on this kind of scale? Please do share them in the discussion below or on HN.

What can an iPhone do on a construction site? Most people only use them for checking email, but I think that there’s something much bigger coming than just allowing people to indulge in their Crackberry addictions while wearing a bright yellow jacket and a safety helmet.

1,001 rooms, 10,000+ drawings

Five years ago, I was working at Foster + Partners on the refurbishment of Her Majesty’s Treasury in London. It was a vast project, with over a thousand rooms and nearly three thousand doors, every single one different because of the building’s complex arrangement and history.

All this work needed to be checked. Were all the light fixtures in place? Was the correct door installed (or removed, for that matter)? Were there any other issues? Taking all the drawings with us to each room to check that it matched the requirements would have been difficult (picture dragging a trolley of large drawings after you room after room, through several floors). So we did the opposite – we took the rooms to the drawings.

Taking the rooms to the drawings

Her Majesty’s Treasury Photo by chaserpaul

Because of this vast complexity, F+P spent the resources to develop a custom Microsoft Access database that could be used to record the state (or absence) of each of those innumerable fixtures, to track the progress, make notes of problems, and take pictures for reference and illustration. The data (in the form of drawing schedules) was already available electronically, so it just needed to be pulled together and integrated into a single screen that could tell you what you should be checking in the room you were in right now. This was basically a primitive version of BIM (Building Information Model).

We used to spend hours each week combing through the building’s Arabian Rooms, examining its thousands of doors, and snagging the details of each room on a tablet computer running our then state-of-the-art Access application. Back then, tablet computers were the latest and greatest, the “in” thing that was going to revolutionise the industry and bring it into the 21st century. The way I saw it, it was a huge, hot, heavy and power-hungry monster that I had no desire to lug around if I could avoid it.

And yet, to the annoyance of the contractor, we did carry it with us, dutifully recording everything from the absence of light bulbs to incorrect door numbers, snagging every little thing that was not perfect to the Foster standard. We put up with it because it was immensely useful and saved us countless hours of paperwork, and because for this particular project it was simply not possible to do it any other way, due to the building’s complexity.

This was five years ago.

A heavy burden Photo by Akihabara News

The revenge of the monster tablet

Considering how useful this was, you would think that this technology would be widely used by now. And yet, the building sites that use it are still rare. In part, this is because most projects can’t find the budget for that bit of work to create the snagging application. But the greater issue is the impracticality of carrying that laptop around.

Today’s tablets aren’t so huge and monstrous anymore, but they’re still a pain on most building sites, particularly since they seem to have the uncanny ability to sense when you’re halfway through your site visit and promptly run out of battery.

It doesn’t have to be this way, of course. Smart phones can perform all of the snagging functions of the tablets of yore. Better still, they are much less bulky, they rarely run out of battery, and they can easily integrate photo taking (the Treasury tablets didn’t have cameras, so we had to take the pictures with a separate digital camera and write down the file name into the tablet).

And yet, it seems no one has yet built this snagging application. Perhaps it’s because powerful, useable, wi-fi-connected smart phones with large screens are only just now becoming popular and mainstream enough to warrant it. The iPhone has also shown us that even complicated applications can present a simple, easy to use interface on a mobile device.

What it would look like

You get a call from a potential client. Your phone in your pocket, you go over to the site to meet the client. You create a new job on your phone and start taking pictures and making short verbal notes attached to the pictures. Back in your office, you can then take the time to evaluate the job properly with good information.

Later in the project, you’re doing regular site visits to inspect progress. You spot something going awry, so you take a picture and record a note “There’s a crack in the concrete, and the wrong window is blocked.” This is automatically synced and recorded back in the office (perhaps on a repurposed monster-tablet) and forwarded to the contractor. At another visit, you can simply load up the snag, check that this has been fixed, and mark it off. No need to carry a big folder or have to remember a thousand todo’s.

Once the project is at completion, you’re inspecting the site prior to signing it off for your client. You walk into a room and tell your phone where you are. It brings you a checklist of door handles, light fittings, fire alarms and window requirements. Can you sign off the room? Almost. There’s a light fitting missing and one of the doors has the wrong handle, again. You record them as before and move on, safe in the knowledge that the contractor will hear about them and maybe even fix them before your next visit.

Is this realistic?

To get this sort of tight integration, you’re going to need applications, both on the phone and back in the office, that are specifically tailored for architects. But you don’t need any new technology – all of this is perfectly doable with today’s hardware and with fairly unchallenging software (it’s not rocket science, and it’s all been done before). At the beginning, maybe only large practices will be able to afford this. But over time, I think software companies will look into developing this software and selling it more widely.

The smart phone is going to play a massive role in the industry. Within the next two years, we’ll start seeing a wave of smart phone applications tailored for the construction industry. And if other people don’t do it, maybe we’ll start doing them ourselves at Woobius.

What role do you think smart phones will play in the construction industry? Please post them below.