One memorable day, I was asked to take over a programming project that had "gone South" -- ominous words.
The background: This was the second project we'd taken on with a customer we'll call "Acme," a small hardware company that manufactured aviation components. The first project had been a monitoring system in which we wrote the software for Acme's hardware.
[ Get a $50 American Express gift cheque if we publish your tech experiences. Send your story of a lesson learned, of dealing with frustrating coworkers or end-users, or a story that illustrates a relevant takeaway to today's IT profession to email@example.com. | Get a new tech tale delivered to your inbox every week in InfoWorld's Off the Record newsletter. ]
It was such an unpleasant experience that our company owners promised we would never do business with Acme again. Hardware delays, accusations, arguments over responsibility, and disagreements over payment all had made the project difficult. On top of that, "Bob," Acme's director of engineering, was a verbally abusive, vulgar, profane, and completely unpleasant person. It was well known that he had over 100 percent annual turnover in his shop.
Fast-forward a year and a few rounds of executive golf and we were somehow doing another project for them.
This time, we were told, was going to be different: The project was a simple addition of one new component to the system we wrote, was backed by a multinational aerospace conglomerate, and was going to wrap up in six months. Acme was sending prototype hardware within six weeks, and our company's project manager quickly and easily created a software specification that was tightly bound to the hardware requisition. It was a small, focused upgrade.
Unfortunately, at six months, the project was nowhere near complete. We hadn't even received any prototype hardware. This is when I was asked to take over.
I learned that the reason we didn't have any hardware was because Acme was re-engineering the entire system. Nothing was the same, and no code from the original project was reusable.
The entire contract should have been renegotiated, but our company executives did not want that kind of hassle. Our project manager was tired of the mess and of dealing with Bob, so he pushed the project onto someone else: me.
Because Acme was inventing new hardware, there was a steady stream of changes. The tightly bound software specification meant that with each change, no matter how reasonable, had to be traced up and down the document chain to comply with FAA regulations. Hardware specifications came from system specifications, leading to software specifications, test plans, software design documents, test cases, software modules, and right down to lines of code and individual tests.
We spent most of our time tracking changes and updating documentation. I invested most of my time with engineering change orders and daily project plan updates. When we finally got three prototype hardware systems, the same software build wouldn't run without significant changes.
Topping it off, we had to work with Bob. He swore when we told him that the hardware wasn't the same, he cursed when I sent change orders, and he threatened us constantly -- from killing the project to lawsuits for our mismanagement.
Bob also came to our shop daily for a status meeting. He would bring my project plan, printed out in color on a four-foot sheet of paper, roll it out on the conference room table, pull out a red marker, and make a huge line up and down on the current date. Then while gesturing and scribbling he would yell, "I just <bleeping> want to know, are we <bleeping> on this <bleeping> side of the <bleeping> line, or are we <bleeping> on this <bleeping> side of the <bleeping> line."
I realized that Bob's theatrics were an attempt to get me to react. Fortunately, that isn't my nature. After Bob was done, I would present the change orders to him. He would sign them (more profanity) or throw them on the floor and stomp on them, only to sign them some other day.
To get Bob and his theatrics out of the way, I started including Acme's president and the chairman of the company board, as well as our senior management in short daily updates. Pretty soon, there was open dialogue at all levels, not just one funneled through Bob. Progress was being made.
I focused on cutting as much out of the project as possible and locking down details as quickly as feasible. We managed to get the project out of our shop and approved by the FAA.
Through the experience, I learned a tremendous amount about staying cool, not letting someone else's bad manners influence me, and keeping my eye on the ultimate goal. Oh, and we never did another project with Acme again.
Looking for more tech stories or tips? Also on InfoWorld:
- Stupid user tricks 5: IT's weakest link
- The dirt locker: Dirty duty on the front lines of IT
- Off the Record's best stories of 2010
- Follow these tips to protect your IT assets: How to divorce your tech vendor
- Get tech career tips and advice in Bob Lewis's Advice Line
This story, "A software project's challenge: Working with a bully," was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.