One of the most useful things I've learned during the last five years is to spend some time, at the start of a project figuring out your "promise" - a 2, 3, or 4 sentence promise to your project's customer. The effort that goes into preparing the promise is akin to the effort journalists go through to prepare the "lead" for an article. You get the lead or the promise wrong then you write a bad article or deliver a lame project.
I first learned to use promises when I ran a data cleansing project, while working for Vision Consulting, (my first non-software-development agile project) where the promise was to "remove [our client's] customer's reasons for not paying their bills" - they weren't paying their debts because they didn't believe the bills because the data was bad, which is why we were cleaning it. Somewhere between making the promise and delivering on the promise we'd become a data cleansing project, rather than a "remove the reason for not paying your bills" project. Once we realised that, we shaved months and months off the project, by eliminating work customer was happy to pay for but didn't really want.
We delivered that project in 9 months - it was cross-fingeredly estimated to take 13 or 14 months, but people thought it would take much longer. I'd say that my charming personality made up for 10% of the difference, using TOC/Agile made up 50% of the difference, and working from a solid promise and remembering to revisit it, accounted for the rest.
If you're doing a cost/benefit analysis: it took between 1 and 2 hours to come up with the promise.
My favourite promise was the 2-word "Rebuild Trust" - a 30 minute effort which steered a mutli-million pound project in the right direction and resulted in millions of dollars of new sales. The promise is there if you just spend a little time looking for it.
So I like to make a 1-4 sentence promise but while you're making your promise you really must ask yourself "how do I know if I'm keeping this promise?". That's why I like Tom Gilb's ideas so much. QFD is also fantastic. The two seem to compliment each other very well. You can read more about Tom's work in his (extraordinaryly good, but extremely densly packed) competitive engineering. My TOC buddy Richard Zultner recommends Step by Step QFD and, although Richard isn't fond of it, I also found Quality Functional Deployment: How to make QFD work for you useful. And finally, yesterday, I stayed up late reading How to Measure Anything: Finding the Value of "Intangibles" in Business which, although this may be the nerdiest thing I've ever written, is absolutely fascinating. I'm only on chapter 2 ... but I've got my moneys worth already.
I started out writing this with the intention of telling you a little story, so forgive the preamble. It's about measurement and promises.
A couple of days ago I met up with some very clever folk who work in a very clever local company which makes rather clever medical imaging software. We were chatting about how they measure progress on some of their "Research" (as opposed to Development) projects. We got to talking about one project they were working on - a 6 month effort with one very clever customer and one very clever researcher/developer where the single requirement was to scan though swathes of data from some sort of medical scan and (digitally) "pluck out" the data that belongs to the heart. It's a simple requirement, but how do your measure that? What they did was take, say, 50 scans and give them to real life doctors and get them to identify the heart manually with (one hopes) 100% accuracy. Then, as the project progressed, they measured the software's accuracy rate when it processed exactly the same data. The accuracy started off poor, quickly improved, and then tappered off. It's a very simple measure that you could graph out and monitor over time.
So starting out with a promise "pluck out the heart" they could measure how good they were at it. They could judge when it was worth stopping, either because the hit rate was good enough, or because it was getting too expensive to improve. They could also use an estimation matrix to compare design ideas "I reckon if we did X, it'd cost Y and we'd get a 5% accuracy improvement. If we did Z, it'd cost us W, but we'd only get ...".
So: agree out your promise, figure out how to measure it, monitor and manage.
