Skip to main content

CSI and the Communication Plan

Timely and effective communication forms a critical part of any service improvement project. To transform an organization and move people and process from just thinking about Continual Service Improvement (CSI) activities to actually allotting time to be able to performing CSI activities, it is critical that all stakeholders are informed of all changes to the processes, activities, roles and responsibilities. The goal of the communications plan is to build and maintain awareness, understanding, enthusiasm and support among all stakeholders for the CSI initiative. A communication plan is much more than just sending out one notification on what is about to happen and should be a series of notifications and meetings to keep people engaged, informed and passionate while incorporating the ability to deal with responses and feedback from the targeted audience.

First, we must design how we will communicate and then we must define what and to whom we will communicate.

The plan must contain:
  • What mechanisms and tools will be engaged to both deliver and receive responses and feedback to the project team, process teams and target audience.
  • Identification of key stakeholders and target audience.
  • The creation of an overall communication strategy and tactics.
  • The creation of a matrix of who, what, when, where and how.
  • Defined project milestones.
An effective communication strategy and plan will focus on creating awareness of why the organization is implementing changes, the value of those changes to the organization, how each individual team or unit will be impacted, what the value to them will be along with the purpose and importance of their engagement.  The plan will also need to speak to what additional skills or tools may be needed and what formal education, if any, will be provided. When developing your communication strategy and plan it is important to take into consideration how corporate communication works today. In some organizations this will need to be planned.  We must also keep in mind the culture around communicating with the business. There may be guidelines on who can communicate with the business.

When defining your plan, the following needs to be taken into consideration:
Who is the messenger? This is a critical element and should not be discounted when assessing the importance of aligning the messenger with the message.

What is the message? Define the purpose and objective of the message. This needs to be tailored to the target audience. Keep in mind the importance of communicating the benefits of the CSI initiative. The what’s-in-it-for-me approach can be a strong persuader for the individuals who will be expected to carry out the activities of the initiative and must be addressed.

Who is the target audience? The target audience will be any stakeholder who will be performing CSI activities or that the initiative will impact. The target audience will often define who will deliver the message based on what the message is.

Timing and frequency of communication
Be sure to plan and execute your communication in a timely manner. For your communication to be effective, it should be an iterative process that will take more than a one-time communication. If milestones and progression of the project is what is being communicated, you will want to have defined timelines and frequency for your target audience.

Method of communication  
The practice of sending emails and putting something on the web can work for some forms of communication, but to ensure success, the need to engage in face-to-face meetings where there is an opportunity for two-way communications to take place will be a critical success factor. Attending staff meetings, holding information meetings open to all stakeholders and conducting town hall meetings must be considered.

Be sure to keep a record of all communications as that will ensure your plan has been properly executed and can be utilized later in a post-implementation review.

For more information on Communication Plans (download these free templates) and/or consider attending ITSM Academy's next ITIL Continual Service Improvement Certification course.

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: RenĂ©. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…