Portfolio and Programme Management

A Portfolio is a collection of programmes and projects collectively forming the set of investments held by the organization

A Programme is a collection of related projects that collectively deliver business value (through a series of Releases)

A Project is a temporary collaborative endeavor undertaken to create a unique product, service or result (through a series of Releases)

This definition of “Project” is close to the PMBOK standard and points out some key features of a project:

  • It is temporary, once its aim has been met it finishes
  • It is collaborative, it uses people and resources
  • It has a specific goal, normally one primary goal

Strictly by this definition most work to create a product can be considered a “project”. In HSD we often talk about “product development” and “projects” fairly interchangeably because of this. However, the word “project” also invokes ideas around traditional “project management” that can be counter to modern ways of working with embedded bias towards waterfall methods. As a result, we see a lot of focus on “teams”, “cells”, “delivery units” etc. The software industry needs to move past this discomfort. When we use the word “project” in HSD, we mean a temporary collaborate effort to meet a specific goal or create a product through a series of Releases

Project != Project Management

Sometimes a project has a number of primary goals, or has very large scale and is complicated and so is better delivered as a set of inter-related projects – a Programme. However, a common dysfunction we have seen is a perception that every project must be part of a programme. If the problem doesn’t have multiple primary goals or very significant scale/complicated structure, then it is simply a project. As mentioned in Organization Structure, Projects can, and should, exist as stand-alone projects within the Portfolio. Imposing a 1 to 1 relationship between a programme and a project in simple cases leads to significant waste as effort is duplicated and responsibilities for requirements, architecture, quality and planning become confused.

A Portfolio is a collection of programmes and stand-alone projects. In Holistic Software Development we consider software projects to deliver a Product whereas a Programme will deliver a Product Family – A Product Family is a set of products that work together to deliver business value to customers . Often described as a system-of-systems, a Product Family is typically delivered by a programme using multiple teams in parallel integrating their work regularly or continuously.

The top-level Portfolio can be split into a number of child Portfolios to support vertical business lines in some organizations however we recommend keep Portfolio structure as simple as possible, filtering by categories and other data but avoiding structural separation if possible. Structural Portfolio separation leads to fragmented business practices and dictates silo mentality from the very beginning creating strategic inertia in a business. We apply this loose structure idea to the Hybrid Dynamic Model portfolio.We apply this loose structure idea to the Hybrid Dynamic Model portfolio.

Portfolio management, and Programme management where it exists, is part of the Controlling layer of governance in an organisation. It exists to serve and execute strategy through investment decisions and cross product integration. Resourcing at this level should me minimal as there is a dysfunctional tendency in organisations to believe they can resolve complexity at a planning level. The engine of value in an organisation is in its executing layer and not all work benefits from being “controlled”. High Complexity work in particular is poorly suited to Programme Management.

Portfolio and Programme Management Practices

Managing the dynamics of Portfolio and Programmes is a different proposition to managing a Project or a Delivery team and so different practices are appropriate. Simply repeating small team practices for large scale business management, because they work at software team level is a logical fallacy. Both Portfolio and Programme management are primary methods of implementing governance in an organization via:

  • Financial Management (forecasting, extrapolation of actuals)
  • Resource Management (forecasting and adjusting based on actuals)
  • Dependency Management
  • Risk Management

The progress of a Programme of Portfolio is based on the progress of its child projects and so dependency management, communication, feedback and evidence based planning are all critical to Portfolio and Programme Management. Similarly, cross project and enterprise risks are managed at Portfolio level. Progress is not based on sub-project progress against plans however, but in terms of integrated working software.

In high complexity situations where there is unpredictability, dependency management is best done by “pull” rather than “push” forces. The traditional temptation is to define and manage dependencies from a top-down fully detailed position. However, simply tracking things (and assuming they won’t change) doesn’t resolve or simplify them. Instead, in line with Lean principles, create a “pull” pressure towards demonstrating end-to-end value through cross-team integration. This will “pull” the dependencies together, letting teams organically communicate to resolve them.

The Portfolio exists within the context of Enterprise Architecture which helps focus Portfolio Requests. Often Portfolio Requests involve a change to the Enterprise Architecture or even a strategic move to a new Enterprise Architecture. This is inherently a cyclic relationship.

Programmes in contrast involve the elaboration of a Solution Architecture which describe how a set of products interact to deliver Business Value. At this level HSD describes flows across a Product Family (or system of systems) as Integration Scenario requirements.

