CBS wants your PM hero story
A journalist for BNET, part of CBS Interactive, is looking for a great short story on dealing with things going wrong on projects.
She wants:
First person stories about how you recently saved a project by tackling a deadline problem, scope bloat, budget issues, key person quitting, etc.
Since she seems cool I offered to throw it out to you guys and see what good tales you might offer about how you overcame a really tough situation.
Leave ’em in the comments. I suspect you should keep it to a few paragraphs max :)
I have soooooo many horror stories.
But not that many hero stories.
When project managers do good work
OK, Scott. You’ve known me for half of my life. Translation: you asked for it. I don’t know if this qualifies as being a hero. I’ll let you judge. Because these stories can be boring, I’ll go with a Fight Club motif.
Here goes
Mike, I tend to agree with you – successful projects don’t tend to look all that hard, let alone heroic.
I wonder if an example of one is when you start out so constrained (too short a timeline, high risk, no budget, whatever) that failure is inevitable, but that the powers-that-be demand it happen anyway. (Tell me I’m not the only one in those situations.) The heroism comes in when the team pulls together, lives on ramen and gas-station coffee and delivers something that wows.
I’m thinking of one success in recent years. I’ll call it living to fight another day.
A product in the making for a tech-driven startup needed at least a couple successful pilot deployments before current funding ran out, to use in securing the next round. In a sense a startup is a series of projects each with very real milestones of business results, product scope & quality, and time / cost. You deliver well enough or you are done.
Well, in the run-up to the end of this runway, their QA manager quit or was fired, depending on who you ask. I was already in conversation with them, so went from a phone call with the CEO Tuesday, to on site three days later, and committed to the target the following Monday, April first. (Really.) Now QA-guy is not necessarily project-guy, and they had a PM in place / on site.
However, nothing good had been happening project-wise. They had task lists and timelines, yet delivery was failing. They also had piles of test plans and procedures, and various pretty assessments of “coverage”, yet the project was not converging and each attempted pilot deployment was a surprise.
It turns out the “project” and the goal for the next business milestone was really to “productize” a formerly toolkit-based semi-custom app. So it was really mostly there. What wasn’t was any semblance of progress. It turns out that the work that needed doing had little to do with a development-pure WBS of analysis, design, code & test, whether incremental, iterative or big bang. This was an integration problem, really. They needed a reproducible baseline for a system that was 70 – 90% right to begin with, yet existed only as craftily hacked together custom integration produced over a great period of time.
So, I did two things, really. Listening to the production talk there was a constant litany of piece-parts to be tweaked, created, accessed, recovered, or put in the right place. So, at the right moment I asked the PM “Do you have a manifest?” After a little back and forth I ended up saying: “It seems like there are a lot of pieces and you don’t know the list, or the state of many of them. I think we start with a manifest,then the work becomes to capture & baseline a version of each – make that the authoritative revision – and go from there.” In project management terms, the WBS was nonsense because the manifest was nonsense. Completion of identified tasks meant less than nothing in relevant progress.
Now, there were quite a few possible scenarios, and you could go after test coverage a bunch of different ways. The recently-ex QA-guy had gone off into the by the book QA zone, with piles of test cases and so on traceable to lots of nothing relevant. The key scenarios, were only two. We needed to be able to install the thing, and as an appliance we could do that ourselves, by hand, even with some fits and starts. Yet, in this scenario each item missing, mis-versioned or incomplete from the manifest, baseline or install procedure really counted as a defect.
The other scenario was to support as I recall five specific versions of five network devices. Now, in test we had the ability to simulate that traffic already via a homegrown tool. Yet, this wasn’t happening. So, I declared that we would simulate maximum load and all known responses from those five devices. That was out “scope.” Shortly after that, we added half a dozen or so “smoke test” equivalents exercising other capabilities at all, but not at all completely.
What did those two things really do? They set scope. They reduced project activity to tasks that were relevant to the milestone at hand, not some other, later milestone, or some hypothetical notion of “good.” More than the quality of the artifact, and defect data, the “testing” performed really provided project management feedback on the completion of the work being managed. The work to build a thing isn’t done until the thing is baselined, recoverable, and does its job for those five network devices.
It turns out that the project “plan” attempted to address the wrong scope – the eventual scope of the ultimate product, and as if development were starting from scratch. The “plan” was wrong in its activities, omitting perhaps half of the required artifacts – parts of the running system – and as much as 20% of the work. The “plan” was wrong in its steps and tasks, focusing on coding as if from scratch, design as if from scratch, etc. Activities and tasks both omitted integration altogether. This is what I said to the CEO and Engineering VP over dinner that fateful first Friday on site – “This is an integration problem, not a development problem.”
Since the team was adept at both grand future pronouncements and short-term heroics to “resolve” (really relieve) the current stubbed toe, producing really a system in perpetual mutation, talking about the problems would just stir up more make-work. Rather than talk, we installed our own test target using the written manifest, pulling from the baseline repository. We tested this against the actual, minimal target scope – five devices and a smoke test. Anything mucking up became a change request. Initially, the vast majority of these were resolved by changes to the manifest, adding items or changing the version required.
31 days after that April first, the test team demonstrated every major feature of the product to the whole company. The CEO declared: “I have just seen the birth of a product.” The company, needing one and preferring two deployed pilots in evaluation, had three by mid-month, and got their next funding round with time to spare.
I don’t know from heroics. Aside from some unpleasant flight schedules to allow me to be on site during the work week – the immature organization really requiring “application of force of personality” to play by their own declared rules – there was little dramatic extra work. And while I was in principle in QA, these were really project management interventions delivered in testing terms, since that is what could be heard – scope of features, scope of WBS, and accurate knowledge of completion of work. We really just started managing the actual project and the actual work, vs. the project management artifacts (like a Gantt chart saying this or that is done because the date has passed).
I hope this story is the kind of thing our correspondent is looking for. I have many more. The correspondent is welcome to contact me if I can be of help.