BA 101: An Intro to Organizational Strategy, Portfolios, and Programs

Share This Post

I am your typical Business Analyst – in other words, I went to school for something COMPLETELY unrelated, and somehow found my way into writing requirements for software development. My background is in chemical engineering and, although I have always had an interest in business and marketing, I have no formal education in business at all (unless you count macroeconomics my freshman year of college, which I do not).

Recently I was tasked with putting together some material on Portfolio Management based on some literature from The Project Management Institute. This was a great opportunity to wrap my head around some terms that I am only vaguely familiar with. The truth is, organizational strategy and portfolio alignment or the difference between a portfolio and program probably don’t matter much to me as I am working on a project – they exist and my project exists as a result of all those things, but beyond that, I am not influencing them or directly working on them; so my scope of interest, attention, or working time does not expand that far up the ladder. This may be true, but having a basic understanding of the business structure and management is important and useful in understanding exactly why you are doing the things you do on a project. So I am taking this opportunity to pass on a few of things I learned about business structure and high-level management methodologies to my fellow BAs who may also be lacking in their business background.

Organizational Strategy

At the highest level, an organization has a specific vision and mission. Everything the business does is aimed at achieving that overarching objective. Although strategies vary greatly from one business to another, there are some universal factors that influence strategy development: effective resource management, managing stakeholder value, capitalization on opportunities, minimizing the impact of threats, response to changes in the market, legal and regulatory environments, and maintaining focus on critical operational activities. Everything below this level will ultimately aim to support the organizational strategy. Every portfolio has its own vision and plan, which should align to support the objectives of the organization.

What is a Portfolio?

According to the PMI, a portfolio is “a component collection of programs, projects or operations managed as a group to achieve strategic objectives.” The components within the portfolio may not depend on one another, or even aim to achieve the same strategic objectives, as a single portfolio may target multiple objectives. The can (and should) be ranked/prioritized though. An organization may have one or many portfolios that are composed of subportfolios, programs, projects, and operations. A key thing to realize is that these components may exist within the hierarchy followed in the previous sentence, but a project, for example, may exist within a portfolio without actually being part of a subportfolio or program.

What is a Program?

The PMI defines a program as “a group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually.” The programs are mainly made up of projects, but also include all the efforts required for the projects to function, such as training, operations and maintenance, as well as management resources and infrastructure for the program itself. Programs and projects exist to deliver benefits to the organization, whether it is by expanding capabilities, delivering new products or services, enhancing existing capabilities or generating business value.

Portfolio vs. Program

Programs and portfolios may seem similar in design, but there are distinct differences. The following are a couple key differences, especially from a portfolio and program management perspective:

  • First of all, portfolios are continuous and thus the management lifecycle is a continuous process. The roadmap or components within the portfolio may change, but the portfolio does not have a planned ending. Programs have a clearly defined beginning and ending; the program lifecycle includes a closeout phase to ensure the benefits of the program are continued after the program is formally closed.
  • Portfolio components may contain no inter-dependencies or relationships, whereas program components are related and working together to achieve a set of set of objectives and benefits.

This information doesn’t give you everything you need to know about organizational strategies or managing portfolios or programs, but hopefully you understand where these three things stand in relationship to one another now.

More To Explore

Visuals in Requirements Mapping

In Praise of Requirements Mapping

Learn how to tie software requirements together with visual models and other artifacts created during the analysis process.

It’s a Matter of Trust

The combination of pandemic and moving to a rural community has increased the amount of shopping I do online, but even before those events I found myself depending more and