Prosjektledelse Prosjektledelse nr. 1 2020 | Page 35

DEBATT
Marc and I share some values regarding require-
ments specification. But I have some problems
with some of his remarks, and some suggestions
for more-advanced thinking on requirements.
One value we share is quantification of (some)
requirements:
“Project objectives are the
establishment of requirements
which are as quantified as
possible and which must be
met in order for a project to be considered
successfully completed.” (Marc W)
“Conflicts of objectives are to be
avoided.
….A complete definition
of objectives requires the
identification of all relevant stakeholders,
which can lead to conflicts of interest.
Conflicts of objectives are to be avoided, i.e. the
different project objectives must fit together.”
You cannot avoid conflicts of objectives, all obje-
ctives are inherently in conflict with each other,
both for the common budget, and because they
just conflict with each other, security and usabi-
lity are examples.
Project requirements are of many types, and some
of them do not admit to quantification, because What Marc might have said is the following:
they are binary (present or not). 1. You should not specify a performance (value,
See Fig-1. So all performance and resource/cost quality) goal level which makes it impossible to
requirements can and should be quantified. But reach reasonable and necessary goal levels for
(Function/Deign/Condition) other critical objectives.
constraints,
and
Function Requirements are not normally quanti- 2. You need to find a reasonable balance regar-
fied. They are binary. Present or absent. ding performance goal levels so that minimum
PROSJEKTLEDELSE • NR. 1 2020 35