In How Big Things Get Done, the first advice Bent Flyvbjerg and I offer anyone thinking of tackling a big, ambitious, complex project is simple. Slow down. For various reasons — psychological, political, cultural — people want to get big projects going as soon as possible. Put shovels in the ground. Measurable progress. Push, push, push. Unfortunately, this approach is as bad as it is common — because it means planning will not be nearly as detailed and rigorous as it needs to be. Problems aren’t recognized. Solutions aren’t found. And overlooked problems don’t vanish. Sooner or later, they surface, and because the project is already in delivery, they risk doing real damage, particularly when problems bump up against problems, like cars colliding on an icy highway. This is how a project that starts in a sprint turns into an agonizing crawl that will finish desperately late and horribly over budget.
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.
Dan -- I'm listening to the book now. It's great! My wife is about to start and I am recommending it to the post-docs and other trainees in our program.
"Slow down" can be great advice even for relatively modest projects, such a software enhancement that takes only a couple of days to implement. As a very senior (read "old") software person, my competitive advantage over my younger colleagues whose minds work intrinsically faster is that I am slower and more careful in planning out, implementing, and testing at each stage my code updates. The result is an implementation velocity at least as fast as theirs, with less rework.
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.
Dan -- I'm listening to the book now. It's great! My wife is about to start and I am recommending it to the post-docs and other trainees in our program.
"Slow down" can be great advice even for relatively modest projects, such a software enhancement that takes only a couple of days to implement. As a very senior (read "old") software person, my competitive advantage over my younger colleagues whose minds work intrinsically faster is that I am slower and more careful in planning out, implementing, and testing at each stage my code updates. The result is an implementation velocity at least as fast as theirs, with less rework.
Ordered my copy today and looking forward to reading it.....with or without graffiti , congrats on the release!
WYSIATI has a pronunciation! I didn’t realize.