Technology isn

When deciding to go with a new Web-enabled technology, a company’s choice of product should only make up about 60 per cent of the final decision, according to one industry analyst.

“They should allocate 40 per cent of that decision towards non-technical issues such as the training, support, scalability and services,” said Dave Kelly, vice-president of application strategies at the Framingham, Mass.-based Hurwitz Group Inc., and author of the study Best Practices for Web-centric Application Development.

Although there is little question that Web standards such as TCP/IP and Java hold many benefits for companies, such as lower deployment and application management costs, they can also carry great risks, Kelly said.

“Companies tend to look for silver bullets, to hope that a specific technology is going to solve all their problems. So they often place too much faith in a product or technology, when they should be looking beyond that to some of the organizational, design and architecture issues.”

Firms investing in a new technology need to spend more time analysing it to make sure it will be scalable and flexible enough to meet their needs in the future.

“You don’t have to put everything on hold and go into a deep organizational study or business process re-engineering. But you want to evaluate the product within the context of your organization, your skill-set, the expectations of the user, the requirements from a business perspective, how those requirements will change and the training in terms of what’s involved,” he said.

“Part of the problem is that software is generally getting more complex, and without some guidance or training from the technology provider, it’s hard to understand how best to buy the software or developer tools. Some companies know enough to budget an appropriate amount, but often times we find companies assume the technology is going to solve the problem, and they don’t want to budget a lot of money either for training or the appropriate services and mentoring.”

Kelly said many failed projects are not so much a bad product selection, but a bad implementation of the product.

“So if the company had invested in additional training, mentorship, or architectural guidance, they would have ended up with an application that is much more successful.”

A fair number of companies also have tunnel vision. They want to solve their immediate problems, but end up boxing themselves in — for example, implementing a system that uses Java when the bulk of developers are Cobol developers, Kelly said.

“So to create the new application, they’ve either got to retrain all of their developers, or they have to go outside and hire contractors. Whereas if they had considered the skill set issue initially, and looked for a product that would be at least amenable to Cobol developers, they would be in better shape,” he explained.

“You also get situations where the IT departments are not talking to the line of business, the people who are the actual end users of the products. They may be delivering an new application or product that does solve problems from the IT perspective, but may not make the end user’s life easier — and may in fact make it harder.”

Alan K’necht, president of K’nechtology, a Thornhill, Ont.-based intranet/Internet technology firm, agreed that getting users involved is very useful before starting a project, “because there is nothing worse than developing something and having the users say ‘no, what we really wanted was this.'”

K’necht said he was recently involved in a project with Peel Region, where before embarking on a costly implementation, a user focus group determined a particular Web application was not what the company wanted.

“It would have been a three or four month development time to get it up and running and get data converted,” K’necht said.

“They basically did a pilot, installed minimal database and asked, ‘Is this really what we are after?’ And then determined that the functionality was useless.”