Many years ago I did a workshop on how to get marketing to work with IT. I’ve noticed that when IT says, “I need a requirements document,” marketing often hears that as “go away, kid, you bother me.” The reality is that IT really does need a requirements document.
Does the same logic apply to how we document processes?
I raise the question because I’m noticing two different attitudes towards documentation. One attitude is consistent with the requirements document concept. The documentation – like the requirements document – comes first, then you build it.
But sometimes the process of building something isn’t all that clear up front. You have to find out how you’re going to do things as you go. It’s more along the lines of “Ready, Fire, Aim.” There are some things you have to do before you can document them.
A requirements document specifies an outcome. It doesn’t have to specify a method. In fact, most of the time it shouldn’t, because the person writing the requirements document doesn’t know all the options.
So we can divide “documentation” into outcomes and methods, or goals and operations, if you prefer. Outcomes (or goals) should be defined up front. Methods (or operations) can only be defined after they’ve been figured out.
The pre-planned part — which would be the outcomes or goals — should be defined by whoever is proposing or sponsoring the new initiative. That is, “here’s what we want to accomplish and why.”
Operational details are responsive as you work through the problem and figure out how to do things. Trying to specify operational details up front is a mistake.
