|
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.
Evaluation
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 |
|
 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.
|
|
 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.
|
|
|| Feedback
|| Subscribe-