Risks, along with issues, positive headlines and proposals for change may be escalated to Programme or Portfolio level (via the Bubble Up practice). Items are escalated when constituent parts (teams, projects etc.) cannot deal with something themselves or wish to highlight something upwards. Responding visibly and directly is a primary responsibility of those working at programme, portfolio or even executive level. A commonly reported problem in many organizations is a perception that issues, both positive and negative, are raised into a “black hole” because there’s never any reply. Feedback loops are not explicitly closed so there is no actual feedback – the loop doesn’t work! We strongly recommend directly replying to any escalated item, whether it be a risk, issue/impediment, positive headline, suggested change or anything else.

Open and transparent leadership is predicated on good communication.

Common understanding of the different levels of requirements, architecture, quality and planning at Portfolio, Programme and Project level (when those levels explicitly exist) is critical in terms of ensuring smooth flow throughout value streams and ensuring that each level is adding value. We have seen many examples of conflict between Programmes and Projects with multiple versions of mismatched requirements, ill-fitting architecture and ways of working that are not joined up. Holistic Software Development puts all of these elements in a cohesive framework to avoid these dysfunctions. Imposing an unnecessary Programme or Portfolio structure above Projects is a fundamental mistake that leads to failed projects and inefficient businesses.

The Hybrid Dynamic Model

The Hybrid Dynamic Model is a modern approach to structuring an organisations portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.

An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised and how quality is assured. If the Operating Model is inefficient or unable to react well to change, everything else suffers.

Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with events is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hybrid Dynamic Model is more appropriate.

As organizations recognize that their types of work are different they frequently evolve a Bi-Modal paradigm that involves treating New Investment differently from legacy operations. This creates a two-speed organization, often correlating with the use of Project Management for new work and managing out variance (e.g. with ITIL) for operations/support work. Bi-Modal IT is short sighted, as it doesn’t account for evolution and change. Instead we recommend considering Commoditization as a way of thinking about types of work.

Bi-Modal IT is an example of the black-or-white logical fallacy

A useful mechanism for understanding different types of work, and the different approaches that may be applicable to delivering them within a portfolio is the “Commoditization Scale”. The Commoditization Scale describes a range of types of work from innovation (undefined, rare, speculative and high risk) to more commodity/utility (well defined, ubiquitous, and less differentiated with lower risk).These different types of work require different ways of working, contractual models, technologies, supply chains, cultures, processes etc. More well understood work is more predictable and manageable by its nature, whereas the opposite is true for less well-understood work.

Commoditization scale originally inspired by Simon Wardley, LEF CSC

As organisations begin to understand their work in terms of a hybrid model they can then look to actively apply a commoditization pressure where possible moving work across this scale. Because commodity solutions (often bought in) are typically cheaper than in-house development, maintenance and hosting commoditizing work earns a “Commoditization Dividend” which can then be used to reinvest into the Innovation parts of a business.

As mentioned in Build or Buy we generally recommend against building utility or commodity components, systems or product (unless disrupting a service industry) – these kind of products are best bought (COTS) or provided by open source alternatives. However, in terms of inventing/innovating and specialist products we see that different processes, working practices, teams and cultures may be necessary. Innovation work is typically riskier and more speculative than more mainstream specialist product development and so will be less tolerant of up front planning. “Failing fast” is particularly important in innovative/inventive work and this type of work is often very unpredictable. As a result, building significant structure (in terms of project, programme and Solution Architecture) around innovation work is unlikely to be productive – this work may also be unconstrained, thought informed, by Enterprise Architecture (and indeed “standard” ways of working).

Unless explicitly necessary we recommend that innovative work is treated as self-organized Product Delivery teams that are directly part of the Portfolio, with no programme structure. This (Small Picture) model is preferred for small, simple projects or organizations generally. Small organizations can often outperform large monolithic organizations due to their lack of process, management and architectural inertia – they are free to innovate. Since the relentless commoditization of technology forces all organizations to innovate to survive we strongly recommend freeing people to innovate in whatever manner they need.

There’s nothing worse for innovation than an ideas process

Similarly, and perhaps counter intuitively, there is also less structure required in the Utility and Commodity areas of the commoditisation scale (because the products built are often well-understood, predictable and frequently COTS, much of this work is system integration). This type of very predictable work often benefits from workflow management techniques such as Lean, Kanban or service management processes.

