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?