Asymmetriskt i IT-projekt påverkat beslutsfattande

xii
ment office, audit and the company’s documentation standard.
These factors (and several more) determine the tollgate and
thereby the individuals who participate in it.
The eight factor groups that surround the decision making each contain a
large number of factors. Each of these can on the next level contain several
sub-factors that can in turn be further divided into subordinated factors.
As an example we can take the factor group “Influence situation”
where the factor “Project management office” can contain method responsibility,
coordination, start decision, method training, quality work,
coaching/support, project portfolio and project management resources.
On this sub-factor level a new division can be made where quality work
can be divided into project, product and leadership. Project can in turn
contain method implementation, documentation and goal fulfilment and
these can in turn be divided into the number of levels that suit the company’s
project model/method and that is deemed suitable for explaining
the decision making and creating the transparency that leads to an understanding
of the decision reached. This leads to a higher likelihood of
fulfilling the benefits that the project’s product will provide.
In order to make the model of asymmetrically influenced decision
making more practical it is essential to generalise the model. Generalisation
means being able to use the model in non-IT projects. Alternatively/also
generalisation means that the model can be applied to decision
making in line management. What then differentiates the asymmetric
model in IS/IT projects from other types of project results? IT is generally
felt to be complex/technical for a decision maker. IT staff have
formed their own exclusive arena with its own jargon and this can lead
to ontological problems. Information systems and IT are a part of / prerequisite
for company operations and should be managed accordingly,
i.e. as an integral part of operations. The decision support documentation’s
fact base must be fully authenticated. It is important to remember
the ontology (i.e. agreement over terms and their meaning) as well as the
decision maker’s knowledge of the project product (i.e. the information
system). This is dealt with through communication, training and clarity.
A model for project work should be the same regardless of product/result
so that asymmetry does not occur. This is handled by placing
requirements on the decision support document’s factual contents and
by focusing on operations (e.g. work and benefit) and not on the infor-