Importance of Prototying in Package Implementation- II
For SMEs and Business Analysts, It's best to know the product capability to effectively place a requirement, it acts a priming!
If someone would have said this before this assignment happened to me then I would have thrown it right out of the window for sure! However, this assignment made me realize this key element of human nature- We are always in the inertia of our local needs unless and until an external force acts upon it- Now thats a "requirement nature" reincarnation of Newton's law for you. In this context the external force is the knowledge of the product and its capability to handle a business need. No matter, how hard a package consultant talk about the product feature, the local business needs will try to paint it in the way they want to see it. You go back contended to only realize later that what the business actually requested for in these painstaking requirements sessions were not what wanted in actual, not at least what the Application package would have addressed the best. The process owners representing the respective utility business function were all seated together, in fact it was surprising to note that most of them even had consensus on many common process which were suggested to be followed as part of the process optimization exercise. However they were completely unaware of the workflow capability of the package and gave requirements which were not specific enough. For us the boot camp sessions during the project initiation were meant to cover the features, in the hindsight it did very little help. When the development were completed and the workflow was demonstrated, the result were already out, the business did not like it. The folks at a point felt that the requirements they gave could have been fine-tuned had it been a case wherein they could have pictured their requirements through a demonstrable model during the initial requirement stages.
The "Blind men and an elephant" syndrome
I am referring here to an age old Indian parable which emphasizes on the fact that an individual's perception is highly subjective and largely influenced by the ecosystem which one belongs to. The SMEs belonged to five different business functions with each one of them viewing the package's "workflow engine" elephant in five different ways on mapping their respective process needs. Why blame business users alone, even as a system integrators, we sometimes get carried away with our knowledge of the product and try painting the design using a biased brush. We soon realized that the requirements given by the individual functions were not mapping to what was being intended apparently. In our projects we end up with such scenario, don't we?
A congruence of views was the need of the hour, what the SMEs lacked was a common language which they could use to communicate during these sessions. The Boot camp briefing on the workflow features was expected to set the foundation for the following process mapping exercise using the tool. However, it did not meet its purpose. The process owners had tough time to visualize how their departmental processes would be implemented using the workflow. By now I was convinced that the SMEs were gripped with the tough feeling of uncertainty they were getting into. It was high time to show them some real stuff and modify it on the go. Did we manage it then- yes we did!
Over the years I realized one thing, we end up spending huge effort in charting out the business requirements, but sometimes miss out on the implementation element; the part which actually shapes the requirements into quantifiable deliverables. Being in the IT for over a decade now and having seen multiple IT implementations, I must say that even the best of the breed solutions does not have a panacea for all business problems. The key element for system integrator is a visual communication, on a regular basis, of the requirements getting transformed into implementable packets. Prototyping does wonder in achieving this, at least this is what was apparent from the zealous attitude the process owners had when we actually got them participating in the workflow development process. With critical sub processes identified and developed to be demonstrated, these sub processes were treated as working development models which got refined based on the inputs. Each process owners now had a working workflow model in front of them, a canvas on which they could align their thoughts. I also see a strong potential of our typical phased requirement gathering phase in a package implementation process to get subdivided into smaller packed of prototype discussions.
One may argue as to what happens to the project timelines. Well, to be honest with you, in my experience the development cycle was definitely longer with the iterative approach of prototyping, however there is a good scope of effort reduction in the testing phases. Engaging with the user early on in the development lifecycle save a great deal of effort in the later stage of the cycle. And if you ask me about the intangible benefits, it helps you avoid all the weird surprises like - this is not what I wanted to see; you know what, I might want to squeeze in this one small bit, we just passed the UAT and still have some time for the go-live etc. Above all, to me, a smile of content on the customer face is a priceless intangible you may ask for and I bet you will see it with Prototyping!