Tales of woe and things that went wrong

PM Clinic: Week 17 discussion summary

Compiled: 2/28/2005

The Situation:

This week, lets try something different. Like we did back in Week 3 with our list of mistakes PMs make, I'm looking to compile a nice list of people's favorite war stories about things that went wrong on their own projects, or project's they've witnessed. Disastrous meetings. Missed deadlines. Imploded features. You name it.

Stories:

(Eric Votteberg) Years ago I joined a dysfunctional tools/support team as a new PM. At the same time a new dev manager was brought on; both of us were charged with bringing about accountability to a team recklessly over budget, over schedule and with no leadership. The previous dev lead had been running the show, we'll call him Mr. X, went off to incubate a "new project" in the same org. Three months later things were going well, customer satisfaction was on the rise, we were hitting our dates, good process were put in place. Then, suddenly, Mr. X shows up at my door with one of our more important customers at his side. Apparently, he'd been incubating new feature code for our tools software on the sly with this customer who happened to be a personal friend. There were no specs, no input from test, no input from anybody on the team. A complete surprise.

This important customer now insisted that these new features were absolutely necessary to their business and they should be rolled into the next release; which was already in debug phase and a week from release. Mr. X insisted that his code was "bug free", (as if there was such a thing), and we were being silly to push back putting this into the release. Test was outraged, how could they test new code they've never even heard about and for which there were no specs? They refused to sign-off on the release if this code was included. Rage ran though me, I was cornered, this violated every shred of trust I had in these people and I began preparations to start the brimstone of flame mail to everybody involved to exact my revenge. Fortunately, the new dev manager on my team kept me away from the keyboard for a few days while things cooled off. Many lessons were learned, eventually trust was restored with the customer. Mr. X moved on to another org. Many lessons learned.

(Michelle) Eric! You left out the best part of your story! :-) How were things resolved? Did the code get put in at the last minute? What lessons, exactly, did you learn? How long did it take to wake from this nightmare?

(Eric) Thanks for your interest Michelle, the whole thing take some time to explain; I thought I would just tell the worst part of it for the war story. Basically, we scheduled a QFE release for the new features to follow our scheduled release. We required Mr. X and the customer to provide us with specs before we'd introduce the code. I think we got it out the door within a month of the blow-up. This had a ripple effect through the rest of our schedule, but it had to get done to appease the customer. For me the lesson was all about customer communication: 1. Make absolutely sure that there is one clear and open channel of communication. 2. Be very wary of personal relationships with outgoing staff and existing customers - find out what promises have been made and expose them to everybody. 3. Not sending the flame mail I wanted to send was the best thing that could have happened. Had I sent that mail much damage would have been done. (My final rule on that "never flame first in an email" - it's much more satisfying to do in person or in reply as a counter flame ;-) Cheers, Eric

(Neil Enns) Oh my, so many to pick from... :)

On my last team I owned several feature teams, one of which was responsible for designing and implementing one of the top three features that were requested by our customers. Not only that, but it was a feature that our product was clearly lacking and that our competitors were far ahead of us with. We weren't shooting for a leapfrog design, just something that would get us to parity with the basic level of functionality expected by end users and manufacturers.

All the way back in our planning milestone this was understood to be a key aspect of the release. Our management team agreed completely.

We wrote the specs and designed what we thought was a nice v1 of the feature. Not too fancy, but still with a little bit of spice to make it interesting. If necessary we knew we could trim the spice back depending on resources.

In M1 (M1 = Milestone one, Microsoft terminology for phase or iteration - SB) our resources were slashed to half or so of what we expected. We chopped back the spice and then some, and unfortunately couldn't spend any time on the feature due to something else on our plate that was unexpected. We pointed out to our management team how important even basic functionality in this area was, and they agreed.

In M2 we had more of our resources reallocated. We again pointed out to our management team how important the basic functionality was.

In M3 the lone developer on the feature literally walked into his manager's office, quit, and then got on a plane to move back to the U.K. I swear, he just walked in and quit. Same old song and dance to management.

In M4 we worked out a deal with one of our overseas offices to do the software development. They didn't generally write shipping software, but they had expertise in that area. About this time in the project, I left the group :)

The team is now trying to release, and of course this particular feature came in way late, had stability issues, and was a mere shell of its former self. And all along everyone still agrees that it was key to have something in this area to offer our customers. Ah well :)

Contributors

Eric Votteberg, Michelle R. Peterson, Neil Enns