I received number of comments, few on-line and more offline, about
my previous blog. As a reminder I had written about one of the trends, that I
believe will shape the future of IT industry in next decade or so. “Customers will demand that IT providers should deliver ‘business outcomes’ and not just a software”.
Few readers asked me to clarify
some of the points I had raised earlier. Specifically about the definition of
‘Outcome’ and whether I thought ‘Outcome Based Pricing’ was the only way to get
there.
Outcome … to me, is a business
outcome.
E.g. I was involved in a project
for one of the leading Telecom Company from UK. The project was about creating
a better integration point for their network inventory management software,
with the CRM application … but that’s on the activity side. What the Telco
actually wanted was to reduce their ‘new broadband provisioning time’ from 3+
weeks to 5 days, and at the same time improve the provisioning accuracy to 80%+
(from 60%). In this case, the Telco had to break the business problem (of
reducing broadband provisioning timeline) into various smaller sub-projects,
each to be delivered by an independent agency, and finally hoping that
everything will be integrated in a manner that will allow the business problem
to be solved. These sub-projects operated in silo and made it very difficult to
realize business benefits. Leaning from this, the Telco has now started stating
the main business objective while outsourcing work to various vendors.
Commercially, the contracts have not yet moved to ‘outcome based’ … but I do
see some movement in the thinking, expectations and execution of newer
projects. And eventually it may result into commercially binding the IT vendors
to business outcomes. At minimum, it will mean lot more collaboration between
all the vendors and various parts of customer organization.
Having said so, I urge you to
not take this argument too far. One of the readers of my blog, was skeptical as
to how IT can be held responsible if they developed a software product, and it
eventually did not sell well in the market. And I partially agree with him; IT
alone cannot be held responsible … but the problem is in thinking otherwise.
(Assuming that IT has NO responsibility towards lack of product
sale, is an equally incorrect argument) IT can do a lot to ensure the eventual
business success, and there is nothing wrong in customers expecting that IT has
it’s skin in the game.
To come back to the original
concern: I would add a clarification in my prediction … that IT and it’s
Customer should collaboratively define what would be the business outcome for
each project.
The second concern, raised by
some readers, was about ‘Outcome Based Pricing’.
Outcome based pricing, is not
the only way to deliver business outcomes. But it surely is the binding way. I
do believe that this is a Day-2 thing. Day-1 is going to be more around creating the enablers for the outcome based pricing. Depending on what the expected business
outcome might be, customers may even struggle to quantify the outcome in $ terms. And if
so, the project cost cannot be easily linked to business outcomes. So while I
think there are going to be projects where commercial engagement will be
outcome based, there are going to be many more, where the commercial engagement
will continue to be FP or Risk/Reward etc.
As mentioned in Part I of this
blog … I will surely put my views on the enablers, baby steps, methods and
process tweaks needed to move towards ‘Outcome Based Delivery’. Meanwhile, if
you have suggestions, comments, please do let me know.
