| | By Mick James
When people attack
the consultancy
industry, there’s often
a well-rehearsed and
well-known list of
disaster projects that
gets trotted out as
well, and usually in the
public sector. Usually
the mere involvement of
consultants is seen as
the cause—indeed the
word “consultant” seems
to occupy the same place
in people’s vocabulary
as “lady driver” did in
the sexist days of
yore.
We all know that the
roots of project failure
are as complex and
varied as the projects
themselves. Yet, over
the years, one truism
has emerged: when
projects go wrong, they
normally go wrong at the
very beginning, if not
at the buying stage,
then very soon after. Is
it not perhaps time to
revisit some of the
processes of consultancy
projects to see if there
is more that can be done
at this crucial stage?
Two people who
believe so are Mike
Popham and Dr Mike
Stevens of project
services company SGS.
They believe that a
whole area of project
risk—requirements
risk—often goes
overlooked in the
specification of
projects and have a
wealth of experience to
back this assertion up.
The evidence
comes—consultants will
be relieved to know—from
areas of procurement far
removed from
consultancy. SGS has a | |
|
| | strong background in
defence and other public
sector work, and some of
the “horror stories”
here—which, remember,
come from a sector
considered to be pretty
much “state of the art”
in procurement—make
consultancy project
failures seem trivial.
We are talking here
about an entire class of
warship accepted off
contract by government
which then proved
incapable of military
operations. About fleets
of ambulances that
cannot negotiate
speed-bumps, and police
firearms vehicles which
cannot carry their
requirements loads.
These sorts of
requirements failures
are replicated, although
in less explicit form,
in IT projects, where it
has been estimated in
various studies that a
third of IT projects are
cancelled, half end up
doubling their costs and
nearly two-thirds are
inappropriate for the
firms that run them.
Yet the answer here
is, according to SGS,
not for customers or
consultants to sharpen
their act up. There is
in effect a missing
link—requirements
engineering—which
neither side is suited
to provide.
“Customers are not
very good at specifying
things,” says Popham.
“Systems houses are good
at building things, but
not at supplying them.”
Because no-one takes
an independent view of
whether the user
requirements have been | |
| |
| | requirements:
“There are a number
of problems which
prevent people
specifying good
requirements, and one of
these is previous
experience,” says
Stevens. “It’s very easy
to specify a system you
can fight the last war
with.”
“In terms of
requirements the more
knowledge you have, the
more it interferes with
your ability to write
requirements,” adds
Popham, citing the case
of a major defence
company that was told
that 75% of the marks
for a project bid would
be awarded for
requirements.
“Out of 50 designers
only one was put on
requirements work,” says
Popham. “That’s how much
emphasis industry gives
to requirements even
when they’re told that
that’s what they’re
required to do.”
The answer, says
Popham, is for
requirements engineering
to emerge as a separate
discipline that “bridges
the gap between the
customer and the
client”. This should not
be seen as an extra
layer of “middleware”
but as creating a
triangular structure
round which information
and feedback constantly
flows.
“You need to educate,
engineer and enforce,”
says Popham.
“Requirements
engineering is a great
integrator of all the
elements—even if the
requirement is perfect | |
|
| | you still need a
thorough life management
plan: are you going to
build the right system
and are you going to
build that system
right?”
Despite the case for
requirements
engineering, inserting
it into what Stevens
calls the “closed shop”
of consultancy
procurement is going to
be difficult,
particularly given his
belief that requirements
should attract 15% of
project spend rather
than the current average
of 1%. Even though
Gabb’s paper is six
years old the ideas of
requirements engineering
do not seem to have
permeated the
consultancy profession.
Most consultants I’ve
reflected these ideas to
have either not been
familiar with the term
or murmured “we would
argue that we do that
anyway”. Popham and
Stevens believe that the
impetus will have to
come from customers.
“It has to be
customer led, the
customer has to tell
suppliers to commission
an independent
supplier,” says Stevens.
Are Popham and Stevens
right? How will you
react when a client asks
you to commission a
requirements engineer?
Contact Mick with
your views or
suggestions at:
mick.james@top-consultan
t.com | |
|
| | correctly stated, and
whether the project is
built is going to
satisfy them, many
projects contain a huge
but undefined and
unrecognized element of
risk. This doesn’t mean
that they will all fail,
but when they do, the
results can be
spectacular.
This failure is known
as “requirements denial”
a phrase coined in a
seminal paper by
Australian software and
systems engineer Andrew
Gabb. Gabb pointed out
that although it was
well-known that poor
requirements led to
failed projects, there
was still a tendency to
deny the need for
adequate requirements
planning. The paper
lists “common excuses”
which lead to
requirements denial: the
belief that customers
are uninterested or
“don’t know what they
want, a tendency to
specify unrealistic
performance objectives
or to focus on
particular products
being some of the more
common ones. Gabb argues
that this is essentially
an engineering problem,
and one which is largely
unrecognized by clients
or their suppliers.
It also follows from
this that clients and
suppliers are the worst
people to write | |
|
Previous Page 
