By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"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."