Priorities, a logical choice!

Posted on October 25, 2012 by ThePMJournal

In theory, features priorities are settled in a transparent, logic and consistent manner. As we have seen before, in Gathering Requirements lesson, the priorities in F-Startup are chosen based only on the “mood” of key stakeholders: 

 I rises this problem in operational meeting:

-With all due respect… Our Business Priorities are chosen only on our personal preferences. Our objective is not just to establish importance of the features (Business Priority), but also to justify their business value in relation with to company objectives.

-Put aside “our objective“! replied COO irritated. We gathered here to establish priorities. Based on the impact on business, we chose the priorities!

-And how can you evaluate the impact? I asked.

-Is simple! We just set the impact…that’s all! Now, let’s move on, because today I want to leave earlier the office…

Because I realized people easily confuse the term “priority” (order of implementation) with “importance of the features“, I wanted to find out, as in a little experiment, what think key stakeholders about “priorities”:

What do you thing the order of implementation is between the 4  features (T1, T2, T3, T4) above?

Here were their answers:

A). The order is clear: I want them all in the same time! reply CEO.

B). Order of implementation is given by Business Priority (see the column in the table above) we established in prioritization session: (T1, T2, T3, T4), said COO.

C) Order of implementation does not depend only on Business Priorities.

Although option “B” is valid because could be considered a requirement from one of a key stakeholders, the optimal answer is “C”. Order of implementation (Priority) depends on business priority but and also on project constraints (money, time, resources, quality, risks, etc).

Option “C” has a justification from Project Management perspective: any implemented feature imply a cost. The question above could be rephrased like this:

What is the order of implementation of 4  features knowing the development team has a burning cost of “7” per month and what are the features should be implemented in the first month?

And the 3 answers above, with some imagination, could be translated like this:

A). You tell me! answer CEO.

B). T1, T2, T3, T4. In the first month we can implement T1, T2 says COO.

C). We need to make a benefit cost analysis to determine the optimal order.

Obviously option “B” could be correct and has a logical explanation: from business point of view the importance of features are T1, T2, T3, T4. In first month we can do T1+T2 = 6 (value smaller than burning cost of “7”) so the priorities could be: T1, T2, T3, T4. But this solution doesn’t utilize the maximum potential of the team. In the first month, T1+T2=6, we burn less than ideal burning cost “7”, which means would remain time for other task/feature having a burning cost of “1”.

Therefore, the implementation in this order: T1, T2, T3, T4 involves an inefficient resource allocation. The key to answer is found in column called “Business Reason”. As you can see, in our case, the reasons are very peculiar: “My gut tells me“, “Because I said so“, etc, so they contain “all” the reasons in the world except business reasons and “good sense” of logic…

I believe for nobody is no news, to find out, some managers take decisions exclusively on their “natural” instinct or based on the argument: “My word is law”. Imagine this kind of manager has a decision power and is responsible for choosing Business Priority/Business Value. Would you feel comfortable, knowing the project priorities would be chosen based only on his input (Business Value)? Probably not. That is the reason why priorities are not chosen based only on one person (or a small group of top managers/ one “Almighty” manager) and this might be the reason why the decisions, in general, are taken by multiple persons, in collaboration. The project priorities should be chosen based on all internal and external stakeholders. PM has the responsibility to make sure all the stakeholders inputs are included in the prioritization procedure.

For a PM, to be able to set a Priority, first he/she need to understand the reason why a feature is important or not: Why this feature need to be implemented? Using this information in correlation with all the information from stakeholders, a PM could decide in a logical, transparent, consistent and objective manner priority of a feature (for example by using a Benefit Cost Analysis, one of the most well known and accepted method of prioritization).

Taking the above example, benefit-cost indicators are:

T1 has a Benefit/Cost = 5/5 = 1

T2 has a Benefit/Cost = 4/1= 4.

T3, 4/4 = 1.

T4, 2/1 = 2.

Eager to show my proposal to key stakeholders, I convened a new meeting:

-This is order of implementation (priority): T2, T4, T1, T3.

-What is this? asked COO.

-A Benefit-Cost analysis, I reply.

COO has frozen:

-Who are you to tell us what is the order of implementation? Let the business analysis to be our decission!

