[numlocked]

I loved this, and in particular how to think about teams, experts, and workstreams. But the physical construction (in my experience) has a limited number of software analogs. I wrote about this a long time ago:

We have a problem. People can't get from one area of town to a neighboring area because there is a river in between and no road. So let's build a bridge.

[Long discussion of how to plan to build a bridge in the real world]

Now, let's do it in software.

We're going to start by focusing on the problem to solve: get people from A to B. With software, the solution isn't necessarily as obvious as it is in the physical world. Maybe we need a bridge. But maybe we need a ferry. Or a helicopter service. Or maybe we should just move the two pieces of land closer together. Or freeze the river.

Customers speak in terms of solutions: I want a bridge. I want a bigger kitchen. But with software we know to be wary of this: unlike the physical world, the users of software often do not have a good intuitive understanding of what's possible. So while they speak in terms of functionality and solutions, it's our job to root out the real problem and come up with an appropriate solution - which we might also not have a good intuitive understanding of.