Tag: process requirement

Event Management Process Design – Part Three

This post is the part three (and concluding part) of a series where we discuss the Event Management process and how to put one together. Previously we discussed the elements and considerations that should go into the process design. We elaborated those considerations further with a sample list of process requirements and the corresponding process flow. We will assemble all the information together into one process design document that can be used to implement the process.

In addition to the process requirements and the process flow, which are two key ingredients, I believe a process design document needs to call out additional information pertinent to the implementation of the process. For example…

Sample Process Design Document

Policy statement: The policy statement calls out what are some of the governing points behind the process. Under what circumstances the process becomes applicable or not? What are some high-level expectations the organization has with the implementation of the process?

RACI Chart: Simply put, who does what? Sure the process flow calls out the major roles and describes the interactions between the activities and the roles. Having accountability clearly defined is also necessary. Some activities may involve more roles interacting with one another in various capacities, depending on the complexity of the activity, so it is a good thing to identify those finer details as well.

Process Metrics: How would the process owner or the organization measure the performance of the process? What metrics can be collected for analysis? It will be hard to improve the process over time if the process owner has little idea on how the process is doing at any given point. Or better yet, what metrics will be meaningful to measure because the organization cares enough about them?

Interfaces: How will the process interact with other processes already in place? For example, Event Management process will often interact with the Incident Management process. It will be useful to document what interactions exist between those two processes and what input/output should be taken into account.

Other supporting procedures: Most organizations will have other supporting procedures that further describe how things work together. For example, we described an activity within the process where the Service Desk notifying and keeping the business user communities informed of the incident status. Well, that is pretty high-level still, so exactly how the notification to the end users will be carried out? Again, every organization will have its own approaches so it will be helpful if those details can be incorporated into the process design somewhere or at least made references of.

Depending on the discipline required by your organization, your process design may or may not contain these additional elements, or maybe different ones. In any case, I think a good process design document should spell out all the information and references anyone will need to implement the process fully, just like a specification of some sort used to construct something. Hopefully, the process design you come up with will also have been vetted by the necessary stakeholders of the process, so you will have the support you need to implement. The process design document is also a living document that will require periodic care-and-feeding in terms of reviewing for accuracy and fine-tuning over time.

So what is the point for having a functional Event Management practice in your organization? As a technology service provider to the organization, the Event Management process can help IT stay on top of potential service interruptions or outages. As a capable IT organization, we should be the first to know what is going within our own environment and not depend on the end users to let us know when something has become unavailable. Technology and gadgets break down all the time, and that is the nature of the business. The IT organization should be the first voice to let people know when something has gone wrong within our domain. Having a well-designed Event Management process is the first step in getting a better handle on what is going on within your environment.

I hope the information presented so far has been helpful. Please feel free to suggest options or other approaches that have worked for your organization.

Links to other posts of the series

Event Management Process Design – Part Two

This post is part two of a series where we discuss the Event Management process and how to put one together. In the previous post, I presented some design elements to consider. As a follow-up, I will present two documents to illustrate the design process further.

Sample Process Requirements Document

The first document contains a list of sample process requirements. No different to engineering software or systems, the purpose of the requirement document is to capture all considerations that need to be factored into the process design. What activities will be carried out as part of the process and how one activity will flow to another? What information or data points get fed into which activities and what output are expected? Who will perform what activities and when? We need to define some roles, so we know who will do what and when. If you plan to implement a tool to support some portion of the process, some tool-specific considerations should be captured in the requirement document as well. The sample activities outlined in the document are pretty rudimentary and simplistic. You need to tailor your document with requirements from your organization.

Sample Process Flow Document

The second document contains a sample process flow. The process flow shows who is doing what and the timing of the activities. The flow document attempts to describe the process pictorially while the requirement document tries to carry as much description in text. It should be obvious that the process flow should be consistent with the requirements outlined, and, in fact, both the process requirement and process flow documents should convey the same information about the process. Some organizations combine the information from both documents into one requirement/design document, and that is perfectly fine.

In part three of the post, we will combine everything we have done and produce one final process design document. The process design document will include not only the requirements, the flow, and the roles, but also other information pertinent to the process such as the policy statement, a RACI chart, and the process metrics. The final process design document can then be used as the foundation to implement the actual Event Management process within your organization.

Links to other posts of the series