As a software engineer I adopted the concept of top-down design of software. I first read about this method in the early 1970s. Essentially, you start by taking the statement of the problem and start from the top to break it down into smaller and smaller sub-problems. The description of the design looks like a tree structure where the root of the tree is the module that solves the whole problem. This module calls on various sub-modules that solve different sub-problems.
This technique can be thought of as an outgrowth of what I was taught in my early days at MIT. When given a tough exam question, first write down everything you know about subject of the question. By the time you have finished writing down everything you know, you have either solved the problem or have found the direction to go to solve the problem.
When doing a top-down design, you make architectural decisions at the top that constrain what you must do at the lower level. Many people objected to top-down design because they felt that you could not impose such constraints on the lower level before you knew what was possible to do at the lower level.
This objection comes from a misconception of how I believe a top-down design should be done in real life.
In reality, top-down design is a way of organizing the design process. At every level, you give enough thought to the next lower level to be reasonably certain that the next lower level can in fact be implemented. You may have to descend very far down the levels during the design phase to make certain that all your assumptions can be met. The top-down design method is a way of organizing that descent so that it is focused on solving the top-level problem.
In the same way management decisions can be thought of as a top down design process. The top manager, in consultation with others in the management team, breaks the problem down into sub-pieces. No top level decision is made until there is reasonable certainty that the lower levels can do their part to accomplish the task.
So while the top manager (or top designer) guides the process using her or his own vision, nothing is cast in concrete without consultation with sub-managers (domain experts) to insure that the plan is feasible. This consultation process is where other ideas get raised that might lead to an even better solution than the manager originally envisioned.
This does not guarantee that the original plan will never have to undergo major restructuring during implementation, but it does attempt to minimze the chances of that happening. It minimizes the risk without paralyzing the effort to move forward. If you insist on 100% guarantees, you will be too late to solve the problem (miss the market window).
A plan (or design) developed in this way ends up as also being a road-map to delegating tasks during operation (or implementation). This is what makes a project manageable when you shift from design to implementation. Every member on the team knows what her or his responsibility is with sufficient detail, that the manager only has to manage by exception. As long as things are verifiably following the plan, no drastic management action needs to take place. Each manager can concentrate on the duties specifically needed to carry the plan forward.
Please think of the process described above when you think of President Obama working with the people of his administration and all the people in the country in coming up with solutions to all our problems. Using this management style, nobody in the organization has to be a workaholic in order for the organization to succeed.
See my demonstration and download of software that I have used to carry out the software design and management method described above.
I should add that top-down implementation, testing, and documentation go hand-in-hand with top-down design.