I arrived at the office just in time for an unusually early

eight o’clock meeting.  As if that wasn’t

enough to erase the happy feelings I had when I first awoke, the meeting was to

discuss a project which hadn’t 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 don’t get to participate in, but should take full advantage of

when 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 make

work 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, it’s nearly impossible to stop mid-implementation and proclaim that

it just won’t work.  Enough negative

indicators may be identified during pre-analysis to justify not purchasing the

system.

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 you’re able to speak to a

live person when needed, or if the norm is to leave a message and wait for a

call back.

So, the eight o’clock 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 shouldn’t be discussing this project when another

major project is on the horizon.  It is a

shame more analysis and brainstorming didn’t 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 future

projects 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 to

the process in your workplace.