Products that are more Specialist may need a “bigger engineering” approach depending on their scale or risk factors. Many large organizations will adopt more formal processes in this area as they seek to find economies of scale, especially around reuse. However, over time reusable platforms and architectures can become a hindrance rather than a help. Technically skilled people will notice this point and are encouraged to Bubble Up their concerns. Organizations with significant effort in more than one of these areas of the scale above tend to gravitate towards a hybrid model with a structure embedded in the Specialist, Commodity or Utility part of the business. Applying the same structures, architectures, processes and working practices across all of these work types, ignoring their differences, can cause serious problems so a hybrid model is likely to be required for large/complex organizations.

We recommend using a hybrid, dynamic model for organising a large/complex portfolio. Large, complex organisations have significant effort and coverage across the commoditisation scale. Implementation of a hybrid model caters for this variance using unstructured and structured models where necessary. Structure is introduced only by exception when explicitly needed to orchestrate effort across divergent teams and portfolio(s) not as the default approach. Importantly as pieces of work become more understood, or product sets evolve they will likely begin to move on the commoditisation scale and so may need to dynamically change their ways of working.

Any problem or piece of work, including running a business and software development, can be considered in terms of its complexity. Problems range from the simple to the complicated and complex.

The Hybrid Dynamic Model allows for significantly different ways of working, within the cohesive governance of the H-Model of Holistic Software Development. Using the hybrid dynamic model organisations can have multiple ways of working, cultures and practices co-existing peacefully within a single enterprise portfolio. Using different ways of working, practices and techniques across the portfolio helps bring together the otherwise extremely different extremes of innovation and research work with predictable project delivery. Other business models, such as Incubation, can also be used to help bridge the gaps between areas such as innovation and mainstream engineering practices.

Many organisations evolve a Portfolio → Programme → Project → Team model which is then applied to all work in the portfolio due to its past success at delivering large predictable technology projects. However, this model is wasteful when complexity is low and can actually inhibit communication and feedback cycles in high complexity work that is more speculative. The traditional programme/project model can work for mid-complexity predictable work.

Programme and project structures cause layers of separation, which result in emergent transactional behaviour, effort duplication and confusion over roles and responsibilities. As a result, programmes should only be used when there is a genuine requirement for co-ordinating multiple projects that must be integrated for a cohesive product family or business capability. In other cases, programme structures should be condensed – removing programmes that are simply funding lines; Portfolio Management can and should manage funding lines. Stand-alone projects can simply be part of the portfolio.

Reduction in structural complexity will reduce costs, increase flexibility and adaptability while simultaneously improving an organisations ability to react in a rapidly changing environment. Additionally, simplifying structure will reduce the sheer numbers of people involved in project management and supporting work, removing unnecessary barriers between delivery teams and their customers.

This kind of hybrid structure is similar to using the Small Picture of HSD for the pieces of work in the Commodity Portfolio, the team-of-teams delivery elements of the Big Picture for the Specialist Portfolio (and other small team structures) and the Small Picture again for the Research and Innovation portfolio – sharing the same Strategy and Governance layer of the Big Picture.

COTS implementation may be a signficant piece of work by itself. The COTS Implementation article describes a variant of the Big Picture for use with COTS.

Adoption of the Hybrid Dynamic Model is actually relatively easy, as you simply add it to what you’re currently doing. Regardless of your current structure and operating model, allow variants that are approved ways of working for different types of work. Over time organizations can adjust the amount of work in each part of the model to suit the work, people and disruptive change.

Creating a Portfolio – Portfolio Requests

Portfolio Selection (sometimes called Portfolio Build) is the process of selecting the Portfolio Requests that will be included in scope for execution through a series of leadership investment decisions. Leads directly to the “Portfolio Scoped” Milestone, and is refined through Continuous Investment Review.

Portfolio Build/Selection involves examining the collection of Portfolio Requests and associated Business Cases to ensure that the Portfolio accurately reflects the Business Strategic Direction. Portfolio Build/Selection can occur annually, quarterly or continuously.

Portfolio Requests are simple expressions of a business requirement related to a Business Case. Portfolio requests elaborate a specific Business Case option with an indication of required funding and technical direction for Solution Architecture within the context of Enterprise Architecture. Sometimes Portfolio Requests will be to change the Enterprise Architecture.

Business Cases and Portfolio Requests are overlapping concepts. Both are essentially arguments for funding. In some organisations these are done via the creation of a Business Case. For very large/complex investments a Business Case may cover a number of Portfolio Requests, or spawn a number of investment options. In simpler cases Portfolio Requests and Business Cases may be the same thing.

