Here’s an absolutely mad thought-experiment…
Over at KnowledgeJolt, Jack Vinson is on a “personal effectiveness kick”. And being interested in the Theory of Constraints, he’s naturally looking to define his Goal, and to define one or more effective measures of progress towards it. In response to a little goading from me, he says this in the comments on Too Busy Being Unproductive to Learn to Be Productive:
“What we need to know (in terms of measures) is whether we are reaching our goals or not. If we’ve taken action that moves us in the wrong direction, that’s probably the wrong action. (If we didn’t know that it would be wrong in advance, then it was a good learning experience, and we can do something different next time.)
“The difficulty with productivity, as it is typically used, is that it simply measures output without looking at direction. For example: I did ten things, but only one of them contributed to my long-term goals. Even worse, two of them distracted from my ability to meet my goals.
“I’m not sure what the final personal measure would look like, however. I’d rather have something that showed how much progress I’ve made, rather than an accounting of how many things I’ve done.”
What’s required, then, is a way to define our goals – and to quantify them.
So here’s the mad part: Suppose we define our personal (productivity) goals using the approach Tom Gilb takes to defining software requirements.
I’m no expert in Tom’s approach, having never had the temerity to try it for real on a project. My reading, and a couple of conversations with Tom, suggest that it boils down to the observation that most software “requirements” are actually solutions to deeper business needs. The approach, then, is to repeatedly ask “why?” (sound familiar?!) until we arrive at non-functional quality targets (eg. Usability, Flexibility, Resilience, etc) and then seek to quantify these. The resulting “quantified qualities” are the real requirements, and everything else is design detail.
So I think this could just work for personal productivity. Instead of asking “how” can I become more productive, I should ask “why” do I want to. I may get a range of answers – ask “why” to all of those. And so on. Hopefully this process will come to a natural closure, at which point we then begin asking “how will I know” whether each goal or target has been met. Eventually, we’re looking for a set of quantified qualities that any acceptable solution will possess, such as:
Scale: Days per week on which my in-tray is empty at 5pm
Meter: Visually check my in-tray at 5pm
(The name LowStress.IntrayAlwaysEmpty is intended to imply that I might have several measures, all of which contribute to knowing whether I’m getting towards my low-stress targets. Another might be LowStress.FinishWhatYouStarted, for example.) It seems to me that this meets Jack’s aim of having a set of measures that one can gradually work towards – big visible charts spring to mind – while still leaving the design of the actual productivity improvement(s) down to experience, trail-and-error, etc. The trick with Tom’s approach is first to get away from the “how” space and into the “why” space, and then to dive into the “how will I know” space. Tom claims to be able to “quantify any quality” in the software world, and I don’t right now see why that won’t extend over into other domains…
This has been a thought experiment, meaning I haven’t tried it. Yet. Do you think it might work? Have you tried something along these lines? If so, what was the outcome? If you’d like to try it, I’ll be happy to work with you on the “requirements” analysis!