Development project was a


Earlier in my career, I led a project we came to call the March to Hell.

We landed a contract to help a geophysical research equipment company build a new state-of-the-art control system for its underwater transducers — all in a year.

All my instincts made me certain that the project would go over budget and over time. For the first time, I said no.

Neither the VP nor the CEO wanted to be confused with facts. Both said they wouldn’t hold overruns against me; all I needed to do was “my best”. I said yes.

The company asked for guidance on architecture, hardware platform, language and development tool chains — the works. Given the urgency of getting to market, we recommended using standard development tools and technologies. But the customer’s engineering manager insisted on an 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.

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-away food. We camped out in a corner of the company’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.

My reward? I was sacked with the next layoff. But I’m not sure that was so bad. My consulting business is booming and I get to see my kids. You couldn’t pay me enough to go back.



Please enter your comment!
Please enter your name here