Home > Cover Story
 Print Friendly Page ||  Email this story

Cover Story: Enterprise-wide IT Projects

Walking the fine line

The success of an enterprise-wide IT project depends on good planning and design. Here's an account of the few things that really matter. by Brian Pereira

Four years ago, a well-known multi-state urban co-operative bank scouted for a core banking solution. It was looking for a solution that integrated the three core banking functions: Retail, Corporate Banking, and Forex & Treasury. The bank selected a core banking solution from a well-known company and embarked on a multi-crore project to implement it at all its branches. But things began to go horribly wrong during implementation. As reported in the press some time ago, there were various technical problems. The solution did not cater to the bank's business requirement. Fine-tuning and customization didn't help much either.

The name of the bank and that of the 'failed' core banking solution is no secret. The point is, the incident does teach us a few lessons. The lack of proper planning and understanding of business requirements resulted in a doomed project. Did the bank consider the risks before implementation? Did it plan for such risks? What kind of surety did the bank take from the implementer?

Failed projects mean bad investments and, more importantly, (heavy) business losses. So what can a CIO do to avoid this? There are no manuals that tell you everything-you-need-to-know to ensure project success. Instead, one can build a knowledge base and update it after each project. From our conversation with a few IT heads of prominent Indian enterprises, we gather it's really the Experience that counts. As CIOs go from project to project, they learn from mistakes. All round ownership for the project is important too. And it pays to be prudent, judgmental, and have a sense of ownership right from the beginning.

A Business Case

IT projects are either business driven or technology driven. In the former case IT infrastructure helps achieve business objectives. When projects are technology driven it means IT infrastructure needs to keep pace with business objectives/initiatives or growth. Either way, IT projects must be aligned with business objectives; top management wants to know how business will benefit from the project.

"The IT project initiative should come from business strategy. This ensures it is linked with the business objectives and it stands a chance of succeeding. Otherwise it is hype-driven and the chances of its success are reduced," says Satish Pendse, Head-Information Technology, Kuoni Travel (India)."

Jason Gonsalves, General Manager-IT & Costing, Goodlass Nerolac Paints couldn't agree more. "We do not do IT projects unless there is a sound business case for it. The business heads outline the business plans for the next five years. And I have to decide what role IT plays in supporting these plans."

An IT project is conceptualized when business initiatives get translated into technology initiatives. This is clearly demonstrated in businesses where the delivery of products and services relies heavily on IT infrastructure. The stock exchanges are a prime example.

The Stock Exchange (formerly Bombay Stock Exchange) generates a detailed document called Business Requirement Specification (BRS). This document enables the IT function to recommend a solution that addresses the business requirement. The BRS specifies the business concept, the objectives, the users affected, the activities etc.

"Once the BRS is prepared we get down to the nitty-grittys of the technology implementation. We decide what will be the delivery mechanism (selection of an existing network for delivering the service), which systems and applications will be used etc," says S.B. Patankar, director, Information Systems, The Stock Exchange.

When a project is deemed viable from a business point of view, the planning and design stage begins. Other stages like evaluation, budgeting, and risk planning might be considered to be part of the planning stage, since discussions on such matters occur in the planning stage. For instance, planning for risks occurs upfront in the planning stage.

Planning Stage

By now a steering committee or task force has been set up. It includes the function or business heads, personnel from finance (possibly the CFO) and technical personnel.

The CIO and the internal IT team present various proposals to the steering committee, which in turn makes major decisions in the planning and evaluation stages. Should the project be outsourced or done in-house? Perhaps it will be partially outsourced. What about time to market? What will be the project duration? Is it too elaborate and should it be done in phases over a two or three year period?

While planning projects, enterprises think about scoping, sizing, resilience building, compatibility issues, scalability, manageability, and the tools required.

At the planning stage the steering committee is also thinking about the project deliverables or benefits. Although it's rather early to come up with tangible ROI, one is thinking more in terms of intangibles. Then one has to do the project costing and plan the allocation of funds.


The evaluation process takes place during the planning stage. Here one decides on the platform, the applications and vendors; the system implementer, the type of network, bandwidth requirements etc.

When you do evaluation you are actually doing risk assessment. The steering committee takes into account all the parameters and plans for all scenarios to ensure smooth implementation.

When designing the new system and evaluating solutions, CIOs will have a list of requirements in front of them. The evaluation parameters will differ depending on the nature of the business. Mission-critical businesses look at performance and functionality. Others are very concerned about how well the new solution integrates with existing infrastructure. Some want to know what is the vendor's financial position, and will it be around seven years hence to offer support. Then there are other parameters like scalability, time-to-implement, cost, resilience, etc.

