I Hate Writing Requirements Too

It’s hard work!

Introduction

After Viewpoint engaged a marketing firm to help us develop web content, the marketers asked if we had documented our intended goals. I was stunned that I had none, considering that is one of the first questions Viewpoint also asks our clients! Just like most of our clients, I had no written requirements either. I discovered that I don’t like writing down project requirements. It’s hard work!

Motivation

Anyone who has worked with Viewpoint knows that we love it when, at the start of a project, our client hands us a document with detailed requirements about a project. With the requirements completely described, we know plainly how to design and build the system to satisfy the goals that the client is seeking.

In reality, it is rare when clients have prepared a requirements document prior to that first meeting when we discuss the project. And, my experience is that having written requirements at that initial meeting is becoming even more unlikely than in past years. Everyone is just too busy dealing with multiple projects to take the time to write down their needs.

But, at Viewpoint, we strive to assure that we have decent requirements before quoting a project. After all, we want to make sure our client is delivered a system without any missing features. More often than not, however, our clients have incomplete requirements, and it’s frustrating for our engineers because they don’t know which problem they need to solve.

That frustration seems to be just part of doing business these days, but I don’t like it. And, when the marketing firm flipped the tables on me by asking for documentation of our objectives, clearly stated in a requirements document, I was taken aback. I was transformed into being a client, rather than the usual scenario of being the service provider. And, despite all my frustrating experiences of asking our clients for documentation, I responded just like our clients often do: I didn’t have any.

When the marketing folks asked me for our requirements, I heard myself thinking the same things we often hear from our clients:

“You’re the expert, don’t you just know what needs to be done?”
“I don’t want to include something that might be expensive and time-consuming!”
“If I give you a quick outline sketch, can you fill in the blanks?”

What an eye opener! That experience made me truly appreciate how very hard it is to document project requirements.

Suggestions

After our service provide asked that brief question and the week that followed in response, I realized the difficulty our clients face when asked for documented requirements. It is just simply hard to write down project goals. It takes time and detailed thought. Couple that with juggling perhaps several projects at once, and finding the time to carve out of a day or week to capture details in a document is a real challenge. Here are the reasons I struggled. Our clients experience the same struggle.

Not knowing if what I wanted to do was hard or easy to implement.
Suspecting, but not knowing, if it might be easier to just do it ourselves rather than describing the content in a document.
Wondering if documenting my goals would impose an approach that was ineffective or inefficient.

After the marketing firm asked me that question, I embarked on a week-long process (not full time, of course) gathering my goals and desires for the project. It was hard and challenging. After the requirements was considered and documented, I was struck by a few items, which I will share with you whenever you are contemplating embarking on a new project with another group. Note that this group can be external, such as a services firm you might hire, or internal, such as a team within your company that tackles development projects.

Here are my recommendations on writing requirements, in no particular order.

Interview: Have a colleague interview you about your goals for the project, take notes, and use those notes as basis for the requirements.
Don’t worry about coherence: Capturing your goals in any order and at any detail level is more important than being coherent and specific. A good service provider (i.e., those people being asked to implement your goals) will ask questions when more clarity is needed. If your service provider doesn’t ask questions, then you will likely not receive what you wanted.
Prioritize: After capturing your goals, go back and indicate the importance of each goal. A good service provider will use those indications to have a discussion about the rough costs and durations needed to implement your goals. Some goals may just be too expensive to implement, and you might want to make adjustments or simply push some goals to the next phase of the project. In other words, do only first things first. You may find it helpful to ask the service provider for an opinion.
List who does what: Include a high-level description of any parts of the project that you think you will handle versus those that you are expecting the service provider to manage.

For item 1 above, sometimes having the service provider do the interviewing is the most efficient way to start requirements. Consider that it might be worth the cost to you (the service provider will want to be paid for this effort) to make the interviewing efficient (they will ask questions in real-time).

Summary

My experience with the marketing group gave me a vivid appreciation for the difficulty and reluctance that our own clients experience when we ask them for a requirements document. However, the success of a project depends heavily on putting the goals of a project into written form. Otherwise, items are forgotten until the project has already started or the dreaded “that’s not what I wanted!” occurs during delivery.

So, take the time up front to make sure both sides (client and service provided) know the goals. You should know that I also hate having surprises during project implementation, but that’s another story.