Tales of woe and things that went wrong
PM Clinic: Week 17 discussion summary
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.
(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 :)
Eric Votteberg, Michelle R. Peterson, Neil Enns