Top-down or Bottom-up – Either-or or Both

Different People Think Differently

The question is about how people think and perceive the world and how they go about analyzing the world they perceive. While there is no one right way, there are arguments for taking a top-down approach first and then selectively going down into the details.

On a recent project, working with the definition of program and project scope, one influential stake holder took the position that for the sake of time, the team not spend time on defining the big picture but instead to start with one very important part and work outward from there to ultimately define the full system.

An alternative position was to take some effort to describe the system as a whole and then, once the major components and their relationships were known, to choose what to focus on next in terms of detail. 

Some look at things from a top-down perspective, naturally seeing the big picture and how it works. Details are not necessarily their ‘thing’ but they must acknowledge the value and critical importance of details.

Others take a purely bottom-up approach, focusing only on the immediately relevant parts and either devaluing the big picture perspective or seeing it as something that comes out of the knowledge of the details.

Need for Both

There is need for both top-down and bottom-up perspectives and for people to flex their thinking to apply each in keeping with the need.  

The big picture person who doesn’t value the effort required to address the details and the detail oriented person who fails to see the importance of the big picture are both detriments to optimal performance.

What is the proper balance?  How much time and effort is needed to describe the big picture?  What is the value proposition?

For one thing, a top-down perspective defines the context within which a project or system exists. Here we’ll define the word ‘system’ as a bounded collection of inter-operating objects and processes. Anything can be described as a system.

Practically speaking, every system exists within a higher order system and interacts with other systems.   For example, an activity exists within a project, a project within an organization; an IT application exists within a business process and within a technology environment.

Small Investment for a Big Pay-off

That is why it is important to see the big picture before diving into the details or leaping into action. Without a clear sense of the big picture one runs a risk of unnecessarily disrupting the higher order system. Without a sense of the big picture one is likely to miss opportunities to plan or design optimally.  Risks may be overlooked. Opportunities to build in flexibility and enable future expansion may be missed. Decisions are likely to be made with insufficient knowledge of their results.

Happily, a big picture perspective can be obtained in a relatively short time if it is done correctly. Correctly means visualizing the whole and breaking it down into a relatively small number (3 – 5 or so) of parts (activities, objects, components, etc.) that completely include all aspects of the system. Usually a breakdown of these into a second level of detail is needed to validate the top level and get enough definition to engage the detail oriented people and enable effective analysis.

Once this is done, risk analysis, estimating, high-level design and communication with senior level management can be accomplished before diving into next levels of detail, selectively based on priorities.

Avoid Unnecessary Conflict

It is important to avoid unnecessary conflict between big picture and detail oriented people. Often detail oriented people think that it is necessary to describe all the details in order to understand the whole. While there is some validity to that idea, one can get a sufficient understanding of the whole without knowing all the details. The big picture thinkers must be open to adjusting their ‘model’ of the system as details are defined that raise issues regarding the validity of the model. They must acknowledge that the system is not fully known until the details are defined.

With this in mind, a team can embark on a project or program that progressively elaborates the plan and the definition of the product over the course of project life. They can be careful to avoid wasting time by doing too much top down planning or by not doing enough and thereby discovering issues and risks randomly along the way.

Don’t forget to leave your comments below.