Above my desk is a plaque that reads "Amidst Difficulty Lies Opportunity." I found the words particularly inspirational during an IT project when my technical skills were constantly questioned and my role undermined.
I was assigned to a major project with my associate director and project manager. I was the technical lead for upgrading an application used to document our HMO's medical bill reviews, insert inquiries from customers, and approve/deny medical appeals.
[ Want to cash in on your IT experiences? InfoWorld is looking for an amazing or amusing IT adventure, lesson learned, war story from the trenches, or an instance when something went very right. Send your story to firstname.lastname@example.org. If we publish it, we'll send you a $50 American Express gift cheque. ]
I knew the project would be challenging, and the biggest one would be collaborating with the AD and PM. They were notorious for trying to implement their "fingerprint" so that they could take the credit for a majority of the work. I was prepared to document everything and to communicate with them extensively.
We got started. This application was well-known for not being easily upgraded via the network and acting erratically if not configured properly. I prepared a project plan for my portion of the upgrade with technical specifications, plan of attack, backout plan, and timeline.
Well, one can have good intentions of "this won't happen to me," but when reality hits it can be hard to keep your spirits up. Without consulting me, the AD decided to overhaul my project plan with the assistance of the PM, who did not have the technical aptitude that I had in regard to the application. The PM did not understand there was more to the program than he realized -- the program also needed to have its OCR software upgraded. In my initial plan, I relied on two MSI (Microsoft Installer) packages being activated via a bat script: one to update the application, another to upgrade the OCR portion. The AD and PM in all their wisdom decided that a bat script pointing to the upgrade MSI was all that was needed.
After a week of back and forth, I caved and worked on their solution.
I worked on the scripting, followed the direction I was given to the letter, and alas, it did not work. I tried to isolate all possible reasons, and it boiled down to the fact that the application needed to be removed completely before upgrading and the PCs on the network (approximately 1,500) had to be able to have admin rights to install and a network path for shared repository information. I explained this to the AD and the PM after a week of failures and was chastised, told to "get on the ball" and "we're adding another tech lead to the team."
After many long nights of testing, research, and coffee, my partner and I were able to figure out a surefire way to get the apps updated: use a combination GPO (Group Policy) and MSI with a little bit of bat scripting to ensure that PCs with the upgrade would not be upgraded with the exact same version (the log-off scripting would check the versions of software to be updated and the log-in script would update if needed).
Because this approach differed greatly from the AD's and PM's, it met with much derision. But due to the quickly approaching project end date, they reluctantly went along with it, while whispering to us and around the office the words "imminent failure."
Suffice to say, the project went well, with a 98 percent success rate -- the highest rate of success anyone ever had when trying to upgrade the application suite. The 2 percent that failed were either not current with OS updates or never turned on.
After enough similar high-profile incidents, the PM wound up being replaced and the AD is now a financial services representative for the same HMO.
I learned that the words on my plaque were the best inspiration I could have among people who doubted my ability to successfully complete a major task as highly visible as this one.