I visited two very different customers recently. They had very different problems and the solutions I suggested for them were also very different. But there was one thing that they had in common — they had both delayed starting the improvements they knew were needed because the costs and risks were too high. Instead, they had done nothing and so allowed their problems to continue completely unchecked.
For both these customers, the solution was very similar. Both needed to “Start where you are”, “Keep it simple” and “Progress iteratively”. These are three of the guiding principles from ITIL Practitioner, and between them they encourage IT service managers to adopt an agile approach to resolving issues, rather than taking on big, risky, expensive IT service management (ITSM) projects. I created a few podcasts on these topics for SysAid’s Back to ITSM Basics project, so please do listen to those if you are interested.
If you also need improvements that seem too expensive, or too risky, then read on to learn how you can get started.
One of the organizations that I visited is very large. It provides support services to many external customers all over the world, and has lots of service desks. Some of these service desks are dedicated to a single customer, others support multiple customers, and some are for internal users. Some of them provide logging and dispatch only, others provide level 1 support as well. While many of the service desks use the same ITSM tool for logging and managing incidents, there are quite a few other tools in place as well.
Almost all of the customer communication, for all the different service desks, takes place by phone. The organization would like to shift to more efficient channels, e.g. text-based chat and a self-service web portal, but because the company is so big, the implementation costs would be enormous. IT has, in fact, identified a tool that could provide chat for all of their complex environment, but since they can’t be confident that an implementation project would run smoothly or that the returns would justify such a big investment, they can’t get the funding for this.
As I talked to the IT department, the solution to their problem became obvious. Instead of trying to implement chat for all of their users, which would be a very big and expensive project, they could start where they are, start small, and grow in small steps.
The organization’s users already have a tool that supports chat, although it is not currently used for IT support. So it would be quite easy for IT to start there.
Here’s what they can do:
Find a small group of users and offer to use this existing tool to provide them with IT support. Monitor carefully to reveal any issues for the service desk/help desk or the users, and resolve them before scaling up to support more internal users. Eventually the IT department will reach the limits of how well this tool can scale in their environment, but by then they will have:
This gradual implementation of chat would be very low risk, and, by starting with a tool that is already in use and familiar, would not involve much cost. By the time the IT department has scaled up to supporting a large number of internal users they will know whether a full implementation using an expensive tool will be a cost-effective investment, and they will also have learned what needs to be done to ensure success. If they wish to go ahead with an expensive new tool, this will give them everything they need to create a business case for the next stage.
The other organization that I visited is MUCH smaller. They have just two staff working on their in-house service desk, supported by a manager who carries out other roles as well. They have a few thousand users in a small number of offices, all in a small part of one country. They are finding it difficult to manage user access controls.
When a new user joins the organization, they ask about what access this user needs, and then grant individual rights to the specific applications and data. When people change jobs or leave the organization, it’s difficult to find all the access rights that have been granted, so these are often left in place – and this creates a significant security risk.
The support manager knew that the solution to their issue was to move to role-based access controls (RBAC), where all access rights are granted to roles, and then those roles are assigned to users. But there had been no attempt to migrate to RBAC because of the risks involved. Sometimes things go wrong during even the best planned migrations, and this could cause significant cost and risk to the business.
The solution for this customer was also to take an agile approach. Instead of attempting to change everything at the same time, the organization could start where it is, keep it simple, and do it a bit at a time.
Here’s what they can do:
Next time a new employee joins the company, grant all the rights that user needs to a newly created role, and then assign this role to the new user. This should be no more work and no more risk than would normally be involved in providing appropriate access to a new user. Once confident that the role works well, and that no changes are needed, go on to migrate one existing user to the role, removing the current rights that user has. Again, this would carry only a small amount of risk, and the change could be undone quickly and easily. Next, continue adding users a few at a time. Once confident that there are unlikely to be any issues, move over everyone else who should be assigned to that role. When the opportunity arises, create a second role, and migrate users in the same incremental, low-risk, way.
This approach means it will take quite a long time to completely move from the current situation to a well-managed RBAC implementation. But the one improvement that you can guarantee will never be finished is the one you think it’s too risky to start in the first place. By starting where you are, keeping it simple, and progressing incrementally, the improvement this company wants will eventually be achieved, with little risk, and without a big project that keeps its two support staff tied up and unavailable for long stretches of time.
Many organizations use agile software development to reduce risk and speed up time to market. The same ideas apply equally well to ITSM. Almost every ITSM improvement can be carried out in an agile way, and there really is no need for huge, expensive ITSM improvement projects.
If you’ve been putting of improvements that you KNOW you need, because of the cost and risk, then why not think about how you can “Start where you are”, “Keep it simple” and “Progress iteratively”?