There are a number of routes organizations can take to getting their helpdesk employees certified. You should first and foremost research into what helpdesk certification actually is and means. In most cases, companies that provide helpdesk certification offer courses in Helpdesk Etiquette, technical etiquette, computer skills required for helpdesk operators, helpdesk terminology and best helpdesk practices. Or, some version of that skill-set. What is essential is that they also offer an exam that verifies the certification information learned and also adds some credibility to the entire process.

An avenue that I have consulted business in pursuing is a helpdesk certification train-the-trainer program. By that, I mean that your business choose your senior (or who will be your senior) helpdesk personnel to take part in a formal helpdesk certification course. They then come back and develop a helpdesk training program for the entire organization based on what they took part in and learned. What this gives you is an extremely cost effective helpdesk training program that is also tailored to meet the requirements of your organization. Also, having your own personnel develop and deliver the training re-enforces the material. In the end, this will develop very senior and knowledgeable helpdesk staff.

The benefit of having a helpdesk that is certified is many. First and foremost, you will have personnel that completely understand the helpdesk concept and how it should work and support the company. They will be shy to let you know when the company is straying away from the helpdesk mission, or if they don’t think the current structure is supporting that mission. Obliviously, having personnel certified ensures that they are qualified for the job they are doing and are thus, more confident in the job they are doing. Moreover, they will know what skill-sets it is that makes them better helpdesk professionals and, as a result, become aware of the need to constantly improve their active listening and problem solving skills.

You will see that the negotiating skills of you helpdesk staff drastically improve and you will have less and less high stress calls. Your customer – helpdesk interaction will become a more positive experience. Your customers will feel that they are interacting with a real professional that is focused on quickly and efficiently solving their particular problem. Thus, you will have folks that are not only experts in a certain technical aspect of the company but are also experts in being a proficient and valuable helpdesk specialist.

Share on Facebook

Thus, you end up with a number of folks, in your helpdesk, that are looking towards their next job and not the actual job they are doing now. How do you keep them motivated? How do you keep it fun? How do you keep helpdesk personnel happy to be helpdesk personnel?

The answer is to be a great leader that values the helpdesk position and truly makes it a job that is the entry level for the next great IT technicians you will have in your company.

You should be offering or cycling your helpdesk personnel through apprentice tech positions on a weekly basis. I.E. A helpdesk person would work every 3 weeks on the helpdesk and one week in an apprentice tech position. The tech position requires some thought and ideally should be part of bigger program that is structured and leading towards certification within the company as a technician.

Of course the problem comes in that you do not have an endless amount of technician positions. However, folks should understand that they are number 1 for the next position available or number 2, etc. In the meantime, as you become more and more certified within the companies program it should result in higher pay. Good, qualified, motivated helpdesk personnel are invaluable and the modestly higher wage will be extremely valuable to the company in the long run.

Another, great way to build team unity with the helpdesk is making it a fun place to work. Not an out of control place to work, but a fun place. Some easy to implement ways to make that happen is encouraging holiday themes for the workplace, recognizing birthdays with pizza and cake, develop a recognition program that rewards exceptional service to the customer, organize a Crazy Friday for the last day of month where employees dress up or down and party food is served, or, have one day a month that the manager servers lunch to everybody.

Whatever you decide to do, use the philosophy that the helpdesk are your frontline soldiers. Great generals visit their frontline troops a lot, they give them great accolades and they promote those frontline troops to higher positions because they understand the battle space. You expect great things from your frontline troops so treat them as your companies greatest asset. Your helpdesk and your company will be prosper and grow beyond your expectations.

Share on Facebook

Many companies eventually develop a “gating” process that defines a rule such as …”all changes for next week need to be submitted by Friday at 10 am and then reviewed at the 2PM weekly CAB meeting.”  Any requests that don’t make the cut need to be postponed until the following week.

When to Use an Emergency Change Request

