We tend to spend a lot of time thinking about how to learn from bad situations, but there's just as much to be learned from our success stories. This one, relayed recently by a colleague, illustrates just how important it is not to take anything for granted, and to apply the tools we've been taught no matter what!
Sharon had a pipe-dream project. It was something she had proposed off and on for months, but the necessary resources were never available. Specifically, there was no money or time in Marketing for non-essentials, and this idea, while compelling, was considered a nice-to-have—not really essential to departmental goals. So her pipe dream trickled along, never gaining momentum, but never really dying out either. It remained a pleasant, compelling, but unattainable dream.
Because it remained compelling, the idea came up in meetings from time to time. After one of these conversations, she sent an idle email to one of her IT contacts asking again about the possibilities. Just hypothetically, if we wanted to develop an in-house program to do X and Y and Z, how long would it take, and what would it cost? Is there a stripped-down version that could be done in a week or so?
"Not a chance," was the emphatic reply. "It would take at least a couple of months, and we'd have to spend on software upgrades, too, in order to support the new features."
It was exactly what she'd come to expect. But the next sentence stopped her in her tracks.
"But don't worry about it; we've got a couple of guys between projects right now who are perfect for the assignment, and we'll underwrite the upgrades out of our operations budget. Just let us know what business rules they need to be aware of, and get us a spec. We can get started next week."
Whoa. What the . . .
At first it seemed like a dream come true. But instead of celebrating, Sharon froze. Her exciting idea was suddenly scary and intimidating. Days passed without any progress on the requested business rules, and the spec was nothing more than a few bullet points scribbled on scratch paper. Confronted with everything she had ever wanted, she found herself unable to do anything at all, and she couldn't understand it. "I ought to be elated," she told me, "but instead I'm freaked out."
Why, was my obvious question. "I'm not sure," she replied. "I guess all of a sudden I'm just feeling the weight of responsibility. I have to justify everything. I can't afford to get the least little thing wrong. After all, it's not our money anymore. I'm spending IT's money now."
"Well, yeah, I guess you do have a new stakeholder to deal with," I said, attempting to sympathize.
So far, Sharon had focused entirely on the unexpected pot of money. Who wouldn't love to have a pile of cash and a free, fully qualified team for their pet project? Have budget, will launch. Let's get going! It was almost too good to be true.
But her gut instincts, fueled by years of PMing, told her that it was too good to be true—thus her stall. That rather pedestrian remark got Sharon unstuck. No one hands over two full-time developers and a stack of unmarked bills without a darn good reason. Why in the world would IT commit those kinds of resources to a pet project for the Marketing department?
There was only one possible reason: They cared about the project, and that made them a stakeholder. She'd been unsure how to handle the sudden wish fulfillment, but she knew exactly how to handle stakeholders! There was some new and important work to do. Someone else's vision now mattered, a lot, and someone else's requirements had to be incorporated into the spec. So she called up her IT contact, apologized for the delay, and asked why this was important enough to them to spend money on.
As it turned out, of course, they had a very specific stake in the project. Marketing's needs dovetailed nicely with theirs. Taking on a project for another, highly visible department gave IT the cover they needed to accomplish one of their own critical goals, not to mention justify some idle budget money that they didn't want to lose.
So, instead of handing down requirements, Sharon went back to her long-nascent project vision and asked the critical questions. Why are we doing this project at this time? What will it take to make this stakeholder happy? In this case, it was to put together something that really wowed the crowd; IT felt the burning need to prove their worth and demonstrate their cost-saving potential for the whole organization, and this gave them a perfect way to do it.
We write a lot around here about savvy project managers. One of their primary characteristics, I think, is that savvy PMs assume nothing. Sharon could have decided to take the money and run, but she knew better than to assume that anything is free. If someone is spending money, there's a reason. That reason must be fully understood, so no one thinks the money was wasted when it's all over. Do you know where your project's money came from? Whose budget? Which strategic goal? Which departments care about that goal? There's always a story behind the money, and that's what Sharon's gut knew. By following that instinct, she wound up with more than she expected. She was able to ferret out critical additional stakeholder requirements with the group, which helped her justify not just the stripped down program she'd asked about, but the real game-changer she'd dreamed about.
This is just one example of the unexpected benefits you can turn up when you really take the time to think through your stakeholders. Forgotten stakeholders can derail projects with delays, objections, roadblocks, unexpected requirements . . . most of us know the litany and have learned from previous bad situations. But success stories like this remind us that unexpected stakeholders with common goals can make apparently impossible projects brilliantly, beautifully possible.
Every dollar in your project budget has a story behind it—a story and a check-writing stakeholder. We'd all do well to understand that story.