The Big Hairy Project

Well, here I am; feeling like Sam Becket in Quantum Leap right when he says “oh, boy!”

What did I sign up for? Was I Mikey in the classic commercial? All the full time employees go, “Ew, give it to the contractor.”? Yes, it was a tremendous opportunity; to step on a land mine.

For some context: eBusiness was responsible for all things IT across the enterprise, EXCEPT for engineering tools and support. This was not a friendly co-existence. Two separate Senior Vice Presidents/General Managers with vest interest. Two different personalities and needs for reporting purposes. There was a vendor, with a team local and off shore, other IT contractors, as well as a large group of internal staff involved with the project.

The project sounded simple: take a homebuilt, Access-based system that had the complete inventory of all pieces and parts that were or could be used in the development, support, and production of all things the aerospace company created. It was hosted on two PCs under the desk of the developer that created the original system and needed to be moved to this fancy cloud-based tool. Oh, the developer had retired after thirty-five years. Apparently, the right fee was arrived at to bring him back as a contractor in support of this project. His name was Gerry and he looked like Jerry Garcia as a UNIX wizard.

One of the joys of having a home-built system, with no data standards, is that with thousands of engineers engaged every day in development, production, and support of avionics that you have a large variation of spellings, abbreviations, units used, etc. To solve that problem, a team of engineers had to come together and agree on the standards to be used, get them approved and published by the Engineer leadership council.

No small task but it was done. The VP/GM of Engineering was not going to let the rival VP/GM of eBusiness point at their group as the impediment of getting this project completed (oh, forgot to mention a substantial portion of the project was being capitalized) and as you may recall, a primary goal of the incentive pay program for all employees. No pressure.

Back to the project: now we had standards, we could begin the process of extracting groups of items and sending them to the engineers responsible for the data scrub and ensuring all items followed the standards. Once the updated items were reviewed and approved, it was handed back to the technical team to upload into the new tool. Rinse and repeat.

Single, eh? But wait, there is more. Turns out the vendor sent their A-team for sales, then used the C-team for development. Part of the process is that our onsite team of contractors and vendor team would work, hold a handoff call with the offshore team when their shift ended, we held a hand-off call in the am when our team started up again. It was the project that never slept.

The first handoff from the vendor team did not go well. When our team took the code and attempted to work with it, it did not perform as expected. A few meetings later that day the vendor understood they would be following the internal development standards and subject to the same rigor of code review at hand-offs. It probably did not hurt my technical lead looked like a giant Viking (redundancy? not sure) and they seemed intimidated by him. He was a nice person and genuinely helpful.

We had no more quality issues at hand-off going forward.

In addition to the migration, we needed to get all the engineers trained on the new system, expand awareness of the new data standards and other process changes. And there was the reporting.

To solve this quandary, I separately talked to the sponsors about what their needs were for updates and what information would be useful to them. I combined the requirements to create a master list of information needed to create the reports for the interested parties. Everyone was happy.

A tough thing happened along the way. We were within budget but forecast to exceed. We could not do that. Approval for more money was not possible. However, as I sat and talked with my technical lead about the remaining work, we realized we could complete the project with one less contractor. We talked it out with our leadership from the contract house and then the project sponsor. We identified a person whose skills were great, just not a best match for the work that remained.

Since we were forecasting and not reacting, we were able to provide a lot of advance warning that his part of the project was winding down; his recruiter had started actively marketing them. Their performance was more than satisfactory, it was a pleasure providing recommendation/reference for them. Within a few weeks their next gig was lined up and so there was no disruption to his income. It still felt like crap.

One more complication we encountered; the new tool required a different version of Java than was currently standard on the enterprise image. We worked with the desktop support team and other teams to produce a solution and we were able to overcome the technical challenge. We also coordinated the rollout of the tool as well ensuring other operational readiness tasks were completed to mitigate the risk of a rough handoff from development to operations.

In the end, we delivered successfully, and the objectives of the project were completed. The enterprise goal was exceeded, all those on the incentive pay program were paid appropriately.

This project is really the most formative of my transition to project manager experience. The lessons learned have remained valid ever since that time so long ago. My contract ended, but hey, I was able to land a direct position that began immediately upon completion of my engagement. I had that going for me.