Principle 3: "Taking an economic view" - SAFe Part 5
Dimitrios Mitrentsis
Department Manager System & Infrastructure, License & Contract Manager, Senior Programm Manager, Agile Transformation, Global Transition & Transformation, Outsourcing Services, M&A
This is a series from the SAFe maturity concept, which is based on living practice examples. This is Part 5 - "Taking an economic view".
The business and IT strategy is represented by the business IT portfolio, prioritized according to cost / benefit criteria and implemented step by step (early & often). The objective includes several steps and action points that are necessary for a successful conversion of the strategic business portfolio road map to an economic view. Essentially, the following action points have to be introduced.
AP 3.1 - There is a method for defining a Business & IT Portfolio
Start by developing a process for defining and collecting project ideas and requirements with your partners and customers. Corresponding parameters for projects and requirements are primarily based on the strategy and benefit for the company.
Define cycles and the process of continuously gathering ideas and requirements or the inclusion of your customers in requirements management and maintain your business road map. When setting up and updating the strategic business and IT road map, you should not forget to assign the associated budgets before starting implementation. Do this a few months before.
The action point is completed after you have established a quarterly review of the strategy and portfolio road map of the company.
AP 3.2 - A prioritization method is applied across all requirements
A business road map quickly turns into a flop if the prioritization of the requirements and ideas is done at will. It is therefore no secret that the strategic business portfolio of many companies is regarded as out of date or unnecessary action one day after the publication of the final road map.
"Projects without priority are like traffic lights without switching rules."
Such indices indicate that there are no recognized prioritization principles. This is not uncommon, especially when you are a monopolist or the margins are so high that you have no reason to plan strategically.
It would be appropriate to submit all requirements and ideas to an economic viewpoint and to design and define clear prioritization criteria for the company. At the latest when the money becomes scarce, you need a prioritization or a ranking.
You will fit to this action point if a ranking and a sequence is for all requirements or requests are defined. The budget is spread along the ranking list and is strategically corrected if necessary by senior management.
As practice example, allready is establish in the portfolio office of many companies, there is a scoring and rating matrix by some possible standard criterias. Some criteria that can be used to calculate the rankings would include:
- the economic benefits (business value, ROI),
- the potential damage in case of non-implementation of strategic issues,
- security or legal requirements as well as laws and
- usability or lean approaches
If two ideas or projects have been assigned by the same ranking, the fastest possible project or project with the least effort should be forced. Sounds simple, is easy. Try to establish something like this.
Be sure to strictly apply the prioritization criteria. A reasonable and sustainable prioritization is one of the greatest success factors in the implementation of IT Projects. If you do not succeed in prioritizing at the portfolio level, it does not make sense to think about a further SAFe introduction.
AP 3.3 - Requirements and dependency management is established
Evaluating requirements without the dependency management along the system landscape and the representation along the business process chain is not an optimal requirement management. Also think about how the requirements or ideas and features are reported (granularity and quality) must be defined and adherence monitored.
When you setup the requirements management, you should pay attention to best collaboration between development (IT) and requester (customer) and also the elimination of unnecessary communication channels between them. In almost all organizations, requirements management is the direct input channel to IT.
Both in the description as well as in the estimates you should give priority to agile methods. Prevent unnecessary activities, e.g. evaluations by persons without knowledge. In cases you need estimation for pre-selection by customer, use indicator classes (1 day / 10 days / 50 days / 100 days ...), which can also be filled by non-specialists or even by the requester himself (e.g. in the description of the requirement or IT Request).
When establishing dependency management, you should pay attention to avoid producing data waste, and to document dependencies that are large enough (for example > 100 work days) and these one that will be surely implemented. Prevent unnecessary work done by your specialists. Finally your specialists should be used for important projects, so that you should not deal with unnecessary tasks.
Keep an eye on the system and do not lose yourself in the details.
AP 3.4 - The project portfolio is strictly implemented according to cost / benefit prioritization
After the project portfolio has been prioritized, one of the most difficult exercises will be the implementation of IT Requests according to the defined ranking. Companies with high degree of SAFe or agile maturity in development will do the implementation along a defined prioritization and rating.
Many companies are already failing at the initial definition of the ranking of the It Requests.
It is important for this action point to implement the projects and requirements along the rankings. But don’t do implementation of program team backlogs blindly and without meaning. If the implementation of a requirement leads to a further requirement with lower ranking put them together for the release and sprint planning.
As a product owner or chief product owner it’s important to present the prioritized requirements correctly and completely. Also you have to observe the dependencies in the supply chain and to agree with the other product owners. For dependencies the principle of the periodic freeze is valid. Until the next planning, the backlog will be implemented as planned. Again, if it makes no sense you can change your backlog.
If you have managed to establish and live this action point within your program organization, you have created the prerequisites for agile planning within your company. You designed a template for scaling agile approach to other program organizations in the entire company.
For most companies, the overall planning process ends within a program. This is increasingly due to the rigid hierarchies within the company itself. In this case, it is advisable to prepare the programs for agile planning methods and, if necessary (e.g. delivery conflicts or dependencies), to coordinate with the other programs. If the votes are broken and the success occurs, the organization will find pleasure in the overall planning and self-organized planning and voting workshops.
Don't do too much at the beginning; you first should concentrate on the success within the individual programs. After that, start with overall planning by using more than one program.
AP 3.5 - Continuous Business road map is established (portfolio live simulation)
What is a Continuous Business road map and when is it established?
One possible vision for Continuous Business road map is to have a live simulation of implementation for requirements at any time. As far you implement and maintain requirements based on prioritization methodology, you can speak of a stable business roadmap. At least for a certain period (cadence) the above statement should apply.
A further point for Continuous Business road map is to keep the business road map up-to-date at all times. The already established requirements process with all your stakeholders will help to proceed. Annual planning of projects and IT portfolio is no longer state of the art.
We live in an age of steady change, so you do not need outdated portfolio management and dusty demand processes. You need an always up-to-date continuous business project and feature road map that helps you to align your IT quickly and effectively to the market requirements.
This also involves actions like turning upside down defined delivery cadence, the priorities and the planning and keeping them up-to-date at all times. This ensures that you do not unnecessary work.
Pick up your budget for the important requirements and features and stay on the same level with the market.
For the first SAFe maturity level you have to introduce the action points AP3.1 - AP3.2 -AP 3.3. If, after 12 months, you have implemented the essential action points of "principle 3" and know you are looking for more, you can devote yourself to the last two points. These two points are not, however, prior within the first year of SAFe introduction.
Do not hesitate to contact me to provide you with the SAFe Maturity Concept and more detailed information to practice examples in implementation of "principle 3".
Next article will be PART 6: Principle 4 "Define and live decision-making at all levels"
---------------------------------------------------------------------------------------------------
Dimitrios Mitrentsis publishes and comments on LinkedIn various topics as a private individual. All statements or opinions expressed in the articles reflect a purely personal opinion.
Take a look at my other articles:
Principle 2: "Design the SAFe framework for enterprise needs."
The SAFe Maturity Concept - a way become agile and to be
SAFe - PART 3: Principle 1 "enabling the organization"
"being agile" - the will for a controlled transformation - part 2
Mensch 2 Mensch... Emotionen entscheiden!
Culture eats transformation first...