Monday, July 07, 2014

The Chicken and the Egg

They traveled the seven seas in a small group looking wide and far for the ultimate solution to beat all solutions and their competitors. Visiting software solution providers and their customers, the team ensured that they explored all the nuances of the solution as used by their hosts. It was a search spread over many months and millions of frequent flyer miles. They came back with voluminous notes which were put together to create the decision matrix. A winner emerged from the chaos; it was the current market leader.

The team was excited with the prospects of implementing the world’s best solution; they presented their conclusions to the management using business case formulated on vendor provided parameters and some internal thinking. Despite the high investment required, management accepted the widely used solution considering that alternatives were not even known by name. The system integrator and implementation partner who had worked through the journey celebrated the decision along with the team.

The team chosen from business, IT and the vendor made preparations and started the project as a cohesive group with broadly defined timelines. It was perceived to be easy with clear use cases and the fact that current manual process was riddled with inefficiency. Lagging competitors by many years, the team and everyone around acknowledged the need and urgency. Well begun is half done, so goes an old English saying; that applied quite appropriately to this marquee project which had all the ingredients that consultants and wise men talk about.

Months passed by in the requirement gathering phases and everything was hunky dory; the rigor of the business team was highly appreciated. Some more months passed by, the team was still in discussion on feature fit to the future state process. Exceptions were highlighted and the system expected to cater to these. The implementation partner was getting restless. Another couple of months later there were no conclusions on the final process; the IT team raised a red flag to the CIO, users reciprocated with an escalation to the functional head.

A senior functional resource was brought in to resolve the bottlenecks; he quickly realized that the users were attempting to force fit their existing processes into the new system. The group had challenges in understanding the basics features of the system despite multiple rounds of demonstrations and step by step explanations. Their lacked the ability to define new optimized processes and with no interest in changing the process they kept shifting the goalpost. Soon it was evident chances of success were like water on Mars.

The SME decided to unearth documents that were the foundation of the product selection. The going in comparison set was not a portrayal of the future state but a broad level definition of the function which obviously met every systems checklist. The selection was based on market positioning and market share in their industry. Almost everyone was using it and thus the decision was kind of obvious. It did not need the process that was adopted to determine the tools. The lack of focus on process from the beginning led to the current situation.

What comes first, process or technology ? Should an organization determine the future state before attempting to select a tool or follow the process that this company did of finding the best tool and then try to figure out how to make it work ? If technology is indeed subservient to business and process, then the journey traversed by the team had a fallacy; even when choices are limited as was the case again, should the process take precedence over technology ? The savior understood the problem and solved it quickly to get the project back on track.

The Knight in shining armor took some difficult decisions and changed some resources while staying involved with the rest focusing on what mattered. He separated the critical and the important while parking the good and nice to have. Exceptions will be addressed when they occur, let’s move on with the 99%. Suddenly everything started moving and though delayed they were back on track. Given the situation I believe that it does not matter which comes first in the poultry farm; it is about where you want to go.

The organization acknowledged the fact, “People are not your best assets, the right people are !” and that’s a story for another time.


  1. Jatin Sheth10:37 AM

    The eternal debate... superb article, Arun!

    The first hint of future problems was when you said, "...using business case formulated on vendor provided parameters." It's a common-enough scenario and I don't blame the project team for taking this easier option.

    As for the final conclusion - which comes first, process or technology - I believe there are a couple of special situations in which process must come first.

    One example is when the existing processes are antiquated (either because the business or the organization has changed sufficiently) that they needed re-engineering even if there was no IT implementation involved.

    Another is when the existing system is largely manual or paper-based. This represents not just a necessity but an opportunity to overhaul key processes.

  2. Thoughtful Article..

    A successful implementation takes place when people, process and technology are in synchronization.

    Popular and widely used technology may be a failure in some circumstances if it is not well accepted by the people and doesn't match the process.

  3. Excellent article for sheer language flow. Liked a lot. Process and technology go hand in hand to achieve a common objective. I think there is no first.