Development project becomes “March to Hell”

When the project time line is impossible and the requirements keep changing, experienced managers look for the exit

I started out as a developer but quickly moved into project management, process development, and training. Eventually I became an IT director, but when the bad times hit a few years back, all of us midlevel managers became hands-on again. That’s how I ended up heading the project we came to call the March to Hell.

For years, our company had been wooing “SeaTech,” an outfit that made geophysical research equipment. Eventually, we landed a contract to help them build a new state-of-the-art control system for their underwater transducers: We were supposed to architect and design the solution, write it, test it, train their in-house developers, and get the new product out the door —  all in a year.

It was a tall order, but nothing we didn’t know how to do. Except for the time line. I roughed out a schedule, and no matter how I tweaked the data, the worksheet kept spitting out numbers like 24 months. All my instincts made me certain that the project would go over budget and over time, end up burning out our team, and probably aggravate SeaTech. For the first time in my career, I said no.

Neither the VP nor the CEO wanted to be confused with facts. Both promised they wouldn’t hold overruns against me; all I needed to do was “my best.” I’d been pushing 50-hour weeks for six years, working through vacations and all that stuff, and in some strange way I was proud of my ability to take the heat and deliver. In the end, I said yes. I always said yes. I was a company man.

SeaTech asked for guidance on architecture, hardware platform, language, and development tool chains —  the works. To make matters crazier, the outfit was inventing a lot of the underlying technology used by the devices that the control system would control. Given the urgency of getting to market, we recommended using standard development tools and technologies. But the customer’s engineering manager insisted on a fully vetted, open review of the options.

Three months and countless meetings later, not one key decision had been made. I began to realize that the only acceptable recommendation was one that coincided with the engineering manager’s predetermined opinion. In the interest of moving forward, we caved.

Not that it helped. With only nine months left, the hardware was still being revised, we had settled on an operating system that had never been used for a control system this large, and no one on the team had ever used the tool chain.

In the end, we worked 80-hour weeks for half a year. We ate lots of nasty take-out food. We camped out in a corner of SeaTech’s office. But the product shipped on time. Sort of. When post-deployment defects began to show up, we had to place engineers on-site for months. The project, which had been way over budget already, went even deeper into the soup. Team members started calling in sick, then giving notice. SeaTech grew more dismayed.

My reward? I was sacked with the next layoff. But I’m not sure that was so bad. My consulting business is booming, I get to see my kids, and I’ve had many terrific conversations with my wife. So much for being a company man. You couldn’t pay me enough to go back.