Process drives the tool - Part 2
In my last post Process drives the Tool, I shared some of my experiences around process-tool interaction in ITIL process implementations. After years of preaching from the practitioners and the experts like the one here , there is a good understanding that tool follows in the guidelines set by the process. In practice since the teams that are responsible for process definition are usually different from those that develop and customize the tool, the realization of process definition into the tool implementation becomes a bit more challenging.
Two areas that organizations need to be really careful about are - Requirements gathering and Detailed Process design. It has been my observation that many process teams get too gung-ho and collect detailed requirements and design process as per their interpretation of Best Practices. While ITIL and other Best Practices are very useful in the initial stages or the High-Level Process definition, it is a poor decision to collect detailed requirements or define procedures in isolation of the tool. In one place, we spent months putting detailed requirements, processes and workflows without any idea on how those requirements or processes will be implemented. Having learnt from experience, I now advise my clients not to get in too much of details without giving due consideration on these will be implemented; otherwise there is a risk that several less than ideal situations may result:
· The requirements may be vague and may need back and forth between the parties to bring it to required level of details and clarity.
· The requirements list gets too long and may need another round of prioritization and elimination.
· There is a risk of mismatch between the requirements and the finished product. Remember the telephone game!
· Detailed Process definition does not match with the tool workflow leaving the users confused.
Any kind of detailed Requirements Gathering or Process definition activity should be done with the tool in the close proximity. In fact it is highly recommended that you start with a comprehensive walk through of the Out of the Box Tool capabilities and then gather detailed requirements or get into detailed process design. And keep referring back to the tool capabilities in your discussions. This results in a better appreciation of the tool capabilities that result in:
· People providing the requirements are able to provide much more specific requirements.
· A part of requirements are eliminated because they are not business-critical and can’t be supported by the tool ‘Out of the Box’.
· There are fewer gaps between requirements / procedures definition and the tool capabilities resulting in fewer surprises when the end results come out.
These simple steps are amongst the other practical advice that will increase your chance of a successful and best practices compliant implementation. And one that meets the objectives of Process, Technical and Finance team alike!