A change request is only an emergency request assuming there are rules and schedules in place that need to be overridden for this particular change.  Most organizations have rules that prohibit production changes during a critical period, such as month end or quarter end because any change during that time may interfere and cause time critical processes to be delayed.  For example, there may be tight timeframes in which reports need to be produced for clients or regulators and the idea is that no unnecessary changes to the system should be made that might jeopardize those goals.

If however, a problem is discovered that is deemed so serious that it should be fixed immediately, despite the standing rules and procedures, then emergency procedures are followed.  Typically such a so-called emergency change requires approval from a higher level of management than a normal change request would.  This ensures that the rule is not being abused and that managers at the proper level are aware of all emergency changes that are implemented.

Share on Facebook

Firstly, you need to make sure that accurate note taking and logging is enforced throughout the entire service support cycle. Encourage great work and discipline shoddy effort. All employees must take the note taking process seriously and the only way that will happen is if management takes it seriously. A huge frustration to customers is when they have to repeat their problem over and over again to different levels. Folks don’t mind confirming the problem, but they don’t like having to repeat it.

In order for the customer to have that experience, it is a must that at every level in the support chain they document and/or update the following:

• A detailed description of the problem.
• The error message, if any, or resulting negative output.
• How often it occurs.
• Step by step instruction on how to reproduce the problem, if reproducible.
• All information about the system and any recent changes to the environment.
• Customer information and product serial number.

These should be captured in a form that is clearly written (preferably type-written) and automated. The information should be part of a template that repeats the same information in the same manner each and every time. Again, an automated tool is highly recommended. Many tools now come with the ability to record the conversation. If you have such a tool that audio file should be available to the FSR so he can listen first-hand to the customer describe the problem.

However, no list can be complete. Many products differ widely and it is extremely useful to have the FSR’s review the forms and templates used for each product to evaluate if they are getting all the required information they need to do the job effectively. Moreover, you should have a periodic review with your FSR’s on a bi-yearly basis (or, as required) to ensure that the information gathered is meeting their needs.

Lastly, make sure the FSR reviews thoroughly the information he receives from the helpdesk, technicians and engineers before going to a call. It will mean more to your customer relations to have the FSR arrive a little late with all the information required then to arrive on time and have the customer have to explain the problem all over again. The latter makes the customer feel like the helpdesk was a waste of his time and has no value-added.

Share on Facebook

You may ask what a Service Delivery policy is? Well, it is a clearly defined document that outlines your helpdesk availability and your helpdesk service level priority description. That coupled with a great customer relationship management (CRM) tool will allow you to clearly calculate, define and re-calculate your helpdesk call response times and, more importantly, set clear customer expectations regarding response time.

Let’s first look at service availability. Service availability should clearly outline the hours of operation for your helpdesk and, if anything other then 24/7, the exact times for different regional locations. This should be large and clear, the customer should see this first and foremost and it should be available online, in product documentation, in workplace memorandum and/or via a recording in phone “welcome” message.

The service level priority description breaks down responsive actions by priority. These priorities can be: critical, high, medium, low, none or 1, 2 ,3 ,4 , 5. Then for each priority you would correlate a response time and a resolution time to each priority.

With this type of detailed matrix you can then give customers feedback that their problem is designated- “A level 1 priority and the expected resolution to their problem within 2-4 hrs.” Thus, the customer having seen this breakdown before contacting the help or service desk (because you have made this information available as per the instructions for the service availability information) now has a confirmation to what he expected would be a reasonable resolution time.

Now having outlined clear service response and resolution timeframes you can use the metrics that you capture with your CRM tool (many, many excellent tools are available) to track the following must-know metrics:

• Average time waiting for phone calls to when helpdesk answers
• Percentage of calls solved first time
• Percentage of incidents or service request breaching resolution time targets
• Customer satisfaction

With these metrics you can track whether you are meeting your response time goals and re-define those resolution time response and resolution times as required for your helpdesk, identify where you require more staff or identify choke points in your helpdesk.

Share on Facebook

While this story is funny at first blush; at a deeper core level, it also highlights the absolute importance of the service desk team members asking the right questions. Reasons abound to support the importance of asking the right questions. Let us examine some of the most popular reasons and theories.

