|
 |
Home > Topics > Test & Evaluation > Detail: Going on a Picnic with James Watt
| |  |
Going on a Picnic with James Watt
By Clarke Ching
  
Summary: What if you had a picnic and no one brought potato salad? Find out what picnic planning and steam engines have to do with project success and not just satisfying your customers but delighting them. | | |
|
 |
"Takeout, please," I said. It was a nice day; we'd sit outside and enjoy the sun. I looked around the coffee shop as I waited for the barista to do his thing, but Dave wasn't here yet. It wasn't like him to be late.
Thankfully, the barista was in no rush and Dave arrived three minutes later, just before the coffees did. I handed him his coffee and we made our way outside, across the road, and into the park where we found a comfortable bench.
"How are things?" I asked Dave.
"Absolutely horrible," he said.
That's strange, I thought. Dave is managing a software development project for one of CCXSoft's big banking customers. It's his first big project, and I've been coaching him since he started the commercial negotiations a few months ago. Things seemed to be going well four weeks ago when we last met, but the project hadn't started yet.
I asked Dave how things could have turned so bad just three weeks into the project.
Dave let out a long, deep sigh. "Simple," he said. "The customer has reneged on its commitments. The bank promised me its subject matter experts and testers would be on board two weeks ago at the very latest, but they've not arrived. The customer keeps promising the SMEs and testers are going to arrive any day now, but I've been hearing that for the past three weeks. I don't believe it any more."
I sipped my coffee silently, leaving Dave plenty of space to tell his story.
"I'm convinced that the project is going to run late, and I can't do anything about it. It's a mess."
"You used the 'picnic principle' right?” I asked.
The picnic principle states that if you are planning a picnic with a group of friends and you want them all to turn up, then you make sure that each person provides something unique and vital to the picnic's success. Provided everyone's individual responsibilities
are clear and everyone knows that if he doesn't turn up then a vital part of the picnic will be missing and he'll be letting down all of his friends, then it's likely everyone
will turn up; no one wants to be blamed for ruining the picnic. The same applies in projects.
"Sure. We planned this project together, and I've made it very clear to the customer that its SMEs and testers are vital to the success of the picnic."
"The customer knows your team will be guessing at requirements without its help and, as a consequence, you will end up delivering an inferior product?"
"Absolutely. Garbage in, garbage out. I've repeatedly spelled this out to Mary, the bank's IT project manager, and she says she knows this but the people we need don't work for her. They work in other parts of the bank. She says she's been repeating that exact message to them: If they don't provide the right people, they'll get a weaker product.
"Mary keeps reassuring me that she is doing her best. The problem is that the SMEs and testers are working in operational jobs and their current bosses won't release them for our project. Not yet, anyway."
"It sounds as if Mary won't feel all that much pain if they don't turn up. Is that right?" I asked.
"Oh, she comes across as genuinely embarrassed by this. She keeps saying things like 'Don't shoot me, I'm just the messenger,' and I'm quite sure she's noted the delays prominently in her internal weekly status reports."
I smiled. I'd dealt with this bank--and many companies just like it--and the successful managers all seemed more focused on protecting themselves from being blamed for failure rather than ensuring success.
"So why are you bothered, Dave? You're not going to be blamed for their internal problems. If they're willing to take a lesser product, surely that's their choice."
Dave put down his coffee, thought a minute as he chose his words, then turned to face me.
"It bothers me because although we can deliver the product on the date we promised, that product then has to be accepted by the very same SMEs who should be working on the project NOW. They'll reject the software because it doesn't do what they want it to do. We'll start fighting about who pays for the changes. We'll lose money--unnecessarily--and we will have to delay starting work on other projects while we do the rework."
"Rework that could be prevented if they'd just kept to their promise?"
"Precisely. Look, Steve, when I took on this project I promised our VP that I would show him how I could use the stuff we learned last year not just to satisfy but delight the bank. I don't want merely to deliver what we agreed in some sterile contract. I don't want the bank saying, 'Well, the product is OK' and that they 'got the best they could expect.' I want to delight them."
Dave leaned forward. "Sure, I want them to get a good product, and I want to deliver on time, but it's more than that. When Mary, the SMEs, and the testers leave this project, I want them to say, 'Wow! What a great experience.' I want them to thank us for our hospitality, to say they just loved the picnic. I want them to volunteer the next time their bosses want to do a project with us."
Dave was talking faster now and his hands were flying over the place as he spoke.
"But, it's even more than that. I need their guys on board, collaborating with my guys. When the SMEs meet with their bosses and are asked how things are going, I want them to be able to say that we-re working hard--that we are hustling, even. They can't say that if they're not here working with us. I want the bank to feel that it's getting good value for its money. I can tell them that ... but I'd rather show them, each and every working day."
I dropped my poker face and smiled. "So, what's missing, then? What would make the difference?"
"Isn't that obvious? I need their SMEs and testers on board, like they promised."
"So, what's missing, then? What would make the difference?"
He frowned, not sure what I meant. I gave him time.
"The folks I'm dealing with are willing to accept a lower standard than they need to."
"So, what's missing, then? What would make the difference?"
"What would make the difference? If I could just put my case to someone who cared. Someone who could do something about it."
I said nothing. Dave knew what he had to do.
"It's obvious, isn't it? I have to talk to Mary's boss--the project's sponsor. I have to make him feel pain. Mary’s heart is in the right place, but she doesn't have the authority to make people move faster. Her boss does."
I nodded. He'd been having the right conversations--just with the wrong person.
"Good, Dave. Now what are you going to say to him? You've described the benefits to you and CCXSoft for getting its people on board now ... but he'll just laugh at you if you repeat those to him."
Dave frowned. "I'm going to need to talk dollars, aren't I?"
"It's easier than you think. Let me tell you about Watt."
"What?"
"No, Watt. James Watt--he helped kick start the industrial revolution. He also invented the term 'horse power.'"
Dave raised his eyebrows slightly then smiled. Another one of my analogies.
"Watt was a clever technician and an astute business man. He didn't invent the steam engine--he took an existing invention and improved it so it was commercially viable. After he'd done the innovative technical stuff, though, he found himself with a brand new problem: how to sell his new innovation. He decided to sell the steam engine to coal mines where miners could use it to replace the horses they used to pull coal and pump water from the mines. Watt needed to figure out how to sell to the owners of the coal mines, so he invented the term 'horse power' to describe how many horses each engine would replace. So a twenty-horse-power engine would replace twenty horses, saving the coal mine owners a lot of money. Watt took one third of the savings as his price, and both sides in the bargain came out substantially
better off."
"The bank doesn't employ horses."
"No, but imagine if you had the conversation with the sponsor where you say something like: 'If your people don't come, then we will still deliver to you in time to start your acceptance testing, but we expect that it'll take between two and four months longer for your team to do its acceptance testing. Some changes are going to come out of that--changes that we could avoid if your team were on board now. I estimate we will have to charge you between X and Y dollars to complete those. It'll also mean that you will go live two to four months later than you currently plan. I imagine the delay will cost you considerable revenue, too. I'd like your help to prevent those costs."
I looked at Dave as his frown slowly turned into a smile.
"Yes! That would work. He's going to feel pain--that's inevitable. He's also got the power and authority to avoid it. But I'm not going to talk to him."
"You're not?"
"No. I'll have the conversation with Mary first, then suggest we both go talk to her boss. Together we can come up with a stronger argument. And, more importantly, I want to collaborate with her on this project. How’s she going to feel if I go to her boss behind her back? That's not collaborative ... that’s adversarial. And that’s no way to delight a customer."
Good work, Dave. {end}
Dave is right: Projects deliver much more than what's in the contract, they also deliver an experience. Tell us about a great experience you've had and what made it great.
Join the conversation below or start a new one in the Member Comments section.
About the Author
Clarke Ching is a New Zealander living in Scotland. In addition to being an independent consultant and a regular columnist on StickyMinds.com, he's a passionate advocate of agile software development and a chairman of the AgileScotland special interest group, which meets monthly in Edinburgh. Clarke currently is writing a book titled Rolling Rocks Downhill, in which he explains why working with software projects often feels like pushing rocks uphill. He also demonstrates how to use lean, quality, and agile techniques to make your projects more productive and predictable. Read more about his book and other articles and listen to his podcasts at www.clarkeching.com.
Back to Top
|
|
|
|
|
|
|
|
|
Testing Training Courses
Software Testing Certification, Systematic Software Testing, Test Management, Mastering Test Design, Just-in-time Testing
Software Engineering Training
Mastering the Requirements Process, Requirements Modeling, Introduction to the Capability Maturity Model Integration, Business-Driven Software Measurement
Agile Software Development Training
Scrum Master Implementation Workshop, User Stories and Estimation in Agile Development, Design Patterns Explained, Practical Test-Driven Development
|
|
|
|
|
|
|
|
