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.
The eternal debate... superb article, Arun!
ReplyDeleteThe 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.
Thoughtful Article..
ReplyDeleteA 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.
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.
ReplyDelete