|
Is
Technology your Friend or Foe?
Even with the right tools and a superb technology platform,
a successful IT project is still quite a feat. But what
happens when you don’t have the right technology for
the job? Many times an IT project struggles simply because
it doesn’t have the right technology tools for the
project. And it doesn’t matter how good your team
is. Your team can work with great speed and skill to bail
the water out of the boat but eventually the leak will overwhelm
your magnificent efforts. This article describes some symptoms
of when technology may be preventing your success and it’s
time re-examine your technology platform.
Technology is
a big capital investment. So it’s no surprise that
there’s often pressure from management to use existing
tools as much as possible. But using a technology or toolset
simply because it’s the one the company has purchased
is filled with risky assumptions. The biggest assumption
is that the platform/tools that were acquired a few years
ago are still the right tools for the next project. The
fact is the wrong technology can doom your project for ultimate
failure right from the start. Yet chances are you won’t
realize it until you’re near the end of the project
when these intrinsic issues start to manifest themselves.
The other dynamic that delays the realization you may not
have the right technology is the incredible effort a talented
IT team will put in to overcome these shortcomings. But
in reality all they are doing is masking some serious underlying
technology issues in the technology toolset and postponing
the day of reckoning when the project is inexplicably behind
schedule and over budget. Here is a list of symptoms that
can alert you to the need to re-examine your technology
platform choices. Ultimately, it could be the difference
in your success – no matter how good you and your
team are.
1. More time is spent working with the technology team putting
out fires than working with your business partners on requirements
and a deployment plan. You know you that the bulk of the
project’s time should be spent building consensus,
setting expectations and keeping management informed and
the myriad hundred other non-technical things critical to
IT project success. But it seems like every other day there
is a new technical issue that threatens the project’s
deliverables. And although some of these are inevitable
in any project, too many will undermine your success, if
for no other reason than they monopolize your time. One
benchmark of the right technology is that you don’t
feel like the technology is a daily struggle and you have
time to focus on critical success factors like maintaining
your business partners active support and participation.
It’s enough of a struggle just staying on top of ever
changing user requirements, scope creep, and maintaining
organizational buy-in from the project sponsors –
the last thing you have time for is a struggle with the
very tools you’re using to implement the system.
2. Relatively
simple change requests start off the panic alarms. Constant
change requests are a fact of life in every IT project.
And putting them all on the long term “to do”
list is seldom an option. You need a technology that can
let you accommodate the inevitable changes relatively easily.
Users are constantly changing what they think the system
should do and how it should look. A good technologist knows
this and plans for it. Not to confuse this with the insidious
bane of most projects – Scope Creep – but most
projects are really more fluid than our project methodologies
allow. How much time and money does the average change request
take? For each technology, it is different. This can be
a vital variable in your project’s success.
3. Every time you need something, you need to cut a purchase
request. In every project, there’s always a need for
additional tools and utilities that nobody expected. The
question is how many options do you have? Are you locked
in to a particular vendor where costs become an issue? When
you search for fast inexpensive solutions, do you find that
borrowing and using components, modules and services from
other systems is difficult? Does your architectural approach
allow you to use utilities and tools from the ever expanding
universe of the open source library? How wide is your potential
solution base? Your toolkit should consistently adhere to
and work with true open standards and not a vendor’s
flavor/version of a standard. This can be tough to discern
amid all their proclamations. But even a small variation
in how they implement a standard can cost you a lot of money
and time as you’re forced to keep going back to them
for next solution. And they don’t mind at all.
4. It’s difficult to find the needed technical expertise.
This is a common symptom that sometimes has as much to do
with your approach as your selection of technology. If you
find that your staff is short on the skills needed to meet
the schedule in a timely and cost-effective way, you may
have chosen the wrong technology vis-à-vis your resources.
All professionals like to stretch their skills and feel
challenged. It’s good for morale and it’s good
for the resume. But sometimes, we stretch too far. The skills
on the team are not lending themselves to a quick learning
curve on the new technology, as was expected. The C++ programmers
are taking longer than expected to learn Java. Are you confident
you can cost effectively source COBOL developers? Asking
an IT person to wear several hats is okay but you also need
to do an objective assessment of your capabilities against
the project deliverables. Is there a learning curve built
into your schedule? Few schedules can afford and since it’s
a risky assumption to include.
5. The
learning curve consists of reading the code and poorly written,
incomplete documentation. Companies acquire technology in
many ways – purchasing, mergers, acquisitions and
the most common – “We’re not totally sure”.
No one can recall who purchased it and the exact reason
why it was purchased. The person responsible for the technology
decision is gone and all that’s left is the technology
and now your team has been told to use it – after
they learn how it works. Some of the utilities in the platform
are obsolete legacy components that lack documentation and
adequate support. If the system you’re working on
was originally built or written by folks who are long gone
– excellent documentation is critical. The lack of
such documentation will slow up your project’s progress
significantly.
6. Integrating your system to other systems is a complex
time consuming task. Integration is the monster in the closet
– it’s only a matter of time before you will
need to interface the system to other systems. The question
is what types of standards based interfaces are available
to provide a relatively straightforward integration strategy.
If you find that interfacing the system to other systems
is going to be a time consuming challenge, you may want
to re-evaluate that platform. Every IT project should have
an integration strategy for how the system will interface
with current and future projects. If the company has a middleware
architecture the project team should scope out exactly how
they will interface to that.
Conclusion To conclude, I’ve seen too many projects
ultimately fail because the tools and technologies were
not right for that particular project. Regardless of how
smart your team is and how hard they work, in the end the
project will not meet your business partners’ expectations.
The next time you submit your request for funding for that
next project – make doubly sure the technology platform
you plan on using is the right one for your project.
Copyright
2005 All Rights Reserved. IS Value Corporation, 1644 Hunters
Ct. Yardley, Pa 19067
Tel.
215-493-0940 www.isvaluecorp.com, Jim.Carty@isvaluecorp.com
|
