From rbutterw Wed Oct 22 13:49:26 2008
To: tserviss@math.uwaterloo.ca
Subject: Re:  Change Management Process_Request Tracker_Process V1.5.doc

>  From tserviss@math.uwaterloo.ca Mon Oct 20 12:04:41 2008
>  Please review the following proposed policy document.
>  A scaled down procedure will be created shortly.
>
>  Please address your comments directly to me.


I'm not sure this is what you wanted, but it's what I ended up with,
very little to say about the policy itself and perhaps too much to
say about the document that describes it.

Picky comments:

 - I won't duplicate Robyn's observations, but generally agree with them.

 - It would be easier to comment on specific details if this were
   in a more portable form (e.g. text or HTML) rather than being
   stored in a Proprietary Document Format.

 - The UW logo has poor resolution.

 - Many words use the British alternative "-ise" spelling rather than
   the correct-everywhere preferred "-ize" form.
   E.g. "authorisation" vs. "authorization".

General comment:

 - My first impression is that this document is too long to be a policy.
   (The entire original US Constitution is under 5000 words long,
    and except for a few amendments, it's provided enough policy
    to run a whole country for over two centuries.)

   If someone wants to know what our policy is, they would like to
   hear it in 12 words and would accept 12 sentences, but 12 pages
   is way too much.  Anything that long is almost certainly going
   to contain inconsistencies, inadequacies, loopholes, and sections
   that are subject to personal interpretation.

   I think the problem is that it contains aspects of several things:
   background and justification for the policy, examples of implementation
   of the policy, expected results of the policy, and the policy itself.

   The language seems to be both formal and informal at the same time.
   Again, perhaps this is because it's trying to do several things at
   once and policy definition requires formal language while explanations
   and comments don't.  Technical specifications, tutorials, and
   marketing literature are written in different styles for different
   audiences.
   
   This document seems to be trying to accomplish too many things
   at the same time.  Perhaps it would be better written as several
   separate documents, with one of them, The Policy, being very
   tightly written and intended as a permanent official policy
   and the others as more informal documentation that can be updated
   and improved as circumstances change.

 - Many formal documents and standards use the words "may", "will",
   "shall", and "should" with fundamentally different meanings.
   It's not obvious what significance, if any, these words have in
   this document.

 - Far too much of the text is passive, vague, and redundant,
   and much of it assumes familiarity with the rest of the document.
   E.g.
    - 5.1.1 says "A Change Calendar will be published via the web
      as publicly available information.  It will be updated
      dynamically ...":
       - "publicly available":  that is what "publish" means.
       - "updated dynamically":  what does that mean?
       - "will be published":  is too passive.  It simply says
         that something will happen without saying who is responsible
         for making it happen.  (We already do that too much.)

    - In the "Key Definitions" section, the definition of "CAB" is
      "A committee assigned to administer the Change Review Process".
      As a key definition, it's very lacking in information:
       - It doesn't indicate who assigns the members,
         how many members there are, how they resolve conflicts
         and make decisions, etc.
       - "Change Review Process" isn't defined anywhere.
          - Elsewhere it says that the Help Centre is responsible
            for reviewing change requests.  I don't think that's
            what's intended here.
          - Other places refer to a "Change Management Process";
            is that the same thing as "Change Review Process",
            or something different?
       - If this is only an "Advisory" board:
          - Whom do they advise?
          - Are people allowed to ignore their advice?
          - Who actually makes the decision?
   Some of those I can figure out, and some are described elsewhere
   in the document, but one shouldn't have to do that.  A definition
   should be a definition.

 - Some of the document is far too specific though.  E.g.:
    - Section 4.3.2 provides guidelines that staff must follow when
      making changes.  Two of these three guidelines are general
      directions, but the other one is extremely specific.  If
      that point belongs here, then surely there are dozens more
      like it that should also be included.  And saying "the Staff
      member is authorized to speak with the initiator to enforce
      this regulation" implies that Staff aren't normally allowed
      to speak to the initiators, or perhaps they are allowed, but
      not for the purpose of enforcing any regulation other than
      this specific one.

 - Generally I'd say that Policy and Procedure should be treated
   separately.  Policies should be small, formal, static, and
   difficult to change.  Procedures should be less formal and
   much easier to change (while still conforming to the Policy).

   As an exercise, I've drafted a short (~600 words) formal policy.
   The second half in particular (~400 words)
   corresponds to what I think your document describes:
     http://www.math/~rbutterworth/reports/cmp

Policy comment:

 - While I agree with the goals of this policy, I also have concerns
   about how well it will work in practice.  Our current staff and
   management are already not doing nearly as well as they should
   using policies and processes that are far easier to follow.

   As an obvious example, how can we have over thirty RT items that
   have been allowed to go past their due dates?  Or how can we have
   let our various databases get so out of date?  And why do we often
   take a year or more to install new machines, or to upgrade our
   existing machines to Solaris 10?  If I were in management, I'd see
   such things as indicators that staff aren't prioritizing properly
   or perhaps that individual tasks are being assigned to the wrong
   people, but certainly as an indication that as a whole the
   department isn't running nearly as well as it could.

   Defining new policies to regulate how we do things can be good in
   theory, but if the department as a whole can't manage well with
   the current policies and procedures, are new policies going to
   do any good, or will they end up being useless or even doing harm?