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?