First, a major issue shared by most service desks is the overwhelmingly high volume of calls, which usually results in longer wait times for customers. Wait time is the number one complaint that customers have about the service desk, and anything that can speed up this process will undoubtedly increase customer satisfaction. Thus, it is extremely important that when a customer does speak with a service desk team member, that the team member can quickly diagnose the problem and get the proper technician or department involved. The ultimate effectiveness of this series of actions is foremost dependent upon “correctly understanding the problem.”

Therefore, regardless of how frantic or chatty a customer may be in explaining the problem, the service desk analyst must ensure that he or she has systematically asked the standardized questions designed to diagnose the problem and then guides the customer towards the correct solution. Moreover, diagnosing the problem correctly the first time will speed up wait time significantly because an incident ticket will not be sent to the wrong assignment group—thus eliminating the customer’s need to waste time waiting in the wrong group’s queue or to repeat his or her stories to a new support engineer.

Furthermore, collecting data metrics on your products is an intricate part of any business model. Data collection regarding service support normally comes from two areas: 1) the service desk and 2) the service provider.

Using Information Technology Service Management (ITSM) software, the service desk logs an incident under a certain category when the call comes in, and the service provider engineer will log the problem under the appropriate resolution category when the incident is resolved. Thus, managers can review and decide where they need to spend money on resolving product issues, either by patches or upgrades. If your service desk is misdiagnosing the incidents, or not quite fully understanding the incidents and miscategorizing them; as a result, the manager will not receive the accurate and precise metrics that they require. Thus, the whole company becomes affected for many change releases because the proper resources were not working on the right problems. This whole process begins with your service desk team members asking the right questions and ensuring that they completely understand the problems being explained by the customers.

Finally, one of the main objectives of your service desk is to instill customer confidence. When a good service desk member quickly guides a customer through explaining his or her problems, and then either resolves the incident or connects the customer to the correct service provider for resolution, the customer gains great confidence in both the product, and, by extension, the company. However, as a manager, you do not want customer confidence to be exclusively dependent on the temperament of your service desk team members. While you may have a fantastic service desk team, every member has bad days, and every team member makes mistakes. Thus, it is extremely important that the service desk manager has good service desk practices that ensure the proper and standardized questions will be asked up front—every single time; and that each and every problem will get answered and resolved in a timely manner. Moreover, the incident will be logged under the proper category; and if it is a reoccurring problem, it will be addressed in the form of future patches and versions.

In sum, the first contact with the customer is important because it affects the entire service desk process. Additionally, it is equally important for service desk managers to ensure that their service desk team members are asking the right questions. Many service desk managers often overlook and underestimate this aspect of the service desk. If you already have a good bank of clear and concise questions, make sure you continually review and test these questions to validate that they are still the right ones. Otherwise, the whole company will eventually be affected.

Share on Facebook

The change calendar drives the Change Advisory Board (CAB) meeting. Each change listed on the calendar is briefly reviewed, and the change owner (present at the meeting) attests to the readiness of that particular change for implementation. The items on the change calendar are separated into either “approved” and “pending” changes.

The approved changes are the items that have passed the standards of readiness already in place. For example, an approved change will have testing evidence as well as the required managerial approvals attached. Prior to the meeting, the CAB will have reviewed all submitted changes and classified each change as approved or pending. On the other hand, a change may be classified as pending because required approvals were not obtained before the CAB meeting. Furthermore, depending on the local practices, the CAB manager may approve such change requests for implementation the following week if the submitter succeeds in obtaining the required approvals by close of business on the following Monday.


Another important indicator on the change calendar is the planned implementation time—it indicates whether a specific change can be implemented during regular business hours or after business hours. For example, a change that may require shutting down a software system or turning off a piece of hardware may need to be implemented after business hours in order to not interfere with the normal operation of the business.

Moreover, the change calendar typically lists the names and contact information of the change requesters and the release and deployment managers, so that when necessary, parties can reach each other. Depending on the volume of change in a particular environment, an open phone bridge may be a standard arrangement to facilitate after-hours communication.



