IT organizations bent on continuous improvement and a high level of IT maturity tend to have documented processes for change, event, incident and problem management – and an organizational framework with clearly defined roles for executing those processes.
Whether these processes religiously follow ITIL’s schema or are home-grown, they tend to have a common set of DOs and DON’Ts that go something like this:
- Try to solve as many issues as possible with first responders (if end-user self-help or the help desk staff can’t resolve the issues);
- Handle your most critical business-impacting issues first (assuming you can align alerts from technology domains – i.e., ‘silos’ – to specific business services);
- Route the issue to the responder with the right domain expertise when first responders can’t make things right (in most organizations, first responders tend to be PC experts and/or IT generalists); and
- When fixing things, only make approved configuration changes (to avoid undesired side effects).
Figure 1 illustrates the kind of role-based process framework organizations are putting in place to enable these DOs and DON’Ts. It was also discussed in a previous blog: Balancing Act: A Framework for IT Transformation.
IT organizations with the above DOs and DON’Ts have clear benefits in mind:
- Drive the waste out of the triage process;
- Speed restoration of service quality/availability when it has been impacted;
- Solve more issues proactively before they impact services;
- Lower the overall cost of delivering services; and
- Free highly-paid staff from time-consuming troubleshooting so they can do more value-added work.













