Part of the product

Last week we held a shortened Kaizen-style event in which we discussed the requirements capture part of our product lifecycle. It was an interesting couple of days which yielded a new process that we think is an improvement on the previous one. That makes it sound very simple, it certainly wasn’t, but it was a fascinating couple of days.

As I’m responsible for the technical information that comes out of the development group, I had a slightly different view of things and took away some ideas to discuss with my team of writers. One of which we have discussed a little but haven’t yet pushed too hard. I think that is about to change.

Going back to our requirements capture process, one part of the new process suggested some additional information that should be provided with the business case attached to a requirement. That got me thinking.

At present we (my team) face a backlog of information which was never previously considered nor written up (an oversight by my predecessors) and we’ve been trying to tackle the backlog as well as keep apace of the new features being added. Ultimately this has proved futile and we’ve discussed ways to get around this. More resource is one option, but another would be to work smarter and only provide documentation based on a priority basis or, for want of a better description, based on a viable business case.

The question I’m pondering is whether we go the whole hog and make documentation requests part of the requirements capture process, or use our own understanding and knowledge of what is required and build our own business case.

It’s, hopefully, a fairly unique situation but I’d still be keen to hear how you handle incoming requests for documentation?