Thursday, December 18, 2008

IT is your Friend

I received a phone call a few weeks back to reserve our training rooms for a special training with a vendor. A special piece of software needed to be installed on the training room machines. The installation went smoothly and the technical staff from this department performed the most thorough testing I've seen any of our clients perform.

The guy doing the installation and I looked at each other when we got together for followup and said:

That was too easy.

Famous last words. So we both made sure we had some flex time in our schedule when the vendor was scheduled to arrive. Because when things go that smoothly - bad things happen at the last minute.

Yesterday morning, I received a panicky phone call from the client.

We can't get into our databases! You all said this was tested! We have to do this workshop!

The issue - just because the software is installed doesn't mean that it is configured. No one gave us that part of the equation. And it's not fair to expect the client (who is NOT a member of the department's technical staff) to know that they need to ask what other configuration steps are required to prepare for the session. Even the department's technical staff was caught off guard. Because they DID thoroughly test the application based on the information they were given by the vendor and based on the knowledge they had at that moment.

As the installation guys and I worked to resolve the immediate issue, something became very clear: this is a rogue project and the department is way in over its head. Furthermore, they are expecting IT to save them when they start drowning.

Another alarm in my head sounded when I discovered that the department expects the new software to be able to connect to and communicate with our enterprise application. They hoped to do this with minimal IT participation - other than as informal "favors" between friends.

And we all know how time-consuming those "favors" become.

The third alarm sounded when I realized they are building a parallel database hosted outside of the organization (with potentially sensitive information). Not only does this potentially make our "system of record" inaccurate, we may be dealing with an information security issue. From talking with them, there did not seem to be any plan to figure out how to reconcile these two systems.

Bells are ringing.....

Oh, and did I mention that we are about to embark on a major upgrade of that "system of record" that directly impacts their shiny new system. They never bothered to ask if anything would impact them. The departmental director's and the vendor's eyes got really big when I provided that little piece of information.

So I got to spend the past couple of workdays being the bearer of bad news. I'm hoping we caught this in time before real damage was done. The decisions are now being kicked upstairs.

The department may be seeing their pet project's timelines change dramatically.

And I'm going to try to lie real low while the storm passes overhead......


It is a case-study in why you need to talk to the IT department FIRST before embarking on projects that impact organizational computers and networks.

The IT department has expertise and resources that (if you go up to them nicely and well BEFORE you start) can help you implement whatever it is you are trying to do.

Yes, I KNOW that many IT folks have a knee-jerk "No" response.

Within that "no" response, however, is a love of problem-solving. They may have a better idea.

Sell them on what it is you want to accomplish - not necessarily HOW you want to accomplish it. Ask them nicely for advice early (like when you are even THINKING about possibly implementing the project) and often.

IT folks love to play with new tools. They may have information on tools that fit within the existing system or, even better, that already exist in the organization. As a result, they will better be able to support you.

If nothing else, asking their advice along the way will save you a tremendous amount of headache.

1 comment:

Unknown said...

"Sell them on what it is you want to accomplish - not necessarily HOW you want to accomplish it."

This statement says it all. I can't tell you how many times some design or other strategy was FORCED on us that we couldn't suggest alternatives on because we were never given the original problem to begin with.

The reason for so many knee-jerk "NO" responses is because we have been suckered into helping too many times on projects that got started without IT, and are drowning. The bitterness is strong with us.