Whatever the parameters are, the underlying factor is to know what you want and to find out how best the solution can address these requirements. Sometimes decision-makers are so engaged in evaluation that they forget simple principles. In the following pages we bring you some best practices followed by leading enterprises in India.

Brian Pereira can be reached at brianp@networkmagazineindia.com

Enterprise-Wide IT Projects

Click on image for larger view
'Evaluation is a Risk Assessment exercise'

Jason Gonsalves, General Manager-IT & Costing, Goodlass Nerolac Paints says one needs to be very cautious during evaluation as one does not know what could go wrong later, and the impact of that on your business. "It's actually a Risk Assessment exercise that happens when you are doing evaluation. We give more importance to the business risk or the impact on the organization."

Gonsalves tells us how he conducts evaluation and offers a few words of advice:

  • Our evaluation process begins six months before the project is initiated. We do thorough research when scouting for solutions. We follow the media, websites etc, and learn about the players and their solutions. We also talk to many vendors. Once we get a feel about their solutions, the type of professionals they have, and how committed they are, we shortlist a few vendors.
  • Spend more time talking to the vendor or implementer. Gain good insight about the solution. Also give the vendor a good overview about your organization, its processes and people. This will enable the vendor to tailor the solution more suitably to your business needs.
  • We also expose the vendor/implementer to the risks they are likely to face when dealing with our organization. In return we expect the vendor/implementer to be very transparent when they are educating us about the technology.
  • We want to partner with credible vendors and opt for best-of-breed solutions. We look for vendors who have made significant investments and strong commitments. We gauge the chances of the vendor being around seven years hence, as we don't want to be locked in to a technology or solution that no one can support later.
  • We also check the profile of the people who will work on the project. What are their skills, capabilities, experience, and maturity levels?
  • We also evaluate the type of skill sets available in the market for this technology. This is crucial because if it's a niche technology, there won't be enough professionals to operate or maintain the system in future.
  • Understand the roadmap for the technology. We check the probability of this technology surviving in the long run. Information technology evolves very quickly. Can the vendor evolve the product?
  • One should look at the Total Cost of Ownership (TCO). Consider future and recurring cost as well. We scrutinize vendor pricing models as we don't want to get locked in to expensive AMCs or high recurring costs. We ask the vendor to give us a breakup of costs over a 5 - 6 year period.
  • Ask the vendor/implementer how he will educate you about bugs or new developments in the technology.
  • We check the vendor's capabilities to execute change management within the organization.
  • At every phase of the project there is a sign-off. We ask the vendor/implementer to sign all points discussed so that it's all recorded. This is a clear and transparent practice that ensures commitment.
  • Next we start talking to the vendor about implementation. We discuss the timeline, capability of the implementer to complete the project on time, exit points etc. One should be extremely cautious and do contingency planning.
'Be clear about your requirements'

Satish Pendse, Head-Information Technology, Kuoni Travel (India) says one needs to be clear about one's requirements before approaching any vendor/implementer.

"The requirements need to be documented in a detailed manner and they should be classified. There are some functional requirements that are 'must-have.' We refer to these as 'knock-out' criteria. Other things are 'desirable' and yet others are 'wishful.' Classify requirements accordingly."

Pense offers a few words of advice:

  • Don't go by vendor claims and promises, even if these are given in writing. Instead, check some reference sites or personally inspect the product.
  • When doing the evaluation you need to look at volumes carefully. What's the load that the system can handle today? Can it scale up to meet future requirements? The vendor must provide for scalability. What is the safety factor?
  • Look at Total Cost of Ownership. Don't only look at the cost of the solution but consider the cost of support infrastructure as well. Consider the cost of all components (AMC, software licenses, hardware, bandwidth, networking equipment etc).
  • It's important that the solution is compatible with your existing infrastructure. Platform compatibility is essential otherwise TCO goes up.
  • Think about the future. Can the vendor/implementer evolve his product or technology overtime? BPCS was a good ERP solution 7 - 8 years ago. Today few will remember it, because it couldn't evolve. (Ed: BPCS is now owned by SSA Global Technologies).
  • Consider the vendor's financial position. Will it still be in business 5 - 7 years hence? J.D. Edwards has a strong product, but today the company has been acquired by PeopleSoft. You can check the financial background of a company by reading its financial statements, reports from independent market researchers and analysts.
  • Another important point is India support. How much has the vendor committed for its support operations? How many offices does it have? How many people has it employed for support? Some vendors have their R&D set-up here, while others operate through local partners. When you use real-time applications you need immediate support.