INFORMATION TECHNOLOGY
Lance B. Eliot, Feature
Editor, Eliot & Associates
Year 2000 Outsourcing: Trust but Verify
by Lance Eliot, Feature Editor
The Year 2000 is getting closer
by the day, the hour, and the minute. Many firms are just now
scrambling to deal with their Year 2000 problem (also known as
Y2K), and have decided to outsource most of their Year 2000
activity, including outsourcing the typical range of Year 2000
tasks from initial inventory and impact analysis to actual code
modification and testing.
Outsourcing the Year 2000 activity does offer a number of
attractive benefits. For example, by using outside specialists
instead of in-house staff, the staff is able to continue focusing
on day-to-day operations issues and can off-load Year 2000
headaches to the outsourcer. Also, investments in specialized Year
2000 tools can be avoided by using outsourcers that make such
investments and then spread their costs across an entire customer
base.
Unfortunately, Year 2000 outsourcing can introduce a number of
disadvantages that some firms have recently discovered to their
dismay. Hopeful of putting their Year 2000 fix into an autopilot
mode, some firms have handed over their entire Year 2000 activity
to outsourcersþand then allowed the outsourcers to forge ahead
without any substantial monitoring. Such a Y2K autopilot approach
could lead to a bumpy ride, possibly even producing a devastating
crash in your Year 2000 fix efforts.
Safeguard Needed
As an expert in monitoring Year 2000 outsourcing arrangements, I
have a number of clients that rely on me to serve as their Y2K
safeguard. My motto continues to be: Trust but verify. I aid
companies in finding ways to monitor the Year 2000 outsourcer so
they can be assured that the outsourcer will do the job as
requested.
In my experience, even the most notable Year 2000 outsourcers are
susceptible to many of the failings that I will describe in the
next section of this article. With the tremendous surge in demand
for Y2K outsourcing, vendors are jumping into client engagements
overnight and spreading their talent pool dangerously thin.
Firms contracting for Y2K services are often unaware of the
pitfalls associated with Year 2000 outsourcing since they are not
Year 2000 experts themselves. And, firms are understandably in a
rush to make progress on their Year 2000 problem and may
inadvertently overlook critical checks-and-balance provisions in
their eagerness to push ahead on the Y2K issue.
Common Y2K Outsourcing Problems
Here are some of the more common Year 2000 outsourcing problems
that have struck most of the firms that I've been dealing with. The
list isn't complete, merely a representative sampling.
Because of the inherent nature of the Year 2000 issue, firms often
cannot realize on-their-own that they are experiencing Y2K
outsourcing problems until the Y2K effort is nearing completion.
Thus, I highly recommend that firms establish either their own
in-house Y2K expert to oversee the outsourcer, and/or use an
outside Y2K monitoring consultant to help oversee the chosen Year
2000 outsourcer. Do so as soon as the Year 2000 effort begins
(usually starting with the inventory and impact analysis).
Generally, the sooner that Y2K outsourcing problems can be
identified and corrected, the less impact that the outsourcing
problem has on the overall Y2K effort. Trust, but verify, and do so
right away.
Now then, here are some pitfalls to be watchful of.
Use of Generic Labor That Lacks True Y2K Training
Date handling is simple, right? Any competent programmer should be
able to do it, right? Wrong. There are specific techniques for
identifying date-related problems in code and data. Many
outsourcers are hiring generic programmers who are versed in
particular languages and systems (e.g., mainframe COBOL, midrange
RPG), and then throwing them into Y2K engagements.
Without specific training on Year 2000 programming and analysis
techniques, the generic labor is likely to miss Y2K problems, will
work inefficiently trying to find Y2K problems, and will produce an
overall result that appears fine but is riddled with omissions.
Make sure that the Y2K technicians assigned to your account are
properly trained and experienced in Y2K matters.
Use of Labor That Includes Underperformers
Anyone who has ever managed programmers knows that a good
programmer is a magnitude better than an average programmer. Many
outsourcers are hiring any programmers that they can find to help
fill the huge demand for Y2K services. Unfortunately, some of these
newly minted Y2K programmers are actually the rejects who performed
poorly elsewhere and have floated in the marketplace looking for a
new home. Even if trained in Y2K techniques, the underperformers
will plod along, taking longer than necessary, and being sloppy in
quality of work performed. Don't let your firm be their next
resting homeþmake sure that each person assigned to your account is
worthy.
No Traceability
Can the vendor tell you the W's of their work? Who looked at a
particular program or module? When was it examined? Where did they
look in the program? And so on. The vendor should be keeping a
detailed log of their efforts. I am not referring to a billing log
for hour tracking, but instead a log that provides Y2K traceability
in case questions arise later about the analysis and work
performed. A Y2K vendor should have a database that they use to
track their efforts and report upon the effort accomplished.
Blind Use of Y2K Tools
Some Y2K vendors make use of specialized Y2K tools to perform
various aspects of the inventory, testing, coding changes, etc. I
am a proponent of the use of Y2K tools and view them as a good way
to speed-up the effort and reduce omissions. But, some vendors also
rely on the Y2K tools without a complete understanding of the
limits of the tools. Lingering in your code and data are date
problems that no existing Y2K tool can spot. If machine scanning is
used excessively, you will be misled into believing some Y2K
problems do not exist that may indeed exist. Find out which tools
are being used and whether the vendor really knows how to use them.
Paying Twice for the Same Work
Suppose that your chosen vendor does your inventory and impact
analysis but skimpily records their work (i.e., traceability).
Later, when a full-scale analysis is conducted, the vendor will
often revisit the same areas as if for the first time! In other
words, because of their own inability to trace and document their
effort, you pay twice. Make sure the vendor is fully tracing AND
documenting what they do.
Scorched Earth Policy
Suppose you grant your vendor the first piece of the Y2K activity,
namely inventory and impact analysis, and then open the remaining
activities to rebidding. If the vendor does not get chosen for the
subsequent steps, they often take a scorched earth policy and
delete relevant and helpful records that could be used by the
incoming vendor. When contracting for the Y2K outsourcing, make
sure that access and ownership to all such relevant records are
retained by you.
The Y2K Hollow Survey
Here's a clever labor saving approach that some Y2K vendors adopt.
They hand a Y2K survey to your programmers and essentially say ``do
my work for me'' to the staff. The vendor shows up a few weeks
later to collect the surveys, and the staff hurriedly fills them in
to get the surveys completed. The vendor treats the completed
surveys like gospel, even though the in-house staff didn't
seriously complete them, and the surveys are presented to
management without any sensible auditing of their results. It's a
hollow result based upon the old Garbage In Garbage Out adage. Make
sure a survey approach is workable if you choose to allow it.
Sampling Means Fuzziness
In order to reduce costs or speed-up efforts, some vendors use
sampling as a means to examine code and data. They might look at
10% of a particular module and then extrapolate to make conclusions
about the remaining 90%. You need to know if such a sampling
approach is being used since the results are no longer absolutes þ
the results are probabilistic. And, you need to know how the
sampling was conducted, by whom, criteria used, etc.
Conclusion
Many clients ask me if there is a magic bullet that will deal with
their Year 2000 problem. Sorry, no such tool exists. Likewise,
handing over your entire Year 2000 fix to a vendor is not a magic
bullet. The best intentioned vendor can still make mistakes when
trying to help your firm deal with your Year 2000 problem. I urge
you to take a Trust But Verify approach if you outsource your Y2K
mess. It's better to be safe than sorry.
Remember that your input is welcomed. If you have projects
addressing the information technology area, and you would like to
share this with the readers of þInformation Technology,þ please
contact me.
|