Lastly, the summary section of the change calendar document lists any known future changes that the development and support community need to be aware of, such as major planned downtime or major system upgrades that may require action on their part.

Share on Facebook

1. REQUIRED APPROVALS NOT ATTACHED

Any IT change control process worth its salt will require approval for a change from someone other than the change submitter.  Typically, each major subsystem, or even application, is assigned an “owner,” who is responsible for approving every change to the subsystem or application.  This type of structured procedure keeps the chain of responsibility intact and prevents unannounced or unauthorized changes from disrupting a production environment.

2. NO BACK-OUT PLAN INCLUDED

Another basic part of any sensible change control process is the inclusion of a back-out or fallback plan.  With any proposed change to a controlled IT environment, there is always a chance that some unforeseen circumstance may prevent the successful implementation of the change, whether it be large or small.  A clear statement of how to return the environment to its original, pre-change state is a critical component of every well-planned change.

3. REQUEST SUBMITTED PAST STATED DEADLINE

In any operative enterprise or organization, IT change management is a continuous process that evolves with the needs of the company.  In order to manage change effectively and smoothly, everyone must comply with his or her deadlines so that other people responsible for other steps of this continuous process have a reasonable amount of time to properly perform their function. 

For example: at Company A, software changes are managed on a weekly basis; therefore, a reasonable deadline would be that all changes scheduled for next Monday be submitted by Friday at noon, so that they can be reviewed at the weekly Friday 2:00 p.m. Change Meeting.

If some such logical schedule is not followed, chaos is sure to ensue.

4. EVIDENCE OF SUCCESSFUL TESTING NOT INCLUDED

Another vital requirement of a well-managed change system is that all change requests must include associated and relevant testing evidence.  Change to a controlled environment should not ever be made “on faith.”  There are, of course, situations where the exact actions that will occur in the controlled environment cannot be performed in the test environment (like sending money to a client), but all changes should be simulated to the utmost degree possible to reduce the likelihood of errors in the controlled system.  Change requests with no testing evidence attached should be rejected by the CAB – except where special and well-understood circumstances apply.

5. IMPLEMENTATION INSTRUCTIONS MISSING OR INCOMPLETE

To standardize and further automate your change process, you will need a plan that describes what the change action is.  Some companies refer to this plan as an implementation plan.  Regardless of what you call it at your company, you will need this plan.  As your organization changes over time, the implementation plan should evolve with such changes.  Moreover, it also has to capture all the standard change actions that have occurred company-wide.  It is the responsibility of the change requester to add the required information to the plan.  It is the responsibility of the CAB to assure that the plan is valid before anyone tries to act on the instruction it contains.  In sum, it makes perfect sense that an incomplete implementation plan will cause a change request to be rejected.

6. REQUESTED IMPLEMENTATION DATE IS IN A FREEZE PERIOD

Most organizations will block off certain days every month when any normal changes to the controlled environment are disallowed.  For instance, the change blackout period might be the end of each month when the company is closing out its financial records for the month.  During such a period, only emergency changes are permitted, and any such emergency change usually requires a high-level approval in order to move forward. 

The requirement of high-level approval accomplishes 2 objectives: 
1) Assures that senior managers are aware of the change
2) Discourages the misuse of the emergency change method by those who somehow did not complete a process on time.

7. REQUESTED CHANGE COLLIDES WITH ANOTHER SCHEDULED CHANGE

Another important function of the CAB is to prevent colliding change requests from being teed up at the same time. 

Example: The owners of System A are not fully aware of the plans and activities of System B.

Over time, the CAB should become sufficiently aware in all of the company’s systems that it can help prevent changes in one system that would negatively affect another. 

Example: System A produces output that is used by one or more other systems in the company.

Therefore, a planned change in System A might cause a problem in some downstream system that the owners of System A might not have considered.  The CAB can reject a change request when it detects such a situation.

8. REQUIRED CAVEATS/LANGUAGE NOT INCLUDED IN APPROVAL

