| | By Mick James
There’s an old saying
in the techie world: “If
it ain’t broken, it
doesn’t have enough
features.” Features are
the bane of modern
life—every six months or
so, for example, I
attempt to buy a digital
camera. After wading
through the hundreds of
models and dozens of
options, I’ll narrow my
desires down to say,
four features that
really matter to me.
Guess what – there’s
never a single model
that has them all.
Worse, I can’t find a
camera that doesn’t have
a plethora of other
features that no-one in
their right mind would
ever use and which make
the whole thing harder
to use and more likely
to go wrong.
It strikes me that a
very similar situation
applies to the world of
enterprise software.
Sure, consultancies can
guide clients through
the maze, but why is the
maze there in the first
place. It turns out
that I’m not alone in
this thought.
“The IT industry is
too big,” says Cyndi
Mitchell, MD of
ThoughtWorks, an IT
consultancy which
specialises in custom
application development
and system integration.
“There are a lot of
packages and services
out there that aren’t
really needed.”
Mitchell estimates
that around 60% of the
features built into
software packages are | |
|
| | never used: “We live in
a world of standards –
people build products
around those standards
with feature after
feature that will never
be used – they just lump
all this stuff in,” she
says. “Companies have
literally billions
invested in features
they don’t need.”
Since the 1990s and
the ERP revolution,
we’ve become used to the
idea that packaged
software from the likes
of SAP and Oracle will
dominate the enterprise
space. ThoughtWorks
believes its time to
question that paradigm.
“There are any number
of useful products out
there but they offer no
differentiation,” says
Mitchell. “People need
to ask themselves, what
value does this Oracle
database bring to my
business?”
ThoughtWorks is a
champion of a software
development technique it
calls Agile. Normally I
would shy away from
discussing such things,
but the Agile approach
poses a challenge both
to the way companies
invest in IT and the
relationship between IT
and business.
“In IT we’re so used
to everything going
wrong; the relationship
between IT and business
is so broken,” she says.
“There’s a lot of work
to be done to restore
it. We need to get back
to working in true
partnership, to
revolutionise the deal
that business gets from
IT.”
| |
|
| |
This means attacking
the basic paradigm of IT
investment and project
planning: big budgets
allocated up-front
against projects with a
delivery time of
anything from 18 months
upwards.
“If you’re an IT
person you have to put
budgets in place three
years in advance,” says
Mitchell. “That
cripples business. You
need to be able to say,
here’s a new advance in
technology – how can we
apply it to our
business?”
ThoughtWorks
advocates a drip-feed
approach to IT
investment, where people
match a cashflow of
investment against the
actual value created.
“There’s a very clear
and simple way to
demonstrate value in
hard cost terms,” she
says. “You have a batch
of features and you put
a value on each feature
– increasing revenues,
reducing risk, reducing
cost or improving
efficiency. Then you
move to release early
value up front – asking
what features are
important to me now.”
This approach means
that the software
delivery comes in very
short cycles—from
two-monthly to even
weekly.
“We don’t say it’s
going to go like this
for the next five
years,” says Mitchell.
“Agile allows us to
accommodate and adapt,
to make it easy to do
projects in short | |
|
| | one-week cycles. Users
get to see the system as
it is growing and make
changes as it goes.”
What ThoughtWorks is
after is “hi-fidelity
conversations” between
the business users and
the IT developers. It
doesn’t like, for
example, lengthy
requirements documents
and methodologies.
“People have
difficulty expressing
their ideas – the ideal
situation is that you
have an idea, I’m a
developer, you tell me
stuff and I code it,”
says Mitchell. “The
other way is to have
these big documents.
Everything that is a
step away from business
people telling the
developer what they want
degrades the fidelity of
the conversation.”
What ThoughtWorks
advocates is little
short of a revolution,
and Mitchell admits that
“the way we work is
still a bit disruptive”
and requires C-level
sponsorship. It’s a
tough approach to sell
to government, for
example, where the
procurement process is
pretty much designed
around the old paradigm
(and, in Mitchell's
opinion, “set up to
fail”). However,
Mitchell believes than
in a decade or so Agile
or variations on it will
become the dominant way
to develop software.
In the meantime,
ThoughtWorks is also
adopting the adage that
change must come from
within. Mitchell | |
|
| | believes, for example,
that there are a lot of
people working in IT who
shouldn’t be there.
“IT is where we
flocked to – there are a
lot of people in there
who should be artists or
chefs,” she says.
Conversely, IT
consultancy has
alienated a lot of
people who would be good
at it with its “geeky”
bits. For its new
training programme at
its “University” in
Bangalore, the company
is aiming for a 50-50
intake of male and
female graduates.
I like the
ThoughtWorks approach.
I like the way the
constant reference to
“conversations” a word
which shares a
linguistic root with
consultancy, “con” as in
“with” rather than “to”.
Unfortunately, in the
world of IT right now
the last thing the
market rewards is being
different, but
ThoughtWorks is prepared
to be patient and look
forward five or even 10
years to a world where,
as Mitchell puts it,
“people build software
that you need”. Who
knows, I might even have
bought a digital camera
by then.
| |
|
Previous Page 