How to explain that following a process does not cause delays

By ITIL® from Experience©

It is sometimes difficult to explain that an ITIL® process or any process1 for that matter is needed and that it will not cause delays and extra work. After all, incidents are resolved, service requests are fulfilled and changes are made daily without a formal process. Thus, many people have a hard time understanding how following a documented process, with rules, defined roles and responsibilities is not bureaucratic red-tape that causes them more work instead of just getting it done. Even the act of logging a ticket in the ITSM tool is seen as a waste of time.

Implementing formal processes in an organization where there is none fundamentally changes the way people work. It is the equivalent of transforming people’s work from using artisan methods to an assembly-line2 production system. The challenge of this paradigm shift for people is to relinquish control and trust that others will do their part in rendering services. Moreover, it often impacts their power and pride of being responsible in providing personalized services to Clients.

Let’s use the example of building a car. Before the advent of the assembly line, the artisan was in control and performed the production process from start-to-finish. Even if a task was delegated they were still responsible and accountable to produce the car and to meet commitments (e.g. SLA). Even though it took longer to produce a car people felt a high-sense of accomplishment since expert skills were needed to master everything.. On the other hand, on a car assembly line, the labor is divided between people each specialized and responsible for one piece of the car. When the line-worker has done their piece the next worker does theirs. They know that a car will eventually roll off the assembly line completely assembled. A well optimized production line minimizes delays between each action.

Explaining the benefits of a process by selling and trying to convince people that there will be no delays typically does not work. Instead, first acknowledge their contribution and that they use a process today since just about everything we do is a process3 . Second, admit that a process can cause delays when one element is not well defined, thought out or when people don’t follow it. Then, explain the positive impact a formal and well established process can have for them and how delays can be minimized. Focus on “What’s-In-It-For-Them.” For example a process can:

  • Reduce meetings and emails are needed to figure out what needs to be done and who is responsible for doing it (i.e. who does what?)
  • Require fewer decisions since most are made when the process is designed and built into rules
  • Have documentation to enable training and delegation thus,
    • Clients do not have to wait for them to come back from vacation to get service
    • People can to turn off their smartphones while on vacation
  • Cut down interruptions (e.g. RTFM4 )
  • Lower the amount of troubleshooting and root cause analysis to figure out what someone has done
  • Make it easier to improve operations since delays and bottle necks are easier to identify (however, do not mention measures, controls, compliance, quality at this time to avoid instilling fear!).


Finally, invite them to get involved in designing and improving the process. Their involvement recognizes their knowledge, experience and gives them a sense of control and responsibilities to ensure that the process does not cause delays. It makes it "their" process instead of a thing that the organization wants. Moreover, implicating people who does the work avoids the project from designing a process that is beyond their capabilities and current level of maturity.


Last updated on: 2016-03-08

"If you want it done a certain way, management needs to understand that it has to be put down on paper. " Unknown

More Quotes



Related:

More on Processes


From Around the Web:



Category:
Implementation > People
Implementation > Process


 Plugin disabled
Plugin footnotearea cannot be executed.



Disclaimer


Copyright 2016 - ITIL® from Experience© - D.Matte

<HR>