Requirements Management

An update on Google Docs as a Requirements Tool

Ted Hardy

May 1, 2012 • 4 min read

This post originally appeared April 24, 2012 on BetterProjects.net

Almost 1 year ago, I wrote a post about using Google Docs as a requirements documentation and management tool. Since then, we’ve finalized requirements for our first project phase, have made it maybe half-way through development and have even done a little bit of testing.

I thought this might be a good time to update everyone on my ‘little’ experiment (I’m piloting this on the largest project my company has ever done, thus the quotes around the word little) as I now have a better understanding of what worked well, what didn’t, what sank like the Titanic and what I think we’ll do different next time.

The Good

Believe it or not, there really were a LOT of good things to come out of this test of mine. Here’s a little list for handy reference:

Speed of revision. Like any project, especially one where we started the requirements a long time before the development, we have had to make adjustments along the way as what we thought would work well sometimes ran into the wall of technical limitations. Because we didn’t have an architect or developer reading along as we wrote the requirements, we sometimes failed to get down to the necessary level of detail for the developers to get things right.
Collaboration. Everyone has access to the documents. Everyone knows where they are (or at least they have been told!) Everyone can go look at them and ask questions. They are not buried on some shared drive that is only accessible when at the office or when connected over a VPN. If you need them, they are there.
Prototyping. Using Google Drawings to create wireframes makes getting ideas in front of our customers insanely easy. We have built a set of stencils over the last year or so that make drawing and sharing a new screen idea trivial. This alone has saved me an insane amount of time.

The Bad

I wish it had all been good; I really do. Here’s a sampling of feedback we’ve received on what doesn’t work so well.

Too many docs, too many places. This one I actually take issue with, but it has been a consistent piece of feedback from the developers. They don’t know where to look, despite having divided all the documents up by subject matter separate collections. There have also been complaints that we spent too much time categorizing information into different document types and not enough time tying all the document types together.
Google Docs sucks at formatting. Well, this one I completely agree with; it really is terrible. Thankfully, we are doing a minimum amount of formatting, so the pain isn’t horrible.
Google Docs sucks for large documents. One document that the development team demanded we create, against my better judgement, clocked in at over 300 pages (long story; shoot me before I ever agree to this again). You can’t use the revision history functions; it locks up. Loading the document up in the browser maxes out your CPUs for a very long time. Keep your documents simple; you will not regret this.
Speed of revision. This could probably be said as a bottleneck in our review process, namely finding time for me to actually look at and approve the changes. My BAs are awesome, so awesome that with all my other duties, finding time to review their changes, even small ones, is a big challenge. Thankfully we keep a fairly detailed change log so I know what documents need reviewing.
Collaboration. Some people just didn’t get the concept of a document as a living thing. A few times, we had developers show us printed copies of docs that were 2 months out of date and try to claim things they coded in the last week didn’t match the document. True, it didn’t match the printed copy they had, but it perfectly fit the current one that had been updated prior to the start of their coding. It took several rounds of this happening before the dev team finally believed us that working from the online docs was the best thing.
Mobile. I live on my iPad. It never leaves my side. Google’s support for it is horrendously bad. Drawings appear as an ill-formatted and shrunken image. Text documents only have the most rudimentary editing support. Spreadsheets… just don’t bother.

The Future

We are about to start putting together some ideas for the second phase of the project. We want to build upon the good start we have with this tool and figure out ways to make this process work better. This project (really a program) is going to last for a few years as we replace and revamp our processes and systems from the ground up, so this is something we’ll need to make work well. Here are some of the changes we’re considering:

Omnibus Documents. Instead of 4-5 different types of docs, we are probably going to merge all docs for a particular subject area into different pages of a spreadsheet. While this makes the issue of document size all that much worse, it will (hopefully) make understanding what to read easier on the development team.
Better collaboration. This isn’t so much better about where the documents are housed as it is about having the development and testing teams involved earlier in the requirements process. This lack of involvement in the first phase has been one of the largest hindrances during the project as it has caused a significant amount of rework. The BAs are not developers nor are they testers and expecting them to capture everything the other teams need without input from those teams is just not going to work.
Expanding the use of the tool. Google recently announced that teams can use Google+ Hangouts with Google Docs. For our offshore team, this would be a great way to review documentation prior to any code being written.

So what new types of requirements solutions have you been working with in the last year? Drop us a note in the comments!