Services work with the same rule: services should not offer more value than is being paid for.
There is SLAs that measure all the variables your service is measured. The rest is added value you have to play with.
To play with them?
Right, there are services with the unique objective of provide the outputs for what they are created for. If the customer wants more, they have to pay more and cannot be discussion about it.
But there are other services that enables you to generate other type of value for your business and that generates ineterest for other business initiatives that could fit with your service model.
What type of services have you in your portfolio? do you have clear what are the services that provides more value to your customer? Are they well delivered?
For the renewal discussions it’s important to review the basic concepts of each application support.
Just 4 main items:
- The nature of the business/application output,
- The real demand done to the application in terms of processes and technology.
The high/low level of contacts with the customer.
- The changing nature of demand (financial closing periods, end month, application changes…).
There are other challenges (from a different perspective):
I’m reviewing ITIL concepts, and I found this picture I want to remind,
We are preparing a service support contract to maintain the corrective, preventive and user activities of an application that is being developed now. This is a new type of application done with new technology, so it’s not repeat the process we did for other applications.
Some key considerations we are trying to keep into account.
- We are planning the support activities in “well in advance”, this is necessary due to the slow customer decision process.
Set expectations of customer takes time, this is a new type of service support so they do not have experience on similar areas.
- It’s important the exercises we are doing with the client in order they understand the service we are going to deliver. This is key, customer assumes a lot of activities are not needed, so they do not want to pay for it 🙂
- Preparation of transition activities between teams is key: documentation, processes, training…; check that all project documents are completed and the quality of the content is aligned with service support requirements.
- Perform the effort estimation is easy, to get paid for it is complex.
- Track assumptions and decisions during the negotiations: “out of scope” has to be defined for all domains of change. RACI chart also helps to complete the responsibility of each piece of work.
Perform measures before to start the service support. Having data prepared is key to understand the use of the system by end-users, volumes…
- Use readiness Metrics to go/no go decision making process (less emotional).
- Communicate properly when the service support is going to start. Try to reinforce the importance of both teams (project and service) working at the same time for a short period of time.
- Have the service support manager involved in the last activities of the project.
This exercise is being very interesting for me.
We are delivering a new service support where we are facing the same situation:
- We are doing a great job in number of tickets.
- We are enhancing the application with little details requested by the customer that is enabling them to spend less time when using the tool.
- We are not closing all the errors of the application, recurring errors are appearing.
- We are not taking into account some functionality changes are affecting other parts, provoking new tickets appear.
There is not enough control of the scope of the application, even when we have a detailed functional analysis that helped us to close the project in a good way.
- The complexity of the application makes that the use of the detailed functional document is necessary to perform the changes: and this use is not happening.
- We are able to close 1000 tickets, but not the application with zero errors.
We are suffering a deep lack of governance. Reasons?
- Communications at product level are not done in the right way.
- There is a lack of change management process when a functionality is requested.
- When a new release of the application is deployed, the documents are not properly updated.
- Client expectations are so high and they are not being managed in the right way.
We have a lot of job to do here,
I had some time and a notebook and I wrote this thinking about the IT service support trends.
It seems to be a stupid exercise, but it’s funny to see that the concepts offered yesterday, today and probably tomorrow, all are the same. With the risks and fears of the client, it’s more or less the same thing.
That’s what I said to some service managers which client was not applying these penalties.
They are not applying it because they are agree with all the other issues the service is solving and they want to let the service run. Other times, the SLA are not so restrictive and they always reach the green light. But there will be a time, when the maturity of the service will be higher, where they will be applied.
It took some time to do it, but I convinced them to measure them.
And now, one of these service managers is so happy. The new call for tender for the renewal of his service contains new SLA tables. He has being measuring the levels during 2009 and the consequence is that now he is comfortable with the real numbers he has.
He now does not have to spend so many time measuring month by month all the KPIs and taking into account that there is just a couple of weeks to respond the call, he has time to concentrate on other aspects and work on a competitive answer.
During this the year the baselines to measure the evolution and efficiency of the Service in the work group were not defined at the beginning of the year.
Of course this ‘oversight’ 🙂 provokes that for the rest of the year there were not a pattern to compare what you consider as ‘good’ and measure it with the real numbers you are getting.
For 2008 we have already defined all the patterns that we can measure with data: SLA of tickets, performance of the enhancements, cost charge, risk management… In fact we already are taking information about how we are working during these 3 last months in order to have a quick reference of the current status of the Service.
Finally the most important things using a baseline are the monitoring and controlling the evolution of the Service with respecting this pattern. After that we can analyze and make decisions to correct the evolution of the Service for our Customer. In addition we want to change corrective work in preventive one.
As you can figure out, this is a basic tool of work in Service Supports. The amazing fact is the absence of this tool…
Unfortunately that day came; our client and our CEO agreed that big part of our services will be provided by India.
People now understand that their work can easily done in India, and they regret all the time spent without thinking in adding value.
Sorry guys, it’s so late!
Now the future is uncertain, but people start to be more aware.
During this year we are deploying CMMI in our Service Support.
The best benefit of this deployment has been the increase of business visibility that people has learned about the activities they perform.
Before to have it, people worked without understand some essential topics of the business. Now people feel more comfortable with the tasks they are performing due to they know the business effect each task has.
I need to improve this knowledge, but the initial evolution is encouraging.