Obstacles to Documentation

Often, the biggest complaint against documentation is that it is simply developed for the sake of creating paperwork. This argument often comes from team members who think that they have it all in their heads and don’t need to let anyone else in on the secret. Have you ever come across a developer who starts asking difficult questions about functionality a week before QA or, better yet, who has built code that has no logic to anyone but the developer himself? That’s why we document.

Clients don’t want to create business requirements because often they have a solution in mind but don’t know how it fits into a particular problem or don’t know what the problem is. Most often, though, it’s because they don’t have any time to sit down and write them. Or they know parts of the problem but don’t have a complete picture and either don’t know how to or don’t want to put in the time to figure it out. They feel that you, as the agency, will not only figure out the solution, but in doing so miraculously come up with all the business problems that need fixing. Whatever the case may be the project manager needs to drive requirements gathering to completion before development can begin.

I’ve worked on projects where the client doesn’t have a clear understanding of the problem. When this happens it is a pure strategy play and should be run as such. If this is the case, sell in a learning period to buy the time to develop the appropriate business requirements and functional requirements documentation. This proposal has a budget with start and end dates and a final deliverable of requirements documentation an LOE and a proposal for the next project. It’s important to tie the requirements project up with a pretty bow and transition the effort into the next project or you may end up in requirements swirl. Don’t skip a beat.

Don’t fall into the trap!  Below, I’ve outlined a few Common Traps that project managers tend to fall into. They are the excuses that are used for pushing off requirements gathering to a later date. It’s important to recognize these excuses for what they are, Trojan horses that can take down the whole project when no one is looking.

Trap 1 – We don’t have enough time to take a month to create a requirements document. Everyone will want to see it and give us their two cents.

That’s exactly what you want. Anyone who is going to offer their two cents today is going to do it three months from now as well. The only difference is that if you wait three months to get their input you can guarantee that they will have changes to what you’ve developed and will probably be a little cranky that you waited so long to get their thoughts. If this is the case you can kiss the budget and timeline good-bye.

Trap 2 – We’ll gather the requirements during production ahead of development.

I’ve never seen this work. No matter how hard people try to keep the requirements gathering ahead of development it just doesn’t work. Remember Trap 1, “Everyone will want to see it and give us their two cents.” That takes time. More time than you’ll have when a developer or designer is waiting for direction to complete a task.   This tactic will most certainly extend your timeline and, if you’re working in an agency, negatively impact your margins.

Trap 3 – The client doesn’t want to pay for documentation; they want to see progress.

This is a fun one. Translated, this means that the client wants to come up with requirements by way of tweaking development. Why put any thought into what a solution should look like when you can review a demonstration and make changes on the fly. That’s fun for the client but not so fun for your team. And it’s devastating to the budget, timeline, and your mental health.

As I’m sure you already know, these arguments aren’t worthy. It’s just a lack of desire to properly prepare for the workload that is bearing down on them. It is your job to make sure that these documents are created, used, and updated. It is imperative! These are the cornerstone documents that you can fall back on to ensure that the project is going in the right direction and to keep the client honest.

Pg. 27, The Process of Communication