Development project becomes 'march to hell'

22.03.2006
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 mid-level managers became hands-on again. That's how I ended up heading the 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: we were supposed to architect and design the solution, write it, test it, train the in-house developers, and get the new product out the door --all in a year.

It was a tall order. 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 the company. 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, 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.

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 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-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. The company 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. What dismays you?

E-mails to Sandra_Rossi@idg.com.au