A particular company may require that certain statements are included in every change approval form.  A federally regulated company may require, for example, that the Sarbanes-Oxley compliant controls be included in all change approval forms.  The lack of adhering to such controls would be a valid reason for rejecting a change request.

9. PROPER REQUEST ROUTING INFORMATION NOT SPECIFIED

A well-designed IT change request will include instructions that tell an analyst what group the change request should be sent to—that is, who will actually do the work described on the change form.  Without such information, the change request cannot be processed and should be returned to the requester.

10. CAB DECIDES THAT A REQUEST IS NOT COST-EFFECTIVE

The CAB can operate at a number of different levels.  In addition to processing the daily requests for change to existing processes, the CAB can also evaluate the cost-effectiveness of large, capital-intensive changes.  Some companies reserve such reviews for changes with an estimated cost over “X” dollars.  If the CAB decides that the proposal is not cost-effective, the project would be stopped.

The 10 issues described above are just some basic characteristics of a well-designed change process.  To delve deeper into ITIL-based change management, try the change management section at  IT Library .

Share on Facebook

First, in a September 2009 blog article titled Moving Beyond Compliance: The Status Quo is No Longer Acceptable, government technology heavyweights, Vivek Kundra (Federal CIO), Robert Carey (Navy CIO), and Vance Hitch (DOJ CIO) informed the public that a Security Metrics Taskforce was formed to combat the continuously evolving threats to our nation’s information security. Experts, from both the Federal community and the private sector, such as the Federal CIO Council, the Department of Defense, the Director of National Intelligence, Privacy Advisory Board, and many others held their inaugural meeting on September 17, 2009, to discuss and debate, and subsequently to develop new metrics for information security performance for Federal agencies that are focused on outcomes, rather than mere compliance. By shifting the focus to outcomes, the experts anticipate that the change will “enable new and actionable insight into agencies’ information and network security postures, possible vulnerabilities and the ability to better protect our federal systems.”

Although this blog does not specifically state that Federal IT spending will increase in the near future, all signs point to “Yes.” Experience and common sense indicate that certain actions and key words = more Federal spending.

A new taskforce/committee, Security Metrics Taskforce, was formed. This new taskforce will evaluate threats to the electronic infrastructure of the Federal government.

The Security Metrics Taskforce will develop a new set of security metrics. Factors that will impact the development of new metric include: “a trust but verify approach, fulfilling statutory requirements, real-time awareness security posture.” “Fulfilling statutory requirements” and “real-time awareness security posture” are phrases indicative of more Federal spending since more manpower—both administrative government workers as well as IT specialists—must be hired, and more hardware as well as software purchases and upgrades must be implemented in order to fulfill the new security metrics.

In the most recent issue of CDW IT Monitor, a bimonthly indicator that tracks the direction and momentum of the US IT marketplace, all signs and trends point to the continual increase of Federal government IT spending. For starters, when surveyed, Federal government IT decision makers anticipated growth on many levels—“44 percent of Federal government organizations plan to make significant software purchases in the next six months, an increase of 14 percent since June.” Additionally, “89 percent of Federal IT decision makers plan to make hardware purchases in the next six months, an increase of nine percentage points since June.” Though this short blog does not offer any explanation as to why Federal spending is increasing, by taking into account the article Moving Beyond Compliance: The Status Quo is No Longer Acceptable, and the subsequent analysis, we can safely draw the conclusion that Federal IT spending will be increasing in the months to come.

Perspective Conclusion on Federal IT Spending:

Federal IT Spending will increase in the areas of Public Healthcare, Defense, and general Information Technology in 2010—due in part to projected plans from President Obama’s executive branch as well as the typical upgrade cycle for most technology assets. No doubt some of the Federal IT budgets increase will be spent on Microsoft Windows 7. Moreover, the government’s main expenditures of 2010 in IT will vastly exceed expenditures in previous years with the focus on the aforementioned Windows 7, Process Improvement such as ITIL, Security Software, and Asset Management Software.

For more information on the Federal IT articles mentioned, check out the following sites:

Federal IT Dashboard

CDW IT Monitor

Share on Facebook

Share on Facebook