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.
The new air traffic control system at Swanwick may finally have gone live last weekend, five years over deadline, but elsewhere IT projects are still soaking up corporate budgets.
This is bad news for there is, of course, no such thing as an IT project, only a business one with an IT component. That means the project must be sponsored and owned by business not IT.
This also applies to the benefits and the risks, which are business benefits and business risks, not IT's.
Yet, warns PA Consulting's David Elton, often IT departments have responsibility for a portfolio of projects with a substantial IT development or process to them. "Yes, the business should own projects, but often you find that ownership of the risks and benefits is adrift in no-man's land," he says.
This then results in the project's focus being more on software than on the underlying business objectives.
The IT department, says Elton, can easily become a willing accomplice in this. IT presumes that technology, per se, will confer untold business benefits - and sometimes the business is all too happy to go along with this vaguely optimistic outlook.
"There is a tendency in IT to push solutions, and a tendency in senior management not to understand fully the implications of the technology," says Elton.
The business case for the project then becomes solution-led, and rests on an assumption that implementing a given system is, in fact, the purpose of the project.
"The trouble is that this infers benefits to the business simply from implementing the package," says Elton.
The project goals then become getting the software implemented to time, budget and quality.
Every business project, it goes without saying, must have clear objectives in mind, which should reflect the overall business strategy of the company.
If, for example, the business strategy is to be a least-cost provider, then the project's objectives should be to reduce the costs of, say, a key business process. And the software chosen to be the technology component of that project should be able to help achieve that aim of cost reduction.
One company, Elton recalls, had a defined strategy of maximising business-to-business selling. Yet the customer relationship management project it was implementing involved a software package that was far better suited to business-to-consumer selling.
However technically excellent or cost-effective the package was, it did not contribute to the goals of the project or the overall strategy of the company, so it was the wrong software to implement.
"A business defines its strategy about the [market] position it wants to be in," says Elton. "It needs to do the same for IT. Implementing any IT will change the way staff are deployed, or how the firm deals with suppliers or customers, it changes the company's position."
And if it does not allow or support those changes then it is the wrong software for the right project.
This may seem obvious but, points out Elton, "it doesn't happen a lot".
For Elton it is a clear case of making sure that things happen in the right order when it comes to a project with a lot of IT in it.
- First, consider what the overall business strategy is: for example, to be a low-cost provider
- Second, consider how the proposed investment will contribute to that strategy: eg reduce the cost of a critical business process
- Third, select and implement the most appropriate software to achieve that objective, on that criterion alone, and no other, however tempting the bells and whistles that IT wants to play with