I arrived at the office just in time for an unusually early
eight oclock meeting. As if that wasnt
enough to erase the happy feelings I had when I first awoke, the meeting was to
discuss a project which hadnt been approved for a system not yet purchased. Besides the vendor, there were happy
representatives from most of our IT departments Client/Server, Networking,
Database, Interface and local hospital IT staff. The purpose of the meeting was to discuss the
feasibility of a new system before purchasing it. The hang-up for most attendees, other than
the early start time, was they perceived the meeting as a waste of time. Lost was the idea that we were called to
perform pre-analysis work, and not to fix something. Performing project pre-analysis is a luxury
most IT pros dont get to participate in, but should take full advantage ofwhen presented with the opportunity.
The process usually works something like this. Sales and marketing people peddle an
application towards directors and department managers, not IT staff. The managers get sold on the benefits such as
increased staff efficiency and cost savings, and, ultimately, the system is purchased. It is then handed to IT to implement and makework in the existing environment.
Back to project pre-analysis. This represents the perfect time to request
more detailed information from the vendor, other than the one page data sheet
posted on their web site. Many times the
sales person can give the contact information for one of their installation engineers
or technical support specialists. A
single one-on-one phone conversation can often answer questions about the
architecture of the system, recommended hardware configurations, whether it is
supported and certified to run in a thin client environment, or if any
components are a good candidate for virtualization, etc. An entire book could be written on what to
look for and what questions to ask during the pre-analysis phase. But the important point to remember is to be
as thorough as possible. Once
expectations are set with your customers (i.e., end users) and the system is
purchased, its nearly impossible to stop mid-implementation and proclaim that
it just wont work. Enough negative
indicators may be identified during pre-analysis to justify not purchasing thesystem.
One additional strategy I find useful is calling the customer
technical support line. This can reveal uncensored
candor about common customer complaints and issues. For example, they might reveal that printing
is always a problem because printers are defined per user using .ini files where
form margins are manually set. Or you
could discover the system requires quarterly updates, which translates into a
30 60 minute time commitment per server and each fat client, and, oh yeah, it
needs to be completed after hours. Okay,
I slid in a couple of real examples, but they well illustrate my point about
the kind of information which can be gleaned from calling tech support prior to
giving the green flag for a system acquisition.
It also can be an indicator to how promptly youre able to speak to a
live person when needed, or if the norm is to leave a message and wait for acall back.
So, the eight oclock meeting scheduled with the good
intention of identifying potential implementation pitfalls never got on
track. The ninety minutes were largely
spent arguing over why we shouldnt be discussing this project when another
major project is on the horizon. It is a
shame more analysis and brainstorming didnt get accomplished with so many IT
team representatives in one place. It is
not often that all the pieces are together for collaboration and analysis from
different areas of expertise. An
opportunity like that should not be squandered.
A little research up-front today can pay huge dividends for futureprojects tomorrow.
Feedback is welcome as always. Let me know if you have developed a good
system for conducting project pre-analysis, or if you face similar resistance tothe process in your workplace.