In 1990, former General Electric CEO Jack Welch wrote a prophetic passage in the company’s annual report. “Our dream for the 1990’s is a boundaryless company…where we knock down the walls that separate us from each other on the inside.”

Ever since, large enterprises have attempted to live by Welch’s dream, yet the reality of the “boundaryless” organization remains tantalizingly out of reach for software development companies. They remain hampered by set hierarchies: development teams and product owners exist on one level, business management and system engineers on another, while enterprise architects and portfolio managers reside atop the organizational food chain.

These hierarchies impede efforts to achieve the three V’s of corporate success – vision, value, and velocity. Vision defines organizational goals, and development teams must deliver value that aligns with that vision. To do so, they must be able to accurately plan and estimate velocity – the amount of work completed during a development iteration – and gauge factors that could impact the speed of that work.

Employing a top-down estimation approach to project management can help organizations overcome boundaries and satisfy the three V’s. Let’s take a closer look at how this approach can work for software companies, particularly larger organizations, to help them improve project management, team collaboration, and development practices.

Top-down estimation is a preferable alternative to traditional bottom-up estimation processes. Bottom-up estimation calls for every team member to estimate how many hours it will take to complete a project. The project manager then takes all of this information and compiles it to get a sense of overall total hours for project completion. Unfortunately, much of this is guesswork and opinion and can lead to unrealistic estimations.

A top-down approach can be much more effective and accurate. Rather than relying on the input of individuals, top-down estimation takes a look at the scope of the entire project, overall efficiency of the organization, and complexity of the proposed work – before any actual work is done. It provides valuable data that companies can feed into any large-scale agile framework they may be using, including SAFe, DAD, or other methodologies.

Top-down estimation is grounded in planning and forecasting the time and effort it will take to complete epics (large bodies of work) from the outset. Through this process, managers can break epics up into stories – smaller chunks of work – product features, capabilities, and other more manageable, bite-sized pieces. Then, they can estimate the appropriate number of resources and skillsets required to successfully complete the entire project.

Top-down estimation also helps teams leap across boundaries by providing everyone with a holistic view of work being done across the organization. Teams are provided with comprehensive insight into all of the connections and interactions involved in producing consumable products. Thus, top-down estimation supports the theory that the value of a system is only as good as its various connection points.

Those connections are comprised of staff working at different hierarchical levels, and top-down estimation can keep those people on course and in alignment with organizational requirements. For instance, product managers may have their own ideas regarding staff and spending rates, but they may not be commensurate with those of the company as a whole. Estimation allows those people to see if their plans exceed their organization’s current and near future capacity. If they do, teams can make adjustments to bring them more in-line with reality by changing start dates, tweaking their scope, and other simple practices.

By providing a holistic view of software projects and the teams working on them, top-down estimation helps organizations build better systems and software and achieve the three V’s. More than that, it can help organizations achieve Welch’s long-sought goal of fewer boundaries and better production.