Google Docs as a Requirements Management Tool? No, Really!
This post originally appeared May 24, 2011 on BetterProjects.net.
At my day job, we’ve recently started a new program which will likely be the largest single technology endeavor ever undertaken by our organization. Its got big goals and, assuming we pull it off, will position us more than a decade in front of our leading competitors when it comes to technology integration within the organization. The advantages of our approach is making everyone from operations, finance, support and IT rub their hands in glee. Its got a little for everyone and a lot for some. Its one of those endeavors where everyone is on board with it and the only real complaint is that we’re not done already.Given the high priority and the huge operational need for this project, you might be asking yourself, why on earth would I, a guy who blogs about projects in general and requirements in specific, be dumb enough to pick a hack tool like Google Docs as our requirements repository. Great question, glad you asked. Its actually a long story, but for the sake of not overly boring you, I’ll sum up a bit.
One of my favorite features of Google Docs is the drawing function. See, I like Visio for diagrams and even for rough wireframes, but the fact that nearly no one has Visio installed and the license fee is high enough that no one outside of BA’s and IT manager can justify the expense in most organizations means that you’re forced to output to PDF or past into Word just about everything you create. Frankly, that sucks.
But as nice as the drawing functions are, what really caught my eye was templates. A very short time after the template sharing was launched, I spotted this link for a basic set of wireframes that met my two requirements for any tool: simplicity and usability. I kept the link around for nearly a year before I found a project where it would be perfect.
What I wasn’t expecting was how well people have taken to the idea of using Google Docs during our requirements elicitation process. We’re totally changing the user interface and business processes used by this enterprise application of ours. Our user community is (rightly so) not thrilled with its current implementation, but, like most user communities, has trouble articulating exactly what it is that would make for a good application that meets their needs. This is where Docs, in general, and the linked to wireframe template, in specific, has come in so very handy.
The Process
Knowing my user community as well as I do, I knew that if we walked in to the first elicitation session with nothing to show, we would spend most of the day off in the wilderness trying to chart a path. So, having spent many years learning the business, I put together a few different sets of wireframes that gave different (sometimes wildly different) takes on what you could do in a modern application.
It was during this process of putting together those initial wireframes that something I wasn’t expecting happened; I remembered a great little feature in Docs called ‘Sharing’. As a lark, I decided to share off my wireframes to my Director and VP (plus a few other BAs on the team). They were curious as to what I was doing, so I figured the easiest way to make sure they always knew what I was doing was to allow them to proverbially watch over my shoulder.
From that point, things just started snowballing. I added a use case template and the BA creating the use case library for me started adding her docs and sharing them off. She and I use a Google Spreadsheet to keep track of the use cases we’ve identified, the status of each and as a way to signal to the other what work needs to be done. The best part, although its one we’re just now really starting to use, is collaborative editing. We sit no more than 20 yards away from one another, yet being able to watch the other person update a document in real time does wonders for the creative process. I can’t recommend this enough.
The best part of this is how successful we’ve been so far. Everyone has all the information the need whenever they need it. No document checkouts needed. We modify documents, compare revisions and leave each other electronic notes in the margins. No need to print out, mark up and return for review. We make changes on the fly, right in the document.
Our users don’t (yet) have a clue how we’re doing all this. Honestly, there hasn’t been a need as most of my external stakeholders don’t spend their days looking at their computer (outside of email and reports anyway). What I have seen is how they’ve taken to me sitting in front of them during review sessions and making changes live, in front of their eyes, as they make suggestions. It has shortened the feedback cycle, making the team significantly more effective at our job. When I started this effort, I expected it would take months to complete just the 75 use cases I originally outlined. We’ve been at it for about a week now and have 25 ready for stakeholder review.
Lessons Learned
Having the right tool is invaluable. No, we’re not using a structured requirements tool. No, we’re not using rich prototypes. No, we’re not using pixel-accurate renderings of screens. Yet, we’re achieving astounding results for no other reason than we’re collaborating in a way I have never done before. So far, only a subset of the team is working this way as well. What will happen when the larger group of BAs, our stakeholders and the development teams start using this as well? I can’t even imagine the productivity gains that are yet to be recognized.
Collaboration, when facilitated by technology, is an enabler you can’t understand until you have experienced it. Yes, it is still annoying when I have to output my wireframes to a image file and then import them into a MS Word document in order to share them with my stakeholders. That is still frustrating, yet being able to work in real time with my coworkers nearly makes up for it. My stakeholders only review a nearly complete work product; they don’t care about the guts of how I get it done. If what used to take me weeks of struggle fighting with my tools and of outdated versions found in the hairball that is a networked shared drive are things of the past, that alone is a victory worth celebrating.
I’m sure someone reading this is saying, “That’s great. My company implemented something to do this YEARS ago. Tell me something new.” That’s awesome for you; we all envy you and wish our organizations put such an emphasis on providing such great tools to us, but we don’t work there and have to make due with what we have. BUT, if this post taught you anything, it should be that good tools are out there and they are just waiting for you to use them. Use Google Docs for collaboration one time and, minor formatting concerns aside, I bet you’ll be like me and be even more loathe to open up MS Word.