Hackos and process maturity

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Alex Silbajoris reports <<... for the third time, I'm telling the admins
that we need en established review process.  As it is now, I'm sending out
drafts like bullets into fog.>>

Remind me to wear Kevlar next time I'm out for a stroll in the mist! <g>
This is an ongoing problem for most of us, and the trick is to figure out a
way of getting all the benefits of the process (covering all the important
points) without the drawbacks (red tape-induced procedural paralysis).
"Process" is not an inherently evil word until it becomes atherosclerotic
and begins interfering with your work; for example, we spent a few months
this past year examining the process we use to produce technical reports,
identified the problems that caused the most significant delays, and set up
a fairly rigorous process for resolving those problems. The result: a 60%
decrease in the time required to generate reports. Moreover, because we
worked with the authors to identify solutions they could live with, the
users of the process are much more satisfied with the task of writing
reports than they ever were.

<<The problem is that no one sees any worth in a review process; as with
documentation in general, it's pushed down to a low priority when time
allotment is considered.>>

Yet another recurring refrain. One important distinction to make whenever
you discuss procedures and processes is that you don't always need a formal
process; sometimes informal works just as well. A couple examples:
- Although my current employer's software development process barely
registers on the "process maturity model" scale, I recently worked directly
with two of our researchers to prototype the interface for a database
application long before anyone began writing code. (Tip: Dreamweaver makes a
wonderful prototyping tool, complete with interactivity. You don't have to
build in database links; all you have to do is fake it by showing a sample
results screen.) Once we'd gone through a couple revisions together, we
turned the prototype over to the developer and sat down with him to discuss
how to implement it. Believe it or not, he had some great ideas for
usability improvements. (Tip of the hat to Marc!)
- By keeping plugged into the grapevine, I sometimes get advance warning of
an author's or a developer's schedule, and can plan to send them a review
document during a gap in their schedule. It doesn't always work, but when it
does, they usually owe me enough favors that I can convince them to spend
some of that free time on a review. Even where that's not the case, I've
cultivated a good enough relationship with all my colleagues that I can
usually steal 15 minutes of their time with no more advance notice than a
quick stop at their office and a "can I have 15 minutes of your time later
this morning?"

The second example raises an important point that requires some elaboration.
At these ad hoc review meetings, I never simply deliver a pile of
documentation and sit there twiddling my thumbs while I wait for them to
read it. Instead, I carefully identify the aspects of the documentation that
I can confirm myself before I go to the meeting, and highlight the points
that I need the expert to confirm. Using Post-It flags on the pages with
questions helps greatly because then I don't have to skim through the
documentation page by page trying to find my questions. Having done that, I
explain each potential problem to the reviewer rather than forcing them to
skim the whole document looking for questions. Instead, the reviewer simply
reads the few highlighted lines that I've found for them and provides enough
information for me to revise the lines--and to confirm the correctness of
the revision with the reviewer on the spot, so I don't have to come back
later and ask for a second confirmation. Focus on the important stuff, and
don't ask reviewers to worry about stuff that they really don't need to
review.

<<I don't want an elaborate model like the Hackos-based approach>>

The problem with Hackos and the process maturity model is not that she
advocates a rigorous approach to managing projects, but rather that people
have come to equate "rigorous" with "rigid". As indicated above, you can
accomplish many of the important aspects of what Hackos advocates (e.g., the
review I mentioned above, good initial design) without being tied to a
rigid, formal schedule. Focus on the goals of the steps that Hackos
describes (e.g., getting good reviews done), not the nitpicky details of the
process. I haven't read her book, so my knowledge of her methodology comes
primarily from her journal papers and conference presentations, but I didn't
get the impression that she advocates a monolithic, one-size-fits-all
approach; if she does, I'd be disappointed, but wouldn't throw out the good
points of her approach because of it.

<<I would simply like a reliable process of consideration of materials
before they go out to their intended audiences.>>

Sometimes you have to think laterally. For example, in my first
documentation project, we had no time for the developers to do a rigorous
review of the documentation, and no permission to go outside the company to
real users of the product. So I negotiated a couple hours of time from two
of our research technicians, who are similar to the users of the actual
product in many ways, and asked them to shred my documentation. They did a
great job of reviewing things and helped me produce better docs than might
otherwise have been the case.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author!  iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,000 retailers.  And it's
affordable.  Join our almost 10,000 published authors today.
http://www.iuniverse.com/media/techwr

  Your monthly sponsorship message here reaches more than
  5000 technical writers, providing 2,500,000+ monthly impressions.
  Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.