Loading...
 

Priority

Definition:

A “priority” is the determination of a relative Claim on limited Resources. Priority is the relative right of a competing Requirement to the Budgeted Resources.

Alternative Names

Concept Number: *112
English Master: Priority
Synonyms, Variations & Acronyms: none

Detailing

If Resources were unlimited, there would be no need to prioritize things. You could “have it all”. An explicit Priority Parameter can be used to specify any direct Priority relationships.


Illustrations


Illustration: none


Type

Parameter, Design Concept


Examples

none


Notes

1. The specified, qualified, Stakeholder Requirements (the targets and Constraints stated in the Requirements) provide “natural” (Requirement related), and dynamically computable, Priority information. The gaps remaining until the Goals are met, and Budgets used up, can be measured and computed. In general, the largest gap to a Performance-Target will have the highest Priority and, the largest gap to using up a Budgeted Resource will indicate the safest Resource opportunity. However, to determine your priorities in specific cases, the degrees of Risk and uncertainties and/or, knowledge of the effort (the Resources) needed to close the individual gaps to meet each of the Function and Performance-Targets, and the likely resulting Stakeholder values on delivery, all need to be taken into account (See below for a more Complete list).

2. Priority is not a constant. It cannot and should not be determined and specified in the form of static Priority weighting numbers (for example, “25%”, or third on the Priority list) or words (for example, “High”). Current Priority Depends-On how well satisfied the competing Performance-Targets are, and how “used up” the Budgeted Resources are at any given time. Current Priority also Depends-On the more fundamental changes that can occur in Requirements themselves, as Stakeholders modify their Requirements, and as the external business environment alters - to demand Requirement changes.


Example:
Consider your priorities for food and air. If you are hungry, then you give Priority to eating. However, as soon as air is in short supply, your priorities change. Your body gives Priority to breathing.
Your body knows your food and air Requirements, both targets and Constraints. Your body knows the current supply Levels of these Resources. When changes in the body Resource Levels dictate change in our priorities, this knowledge triggers the body to appropriate Action. The body, as a System, acts in order to ensure our comfort and survival.
Priority is dynamic

3. Priority is decided by a wide variety of factors, which include but are not limited to:
Qualifier Conditions (factors such as timescales and location)
Stakeholder Authority
Stakeholder influence
• consequences of failure (not meeting Fail Constraint Levels)
• consequences of Tolerable (not meeting Survival Constraint Levels)
• previous experience of meeting similar Requirements (including no experience!)
• Complexity of meeting the Requirements
• consequences of success (primarily meeting the Performance-Targets, the
Goal Levels: the System improvements delivered, and the benefits likely to
be experienced)
• Resource availability (or maybe more significantly, Resource unavailability)
• dependencies

Within Planguage, the relative Priority of a Requirement Depends-On a combination of the elements of the specification. These elements include target Levels (examples Goal, Budget), Constraint Levels (examples Fail, Survival), its Qualifier Conditions [time, place, event], and its Authority Level.

If you consider only the different Requirement Level Parameters as a Class: first Priority is satisfaction of all the Constraints; the Survival Levels, then the Fail Levels. Then next Priority becomes satisfaction of targets; the Goal Levels, After that any Stretch Goals are considered, and finally perhaps some Wish Levels.

However, you have also to consider the Qualifier Conditions as well, for all these Levels, as qualifiers bring into play additional factors, like the timescales for the Requirements to be met, and the events under which the Requirements actually exist.

No Priority exists until the Qualifier Conditions [time, place, event] warn us of potentially unfulfilled Requirements. Targets and Constraints are not finally effective until their Qualifier Conditions are true, but the designer, the architect, and the project manager have to prioritize their contribution in advance of deadlines, and other Conditions, becoming “true”.

4. Stakeholders” needs will ultimately decide the relative priorities. There will be trade-offs to consider when there are conflicts between Requirements.

System designers should evaluate priorities, and then present the results for confirmation, selection, or conflict Resolution, to the Stakeholders themselves. Stakeholders, as a Result of seeing the Cost and feasibility of design options may then choose to change some of their Priority specifications.

5. The Priority Parameter can be used to help people to more directly understand the priorities (or to confirm the derived priorities with Stakeholders). Alternatively, it can be used to specify priorities that differ from what would otherwise be expected or evaluated.

6. Rationale and Source Parameters should ideally support Priority Parameter-Specifications.

Example:
Usability:
Scale: <Speed of mastering> defined [Tasks] by defined [Staff Type].
Tolerable [USA, Task = Query Handling, Staff Type = Customer Service]: 35 hours.
Tolerable [Europe, Task = Query Handling, Staff Type = Junior Management]: 25 hours.
Goal [Australia, Task = Query Handling, Staff Type = Customer Service]: 30 hours.

Priority [Usability]: Australia Before Europe Before USA <- Marketing Plan 6.5.
Rationale: Past bad experiences with current System.
Source: Technical Director.
Without the explicit “Priority” statement we would normally prioritize the Fail Levels.
However, the Priority specification Means we should use scarce Resources on the Australia Goal Before we use them on the two Fail Levels. We should then use Resource on Europe Before the USA.

7. Priority is not the same as “time sequencing”. “Priority” Means “priority for getting limited Resources”. “A => B” (=> icon for Before) Means A will be sequenced Before B. But “A > B” Means A will be allocated Resources Before B, and B might never get Resources if they run out. Also, the mere fact that “A > B” does not necessarily mean that A will actually be scheduled for delivery Before B, if B finally gets some Resources. There could be reasons to deliver B Before A if it does get Resources. However, if real time, or “Time-To-Market” are the only Resource we are considering, then time sequencing and Priority seem to be equivalent Concepts.


Keyed-Icons

> has greater Priority than
for example, A > B

< has less Priority than
for example, A < B

= has equal Priority to
for example, A = B

where A and B represent tags of Resource consuming options, such as Requirements or Evo-Steps.

A space is recommended on either side of the icon,
Example: “A < B”, not “A<B”.

“{> | < | =} [*]” , Priority operator and Resource Qualifier
for example “ A > [ Money] B” Means “A has Priority over B for Money Resource”
Explanation: Any Priority icon (“>“ or “<” or “=“) can be followed by any Qualifier indicating the set of Resources for which this expression is valid.


Drawn-Icons

none


Level *337
Risk *309
Gap *359
Dependency *189


History-of-Concept

none









This Concept entered by Kay Dudman

Created by system. Last Modification: Tuesday 13 of November, 2018 15:08:46 CET by Admin (Kai).
(Cached)

Concept Search