Risky Beginnings

Projects get off track for a lot of reasons. Sometimes they get into trouble because of things we just can't anticipate at the start. Sometimes projects drift off-track as work takes longer than anticipated, or when shortcuts taken to "save time" lead to intractable problems. And sometimes the signs are right there from the start. These are the problems that are easiest to spot, yet they still bedevil many projects.

Fifteen years ago, I was a first-time project manager, straight out of the programming ranks. I was tenacious and a good problem solver, and my boss wanted to give me an opportunity to move up in the organization. He picked me to lead the first big project my area had done in years: a database migration. The project involved moving data from one database management system (DBMS) to another, and replacing the existing data access routines in a large system. We were all familiar with the existing systems' data access methods, but this was a much larger effort than the small patches and enhancements we usually worked on. We would be touching almost every module in the system, and writing programs to move data from the existing structure to a new one based on a normalized data model.

I didn't know much about project management: I'd never managed a project or led a team. But I knew the system, and I wanted to do a good job. So I took the half-page project description and target date from my boss, made a plan, and set out to manage the project. I felt good about starting this project-I believed that the problem was pretty straightforward, and that it was a good chance to prove myself.

I remember the feeling I had when I realized that my project was in trouble: that big ball of steel at the bottom of my stomach. I felt it for the first time the day my boss stopped by my desk and admonished me not to waste too much time planning and analyzing…that I'd better get the team coding if I wanted to make the date.

"But," I pointed out, "we don't have the specs done yet, so..."

"Don't waste time with that," he countered. "The specs are in the existing code. Just turn the programmers loose on it, and they'll know what to do."

That was my first inkling that things wouldn't go as smoothly as I imagined. And as the weeks went on, more and more problems kept cropping up. The work was taking longer than anticipated, and the customers were getting worried about the date. My team wasn't acting like a team, and I certainly didn't feel like a leader. Signs of trouble kept mounting.

• Programs we had estimated would take a week to finish were taking two or three weeks.
•  Code that was turned over as "complete" wasn't really done. Some modules were missing functions. 
• We were fighting with the support team over shared resources. It always seemed as if either they needed to make emergency patches to programs we were working on, or they were booting us out of the test environment to test the emergency patches. 
• Although the project was supposed to be a straightforward database migration, the customers persisted in asking us to fix existing problems and add new features. 
• All those fixes and new features meant more development and more testing-with no change to the target date and no more resources to do the work. 
• Our relationship with the end user had always been a little tense; now there was blatant unfriendliness. 
• We weren't going to make the