JRPARIS Operational consulting offer to improve IT Incidents

Our consulting offer focused on IT Incidents aims to get rapid progress on this recurring topic.

 {snippet jrparis_article_01|2015-01-30|2017-01-31}

At the very start of the improvement process, we propose to act:

- animate incident workshops,

- upstream work on the releases of the application versions,

- improve reporting by structuring the support work products.

The actual approach will of course depend on your context, your goals. Generally, issues are linked.

Too many IT incidents!

You have deployed a Digital solution. It may happen that IT incidents are too numerous. This will jeopardize top management confidence in IT teams. A hot-line with low performance results will lead users to put pressure on their directions. Business managers will mechanically over-demand from the IT departments. In the hope of getting adequate applications, they will ask for much more, with tight deadlines. The inflation of the demand can also be functional, but with no associated budgetary growth. New applications, developed too quickly, will be poorly managed by operators and will increase the rate of incidents.

Indeed, improving incidents rate is a priority for IT operations.

Digital applications increase the opening hours of the service. But IT operations cannot be requested 24h / 24h, even for solving emergency situations. Jumping from one fire to new one, even the best talents get tired and go away. Others abandon methods, are taking on bad practices and will find themselves in difficulty when they are requested to carry out projects.

Improvement process. How to get out of this negative loop?

Is there a magic, universal recipe? ITIL brings an interesting framework, for example with the separation of incidents / problems, authorizations of changes and a customer oriented Service Center. However, the operating teams are often not enough trained and organized to transform themselves spontaneously into an effective service center. Obviously, help-desk’s teams cannot do it alone.

Solutions to operational problems are also connected to software development teams, with poor availability for end user support.

Consulting offer

We propose to help the teams according to 3 operating modes:

Incident workshops form a shock campain to "break" the frontline of incidents with high visibility. This one-off effort reduces the obstacles that block progress.

The support of major IT releases aims to enhance control of this critical phase for the service. This special focus on the operational releases (MEP in French = Mise En Production) is carried out in order to reduce risks, but also to maximize the management of future incidents. After the GoLive, the stock of defects must be treated in pragmatic way with the support of the project teams that can be mobilized before they can move on.

The categorization is the background work to make the teams more efficient on the portfolio of incidents, to benefit from indicators allowing to pilot and, above all, better communicate. It will then be time to consider a real Service Center.

Of course, each company has its own priorities and context. It is possible to frame these actions more specifically by an overall assessment (Assessment ITIL ...). Our doctrine of intervention is based on our double consultant and managerial curriculum. We help the operational staff in situ, with a real requirement but also with respect.

IT incidents workshops

An IT incident workshop usually deals with a business domain.

The workshop brings together representatives of the helpdesk and operations, but not only. It is necessary to obtain the involvement of software development teams and also from business units; if the relations with the users allow it.

An efficient workshop’s animation is to follow step by step an incident and then up-stream on a portfolio of problems. The facilitator can also take care of the formalization of the "findings", the summary for the management and the complementary surveys which require too much time for the operational teams. By reiterating the workshops on other areas, the participants are formed during the process to ITIL best practices.

The benefits of a workshop is of course to improve the short-term, at the level of help-desks and on the various links in the chain. The gain is also on the medium-term: the workshops reinforce (sometimes reestablish) a collaboration studies-help-desk. The visibility of problem portfolio management has the advantage of making the current limits more acceptable to the stakeholders; which allows each to better address his part of the problem. The teams in contact with the users feel supported and invest themselves more. 

The commitment of the management opens the way to a more structural improvement of the quality of service. It will be time to consider a true Service Center.

Software releases

Software release assistance consists in strengthening the system by implementing "best practices". The release phase is often stressful due to short lead times, risks related to late activities. Typically, the objectives are to improve one or more of the following:

• • Service management tools
  • Operating documentation
  • Communication
  • Retro planning
  • Perform the release itself

By adding an additional production-oriented specialist, the project will be able to progress further in the finalization of development activities, delivering the "latest" corrections to reflect test returns. In general, the teams are not ahead of these points! Most importantly, this expert can address the points that are specific to operations and can create or complete the relevant operational documentation, the operating files, the indicators, etc. Why deprive yourself of control and steering means during the most critical phase of the take-off of the application?

It is important to produce these documents, ideally enough before, at least during the release. We must resist to the temptation to postpone the delivery of these documents after the hardest phase should be over. After the Go Live, the operational staff will take less ownership of the delivered documentation. On the other hand, it is very interesting that the documentations are used jointly by the studies and by the operators. This will only strengthen the dialogue on the long term.

Due to the overload generally observed during the MEPs, the project tends to fall back on itself and less to ensure communication. However, it is possible to minimize a considerable part of the users and business impacts by a repeated communication and by separately targeting the different users’ populations.

Application’s release is a project in the project, so with a schedule. Like all schedules, it will support several types of stakeholders: trades, computer scientists, etc. It must be able to be amended quickly, be precise. The release manager cannot produce it alone. Studies must bring their knowledge and support. It will be all the easier to react to adverse events if the project design has had integrated the necessary fallback scenarios, potential bypass. The operation’s team members will be a lot more comfortable if they are able from the beginning to use appropriate communication tools.

By relying on us for building the micro-planning, you can benefit from a proven know-how: reviews, blank repetition.

The release requires a disciplined execution over a time slot that can extend to additional long periods. We can complete the device in terms of schedules and activities. You benefit from both a "military" organization and experience on many successful releases or moves. For critical applications, if the size of your organization does not allow access to a pool of backup resources, we can reserve a team of high-level specialists, experienced in many releases or successful moves. In the event of a hard blow, you will not be alone in the world.

Do not wait the day before the release of your major ERP migration project to call on our services. Test us on smaller projects, it will only be more beneficial. You have to train to progress

Categorization

You enter all your tickets? Very good. And what for?

Categorization will allow you to capitalize on the effort, the discipline you consent to enter incidents’ tickets.

Why categorize?

Categorization consists of structuring information, categorizing categories, etc. But, it's not just about classifying to classify.

The goal is to improve how other operational processes “hook” themselves with the incident management process. In order to provide the necessary results, a "high level" process must receive appropriate inputs in relation with its level, so more synthetic than those handled by an operational process. Categorization can synthesize the information to communicate between processes of different levels.

What are the expected benefits?

The benefits of structuring operations concern the day-to-day management of the incidents but primarily the other processes:

By having pre-established categories, the operator can process a unitary incident in a more efficient, better prioritized way. It is obvious that an experienced operator on a domain will not make a major gain in performance.

So, the main benefit is mostly for other processes than incident management. It will be possible to have better indicators, to define with the trades realistic levels of service, to raise the debates of a notch: to allocate more resources rather than to be stuck in a search for justifications.

How to categorize?

It's not rocket science. Teams often encounter the same pitfalls. To avoid the white sheet effect, it is possible to start on the existing nomenclatures and to amend it. To avoid falling into an unstable categorization, one must look a little further than the short term and integrate the need for processes to connect. Also, it is necessary to discuss with the business, to capture the specificity of the context and to allow a report which will show mutual interest.

Depending on the availability and training of the actors, it is possible to work by alternating interviews, reviews.

Once the category, better saying, the required categorizations have been set-up, repeated several times, with effective interfaces with the other processes, you will have many more elements to sell the Service Center to the management.

If you start directly by establishing a Service Center, according to the approach Top => Down approach documented in the literature, you will take risks, get less means than it should and an insufficient support from management on the long term.

Our consulting offer is differentiated by its pragmatism. We know how to start from the concrete. It "starts from the bottom" and grows to higher governance level.