How to start with ITIL
Every start is an enormous stretch that needs to be put into effort to chase success. ITIL makes no difference and with time the process evolves into something more complex and difficult to guide. This complexity does not necessarily mean that the goals are accomplished with less effort or minimum disturbance due to the evolution of the framework. This, however, with further growing leads to more time to accomplish a certain goal. Therefore, it is vital to define an absolute minimum on which you can build upon for the future. This might be called "a base"; "foundation grounds" or whatever you like as long as its purpose is clear.
A similar term for this is present in the Lean Management and it is called "minimum viable product". The difference here is that we are talking about a process. And no matter how perplexed it may sound, this is basically the foundation of every ITIL activity, which can also be called "the zero-ground start". Once created, it can keep evolving. Another iteration of the concept is to dismantle huge, heavy process activities into smaller ones, simpler ones, independent ones. You can easily define which section stalls you and you can work on it instead of altering the entire cycle. This reduces time for completion.
We are familiar with the term "best practice" and in this case, it is quite vague what that will be in our scenario. However, it is not easy to define as industries vary and it all comes down to environment and requirements, so each "best practice" will be specific only for that sector or industry it is applied on. One such iteration can be good for a small company, and deadly for a corporate environment, so it all depends on the variables. And remember, unlike in Agile, here we have defined process and defined resources and this is what we work with. Some might think this limits the options for change or flexibility, but it is not the case. Of course, it has its ups and downs, but for 3 decades and more, the process has been improved to its maturity.
How can we define "zero ground start" or "zero ground effort"? It is the process, product or service that achieves the necessary targets and goals with as less elaboration as possible or with the shortest definition. It will take into account all the necessary steps and requirements to reach the end phase. In another article I have recently read, there is a good definition how exactly the "zero ground start" influences the four aspects of one such defined process: purpose, customers, triggers and outputs. So, scrutinized, it should mean exactly the following: why, when and for whom we do the work which leads us to who our client target is; how do we enhance the process and what this enhancement will bring as an output.
If it is well-designed it will give you the control of parallel activities and coordination.
Another popular opinion is that efficiency is lost with time. However, having the base can significantly lean out the process. We can think of the "zero ground start" as the pragmatic side of one huge and expected to grow animal. Even with humans, they say, what matters is the first 7 years. You can think of this concept in a similar way - you have the defined time to establish "zero ground" and after it reaches maturity, it will be self-educating … in an ideal world, of course. It does not mean you do not have to interfere, but the impact of the decisions will be lessened and not so dangerous if something goes wrong.
We have to also mention that this all makes sense if you add certain value to the process - and this is where we already start to have complications. With values, often people lose scope and things tend to get messy. Because managers want to add as much value as possible to justify resources for the process, but no. As long as you keep in mind that your primary target is the CUSTOMER and goal of the OUTPUT is to satisfy them, you will be ok. Do not delve too deep in the process as you will lose focus and direction. This has been proved and observed so many times in so many companies that I honestly cannot count them, neither do I want to put an effort in doing so.
Let's go back to the "best practice" again as this might turn out to be the pitfall of the "zero ground" and other concepts in ITIL, as well as in Agile or Lean. We have the process in place and we start facing different obstacles. What might help is to define what works and what does not, is clarifying the roles and responsibilities in that section, one might say. To do this in a "best practice" takes months, and in MNCs could take years - identify gaps, choose better tools, recruit and coach staff and convince them that this is their "best" process, their "best practice". And then your "best practice" is your pitfall. With "zero ground" you have a little bit different situation: responsibility is given from the start to each stakeholder; the teams can adjust according to their needs; improvement is not embedded but is regarded as part of the culture of the organisation and it faces necessary change or problem instead of unneeded option or feature. If a mistake occurs, you can easily go back to the base and start building upon from the start - you do not need to implement large solutions due to architecture or any other complexity. And still, we have a defined process in its very barebone skeleton with the absolute needed, so it cannot be leaner than this. And then you start building upon. And since it is barebone, and the foundation of the whole cycle, you can easily skip validations, controls and other add-ons to increase the value. Those can be done at a later phase - transition for example, where there will be a final overview of what the customer is expecting form the implementation. And you can use the model further - it will all depend on your flexibility and adjustment rates.
In conclusion, the ITIL gives options for various treatment of the general requirements, considering the peculiarities of the implementing organisation. However, due to misunderstanding or fear from practicing new iterations of the framework, lots of organisations stick to the very first edition of the activity set of the methodology. This does not mean one should have free interpretation of the recommendations, described in ITIL but should have deeper understanding of what exactly their organisation needs. You cannot take a process, like it and decide to call it ITIL or make it part of its activities - if it does correspond to the framework - yes, otherwise it is something else.