In our series on prioritization methods, the first article introduced basic techniques like MoSCoW and the Eisenhower matrix, which help reduce subjectivity in assigning priorities. The second post discussed scoring formulas for prioritizing many work items.
While those techniques emphasize a broad approach to understanding value and effort, there’s another paradigm that zooms in on the time-sensitive nature of value using the Cost of Delay. In this article I’ll explain this concept applied to the management of a project portfolio from a Lean/Agile perspective.
Cost of Delay
In 2009, Donald G. Reinertsen released “The Principles of Product Development Flow”. This book rethinks conventional product development and project management approaches, emphasizing lean principles that focus on waste reduction and enhanced workflow. It also provides a deep dive into managing queues, variability, batch sizes, and feedback to optimize product development processes, but probably the most relevant concept it introduces is Cost of Delay (CoD), underlining the economic impact of time in product delivery.
At its core, CoD represents the potential revenue lost or additional costs incurred due to postponement of a task or project. In essence, it quantifies the impact of time on the outcomes we’re pursuing. Within the Kanban method, CoD is often used to define classes of service, ensuring work items are prioritized not just by their inherent value but also by the economic impact of delaying them.
A common practice in Kanban is to classify the work items in separated swimlanes depending on their corresponding class of service, so the team just needs to pull when they have capacity, depending on the working agreements (or policies) for each class of service.
Weighted Shortest Job First (WSJF)
Now, imagine you’re managing multiple projects with imminent deadlines. How do you decide which project to focus on first? Reinertsen introduces a method called Weighted Shortest Job First (WSJF) that can help.
Each project has two main factors: the time it’ll take (duration) and the penalty if it’s delayed (cost of delay). If all the penalties for being late were the same, you’d simply tackle the quickest project first; this is the Shortest Job First (SJF) approach. But what if a slightly longer project, if delayed, could cost your company a major contract or a key client? This is where WSJF comes into play. With this method, you prioritize projects based on both their duration and the potential cost of delays. It’s like choosing to complete a project that’s slightly longer first because securing a significant business deal depends on it.
Look in the figure (extracted from the book) how the total delay cost (the dark area) can vary significantly depending on the order used to schedule the projects.
Some companies might just tackle projects in the order they were received. This is like treating every client or stakeholder equally. However, it’s not always the wisest approach, especially if delays in certain projects have larger ramifications. Others might focus on the buffer each project has. It’s like checking which project is closest to missing its deadline. But this method doesn’t always factor in the potential financial or reputational costs of certain delays.
The bottom line: it’s essential to consider how the time factor can drastically affect a project’s overall economic outcome. WSJF helps prioritize tasks by combining how long they take with the price of being late. It adds a time-focused layer to task prioritization, ensuring the most urgent and impactful tasks are tackled first.
Applying the formula
SAFe adopted this formula (also known as CD3, Cost of Delay Divided by Duration, by other authors) as its recommendation to prioritize backlogs, and it’s described as follows:
WSJF = Cost of Delay / Job Duration
where Cost of Delay is estimated as the sum of User-Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement, and Job Duration is usually substituted by Job Size as a good-enough proxy metric.
In a practical scenario, obtaining precise numbers for these variables might be challenging or nearly impossible. However, even an approximate estimate can pave the way for valuable discussions. Remember that it’s crucial to focus on engaging in meaningful conversations about the potential value each feature will (hopefully) bring to the company. So, instead of trying to estimate a timeframe for this calculation, it’s better to set a fixed duration for a Minimum Viable Product (MVP). For example, consider asking, “How might we realize the potential value of this option in a maximum of 6 weeks?”. If it seems unfeasible, break down the feature until it becomes achievable within that time frame. Then, rank all options based solely on Cost of Delay (CoD).
Lean Portfolio Management
To truly make the most of these methods, it’s essential to link them with our product strategy. And if we’re managing a company’s project portfolio, they should align seamlessly with the company’s broader objectives. This alignment ensures that every effort, every project, moves the company closer to its goals. This is where the notion of Lean Portfolio Management (LPM) becomes relevant.
LPM is an Agile approach to align project execution with an organization’s overall strategy, ensuring that resources are invested in initiatives that deliver maximum value. It emphasizes adaptability, continuous feedback, and a focus on delivering value to guide portfolio decisions and priorities. As stated by SAFe (Scaled Agile Framework), LPM is “one of the seven core competencies essential to achieving Business Agility”. Although this article is not focused on LPM as defined by SAFe, I’d suggest you should consider learning more about it.
Another way of looking at LPM is as the alignment between the strategic objectives and the strategic planning, that ultimately is extended to all teams in the organization, all done under the principles of optimizing the flow of work for each value stream, minimizing waste, and fostering excellence and leadership at all levels. Of course, all of this opens many other topics like budgeting, organization and process design, or knowledge management, which are the current main difficulties that companies are facing to achieve their business agility.
A personal case of success
For one year, I worked for BBVA Spain in order to craft the planning process for their portfolio, called the SDA (Single Development Agenda). This initiative aimed to consolidate BBVA Spain’s diverse strategic projects, many spanning several years, into a unified framework.
For me, this is a big hit in my career because we were able to craft a portfolio management process for such a big institution, compliant with their strict rules and given the bank’s intricate landscape. Initially inspired by the SAFe PI Planning approach, we managed to adopt a more adaptive and lean model. This not only facilitated the decomposition of larger projects into more manageable, smaller initiatives but also introduced a quarterly budget review mechanism. Consequently, we achieved a more strategic and efficient resource allocation, all within the bank’s compliance framework.
If you are interested, there are more details in this independent article by the Center for Information Systems Research at MIT Sloan School of Management.
Prioritizing according to the customer feedback
This is the last article of this series dedicated to prioritization methods. We’ve been going from very simple methods, with very simple criteria to classify work items, like the medical triage, to more elaborated formulas to allow the prioritization of a large number of items and including the economic impact of time, like WSJF. It’s important to understand your situation in order to select the best method for you.
Nevertheless, some other methods have been left out. Special mention to the Kano method, which allows us to understand and classify (and ultimately to prioritize) our features according to the user feedback, which is something that should be included in our prioritization criteria as long as we are trying to be Agile.
Conclusions
As a final conclusion, from a Lean/Agile perspective, we shouldn’t make a great effort in having the perfect priority, as reality is always moving. It’s not worth it. Instead of aiming for perfection:
- break down big tasks early on since instead of making a big effort to have an estimation,
- start important tasks soon enough so everyone’s flow is not interrupted.
Notice that the word “enough” is key here. No method can give us a prediction of the future.
This is the last article in this series dedicated to prioritization methods. We’ve gone from very basic classification methods suitable to personal tasks prioritization, to this specialized approach focused on prioritizing larger collections of projects. This approach considers factors such as the time projects spend in our development pipeline, awaiting delivery to users, and emphasizes their impact.