Portfolio Selection is a set of critical business decisions that provides, sustains or removes funding from pieces of work. There is a fine balance to be struck between stopping failing work early (a positive thing) and changing business priorities so often that programmes, projects and other delivery methods have no stability which inhibits their forward planning, diminishes the ability of teams to settle in to a delivery cadence and in turn reduces morale.
For this reason, we recommend Portfolio Selection is done quarterly with Continuous Investment Review happening all the time, considering critical Portfolio Requests (in response to disruption) when needed. Making Continuous Investment Review, and Portfolio Selection, transparent means that while changes in funding decisions may be disappointing, they’re never a surprise to people.
When managing very large portfolios a common practice is to commit to more delivery than the budget allows for, since the uncertainty in early planning means that spending is unlikely to follow plans. Some programmes, projects and other deliveries are unlikely to succeed and so starting more work early on gives more flexibility later in the year. This is a traditionally accepted practice which acknowledged the inherent unpredictability of software work.
In HSD we differentiate between requests which “must” be done since they are critical enablers for strategic goals, requests which “should” be done because they will support strategic goals but represent over-commitment and requests which “won’t” be done because they are prioritized below the previous two groups.

Portfolio Selection in action

A number of decisions are made during Portfolio Selection by Business Leaders, Business Customers and key organizational stakeholders. We recommend making open and transparent evidence based portfolio decisions based on understanding and comparing key information across Portfolio Requests:

  • Strategic Case
    • Does the request map clearly to Strategic Goals?
    • What Business Value will be created or sustained?
    • Is there a valid Build or Buy decision?
  • Tactical Impacts
    • Which Business As Usual systems or functions will be affected and how?
  • Political, Legal and Reputational Case
    • Is the solution impacted by regulatory or compliance requirements?
    • Are commitments to partners impacted?
  • Cost/Benefit Analysis
    • What are the projected resource needs?
    • What are the projected tangible and intangible costs and opportunities?
    • Is the Request worth doing?
  • Risk Assessment
    • Is the Request risky?
    • Does the solution introduce or mitigate organizational risks?

All of this information comes from the Portfolio Requests and associated Business Cases. We recommend prioritizing Portfolio Requests from a Strategic perspective initially, and then comparing this set of information (often in table form) to create a rough set of must, should and won’t decisions. Each Portfolio Request can then be examined in more detail to verify the initial selection decision.

Portfolio Selection is an opportunity to optimize the Portfolio, by choosing options which reinforce each other, align well in terms of dependencies, and collectively move the organization forward. New Investments will typically replace or combine previous Business As Usual solutions. These “convergence” solutions must be carefully managed to ensure that the projected savings are actually worth the cost of a new solution.

Many organisations fall into the trap of repeatedly reinventing their internal systems rather than creating new business value.

Build or Buy

As Shown above Portfolio Selection includes a review of Build or Buy decisions for both Business As Usual and New Investment Portfolio Requests.

A Build or Buy decision informs an organization if a proposed solution (normally in the form of a Portfolio Request) should be built “in house”, provided by a supplier or otherwise acquired “off the shelf”.

Organizations with significant internal development capabilities are sometimes tempted to build everything they need – not just the strategically important. This can waste expensive development capability, and intellectual capital, on building something that is readily (and often cheaply) available externally. Similarly, organizations with supply chains, especially embedded suppliers are sometimes tempted to out-source (or near-source) all of their Solutions to suppliers putting high risk requests that provide core business value in the hands of suppliers poorly equipped (in terms of knowledge, resources and contract models) to deliver them.

Several factors affect Build or Buy decisions:

  • Risk
  • Strategic Positioning
  • Cost/Benefit

Continuous Investment Review

An important part of the Governance function is “Continuous Investment Review”. Continuous Investment Review is the process of checking work progress (projects, programmes and other delivery methods) against forecast budgets and extrapolated costs to decide if the business should continue to fund a project.

This continue, change or stop decision is a chance to apply feedback to work based on actual output, spend so far and projected spend.

Benefit (ROI) = Business Value – Cost of Implementation

Waiting until the end of a piece of work to judge whether it was worth it or not places value at the end of the lifecycle. Business Value is the most important thing, so checking it regularly can prevent organizations from making significant mistakes.

