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?
Hi, from my experience I’d suggest that you should make documentation requests as a part of requirements.
During SDLC, we too were facing similar problems. Often, after releasing the help topics for user testing, we would be told that certain work around or tips is missing, as the business team would have missed to inform us!
Then after much discussion and analysis we made documentation requirement as part of the System Specification document. Because of this we were able to play a more proactive role and content related defects were much reduced. Other benefits included:
* We had a chance to look at the spec at a very early stage and hence able to help the team in terms of usability and design.
* Collecting the the key tips/work around from the business people when everything is still fresh in their minds.
* Able to come up with more accurate estimates.
* The writers and testing team had a clear expectation on help topics.