Hong Kong Computer Society - enterpriseinnovation.net

BIZPEOPLE
4 continued from page 10
that I’ve seen practically every different
type of dispute stage. My standard sell
is a 12-week exercise. At the end of 12
weeks, we’ll have either cured or killed
the project. And I exit, with the project
either back on track or killed.
Sometimes when I exit, I’m sending
in lawyers to deal with termination [of
the project]. But more often than not,
I’m handing it back to the project managers,
and am retained as the “program
conscience.”
CIO.com: With large enterprise software
projects, what patterns do people
and teams fall into?
Coyne: When the project starts, the
[technology-buying] organization sets
out clear outcomes. You see strategiclooking
documents on anticipated success:
a percentage increase in the way we
do this type of process; greater efficiency
here, greater visibility of doing business
there; faster this, that and the other thing.
That’s a very positive stage.
But then what generally happens is
that detail-oriented techies get involved
and business objectives get boiled down
to technical function. The danger is that
people end up contracting or creating an
agreement to deliver technical function,
and that’s how the “success” of the project
is measured: on the amount of technical
functions delivered. Often, there’s a
loss of vision into why the project was
started in the first place.
So the business concept we were trying
to achieve—greater visibility to the
directors or executives, or new business
processes—is often lost, and that’s
where a project starts to fail.
CIO.com: That’s where you come in?
Coyne: You must remind the project
team what they are aiming for. In disputes,
the customer wants to protect the
project’s objectives. But often the supplier
says: “We contracted to deliver you a
module that delivers XYZ functionality,
and we delivered that, therefore we’ve
discharged our contractual obligations.”
But the customer will often say: “Yes,
but this CRM system that you delivered
doesn’t deliver on those [original]
high-level objectives.” But [the supplier]
didn’t contract for these high-level objectives;
they’ve just delivered a CRM
system with these modules in it. That’s
the disconnect.
I’ve got to demonstrate
credibility, and the
way to do that is to
show them that I’m
vehemently independent
CIO.com: Is there a way to fix that?
Coyne: When there’s a disagreement
about the deliverables, I have a process
I call “alignment of objectives”: supplier
and customer go through a matrix
of strategic, operational and functional
objectives. The customer is responsible
for the strategic objective, there’s a partnership
[of all involved] on operational
objectives, and the technology vendor is
responsible for functional objectives.
This process forces people to focus on
the reasons they entered into the project.
It generally gets universal buy-in because
[by this point] the tech vendor sees
they will never going get the project delivered
unless they understand what the
customer is trying to achieve.
CIO.com: How do you deal with the
emotional baggage of these expensive,
career-threatening project failures?
Coyne: Customers always say that the
vendor—prior to signing the contract—
told them they understood the project,
understood the business, have implemented
similar systems in the past, and
described the great ROIs other companies
have seen. Pre-sale, they’ll also tell
customers they’ll get “the A team’ [of
tech-workers]. But then once the contract
is signed, the customer gets the B
team, because the A team went off to sell
the next system.
Customers get emotional because
they must define how they want the
system to look. They always say: “The
vendor keeps saying to me: ‘You need
to specify how you want this to look
and work; spec it out for me’. Customers
are frustrated by that, because the
customers understand their business
processes, but they don’t necessarily
understand what the [vendor’s] technology
can do.
And that’s why they contracted with
these specialist vendors! They didn’t expect
to have to spec it out—they expected
the vendors to guide them through
the process and meet them halfway. So
my job is to put the customer back in his
comfort zone.
CIO.com: How are you different from
a project-management turnaround specialists
at the big consultancies?
Coyne: Those people are usually new
project managers who come in and try
to understand the governance processes
that have been used by the project.
They’ll try to tweak the project and it
make operate better.
But they seldom try to realign the project
to its original objectives. If the project
is going in the wrong direction, doing
it better means you head in the wrong
direction quicker or more efficiently.
You’ve got to ask: Why did we ever start
this project? 3
12 Computerworld Hong Kong Nov 2009 www.cw.com.hk