Development project becomes 'march to hell'

04.05.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.