One of the most valuable decisions a software business can make is to stop a failing project.
Failing projects are a learning experience for everyone involved and can happen even to the most perfect development team. Estimates are only guesses, and software development is hard, and frequently complex. Early failure is success. Late failure is to be prevented.
Although early failure should be encouraged, and even incentivized it must not be more attractive than project success otherwise the organization is tuned to perpetual failure. Incentives for delivering Business Value must out-weigh early failure incentives. The number of projects stopped early should be considered a positive measure. The amount of variance from forecasts that triggers exception reporting should be calibrated according to the organizations’ financial risk appetite. Note that project estimates are expected to vary significantly at the early stages of work until the portfolio, programme or project has been de-risked – even then some variance is normal.
Continuous Investment Review should be transparent and public. By using a common Business Value model (POFL) decision-making around stopping a piece of work, or changing its funding, or moving it in terms of the Commoditization Scale (and therefore the Hybrid Dynamic Model for ways of working and organization) becomes relatively easy.

Return on Investment (ROI) is based on a simple formula:

Return on Investment = Business Value – Cost of Implementation

Where business value is qualified in terms of the POFL tests and cost of implementation is the cost of the product (and/or maintenance agreements) as well as the internal Delivery cost of deployment and support (as well as and configuration/customization costs). HSD helps organizations determine cost of implmentation by illuminating all of the work related to a Portfolio Request.

Where business value is not defined financially (e.g. in non-commercial organizations) we end up with a simple “Business Value vs. Cost of Implementation” equation which offers a simple decision to Business Leaders: Is the benefit worth the cost? We recommend that a wide stakeholder group is used to answer that question rather than just the Business Leaders so that decisions have wide support as they are made, rather than trying to gain support afterwards, especially when those decisions relate to tools, environments or COTS selection.

Similar to relegation tables in sporting leagues we recommend transparently publishing Benefit (ROI) data, cost, forecast and current funding decisions for each piece of work. We recommend literally publishing a league table of pieces of work and their value – cost – progress. The top performers are safe, the lowest performs can be considered at risk in the “relegation zone”. When “relegation” comes, in the form of stopping or reducing funding, no one will be surprised even if the news is disappointing. This process also has the added benefit of gamifying project performance, adding a competitive pressure for teams to regularly demonstrate progress towards new/improved business value.
The following is an example Continuous Investment Review “Relegation table”. Note that this table shows the Business Value indicators and answers the Big 4 governance questions. In terms of financials, we track how much has been spent, how much more needs to be spent and so the total estimated cost. We’ve included the traditional initialisms for these in the table below but only recommend using them if you’re already familiar with them.
Using this example table (based on real information from an anonymized client) below we can make decisions regarding each investment. We include the narrative explaining the table below:
Proj 1” is a bit of work aimed at feeling good and looking good. We know it’s a marketing led piece of work that will improve our reputation with partners and make the workforce happier. It’s overspending a little but not significantly (63% budget for 60% scope) and is pretty healthy. It’s not focused on problems or opportunities but it’s something we want to do – Continue.
Big Programme” is doing some good work against solving the problem it’s aimed at, but isn’t hitting it’s “feeling good” value indicators. We may need to look into that. It’s overspending again, a bit more significantly this time, and it’s a pretty expensive project. Talking to people we know that this is because it’s a high complexity programme. It’s healthy – Continue.
Quick Hack 5” is about seizing a new opportunity. It’s cheap and cheerful and the team are doing a great job, this experiment looks like it’s working. It’s even over-delivering in terms of scope for budget but it’s so speculative we always knew scope was pretty variable. The team need to celebrate their success a bit more, and tighten up a little on their self-improvement. It’s a no-brainer – Continue.
Experiment 2” is not doing too well against its problem although it’s getting some good progress against new opportunities. It’s overspending slightly, but not significantly. Because it’s working practices aren’t looking too healthy and the progress against the problem isn’t great it’s at risk due to being relatively expensive. This might not work – At Risk.
Complex Prog 2” – This was always going to be difficult, it’s very complex. This is a big expensive programme, and it’s spent quite a lot already (20% budget – 6!), but not achieved much in terms of scope delivery (15%) and isn’t doing well at solving its problem, or new opportunity. It’s not hitting the feel good and look good elements very well either. Recent investigation shows a lot of cross-team problems, probably due to the difficulty and lack of progress. This has been a really valuable piece of work, that’s allowed us to fail fast and learn some important lessons. Thanks to everyone involved, the time has now come to sop this Prog. We’ll look to reinvent another solution to problem, ideas are welcome at the Fast Fail party – Stop.
Can you be so honest about your projects and programmes? If not, why not? Good governance is based on honesty.
During development there is sometimes a lag between early releases and meaningful business value – this situation requires business leaders to make subjective judgements and should not be avoided. Unconfirmed business value is more likely in speculative inventive work on the Commoditization scale. Leaders are empowered to make investment decisions, doing so publicly means their personal credibility will be based on their decision making incentivizing them to make good, well communicated, decisions. If your Leaders are too scared to make public investment decisions, then you have the wrong leaders.
The input to Continuous Investment Review is initially Portfolio Requests and/or Business Cases. Once pieces of work are in execution then they will need to interface to this process by providing the data on a continuous basis. We recommend a monthly report to the entire organization as above, perhaps on internal social media platforms.
Continuous Investment Review is especially important in governing Software Engineering Contracts.

