Tony just put up a post at Seilevel’s blog on making sure your spec is reviewed.
Kent Newsome recently posted about starting cross-blog conversations here, possibly inspired by Amy Gahran’s post about it here. Tony’s post is a great topic to cross-blog about.
Three easy steps to blogversation
- Post your contribution
- Link to the other posts in the conversation
- Add a comment to at least one of the other posts in the conversation
The techniques…
Tony identifies 4 techniques to either assess or assure that your spec is being reviewed (read his post to see them), and provides some insights into each one. These are good techniques, but there is more that we can do – and I’m sure some of our readers will have even more suggestions – post your suggestions on your blogs and extend this conversation (or comment on any of the posts if you don’t blog today).
These techniques, while effective, are not sufficient. Making sure the writing is targeted at the audience, and reviewing the spec for changes (because from change you infer engagement) is certainly important. Getting stakeholders to put some skin in the game is also a great idea. But these are still primarily passive activities – worth doing, but there is more you can do.
A couple more techniques…
1. Ask them directly. Asking someone if they’ve read the spec will pop it back up on someone’s radar if they’ve “been too busy” – it also gives you an opportunity to tell them why they need to read it. Each reader will have one or two primary areas of interest – a stakeholder responsible for processing claims, a developer implementing search functionality, etc. Ask them if they’ve had a chance to review a specific recent update that they would care about – “Did you see where the users have asked for cacheing of previous search terms? What do you think about that?” An open-ended question works wonders.
2. Collaborate. Ask someone for help – tell them you need to clean up the widget section of the spec. Or tell them you want to review the current spec with them, and have a short brainstorming activity about related topics (to the gadget section) for future releases. Time box it to 15 minutes if they’re busy. You just want to pick their brain for good ideas. Leave an hour on your schedule – these tend to run off on tangents.
More techniques from other bloggers…
I know there are more good ideas that Tony and I haven’t shared – what are they? Or do you want to brainstorm about untested approaches – blogs can track page views, why not store the spec online and track the viewing stats?
I love the recommendation (from #1 above) of asking about a specific part of the requirements document. I know from experience that this can be a powerful testing mechanism to see if folks are really paying attention. If you are feeling particularly frisky (and have a very solid relationship with the stakeholders of course) you can even throw out something fictitious and totally off the wall to see how people react. You know you’re in serious trouble if people just nod and say “that looked fine.”
I would also suggest using this “make sure you look at specific area XYZ” technique when the requirements are originally sent out for review. As a Product Manager, I always try to think of myself as marketing the importance of the requirements process to the stakeholders I interface with. “Positioning” is Marketing 101 and I think that a well-crafted, customized message to each stakeholder highlighting “what’s in it for them” by reading the requirements can go a long way towards stimulating actual review of the documentation. A critical part of this message should be a pointer for each recipient directing them to the key area(s) that he or she should start with.
Thanks Jerry for the comments. I completely agree about the importance of crafting a targeted message. Otherwise, it’s easy for overworked people to turn on their “filters” and perceive any broad distribution email as spam (unless it’s from their boss).