Better Software - July/August 2008 - (Page 22) Management Chronicles Going on a Picnic with James Watt by Clarke Ching “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 22 BETTER SOFTWARE JULY/AUGUST 2008 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 www.StickyMinds.com 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’ ISTOCKPHOTO http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.