Process drives the tool - Right?
After some Google-ing, I was able to find an interesting article on this topic here.
There is no doubt that process is what drives the technical requirements. But a lot of times you come across dissatisfied customers and costly reworks because someone took the dictum too far. Even to the extent that detailed requirements are collected and procedures written with neither the person giving the requirements nor the person documenting them having any inkling how these will be implemented.
I was once a part of a Configuration Management implementation for a large financial company where we spent close to 12 person months to develop a data model. When we were developing the model, we had no idea of the tool that the data model will be implemented on. Later when the tool selection exercise was conducted, we found that none of the tools in the market offer a data model close to what we had developed.
On the other hand, there are implementations where the tool is implemented "Out of the Box" with little or no attention on how it will be ultimately used. There are confused users and implementers neither of them knowing what went wrong!
At what stage to bring the process and tool together is a critical factor and sometimes decides whether an implementation could be done on time and within the budget.
In my next bog, I will share some of these learnings - some that I learnt the hard way and some just by observing and talking to clients and fellow practitioners. Till then - Happy Reading.
