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.
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 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
- 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?
- What are the projected resource needs?
- What are the projected tangible and intangible costs and opportunities?
- Is the Request worth doing?
- 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:
- Strategic Positioning
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.
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.
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
- Annual Portfolio Review - the outermost feedback loop
- Continuous Investment Review – the opportunity to react to disruption, new information, spiking results and change without waiting for a year
- 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.
- 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:
- Scoped - the planned scope is a set of requirements that are understood at an inch-deep mile wide level
- De-Risked - enough of the solution has been successfully implemented to reduce remaining risks to an acceptable level
- Delivered - the planned scope has now been delivered
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.
If an explicit portfolio is maintained the following milestones can be used:
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.
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.
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 may be met in different ways by different delivery methods. Some delivery methods will not explicitly recognize Delivery milestones.
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.
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.
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.
"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
- What is the work?
- Where are we now?
- When will the work be done?
- What resources will be used?