The development and deployment of a new IT Service Management (ITSM) solution is an exciting and important challenge. It is an opportunity for an IT organization to transform the quality and consistency of the service they provide the business while maintaining “what works” and retiring “what stinks.” The starting point to achieving measurable success begins in the early stages of requirements gathering and design definition. The following are 5 tips to follow to keep you on the right track:
1. Focus on process automation, not tool design
The most sophisticated service management tool is useless to an IT organization without repeatable processes as inputs/outputs. The only purpose for any technology is to automate existing processes. If the processes are broken, the system will not fix it. This will also help you avoid the common mistake of tailoring your business to fit the tool rather than fixing your process.
2. Identify the critical business services IT supports
Every major design decision should be prefaced with the question “does that customization/configuration of the tool help us support the X business service better?” If the answer is “no,” the requirement may not be needed.
3. Do not get buried in cosmetics
Do not spend time in initial stages debating over labels and colors. The cosmetic requirements are traditionally a moving target and furthermore, are simple programmatic adjustments. Instead, concentrate on business needs. For example: need capability for power users to open service requests without ordering from the customer-facing catalog. From there, focus on the workflow, repeatable steps and simplicity for the users.
4. Do not build “Current Tool 2.0”
I have facilitated many requirements and design sessions that start off with the key stakeholders criticizing the effectiveness and functionality of their current solution. We then spend the next few months attempting to rebuild the exact same system. Every proposed requirement should be challenged with a simple question: “Why do we need that?” If the answer is “because that is how we have always done it,” it may be time to make some changes.
5. Document to prove each requirement has been met
A requirements matrix should be created that maps each requirement to the design section that covers the details on how it will be developed. This matrix should be extended to map to the specific test cases documented to prove the functionality works. Not only will this provide a mechanism of testing each requirement, it will also control the emergence of late-breaking requirements that could jeopardize the build and testing phases.
Related reading: learn how ITSM elevated IT Customer Service for a premier transportation company in our ITSM Case Study (no registration required!).
About the Author
Mark Bower, Solution Architect - Evergreen Systems
Mark has more than 10 years of experience in ITIL Consulting. He is ITIL Practitioner certified, and has served as both Solution Architect and Project Manager for more than twenty-five ITSM tool and process implementations/transformations to date. Mark currently architects and leads ITSM deployments for Evergreen Systems.