Project failure has long been a fact of life in the corporate IT world. All too often projects fail to offer layers of functionality or to live up to users' expectations.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Much of the problem, says David Plummer, managing director of IT solutions consultatncy Triage Consulting, is due to a lack of forethought and strategy during the development process.
He has laid down several best practice ground rules for IT project development to minimise dissatisfaction and failure in this area.
Plummer says project failure may not always be down to suspect software development and faulty technology. It can be caused by a problem with the business model on which the system has been built.
"If you have a manual system that doesn't work efficiently, there will still be a problem when you take it to a technological stage. Developers must work with business people to refine processes."
The way some consultancies and services companies work also comes in for criticism. Plummer argues that while consultancies will infiltrate an organisation to make a feasibility study, and ask questions like: "What is your issue?" However, many already have a preconceived idea of how they plan to approach a certain issue. "For many consultancies, there is a bog standard approach to certain problems," bemoans Plummer. "They have one way of doing things, regardless of the uniqueness of the situation." He calls for more flexibility in their approach.
The development process should be "incremental" and "iterative", according to Plummer. This means that development teams should be constantly liaising with their users and clients to test and improve programmes at different points in the development process. "Often, you will run a bit of code and say, 'wouldn't it be great if we could do this' - it's a process of constant improvement, going back, changing this and that and so on. If you go away and write the whole thing in one go without any reassessment then all this is lost."
He also recommends that developers, whether they be contractors or permanent employees, should be paid on "deliverables", rather than on a rate per hour. If a developer is employed to write the code for a 10-page Web site then they will get paid for delivering the project on time, instead of at an hourly rate.
This model, says Plummer, has several advantages. It enables the individual to make lifestyle choices - they can work at times that best suit them. It also means that people will find a more efficient way of doing things so as to optimise their time.
"Too many IT directors have this entrenched idea that if you look good, then you must be good," he says. "They want to see someone at their desk, because then they think people are doing their work. Setting deliverable targets is a far healthier model, it empowers the worker."