Hi everybody: This is an open thread for anyone who wants to comment on How Big Things Get Done, or discuss any aspect of the book. If you like the book and want to say so, please do (I am not above flattery) but also feel free to criticize whatever you like. Civil, open, constructive conversation is always welcome.
I appreciate the lessons set out in this article and look forward to reading your book to have the ideas fleshed out more fully. I wonder if the book also considers the risk of over-planning. I recognize the strong tendency you describe to jump in to solve a problem immediately without fully scoping out what our real goals might be and thus, in essence, moving forward to do more of what we have always done. However, I have also seen instances where projects get overwhelmed by a need to collect yet more data, or to look at more factors which objectively have little bearing in the ultimate success of the project. I suppose that this problem could relate back as well to the very point you have highlighted - namely that the project leads did not spend enough time at the outset determining what their real objectives and measures of success were.
Thanks, Rene. You put your finger on a real problem. It is quite easy to talk endlessly, hold meetings, draft documents, blah blah blah, and accomplish little or nothing. For those possessed of (or perhaps "by") a bureaucratic mentality, the sheer volume of work is itself proof of value. The rest of us know better. This is why the chapter on planning focusses on simulation and iteration, which we regard as the core of real planning -- planning that is worth the time and effort because it identifies problems and solutions and makes you better prepared for delivery. I think you also correctly identify a cause of bureaucratic busywork: In the absence of a clear sense of mission and leadership -- a project with a clear, strong "why" and leaders keep everyone relentless focussed on it -- "more information" and "more discussion" can seem reasonable, when they are, in fact, a byproduct of aimlessness.
Another benefit of working effectively to define objectives and expected outcomes can be finding advantage in breaking down a project into phases. Taking off on my comment above, the desire to collect more and more data can create paralysis while we all wait until perfection is achieved. Only then do we decide to move forward. It can be quite appropriate, I believe, to build a three storey building now but incorporate features that would allow for adding extra floors later on. Or construct a highway in the knowledge that it may be necessary to add lanes at some point. The problem is that we often are working with a budget which does not allow for such considerations.
I have a question. One of the examples in HBTGD is writing a book. But the only point illustrated there is to get reference informed estimates. I imagine other aspects apply too. A number of software text publishers are using incremental publishing to get chapters out as they are written. Perhaps you do this in a limited way with a select audience.
My interest in this is to inquire into how abstract the Lego approach can be. Each chapter is a different thing and you can’t do the next chapter by copying the last, no matter how good it was. But in other ways they are similar- they have to fit together and form a coherent book, problems solved in authoring one may well apply to others and the each forms a new reference point for estimating the work involved.
I don't think we're advocating any universal system, only tools that may have greater or lesser application in particular instances. What matters is to really understand the goal and nature of the particular project and work out which tools are applicable and how they can best be used. Hence, it's difficult to discuss in the abstract.
Thanks Dan. I appreciate all good advice is good except when it is not. The look for scalability advice works well in the case of manufacturing but I am wondering if it works in less obvious cases. In the case of a book it seems hard to apply. Anything too rigid could look formulaic and the reader expects something new in each chapter. But I wondered if you see any application of scalability when working on a book.
I’ve been meaning to ask this question for a while, Dan: Will you or Bent attempt to track projects whose designers and builders adopt significant portions of your advice in the book to see how they compare with the status quo? Also wondering if anyone bases a consultancy off the ideas and how their work influences project outcomes.
I am working as the Director of training and change on one of the largest IT projects in Tasmania (the little island at the bottom of Australia). I work through an agency that has around 50 project managers on various government programmes. I also do some work for the behaviour lab at the University of Tasmania. I've been following this work since an econtalk episode with Bent a long time ago! I was wondering if either or both of you would be willing to do a video call to promote your book? I can get a significant number of senior government decision makers and academics down here to turn up as well, and its a message they probably all need to hear :-)
I like the advice that projects that fail tend to drag on, while those that succeed zip along, particularly thinking about project duration as an open window. The longer the duration, the more open the window. The more open the window, the more opportunity for something to crash through and cause trouble, including a big, bad black swan.
Instead I couldn’t help but think of the Gorilla 🦍 in the Cockpit - Breaking the hidden patterns of project failure and the system for success by Vip Vyas and Dr. Thomas D. Zweifel. They say the root causes to project failure cannot be found in traditional project management books. They are neither technical nor financial. They are human.
I also liked the advice that “big is best built from small with modularity. If a project can be delivered fast and in a modular manner, enabling experimentation and learning along the way, it is likely to succeed. If it is undertaken on a massive scale with fat-tailed distribution, highly integrated components, it is likely to be troubled or fail.”
I'm waiting patiently for the book to arrive, but I've been following the articles and work since I graduated 5 years ago.
I applied the methods described and found instantaneous success. Luckily for me, I worked in the digitization side of projects as well and collected data on some of the biggest projects in the Netherlands. While the organisations never really were interested in the analysis of the data collected, I've definitely used this as a means to prevent exploitation and help me identify behaviours that led to cost overruns.
Not that difficult to do when the industry is run by just a handful of players.
I'm extremely excited to read the book!
My one question is this: critical success factors look and behave differently in different sectors. Too often do I see information being misclassified; either because their methods are binary or because it only factors in one perspective. How do you know if you can trust the data?
I am captivated by the book and can see its potential applications spreading far and wide. I have started recommending it to friends and colleagues.
So far, part-way through, the only place I have paused, quizzically, is the chapter on experiri - that combination of experience and experimentation.
First, I especially value the story about Gehry having nearly been torpedoed by his Disney Hall experience. Without some good fortune, he might never have had the chance to do Bilbao. Then, it was critical that he a) was determined to learn from the Disney project and b) that he knew how to learn from it, what questions to ask himself, what improved planning process to follow.
Which leads me to my puzzle…
The value to be drawn from both experience and experimentation seems to be highly dependent on relentless curiosity. the skill of knowing which questions to ask and the fearless mindset to want to go wherever the answers lead you, which qualities I think are not ‘normally distributed’ under a Bell curve.
First, experience. We all know of people who lean on their experience to say: “that was tried before and it didn’t work”, squelching innovation or even change in its tracks. That incurious statement is too rarely followed by “so let’s try a different version, based on what we learned that time”!
In interviewing one of Canada’s most admired Directors, I came to board composition on which he said: “I look for directors who have a track record of major mistakes, people with scars on their backs”. His unspoken corollary was surely “and who knew how to extract maximum insight from each scar “. Perhaps followed by “and who are not afraid to admit to those mistakes among their peers as a means to advance better decision-making the next time”. I.e., deep experience, by itself, is not enough.
Even a willingness to confront openly the brutal facts about past experiences that went wrong can lead to drawing out precisely the wrong lessons. If Bent had not helped out the Hong Kong project, and applied his expert judgement to knowing which questions to ask, would they have reached the right conclusions? They might have missed the forecasting insights altogether.
As for experimentation, it too, relies on us having the judgement to know: where to look for insight; which sometimes unconventional possibilities to test; and how to frame the right hypotheses to validate, in the right sequence. We need to ensure that most new iterations take us closer to the ideal target design, rather than causing us to spiral further away.
In both forms of experiri, then, we rely on having people with curiosity, fearlessness and a robust skillset polished from years of painful learning. All true. And we can select for these.
But there remains one more ingredient without which these other qualities can fall short - good judgement (practical wisdom) which you note can be enriched by experience. - but is it always? Not everyone with years under their belt can claim to have it. It seems to need an instinctive ‘feel’ that distinguishes the best practitioners, an instinct they might struggle to articulate, but which daily informs their thoughts and actions.
So if I am interviewing candidates for the ideal home reno contractor or manager for a multi-billion dollar project, I can rule out the incurious, the callow or the craven. But how do I test for that elusive quality of good judgement, which may be ‘the one ring to rule them all’?
You probably have to add into this mix how the organizational culture reacted to those failures and experiments. I am certain many people have the innovation and risk tolerance driven out of them.
Hi Dan. A very enjoyable book. I think you found the right level of detail for all levels of managers. And the biography was outstanding. It permits us who want to explore further an excellent base.
I was a little surprised that you lightly treated project management techniques such as bottleneck and the Theory of Constraints (Goldratt). The concept of Subtract (Klotz) wasn’t discussed. On the other side, Robert Hughes’s works were discussed. He’s a significant figure which his ideas of Theory of Change. Also, happy to see the MIT System Dynamics elements referenced. I might have accented them more. But that only my opinion.
Overall, a great book and effort. And a great read to boot.
I went to Indigo at the Rideau Centre to buy a copy. It's not yet in stock! I'd prefer to patronize a books and mortar store. Please let us know when and where you'll be doing a signing.
My online order was held up for the cyber issue at Indigo, similarly their Ottawa-based physical store didn't have it (for an Ottawa-based author!?), but the local independent store did. they had two copies, I bought one and after a discussion with the employee she bought the other. Should have started at the independent spot!
This is the second time I've heard of an Ottawa store not having the book. Weird. But well done for tracking it down. And talking up another sale! Thor thanks you.
I've no immediate or direct comment that I can make on your book, but do want to share that I purchased the e-book for my spouse, and convinced a busy friend with a big project to purchase a copy on audible.com to listen simultaneously as they work. Best wishes to you, your co-author, and your pup.
I appreciate the lessons set out in this article and look forward to reading your book to have the ideas fleshed out more fully. I wonder if the book also considers the risk of over-planning. I recognize the strong tendency you describe to jump in to solve a problem immediately without fully scoping out what our real goals might be and thus, in essence, moving forward to do more of what we have always done. However, I have also seen instances where projects get overwhelmed by a need to collect yet more data, or to look at more factors which objectively have little bearing in the ultimate success of the project. I suppose that this problem could relate back as well to the very point you have highlighted - namely that the project leads did not spend enough time at the outset determining what their real objectives and measures of success were.
Thanks, Rene. You put your finger on a real problem. It is quite easy to talk endlessly, hold meetings, draft documents, blah blah blah, and accomplish little or nothing. For those possessed of (or perhaps "by") a bureaucratic mentality, the sheer volume of work is itself proof of value. The rest of us know better. This is why the chapter on planning focusses on simulation and iteration, which we regard as the core of real planning -- planning that is worth the time and effort because it identifies problems and solutions and makes you better prepared for delivery. I think you also correctly identify a cause of bureaucratic busywork: In the absence of a clear sense of mission and leadership -- a project with a clear, strong "why" and leaders keep everyone relentless focussed on it -- "more information" and "more discussion" can seem reasonable, when they are, in fact, a byproduct of aimlessness.
Another benefit of working effectively to define objectives and expected outcomes can be finding advantage in breaking down a project into phases. Taking off on my comment above, the desire to collect more and more data can create paralysis while we all wait until perfection is achieved. Only then do we decide to move forward. It can be quite appropriate, I believe, to build a three storey building now but incorporate features that would allow for adding extra floors later on. Or construct a highway in the knowledge that it may be necessary to add lanes at some point. The problem is that we often are working with a budget which does not allow for such considerations.
Hi Dan,
I have a question. One of the examples in HBTGD is writing a book. But the only point illustrated there is to get reference informed estimates. I imagine other aspects apply too. A number of software text publishers are using incremental publishing to get chapters out as they are written. Perhaps you do this in a limited way with a select audience.
My interest in this is to inquire into how abstract the Lego approach can be. Each chapter is a different thing and you can’t do the next chapter by copying the last, no matter how good it was. But in other ways they are similar- they have to fit together and form a coherent book, problems solved in authoring one may well apply to others and the each forms a new reference point for estimating the work involved.
Stan
I don't think we're advocating any universal system, only tools that may have greater or lesser application in particular instances. What matters is to really understand the goal and nature of the particular project and work out which tools are applicable and how they can best be used. Hence, it's difficult to discuss in the abstract.
Thanks Dan. I appreciate all good advice is good except when it is not. The look for scalability advice works well in the case of manufacturing but I am wondering if it works in less obvious cases. In the case of a book it seems hard to apply. Anything too rigid could look formulaic and the reader expects something new in each chapter. But I wondered if you see any application of scalability when working on a book.
Maile dhei CHOTI jite tar upshar paako xaina
I’ve been meaning to ask this question for a while, Dan: Will you or Bent attempt to track projects whose designers and builders adopt significant portions of your advice in the book to see how they compare with the status quo? Also wondering if anyone bases a consultancy off the ideas and how their work influences project outcomes.
Very good and buetifull
Hi Dan,
I am working as the Director of training and change on one of the largest IT projects in Tasmania (the little island at the bottom of Australia). I work through an agency that has around 50 project managers on various government programmes. I also do some work for the behaviour lab at the University of Tasmania. I've been following this work since an econtalk episode with Bent a long time ago! I was wondering if either or both of you would be willing to do a video call to promote your book? I can get a significant number of senior government decision makers and academics down here to turn up as well, and its a message they probably all need to hear :-)
I like the advice that projects that fail tend to drag on, while those that succeed zip along, particularly thinking about project duration as an open window. The longer the duration, the more open the window. The more open the window, the more opportunity for something to crash through and cause trouble, including a big, bad black swan.
Instead I couldn’t help but think of the Gorilla 🦍 in the Cockpit - Breaking the hidden patterns of project failure and the system for success by Vip Vyas and Dr. Thomas D. Zweifel. They say the root causes to project failure cannot be found in traditional project management books. They are neither technical nor financial. They are human.
I also liked the advice that “big is best built from small with modularity. If a project can be delivered fast and in a modular manner, enabling experimentation and learning along the way, it is likely to succeed. If it is undertaken on a massive scale with fat-tailed distribution, highly integrated components, it is likely to be troubled or fail.”
I'm waiting patiently for the book to arrive, but I've been following the articles and work since I graduated 5 years ago.
I applied the methods described and found instantaneous success. Luckily for me, I worked in the digitization side of projects as well and collected data on some of the biggest projects in the Netherlands. While the organisations never really were interested in the analysis of the data collected, I've definitely used this as a means to prevent exploitation and help me identify behaviours that led to cost overruns.
Not that difficult to do when the industry is run by just a handful of players.
I'm extremely excited to read the book!
My one question is this: critical success factors look and behave differently in different sectors. Too often do I see information being misclassified; either because their methods are binary or because it only factors in one perspective. How do you know if you can trust the data?
I am captivated by the book and can see its potential applications spreading far and wide. I have started recommending it to friends and colleagues.
So far, part-way through, the only place I have paused, quizzically, is the chapter on experiri - that combination of experience and experimentation.
First, I especially value the story about Gehry having nearly been torpedoed by his Disney Hall experience. Without some good fortune, he might never have had the chance to do Bilbao. Then, it was critical that he a) was determined to learn from the Disney project and b) that he knew how to learn from it, what questions to ask himself, what improved planning process to follow.
Which leads me to my puzzle…
The value to be drawn from both experience and experimentation seems to be highly dependent on relentless curiosity. the skill of knowing which questions to ask and the fearless mindset to want to go wherever the answers lead you, which qualities I think are not ‘normally distributed’ under a Bell curve.
First, experience. We all know of people who lean on their experience to say: “that was tried before and it didn’t work”, squelching innovation or even change in its tracks. That incurious statement is too rarely followed by “so let’s try a different version, based on what we learned that time”!
In interviewing one of Canada’s most admired Directors, I came to board composition on which he said: “I look for directors who have a track record of major mistakes, people with scars on their backs”. His unspoken corollary was surely “and who knew how to extract maximum insight from each scar “. Perhaps followed by “and who are not afraid to admit to those mistakes among their peers as a means to advance better decision-making the next time”. I.e., deep experience, by itself, is not enough.
Even a willingness to confront openly the brutal facts about past experiences that went wrong can lead to drawing out precisely the wrong lessons. If Bent had not helped out the Hong Kong project, and applied his expert judgement to knowing which questions to ask, would they have reached the right conclusions? They might have missed the forecasting insights altogether.
As for experimentation, it too, relies on us having the judgement to know: where to look for insight; which sometimes unconventional possibilities to test; and how to frame the right hypotheses to validate, in the right sequence. We need to ensure that most new iterations take us closer to the ideal target design, rather than causing us to spiral further away.
In both forms of experiri, then, we rely on having people with curiosity, fearlessness and a robust skillset polished from years of painful learning. All true. And we can select for these.
But there remains one more ingredient without which these other qualities can fall short - good judgement (practical wisdom) which you note can be enriched by experience. - but is it always? Not everyone with years under their belt can claim to have it. It seems to need an instinctive ‘feel’ that distinguishes the best practitioners, an instinct they might struggle to articulate, but which daily informs their thoughts and actions.
So if I am interviewing candidates for the ideal home reno contractor or manager for a multi-billion dollar project, I can rule out the incurious, the callow or the craven. But how do I test for that elusive quality of good judgement, which may be ‘the one ring to rule them all’?
You probably have to add into this mix how the organizational culture reacted to those failures and experiments. I am certain many people have the innovation and risk tolerance driven out of them.
Well that’s true - if someone has superb judgement, do their peers recognize it as such? Does the culture reward it?
Hi Dan. A very enjoyable book. I think you found the right level of detail for all levels of managers. And the biography was outstanding. It permits us who want to explore further an excellent base.
I was a little surprised that you lightly treated project management techniques such as bottleneck and the Theory of Constraints (Goldratt). The concept of Subtract (Klotz) wasn’t discussed. On the other side, Robert Hughes’s works were discussed. He’s a significant figure which his ideas of Theory of Change. Also, happy to see the MIT System Dynamics elements referenced. I might have accented them more. But that only my opinion.
Overall, a great book and effort. And a great read to boot.
I went to Indigo at the Rideau Centre to buy a copy. It's not yet in stock! I'd prefer to patronize a books and mortar store. Please let us know when and where you'll be doing a signing.
My online order was held up for the cyber issue at Indigo, similarly their Ottawa-based physical store didn't have it (for an Ottawa-based author!?), but the local independent store did. they had two copies, I bought one and after a discussion with the employee she bought the other. Should have started at the independent spot!
This is the second time I've heard of an Ottawa store not having the book. Weird. But well done for tracking it down. And talking up another sale! Thor thanks you.
I've no immediate or direct comment that I can make on your book, but do want to share that I purchased the e-book for my spouse, and convinced a busy friend with a big project to purchase a copy on audible.com to listen simultaneously as they work. Best wishes to you, your co-author, and your pup.
Thank you so much. For all our technology, one person saying to another "you should read..." remains the king of marketing.
You're very welcome. Thank you for sharing your Substack with me, and making sure your book was offered in e-book, and audible formats.