Discussion Forum > immutability of the size of work
Reposted:
Starting a new complicated project at work, and I found the number of tasks starting to grow past comfort level. Most of these are not 2 minute things like you might see at home. 2 hour seems more likely. What I'm thinking at the moment is to chunk these up. Many many of the items in OneNote are about the same thing, so if I group all those things together and just have a link to them in my task list, the list becomes much shorter, and the items that remain are not often Tasks any more but more Aspects of the project I need to spend time on. This way it becomes a focusing tool rather than an enormous bunch of trees to chop.
January 30, 2018 at 20:17 | Registered CommenterAlan Baljeu
Starting a new complicated project at work, and I found the number of tasks starting to grow past comfort level. Most of these are not 2 minute things like you might see at home. 2 hour seems more likely. What I'm thinking at the moment is to chunk these up. Many many of the items in OneNote are about the same thing, so if I group all those things together and just have a link to them in my task list, the list becomes much shorter, and the items that remain are not often Tasks any more but more Aspects of the project I need to spend time on. This way it becomes a focusing tool rather than an enormous bunch of trees to chop.
January 30, 2018 at 20:17 | Registered CommenterAlan Baljeu
February 2, 2018 at 19:42 |
Mark Forster
Mark Forster
Seraphim:
<< But you've said it often enough, I must be missing the point. >>
The reason you are missing the point is that you are taking my remarks out of context. I agree with everything you say about work often being much less than it appears when we actually get down to doing it. Though we should never forget that sometimes it works the other way and takes much longer than we thought.
But my remarks in reply to Alan's comment (which I've reposted above) have nothing to do with that. Alan was talking about shortening the list by grouping tasks together and just using the list to focus on aspects of the project he needs to focus on.
"This way it becomes a focusing tool rather than an enormous bunch of trees to chop."
All I was saying is that chunking up or chunking down doesn't affect the amount of work to be done. The "enormous bunch of trees to chop" is still there - it's just hidden under wraps.
<< But you've said it often enough, I must be missing the point. >>
The reason you are missing the point is that you are taking my remarks out of context. I agree with everything you say about work often being much less than it appears when we actually get down to doing it. Though we should never forget that sometimes it works the other way and takes much longer than we thought.
But my remarks in reply to Alan's comment (which I've reposted above) have nothing to do with that. Alan was talking about shortening the list by grouping tasks together and just using the list to focus on aspects of the project he needs to focus on.
"This way it becomes a focusing tool rather than an enormous bunch of trees to chop."
All I was saying is that chunking up or chunking down doesn't affect the amount of work to be done. The "enormous bunch of trees to chop" is still there - it's just hidden under wraps.
February 2, 2018 at 19:50 |
Mark Forster
Mark Forster
Makes sense, thanks!
February 6, 2018 at 2:47 |
Seraphim
Seraphim
<< However you chunk it or divide it the amount of work remains the same >>
http://markforster.squarespace.com/fv-forum/post/2653928#post2701766
You've said similar things in many places.
I've always wondered what you meant by that. It seems to be in conflict with other key insights I've learned from you - such as, deciding whether a piece of work needs to be done at all.
I am often surprised at how drastically the amount of work can be cut, when we are focused on outcomes instead of tasks. The point is to achieve the desired outcome, not to complete a list of tasks.
Mark Schwartz writes in his new book _A Seat at the Table_ (p. 78):
<< the Agile approach seeks to "maximize the amount of work not done" -- in other words, to find the smallest set of features that delivers the business value".>>
http://smile.amazon.com/Seat-Table-Leadership-Age-Agility/dp/1942788118
This seems to be connected to the experience many of us had with AF1 (and other systems of yours): some item has been sitting around for weeks or months or years, we have been resisting it all this time, it seems like a big hairy monster that will take hours or days of effort -- but when we finally sit down to do it, "little and often" style, we get it done in 20 minutes.
In short, I've almost never found it to be true that << However you chunk it or divide it the amount of work remains the same >>. But you've said it often enough, I must be missing the point. Can you elaborate?