You only need one thing to bind programs together - and it doesn't have to be duct tape!

Programs, by nature, are a collection of projects.  Depending on the organization, how they group projects into a program can vary greatly.  Organizations may define the content of their programs by the subject areas (Digital Presence Program), or by what the end goal of the program is (Finance Systems Replacement Program), even by the department that is running them (Marketing Program) and unfortunately, often projects in a program have little or nothing in common (IT Program).

In my past lives, I have always struggled to identify the one common language that can bind the projects together into a program, consistently across the organization.  Often, each functional area will have their own nomenclature for what they do, so something that spans multiple departments, markets or geographies tend to be extremely hard to normalize.  Each department struggling to understand the language used by others, and insisting to use their own.

Some of the issues I have come across setting up and running programs:

A number of years ago I started delving into Business Architecture as a way of helping with the programs I was running.  Business Architecture is a discipline that aligns the organization’s strategy to the technology and people.  In short, it allows an organization to ensure that the projects they spin up are in fact aligned to their stated strategy.  The binding language used is Business Capabilities.

Although the word capability has been used, and abused, in a number of different ways over the years, the definition for Business Capabilities provides a really robust way of settling on one common language for what an organization does.  It provides a good leveler that is relevant, externalizing emotional language related to how do they things. For example: what one retail company does is the same as another retail company – but how they do it is what differentiates them in the market.  So the what can be used across the same industry with multiple companies.

A typical capability map contains the following high level (Level 0) Business Capabilities

The capability map delves into more detail within each of these boxes, known as levels 1-4.  Level 4 being quite detailed.  The value is that you have a ready-made hierarchy at your disposal.

If Business Capabilities are able to provide this framework of what the organization does, or should be doing, then using this as the footprint to run programs seems to make a lot of sense.

Consider the following…

• Once you have sourced a business capability map for your industry, you have the full context of the organization to describe your program scope. I have in the past changed some of the wording from the industry generic model to better align with the language used in the organization I am working with.  Is it Human Resources, Human Capital, or something else – changing the language to reflect what resonates makes sense, but I keep the number of changes to a minimum to retain that neutrality.
• This capability map gives you an end to end view of what your organization does. I have found that identifying capabilities in the map that are not currently in scope for the organization is still a useful reminder of what I need to think about.  Consider that the organization may not have any specific Marketing Management capabilities – because they either outsource it, are in a niche market, or do not need it – think nonprofit.  Knowing it is there allows you to still consider this for the future.
• You can then create overlays, or attach attributes, to your business capabilities in order to provide you with a rich array of information about your business. When I run a program, I want to know the context of what is being implemented and why it is important to the organization. 
• Try mapping how these capabilities support your core business, your strategy, mission and your vision. This can become a simple heat map of your business, showing areas that you do well, areas that need improvement, maturity gaps, and most importantly areas that are stopping you from achieving your strategy. As an example, the diagram below shows visually the priority the executive placed on each capability. Red being more important than amber and green,

• Try mapping how these capabilities are currently served by your existing systems, departments and perhaps even regions. In my last program, I found an IT architecture diagram showing every system that IT was supporting.  I grabbed the diagram and created an overlay showing which systems supported which capability.  This was extremely useful in highlighting duplications, where one Business Capability was served by multiple systems – in my example: customer billing was being done by 5 separate systems.
• As you identify how you will address the areas of concern, you can map how the new solution addresses the Business Capabilities. In one of my recent programs, this allowed me to see which capabilities were not being addressed by the new solutions.  Leaving me with the decision to keep the legacy functionality running, or to expand the scope of the new system.
• If you know which departments support which business capabilities, you can start creating your change management plan as well. I found this useful when layering the existing systems, the new systems and the departments supporting the capability.  It not only showed me where training was needed and when, but also that some discussions needed to take place on the structure of the divisions.  Not strictly a role for that program, but a great value add.
• Some wizardry from your business architects can tie these views together, showing you pretty clearly what your program scope should be, the roadmap, the phasing and even the scope of the projects that make up the program. It is simple and brilliant.  A great representation of how capabilities can bind many concepts in your program is shown the diagram below: 
  

Diagram originally created by Karen Bennett

Business Capabilities can be adopted as the default language that the program uses to communicate with the organization on what is being done, who has the responsibility, the progress being made, and when new capabilities will be light up for the business. In most cases, an organization is not interested in what system is being implemented by a program, but what new capability is available to them.

It is also important to note that these overlays will only supply you with information – how you analyze the various views is where the real value lies.  If you want to know more about Business Architecture, try the following links for inspiration:

• The 4 W of Business Architecture
• How Business Architecture Works

There are many sources readily available in the industry that can provide you with a standard Business Capability models for your industry. Examples include telecommunications, retail, consulting and a host of others. 

I have used this approach for greenfield programs as well as existing programs that required a greater level of clarity and transparency.  Note also, that this approach is not tied to any methodology – it works just fine for waterfall, agile and everything in between.