In the current highly competitive marketplace, business service and solution development is a major factor in the competition. Most organisations continually receive development requests to update and improve the business technology estate or to implement new capabilities and technologies that are key to supporting the company vision and strategies for success.
Regarding this, a common challenge faced by business technology functions is to find the right way to orchestrate and prioritise the continuous flow of requests with a minimal viable governance. The objective is to speed up the time-to-market without losing sight of the requests that are lower down the priority order.
The prioritisation and commitment processenables development flow decision making for development initiatives. At the same time the portfolio steering process and necessary stakeholders focus on initiatives that cannot be decided in the development flow.
Figure 5.2.1 Prioritisation and commitment process
As explained in chapter 2.6., Development Portfolio, the demand and development portfolio management provides a set of rules and guidelines to help in identifying if the request is a fit for development flow decision or must go through a deeper level of examination and approval.
The following evaluation criteria determine whether DEV flow approval can be used:
If the answer to all of these seven criteria is affirmative, the requests can be approved with the development flow decision and the development team will add the request to its backlog and take care of further development of the request.
Evaluation may also include further hierarchy steps. For example, if the first evaluation round does not provide positive answer it can be escalated upwards in the hierarchy until it bypasses or reaches the portfolio level. Typically, the lowest level self-evaluation is done by a service manager or a product owner and can be further escalated to a service owner or a value stream owner before going to the portfolio level.
When a request does not pass the evaluation criteria and cannot be approved by the development flow, portfolio steering is required to:
Once the portfolio steering group agrees and is confident with all aspects of the request, it is ready to proceed to development phase where a development request will be produced using either sequential or incremental development procedures:
Before committing to the development, each development request must be prioritised according to different considerations and development method.
For sequential development, shared resources are allocated to the development for a planned period. Prioritisation of sequential development is a complex exercise that requires carefully balancing the following three considerations:
The above considerations are driven by the Development Management Office and provided by the project owner. The portfolio steering provides its own judgement to ensure that all initiatives are prioritised equally.
In incremental development, a team dedicated to a specific business purpose manages a backlog of requests. The team needs to manage the new requests coming in and prioritise its backlog while continuously delivering new service releases.
During a specific workshop (e.g. PI planning session in SAFe) the team, including the stakeholders, works to break down each request into large increments and spends time breaking down each increment into smaller pieces of development (features, stories) that will be realised incrementally. Still working with the stakeholders, the team then evaluates the different pieces of development and prioritises them based on:
The result of this work is a prioritised backlog of tasks for each request. Requests are then compared between each other to select the most viable one to develop first. The criteria for selection is often based on the Cost of Delay Divided by Duration (CD3) of each request or Weighted Shortest Job First (WJSF in SAFe).
Some requests received by service teams refer to minor changes on some existent capabilities, products or services and thus represent only a few hours’ or days’ worth of effort. These changes are usually decided by the development flow and follow a specific steering governance and prioritisation decisions by the Change Advisory Board (CAB).
A service change management process is used to manage the implementation and release of the changes. It employs standard methods and procedures to make an assessment between the need for change versus the impact of change. The objective is to prevent all unintended consequences to service quality.
The changes are usually classified as normal, standard or urgent.