In a software context a contract is a written or spoken agreement that is intended to be enforceable by law between a customer and a supplier on how a product or part of the software development process will be delivered.

Tracking a Portfolio – Governance and Milestones

We recommend Portfolios are reviewed annually in line with corporate tax cycles and continuously as part of Continuous Investment Review. In line with our principles, Holistic Software Development is inherently feedback based. Portfolio management and governance offer three primary feedback mechanisms:
  1. Annual Portfolio Review – the outermost feedback loop
  2. Continuous Investment Review – the opportunity to react to disruption, new information, spiking results and change without waiting for a year
  3. Cross team, project and programme issue and headline escalation via the Bubble Up practice – ensuring the output of team based feedback goes somewhere.

Portfolios are tracked via Milestones across the Portfolio, and constituent pieces of work –  Milestones are initially created as part of Planning.

A Milestone is a significant event or decision point in the lifetime of a project. 

Holistic Software Development uses a standard set of layered Milestones to drive the Risk-Driven Lifecycle. Milestones are a useful way of tracking top-level guesses about when scope will be delivered. Like estimates, they should not be treated as deadlines.

Milestones are often used to represent the completion of a key deliverable or completion of a significant stage of a portfolio, programme, project or other delivery method so that lower level deliverables and/or time periods do not need to be tracked. This means that milestones must be based on some lower level of evidence – not simply the date they were originally planned for.
A common dysfunction in many organizations that track milestones is that a lot of business pressure is applied to managers and teams to meet them. Milestone variance is seen as a bad thing, because it means planning is unstable. This dysfunction often results in almost all “planning milestones” hit on date but much of the original planned scope or level of quality missing. This is effectively “clock watching” and a measurement driven behavior that is actually damaging to a business as it devalues the feedback process. Planning is unstable by its nature, and estimates are uncertain.
Milestones will change and move, forcing them not to is dysfunctional.

To counter this common issue, we define a Milestone in three ways:

  • A planned date – defined as a date with a variation tolerance either way (e.g. 30/11/2034 +/- 4 weeks). We recommend that Milestones are set at month ends rather than specific dates to avoid false implications of accuracy unless there is a valid specific business reason to do so
  • A planned scope – defined in terms of requirements at a target level of done
  • A planned level of quality – defined in terms of acceptance criteria or quality confidence

As with all estimates we recommend always presenting Milestones with an indication of Uncertainty.

In Holistic Software Development we use a standard simple milestone pattern repeated at each level of the business:

  1. Scoped – the planned scope is a set of requirements that are understood at an inch-deep mile wide level
  2. De-Risked – enough of the solution has been successfully implemented to reduce remaining risks to an acceptable level
  3. Delivered – the planned scope has now been delivered
Scoped” Milestones will typically result in a set of Requirements at a scoped (not fully elaborated) state and architectural prototypes\spikes indicating feasibility (except for portfolios).
“De-Risked” Milestones will typically result in a Release as will “Delivered” Milestone(s).
“Delivered” Milestones are often split into a number of scope based Milestones representing key functional requirements or Integration Scenarios as incremental deliveries.
In HSD diagrams this full lifecycle is typically truncated for brevity however a product lifecycle plan might have a lot more detail:
This pattern of milestones means that any milestone, other than the “Scoped” milestones can be easily defined as an aggregate of contributing activity. Although in the example above we’ve represented two Product Delivery projects being in the context of a single Programme, real portfolios are rarely so simple. A real Portfolio is likely to be made up of numerous Programmes and stand-alone Projects as well as various other delivery methods. However, regardless of shape, each can trace its Scoped, De-Risked and Delivery milestones to the portfolio.
Here’s a visualized example of a real client’s portfolio:

