270 likes | 496 Views
Change Management. Minimizing Some Of The Greatest Operational Risks and Threats In a Communications Center. What are the typical risks and threats to successful daily operations???. Change. Change arrives in many forms Some manageable, and some not so immediately manageable. Managing Change.
E N D
Change Management Minimizing Some Of The Greatest Operational Risks and Threats In a Communications Center
What are the typical risks and threats to successful daily operations???
Change • Change arrives in many forms • Some manageable, and some not so immediately manageable
Change Management Change is managed as follows: • Develop an ARCI (also known as RACI) Matrix • Define Roles • Implement Policy • Enforce Policy (with penalties)
Change Management ARCI Matrix Accountable (who is accountable for a change) Responsible (who is assigned to implement it) Consulted (who reviews the change and approves it) Informed (whoever needs to be advised that a change is coming)
Types of Change CAD or GIS System • Who is Accountable for the change? • Who is Responsible for making the change? • Who is Consulted before a change is made? • Who is Informed about the change BEFORE it is made?
Systemic Changes • Changing a computer system component • “Updating Windows” • Anti-virus “updates” • “Router or Network” changes • “No impact is anticipated” • Radio or Console System changes, PM, testing • Remote or Contractor Access
Changing a Computer System Component “We have a redundant system design” “We have done this many times before and no one has ever noticed” “We will just turn on the back-up system” “If we don’t change it right now the whole system will be down very soon” Everybody with any type of supervisorial responsibility should be INFORMED
Updating Windows Computers are set for “automatic updates” “Microsoft has identified a security threat/risk” Users are prompted to update software (Java/Adobe/iTunes) Test, test, test Consult application vendor for every update before applying
Anti-Virus / Spam / Pop-Up Updates “Behind the scenes” Frequently untested until deployed No ability to back out changes easily Test, test, test
Router or Network Changes Changes are frequently just communicated to peer technical staff, at best Back out plans are CRITICAL!!!!! All users should be informed of the change, when it is scheduled, and who to contact when an impairment is experienced
“No Impact is Expected” ??? Really ??? • This is always a “dodge” for bypassing a change management process • In other words, “We do not think anyone is smart enough to understand what we are doing” • In reality, “We are not really sure what the change is going to do as we are not smart enough to understand it”
Radio or Console System Changes • Technical staff disabling system functions, “feeling” that it will not impact normal operations • System components/functions found not to be working (users and techs) • “Radio service testing, 1…2…3…4….5….6….7…” • Talkgroups on console with no known purpose or role definition
Remote or Contractor Access “Ghost in the Machine” “Contractor at the radio site doing some work” Allows changes to be made without knowing the full impact Access should always be approved and monitored A back-out plan should be in place
How To FIX the Problems • For each system or application, meet with management, technical staff, and end users to develop ARCI Matrix • Develop a change process that identifies the roles (not names) that participate in that process • Define roles • Assign roles
How to FIX the Problems • Establish a Change Management Policy • Enforce Policy • Begin to apply your agency progressive discipline process when the policy is not followed • Build severe penalties into SLA / Contractual agreements when policy is not followed
References • ITIL (Information Technology Infrastructure Library) http://www.itil-officialsite.com/ • Project Management Institute http://www.pmi.org/ • Vendor Best Practices • ARCI or RACI Matrix http://en.it-processmaps.com/products/itil-raci-matrix.html
Questions? Contact: Mark Schroeder, City of Phoenix Mark.schroeder@phoenix.gov