Portfolio-Based Demand Management

Using the Enterprise Portfolio to Manage Investments that Change the Enterprise

Ideally, using the enterprise portfolio as the basis for defining business demand and requirements to enable the execution of transformation initiatives is a step in the right direction. If you can’t use enterprise portfolios for this purpose, how much value do they have? So the real question is how do you use them?


Enterprises evolve their business by investing in sets of initiatives (projects, programs, etc.). The initiatives often become silos of activity. The understanding of how these initiatives relate to the business goals, the aspects of the enterprise portfolio, and to each other is often obscure. The result is poorly prioritized and inefficacious investment—that is to say the business doesn’t get the best results from the investments being made.


It is best to broadly divide an enterprise into nontechnical and technical portfolios (which can be related to things both internal and external to the enterprise). In a portfolio view of the enterprise, one considers the sets of things that result from investments (i.e., portfolios) and how they relate to each other. These portfolios include the sets of: goals, strategies, products, people, facilities, capabilities, functions, policies, information, etc. as well as the sets of: applications, infrastructure, technology products, etc. All of these things are the result of various investments the enterprise has made or is making.

These portfolios provide a canonical basis for defining all demands and requirements. All the demands for change in a business can be expressed in terms of these portfolios. In fact, it is difficult to see how the requirements can be expressed in terms of anything other than these portfolios. Initiatives are designed to result in changes to the portfolio, i.e., their intent is to alter the portfolio and they may also rely on or assume use of key elements in the portfolio.

Thus, the enterprise portfolio is analogous to the Cartesian coordinates which we use when we map out changes to cities or buildings. If we try executing many projects in parallel without these reference points, it would end in anarchy.

Further, in analyzing the investments, one wants to be able to consider investments from any portfolio perspective, e.g., investments by program or project; capability or function; product set or product; policy or rule; market segment; etc. (See figure 1.)


The enterprise needs to be clear about how all proposed initiatives relate to the enterprise portfolio. To do this, we capture the business demands accurately and precisely with reference to the components of the enterprise portfolio.

The current approach of allowing people to write documentary narratives just doesn’t work, and the high failure rate of large IT projects is testimony to this.

By anchoring the demands and requirements to the enterprise portfolios, they are naturally well structured. They are rigorous, coherent, complete, and can be communicated without being repetitive, ambiguous, or incomplete. They do not have loose ends because loose can easily be identified and eliminated.


What are considered demands at a high level progressively become detailed requirements as they are elaborated and actioned. These detailed requirements are in turn related to more detailed aspects of the enterprise portfolios. This allows the demands to be understood at the board and executive level, as well as detailed requirements to be understood and referenced contractually at the delivery level—with the assurance that the views are clearly related. It also allows us to analyze the enterprise portfolio at different levels, e.g., capability, function, process.

We can also ensure accountability for delivering business contribution pledged in business cases. The contribution and ownership are clear at every stage. This ties in neatly with the idea that there is ownership for the elements of the portfolio.


Various processes (business as usual) and initiatives are progressively and incrementally changing the enterprise portfolio. Because all the demands are tied to these portfolios, people running transformations always have a current and accurate view across transformations; they see how their work relates to what others are doing and have done over time.


Transformation requires big-picture management as well as a deep understanding of the underlying complexity.

A challenge enterprises have is in seeing across the silos of transformation and understanding how a net change is achieved. Projects are great ways of breaking down changes into “manageable” chunks. But the problem is the degree of uncertainty about the exact boundaries and inter-relationships between those chunks, with technologies evolving so quickly and becoming more and more complex.

Problems arise with traditional project management techniques, which come from a different domain quite unlike enterprise transformation as they don’t deal well with the level and complexity of inter-dependencies (between aspects of the portfolios) that are progressively discovered. Complicating the issue has been an inclination by technologists to foist on business participants methods and terms oriented at detailed engineering. (See figure 2.)

enterprise portfolios


This approach allows investment initiatives to be understood, planned, and managed holistically, including:

  • Understanding how the set of proposed initiatives collectively and individually results in the business outcomes sought, by explicitly connecting business plans and enterprise portfolios (business and technical).
  • Allowing gaps and overlaps to be understood and managed at all the different levels of execution and decision making.
  • Analyzing the transformation options: cost, value, feasibility, conflicts, impacts, resource requirements, etc.
  • Improving how initiatives can be executed effectively and coherently—by the explicit management of the requirements and solutions elements and their relationships to the enterprise portfolio.
  • Supporting better management of contracts and change.
  • Supporting orthogonal strategies for cost estimation and comparisons between these costs, e.g., costs based on requirements (and sub-requirements) and based on the solution elements (and their sub-elements).
  • Allowing a business view of demands and requirements to be maintained independent of views that may be required to engineer delivery.
  • Allowing reference models and reference architectures to be supported and used for analysis.


These common problems indicate a need for better methods:

1. Delays—Solutions run overtime due to unforeseen complications or contention.

2. Cost blow-outs—Estimates or design fail to identify all requirements.

3. Failed solutions—Solutions don’t address the business needs as intended.

4. Adverse customer impact—Poorly defined solutions prevent staff from meeting customers’ expectations.

5. Poor coordination across solutions—High levels of rework/wastage cause time and cost problems.

6. Inability to change with the business—The business context changes overtime, but solutions in-progress can’t change to reflect that, slowing the business down.

7. ROI never achieved—Solutions don’t achieve the benefits originally identified—the bottom line of all of the above.


The starting point is a best practice solution that manages the enterprise portfolio and changes to that portfolio. The solution must allow demands and requirements to be captured, analyzed, and communicated (there are also best practice solutions for managing solution delivery). The result is a simple Web-based solution that all participants can use without any understanding of enterprise portfolio techniques, yet that results in the demands being captured in terms of those portfolios.

  • Demands can be allocated to projects but also seen in the context of the enterprise portfolio. The status and priority of all requirements for selected projects across the enterprise portfolio can be analyzed.
  • Demands can be analyzed and overlaps identified. The status and priority of demands can be viewed against business capabilities.
  • Demands can be prioritized. Demands can be dynamically displayed, sized, and colored by a range of characteristics, such as priority, status, cost, value, etc.
  • Demands can be elaborated at different levels. The hierarchy of demands can be shown so that high-level demands and all the associated lower-level detailed requirements are clearly reported on.
  • Templates can be established for sets of demands and dynamically adjusted. Templates can by dynamically established and reused, allowing the enterprise to implement specialization.
  • Requirements can be communicated in traditional documents. A wide range of information about enterprise portfolio demands can be displayed in more traditional formats.


It has long been recognized that there are significant issues with the way that complex transformations are conceived of, planned, and undertaken. Based on the confluence of a number of techniques and newly available solutions, a new approach has been created that is actually a fundamentally better way of supporting business transformations.

About Michael Ellyett 1 Article
Michael Ellyett founded Enterprise Strategic Transformation & Optimisation (ESTO) in December 2008. Michael's academic background is in architecture and computer science. For over a decade, he worked for vendors that promoted a wide range of technologies: systems (computers, workstations), software infrastructures (databases, middleware), applications (accounting, plant maintenance, patient management, etc.), and specialised systems (GIS, CAD, animation, etc.). For almost fifteen years, he worked for a boutique systems integration business that he founded. During this time he focused on the strategy and architecture platforms necessary to allow transformation and optimization projects to be successful and the methods necessary for delivering projects (project management, design management, development management, etc.). For most of the last decade he has focused on mentoring strategy and architecture initiatives.