I argue my solution:

-Order of implementation T2, T4, T1, T3 uses at maximum the teams potential. In first month we could do: T2+T4+T1 =7 (100% burning ratio) vs. first solution: T1+T2= 6 (meaning 6/7=85% burning ratio). Also, the total Business Value we can get at the end of the month is 10 Vs. second choice (T1+ T2=9). So, the order of implementation based on benefit-cost ratio is:

-No! This is not the order! We do as I said: in the first month T1, T2, replied COO.

The Priorities, a “sensitive” subject

Deciding priorities is a sensitive “subject” of discussion, because is very difficult to reconcile all the opinions of the stakeholders. I was asked myself: When should I (or shouldn’t) use benefit-cost analysis? For small projects (usually Agile project), the Business Priority (Business Value) of the features settled by customer, could be the same as overall Priority (order of implementation). For example, a project developed with Scrum methodology, you don’t always need a benefit-cost analysis to choose priorities and there is a logical explanation for this: each Sprint delivers a demo; if the client is not happy with what he gets (what he gets is for what he pays) he could terminate the project, if the client wants to continue the project he could ask for a scope change. During an Sprint/Iteration, priorities could change rapidly depending on clients needs so reevaluation of benefit cost indicators is often just a loss of time  (of course nothing stops the team to offer a benefit cost analysis to the client favoring a better decision). Development in Scrum is very similar with “a game of life and death”: Fight to survive the changes. Adapt or die!

In large projects, where deliverable are not mandatory at the end of each iteration and resources are shared between different projects, so the cost of one project could impact the cost of others projects, choosing priorities should take into account also other constraints (time, resources, money spent, risks, customer satisfaction, quality, etc), not only “Business Value”.

Priorities in response to illogical choices

The Benefit-Cost Analysis propose a pragmatic prioritization method that reduces risk to choose priorities just on personal opinions, interpretations and emotional response. There are prioritization techniques where emotional response plays a big role, as Kano Model. Despite the fact the model offers an interpretation of the results based on emotions and subjectivity of stakeholders, synthesizes pretty well the needs of customers from the market. The model is interesting and useful in the same time, because it offers a logical interpretation of illogical choices. (For more details read a Full analysis of Kano Model).

Although Kano Model is based more on emotional response and less on rationality, the model behind is a solid, with many practical applications and offers the same “valid” results as Benefit Cost Analysis.

A rigurous method of chosing priorities

The rules of choosing priorities, in a transparent, consistent and less interpretable, are:

1. Take into consideration the opinion of all stakeholders (internal and external). In Example: Development team should always have an input on choosing the final priorities. If team input is ignored, then MBO principle is broken (Management By Objectives, all objectives should be agreed and supported by all levels of organization).

2. If process of choosing priorities is based on team’s Effort(Cost), the Effort estimation should be evaluated on a predefined criteria. The weight of each criteria can be established at organization level or depending on product strategy. The estimation of Effort is represented as a numeric value (i.e. we could choose a Fibonacci series: 1, 3, 5, 8, 13, 21, etc to evaluate Effort or a predefined scale: 5 = very hard to implement, 1=very easy to implement). Example of criteria with different weights:

3. The priorities take always into account Business Priorities/ Business Value. Business Value are estimated using predefined criteria (criteria are defined at organization level: portfolio, program and ideally should not be changed from one project to another). Business Priority should be defined by 3 minimum criteria (the weights could change from one project to another). In table below there are defined two categories of criteria: present and future). The estimation of Business Values is represented by a numeric value (i.e. 5 = very high priority, 1=very low priority).

Why do we need so many criteria to establish Business Priorities?

In prioritization sessions, people tend to over evaluate or under evaluate Business Priorities (sometimes when I ask “Which feature you consider important?”, I receive the following answer:”All are important”). So, in order to reduce the chance of receiving a subjective result, we can settle multiple criteria to set the Business Priority.

5. Each criteria is an average of opinions of at least 3 people. Why minimum 3?

The people, no matter good they are, sometimes are wrong. That’s why PERT technique, is based on 3 estimation (P=Pessimistic, O=Optimistic, M=Most probable); No matter the method we choose to assign the final value to each criteria (PERT, Poker game, etc) you need minimum 3 people to have a more realistic result. In any debate, you need more than two opinions to avoid situation like “my word against your word”.