Not all Programme and Project level “De-Risked” milestones will automatically trace to the Portfolio being De-Risked as different Programmes and Projects will have different risk profiles. Typically, maintenance projects are very low risk and may not even have a De-Risked milestone.

This dependency tree between milestones is sometimes called a “Portfolio/Programme Build Logic”. Since Holistic Software Development includes both programme and project management as well as technical practices which define Build quite specifically, we avoid the term “Portfolio/Programme Build Logic”. Software Product Builds are the primary unit of delivery, progress and business value – since the portfolio milestone dependency is simply a planning construct it is inappropriate to use the word “build” in this context.

We strongly recommend that Milestone dependencies are kept as limited and simple as possible since they will move and change as the solutions are elaborated. Since we know that they are indicative planning constructs early in the lifecycle there is no need to spend a large amount of time planning them and then re-planning them to give a false sense of predictability when we know that uncertainty is an unavoidable part of software engineering.

As mentioned in Risk Driven Lifecycle, Holistic Software Development is inherently risk focused. Milestones are defined in terms of risk reduction and points along the cone of uncertainty, which indicates, but does not guarantee, accuracy of estimates over time.

“Scoped” milestones exist to try and understand the shape and direction of work, outlining what needs to be understood, not that everything has been understood. De-Risked milestones are set at the point at which the business can commit to future investment along the cone of uncertainty with “reasonable” confidence.

Portfolio Milestones

If an explicit portfolio is maintained the following milestones can be used:

Portfolio Scoped

The Portfolio is considered Scoped after the Portfolio Build/Selection process has completed. This results in a number of Portfolio Requests and associated Business Case Options that have been selected for execution by the business combining both new investments and Business As Usual, including maintenance projects and Operations requirements. This set of Portfolio Requests can be thought of and represented as a top-level Portfolio Backlog.

A Portfolio can only be meaningfully scoped in context of an Enterprise Architecture since this will impose certain technology choices and options, or indicate a direction for new development to take (e.g. SOA, Data Freedom etc.). Often the portfolio will result in changes to the Enterprise Architecture leading to dependencies between Portfolio items – we recommend minimizing these as much as possible.

Organizations that do not have meaningful executable architecture struggle to scope their portfolios.

Investment De-Risked
The Portfolio is considered De-Risked when enough top-level risk has been mitigated by constituent deliveries that continued spending is justified and secured for the rest of the Portfolio cycle (normally a year). Various Operations and Business risks may play into this Milestone as well as Programme and Project deliveries such as resource management risks, external competitive, business change, actor risks, technology risks etc.
Early Programme and Project deliveries that produce Product Releases mitigating technical risk through working architecture will reduce delivery risk substantially and so the Portfolio can be considered De-Risked when key (not all) constituent project (and if they exist programme) milestones Product De-Risked and Product Family De-Risked have been passed.
Change is inevitable, and in year changes to projects as further information is understood are inevitable. Few organizations start a year with an empty portfolio, there is frequently ongoing work from previous years. To deal with this ongoing situation we recommend Continuous Investment Review to balance risks with investment in response to change.
Incremental Business Benefit Delivered

The Portfolio can incrementally deliver Business Benefit as its various pieces of work begin to deliver Releases for Adoption and Business Change delivering Business Value. This Milestone might be split into multiple milestones representing major Product or Product Family deliveries, and/or related Business Change Milestones.

Key (not all) delivery Milestones will trace to the Portfolio Delivery Milestones.

Programme Milestones (only if programmes exist)

If using the Big Picture of HSD, and if programmes exist to co-ordinate constituent projects towards delivering Business Value from systems-of-systems, the following milestones can be used:

Product Family Scoped

A Product Family or Programme is considered Scoped when its requirements are understood at an “inch-deep, mile-wide” level. Often represented in terms of a set of Features and Integration Scenarios along with associated Non-Functional Requirements which collectively form the Programme Backlog. Supporting material such as User Experience Storyboards may also be introduced to further elaborate important parts of the high level requirements.

A Solution Architecture will be elaborated to a minimal level describing the structure of the proposed solution in terms of key components, services and products and their responsibilities (often in terms of simplistic APIs). The behavior of the Solution Architecture is normally represented as Solution Mechanisms and Integration Scenarios.

Product Family De-Risked

