You might be
remembering the famous iGATE campaign nick named as 'iTOPS' in 2012 that
promised the customers of business outcome based billing rather than the
'flawed' time and material billing that just takes into account the effort
spent rather than the business results. Though the campaign may not be popular
with IT service industry, I definitely see value in that concept. Customers,
stung by the one recession after another (starting from the US sub-prime
housing loans in 2008 to the recent Euro crisis), are increasingly looking
towards cutting costs. When it comes to cutting costs, their first target would
naturally be IT budgets unless IT is the enabler of their core business model
itself. (think of Amazon or Paypal or eBay). It was a known fact and confirmed
in a recent survey that IT service companies are doing much better than most of
their customers
In the good old
happy days IT service providers milked money on time and material contracts
without worrying about how their customers are performing in their industry
against cut-throat competition. It seems like those days are numbered if not
over already. While the IT companies will fight this trend at many levels and
dimensions depending on their size and capabilities, what it means for
individuals like us- developers, testers, managers or architects?
Am I capable of
providing a solution to my customer's problem(s) or am I capable of just coding
or testing or designing? It requires a fundamental shift in the way we think
and engage the customers. Currently even for a small business problem, we
require a PM or BA to talk to the customer to understand the business context,
a developer to code and a tester to verify the functionality. Most of the cases
the PM or BA is engaged not because the domain is overly complex, but the
technical team is simply not capable of communicating with the customer. A job ideally done by one person is split
between 3 people to fill-in for the gaps in the team. Essentially this leads to
cost escalation and the customer bears this overhead (in most cases) or the
project never takes off due to cost constraints. (that means the customer
learns to live with the problem, which is very bad)
Instead if we have
molded ourselves as a Solution Developer rather than a coder or tester or
technical specialist, we would have given a solution to the customer's problem
- not a software product or worse just services. No doubt any solution is a
result of a product + service. But then a product or for that matter any
service on its own is not very useful. Even after you deliver the product or
service, the customer may still be devoid of a solution to her problems.
Benefits or compensation will be increasingly linked with the results in
future. An electrician or a surgeon or a software engineer is paid for fixing
the problems or providing a solution and not for spending effort.
In the coming days,
'Solution Architect (SA)' will be the much sought after role in the IT. SA
shouldn't be thought of as technical architect or a senior technical person,
but anyone who fits herself into the shoes of the customers, appreciates the
problems of the customer and sees that a solution is delivered. Are we up to
the challenge?
