Risk management in IT projects is itself at risk because no
one wants to face up to bad news, according to a senior BCS member
who has moved from IT project management to
research.
"IT projects are succumbing to a form of political correctness,
where no one can say bluntly that 'this won't work' for fear of
upsetting the client, account manager, project manager or system
architect," said John McManus, senior research fellow in the
Faculty of Business Management at Lincoln University and professor
of management at the US Rushmore Institute.
McManus has been researching this issue with development methods
specialist Neville Jennings and technical architect Pero Kalurovich
of IT services company Atos Origin.
"Most projects have a risks and issues register, but documenting an
issue is not the same as doing something about it," McManus
said.
"How many risks and issues registers include factors that
collectively should lead to the conclusion that the project is not
viable? The risks are softened for senior management. Phrases such
as 'challenging timescales' and 'needs to be carefully monitored'
creep into reports: these are euphemisms for 'this risk will cause
the project to fail but we don't have the courage to say
so'."
One problem could be that risk and quality assurance functions are
too close to the project. McManus said, "Does too much of the
review process depend on what the project itself thinks? If the
project decides what risks and issues to log and how to classify
them, is this not a recipe for disaster?
"A project that has not recognised the difficulties it faces will
by definition not be able to raise the relevant risks and issues in
the first place. Independence and objectivity are explicitly
excluded.
"Perhaps a project will not accept the findings of a review. Should
the burden of proof be on the reviewer to prove that the design
will not work? Or should it be for the designer to prove that the
design will work; and should this proof be on balance of
probabilities or beyond reasonable doubt?"
"Perhaps a project deflects criticism by pointing at all the good
things and asks why the reviewer focuses on negative things. Should
project weaknesses not be accepted if they are outweighed by
perceived strengths? Or are IT projects only as strong as their
weakest element?"
McManus fears it is possible that a project could follow a
prescribed design process, tick all the correct boxes and still
fail.
He said, "Have some organisations lost integrity and the courage of
their convictions - convictions that led to the adoption of
software engineering principles, including a well-defined process
for project and quality assurance reviews? If these reviews are not
effective, these convictions are worth nothing.
"The assurance process must challenge the very structural viability
of the solution. It is time we retrieved the courage of our
convictions."