A Product Family or Programme can be considered De-Risked when its constituent Projects have met their De-Risked milestones or Project Deliveries have resulted in significant Programme risks being mitigated. This milestone will equate to a set of requirements from the Programme Backlog being completed to at least the “Product Family Integration Tested” Definition of Done, although we recommend that “Product Family User Acceptance Testing” is used to further de-risk the Product Family. If the Product Customer (or Product Forum) is not involved at this point there remains a risk that the Programme will not deliver the right set of properly integrated products to deliver Business Value.

Product Family Delivery

As with the Portfolio Delivery Milestones, the Product Family Delivery Milestone may be split into a number of incremental deliveries adding to the completed requirements set in a number of high level time-periods of Programme level Releases. These Milestones represent cohesive subsets of the Product Family requirements being ready in the form of Releases for Adoption and Business Change activities so Business Value can be generated.

Remaining requirements, if significant, may be put forward for a next lifecycle of the product as a Portfolio Request. Or, if less significant, into long-term maintenance and support, also represented as a Portfolio Request or a simple Change Request on a Product.

Delivery Milestones

Delivery milestones may be met in different ways by different delivery methods. Some delivery methods will not explicitly recognize Delivery milestones.

Product Scoped

A Product is considered Scoped when its primary requirements are understood enough to begin detailed elaboration and development. Often taking the form of a set of Scoping Requirements (User Experience Design, Integration Scenarios or Scope Models) elaborated as a set of User Stories (or borrowing a subset of a Programme Backlog). Requirements must be at a minimal level of detail required to understand likely schedule and form a candidate System Architecture in the context of Solution and Enterprise Architectures. Collectively this set of requirements forms the early Product Backlog. Be careful to avoid excessive detailing of requirement as detail is likely to change.

Product De-Risked

A Product is considered De-Risked when its primary risks have been mitigated through delivery of a set of requirements, in the form of working software, on a proven System Architecture to at least the “Integration Tested” level of Done although we recommend using the “Product User Acceptance level” of Done to further de-risk the Product. If the Product Customer isn’t involved in validation at this point there remains a risk that the wrong product is being built.

Product Delivery

The Product Delivery Milestone may be split into a number of incremental deliveries adding to the completed requirements set in a number of high level time-periods or Product level Releases. These Milestones represent cohesive subsets of the Product requirements being ready in the form of Releases for Adoption and Business Change activities so Business Value can be generated.

Remaining requirements, if significant, may be put forward for a next lifecycle of the product as a Portfolio Request or, if less significant, into long-term maintenance and support, also represented as a Portfolio Request or a simple Change Request on a Product.

Maintenance/BAU Projects

“Business As Usual” or maintenance projects are unlikely to have the same necessity to create cohesive understandings of scope in the form of backlogs and release plans and so the Scoped and De-Risked Milestones typically are not used in these projects. Instead a simple number of low-impact delivery milestones are used, roughly aligned to calendar periods or continuously. If at all possible, maintenance should take the form of Continuous Delivery, including Continuous Deployment rather than batching changes into calendar form.

If a maintenance project has enough new scope to require significant architectural effort, significant risk reduction and release planning then it is not really a maintenance project, it is a “new delivery” lifecycle of a Product or Product Family and should be treated as such. Hiding new development as maintenance is typically a dysfunctional measurement driven behavior caused by rigid financial governance. Holistic Software Development incorporates a distinction at Portfolio Request level between “New Investments” and “Business as Usual”, reviewed during the Portfolio Selection process, to help prevent this dysfunction.

In many organizations the term “Business As Usual” or BAU is used to describe work that is considered necessary for the business to function, including maintenance of legacy systems, infrastructure (see Operations). We recommend qualifying the business value of these BAU items on an annual basis to ensure that continued funding is producing Business Value as part of Continuous Governance. BAU can sometimes become part of the fixed cost base of an organization which means there is less funding for creating new Business Value and research/innovation. In turn this means less profit for commercial organizations and less delivery capability for non-commercial organizations.


Milestones are typically created and communicated as part of Planning activities.

Planning is the process of defining an intention for, and making arrangements for, achieving something of Business Value

In Holistic Software Development a plan may be a formal or informal description of how work will be done and controlled, defining scope, schedule and resource usage targets. We focus plans on achieving business value to ensure that plans are aligned to the business strategy and “doing the right thing”. Planning does not constitute progress, only working products should be considered progress.
Plans should be understood to be “best guesses” rather than accurate predictions of the future.
“No plan survives contact with the enemy.”
The purpose of a plan is to answer:
  • What is the work?
  • Where are we now?
  • When will the work be done?
  • What resources will be used?