BKVSOPHB.RVW   20070118

"The Visible Ops Handbook", Kevin Behr/Gene Kim/George Spafford, 2006,
U$21.95, 0-9755686-1-2
%A   Kevin Behr
%A   Gene Kim genek@tripwire.com
%A   George Spafford
%C   #104 - 2896 Crescent Ave, Eugene, OR   97408
%D   2006
%G   0-9755686-1-2 978-0-9755686-1-3
%I   Information Technology Process Institute
%O   U$21.95 www.itpi.org 541-485-4051 info@itpi.org
%O  http://www.amazon.com/exec/obidos/ASIN/0975568612/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/0975568612/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0975568612/robsladesin03-20
%O   Audience s- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   98 p.
%T   "The Visible Ops Handbook"

The introduction notes that while many people see the need for process
improvement, and that the ITIL (Information Technology Infrastructure
Library) contains many "best practices," it is still difficult to know
where to start, and to suggest what should be done in a given
situation.  The authors then go on to outline a study two of them
conducted on the characteristics of "high performing" companies.  They
assert that the factors identified in the survey relate to three areas
of the British Standard 15000 structure provided for the ITIL
practices: release processes (planning and designing), control
processes (particularly change management), and resolution processes
(dealing with problems).  Unfortunately, the authors have often chosen
to describe their findings in terms of what does not work, rather than
what does.  There are also readability issues: the material seems
almost to be written with an intent to impress the reader, rather than
to clearly inform.  Finally, it is far from obvious that the
conclusions the book presents could assist organizations to improve. 
The problems described are common to immature and "chaotic"
enterprises, and the text does not demonstrate whether the processes
identified have made the associated companies good, or whether good
companies use these processes once they have achieved maturity and
stability.

Chapter one suggests that you reduce unplanned changes to your
systems, but is a little short on advice about how to accomplish this. 
There is a great deal of material on the symptoms of an organization
that lacks planning structures rather than specifics of how to
identify or deal with problems.  A suggested agenda for a change
advisory board is one useful item.  You should inventory your systems,
and then identity the ones that cause the most trouble, says chapter
two.  The third phase is to devise a system to manage the creation of
software builds, and provide the company with standard software
releases.  Chapter four outlines a number of useful metrics for
determining how well your organization is performing--at controlling
the release of new and updated software that you write.

If you create software, and particularly if you develop your own
software and systems in-house, then it is a good idea to manage the
process and ensure that changes are made properly.  Therefore, the
advice to do so is good.  However, this booklet doesn't go much beyond
that, and would be of rather limited use to most companies, even those
that do a lot of their own development.

copyright Robert M. Slade, 2007   BKVSOPHB.RVW   20070118