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.