Strong and weak points in Benefit-Cost Analysis

Benefit-Cost Analysis could be used in prioritization of features, projects or products itself. The table below contains a prioritization of products using Effort and Business Value (The release order on the market is given by descendant sorting of column “Benefit Cost Ratio”).

Why cannot always rely on Benefit Cost Ratio to set the priorities?

Lets have the following example:

In figure above, there are 2 projects P1 and P2, with the same benefit cost ratio = 1. Both having the same ration, we don’t know what project to be implemented first… The same situation we have for all projects belonging to mathematical equation: y=Cx (or Benefit/Cost=y/x= C constant Ratio).

Here is another example I encountered in real life that proves the benefit-cost analysis is not always a suitable method of prioritization:

In table above, feature called “UI/UXD part 1” and “UI/UXD part 2” are linked by the same objective (“user graphical interface”), a feature considered very important from business point of view (Business Priority/Value has maximum value of “5”). Based on benefit cost analysis, “user graphical interface” should be done in 2 separate iterations, but the client wanted to see first all “graphical interface” prior to everything.

To resolve the current problem, we had to split “graphical interface, the UI/UXD” feature in more that two parts, we re-estimated the effort and we managed to deliver as much as from “graphical user interface” in first iteration.

In Project Management, there are several known techniques of prioritization that can be used together or as complementary with Benefit Cost Analysis: Matrix Prioritization (see below), NPV (Net Present Value), IRR (Internal Return Rate), ROI (Return of Investment) or even type of Monte Carlo analysis (to prove what decision are better and first to implement).

Matrix Prioritization

A complementary method of Benefit Cost Analysis, is known as Matrix Prioritization Plan which in fact is another type of Benefit Cost Analysis, offering a visual interpretation of data. The order of implementation is given first by Y-Axes (Business Value) and then X-axes (Effort): the order of implementation is given by quadrant: 1, 2, 3, 4. The bubbles in the same quadrant, we can split in other 4 quadrants and apply the same rules as above. This method does not have the same limitation “C Constant Ratio” as “classical” Benefit Cost Analysis, because we use on sorting two dimension (Y and X). On the first dimension Y, we sort features by Benefit, then we use the second dimension “X” to sort on Cost, so even Benefit/Cost is the same, the sorting can be still obtain ordering Benefit. Matrix Prioritization still have a limitation, if two products have the same ratio Benefit/Cost=C and the same Cost (in this case, the products cannot be ordered using only the two dimensions and we need supplementary “sorting dimensions” or constraints).

The advantage if this method is we can choose priorities visually, without any calculation: P1, P3, P2, P4.

Priorities, a logical choice

I realize few PMs have luxury to decide project priorities. Choosing priorities using a standardized method is a nice story, but in real life, priorities are imposed from outside project by functional managers, clients, Sponsors and not settled by PM. Normally, PM should choose priorities using a standard procedure (defined in Organization Process Assets). The procedure of choosing priorities is part of a document describing very clearly how criteria and priorities are chosen, how priorities are linked with company objectives and products strategy. This document is kind of “New Testament” or a “Gospel” containing the definition of each priorities criteria:

UXD Criteria: “I believe user experience decide success or failure of the product”, Up-selling Criteria: “I believe up selling features will significantly increase revenue of our company”, Brand criteria: “I believe by increasing brand awareness will attract more strategic partners!” etc.

If you don’t have such a document in your company, then pray in chorus “God have mercy on us”…

Priorities are chosen logically based on predefined criteria, not based on instinct. But here comes a natural question: if priorities are a logical choice, how come Apple, people defied logic in whatever they made, managed to be so successfully? Did they use analytic methods, graphics, mathematical models to choose their priorities? Obviously not! First of all, they haven’t settled priorities, but objectives. They begun from the essence of the things (objectives of the company) and priorities derived in natural and logic manner from objectives. Although their objectives were sometimes crazy and almost illogical, priorities were a logic choice.

Read next: A day in the life of Product Manager.

Previous: O lectie de Gathering Requirements.

Recommendation: When is about business, logic fails!

Books: Agile Excellence for Product Managers