IT Policies

Help Desk Implementation Diary: Testing

This week in his help desk implementation, Jay Rollins finds that most of the initial bumps have been smoothed out and major items have been squared away. But as they test the software, his team raises some issues.

This week in his help desk implementation, Jay Rollins finds that most of the initial bumps have been smoothed out and major items have been squared away. But as they test the software, his team raises some issues.


As we have progressed with the implementation of our ManageEngine Help Desk application, most of the initial bumps in the road have smoothed out. The major items about various communication needs, SLA setup, ticket classification and work tracking are, for the most part, squared away.

As with any new system, over time, users (and in this case IT is the user) start playing with the system. "Hey, here's a button I haven't pushed yet. I wonder what it does?" And eventually, you start getting requests for added features and functions. With the help desk software this is no different.

We started to deploy the Change Management feature. As we start bringing on partners to manage our printers, copiers, and network equipment, we wanted to maintain the customer interface. Therefore we have made sure that our partners use our help desk system.

When it was a small IT team, change management was pretty straightforward. We made a list of the changes during our Monday meeting that were going to be deployed during our weekly maintenance window. Now, with partners, the scenario gets more complex and we have to leverage the system to help us facilitate changes.

What I have found with the ManageEngine product is that Change Management and Problem Management are partially integrated. You get an issue or a request and if it can't get addressed right away or needs some extra steps that can't be accomplished in a 20-minute customer interaction, the issue gets moved to a problem.

The Problem features allow you to address and document the short-term resolution or workaround, document the solution, and schedule a "Change" to the infrastructure to deploy the solution. The problem feature has an "Analysis" step that allows you to denote the impact of the problem, the root cause of the problem and what the symptoms of the problem are.

Next step in the process is the Solution step. Here, you document the current workaround and, in a separate section, you add the final solution. Tasks can be assigned to individual technicians and includes status tags and the usual start/stop schedule elements. There's also a work log element used to track time spent on the project.

What's cool is the next tab. You can associate incidents and requests to the problem. This helps you track the impact of the problem. Once the problem is created in the system, you go through the history of requests and incidents and add them to this tab. On a going forward basis, the help desk team can continue to add incidents to this problem. This helps them identify tickets that are going to be addressed once the problem has been resolved. What I have not found out yet about this feature that I plan to shortly is the following:

1. When an incident is attached to a problem, do the communication mechanisms to the end user transfer control from the incident view to the problem view? Let's say an incident is attached to a problem. When the problem has been completed, does it close the incident automatically and take care of sending the "Incident closed" e-mail communication?

2. Does the portal view automatically re-direct users to the problem and give them insight into the progress of the problem?

To implement the solution to the problem, you need to make a change to your infrastructure. The change management feature is the next step in the process. I've found this integration is not as tight as I would like. The problem and the change are associated by creating a change and then selecting the problem tab and selecting the problem or problems associated with the change. You can also do this for incidents.

I understand the logic. There can be a one-to-many relationship between a change and a problem. The same thing goes for an incident or request. A change can also be a list of changes rolled into one change package that can address problems and incidents as well. What I would like to see, however, is the ability to schedule a change within the problem and have it automatically inherit the associated incidents. Then, if there are additional problem or incidents that will be rolled into the change, you can open the change item and add them after the fact, or even better, associate them from the problem or incident screens.

Other interesting elements about change management include the planning tab. There is a section for impact analysis. No guidelines, but a place to add free text and attach a file. Impact, as an FYI, is understanding what systems can be impacted with the change. I like to look at the control books for the servers for this and run through the usual suspects such as disk, network, CPU and memory impacts to a server, but also the services impacted and the applications impacted by those services. This is where the expectation setting plan is built.

The ext item on the planning screen is the Roll Out Plan. Same free text and attachment capability. This is a good place to insert a template response, however. What time is the change scheduled for? What is the order of install? What are the interim test steps? Do you have to make sure something else is working before you move on? When is QA going to review the production changes and give the go/no go decision?

Next is a back-out plan element. Another template would be useful here. If something happens, what are you going to do? Are there changes that are independent that can be deployed, while others are backed out? What is the impact of this and how do you do it?

Finally, is a checklist. Free text and attachment again, but it would be nice to create a template that can go in here with checkboxes. You can get into some detail here. What services were stopped, when they need to be restarted, a service checklist denoting which services should be running, system has been rebooted, system has been added to production network, etc.

Once you are through the planning stage, there is an approvals tab. I'm not a big fan of the approval process. How it should work in my opinion is you identify your change management board members and create the list (which you can do) and the system sends e-mail notification to the board members to review the change. There is no work flow for the various approval stages. Basically, you select one of 10 items in the drop-down menu (Requested, Planning, Review, Approval, Approved, Rejected, Implementation, Testing, Release and Completed) and that serves as the communication.

There isn't a way to communicate the various stages as the system only communicates once when the change has been created. I could not find an audit trail for the various approvals. There is also an area where you can go in an select "Approve" but it is not connected to the status incide the change screen. How it should work is that everyone who needs to approve the change clicks the "approve" button and only then will the status change to the next level. When certain steps are completed, the status changes appropriately. If you can have control over what is required versus not required, that would be better.

The reporting on these various elements are pretty good. To get complex, you need to do some serious tweaking, but the interface is pretty straight forward.