Internati
o
nal
Journal of Ele
c
trical
and Computer
Engineering
(IJE
CE)
V
o
l.
5, N
o
. 4
,
A
ugu
st
2015
, pp
. 83
2
~
83
9
I
S
SN
: 208
8-8
7
0
8
8
32
Jo
urn
a
l
h
o
me
pa
ge
: h
ttp
://iaesjo
u
r
na
l.com/
o
n
lin
e/ind
e
x.ph
p
/
IJECE
Guidelines Aimed at Red
u
cing th
e Ri
sks of Us
er
Accept
a
nce Del
a
y in th
e Cont
ex
t of an IT Service Project
Management Plan
E
un J
o
o
Je
on
g
,
J
i
Hwan Bae, Seung Ry
ul
J
e
ong
Graduate School of Business I
T
,
Kookmin
University
, Seou
l, Rep
ublic of Korea
Article Info
A
B
STRAC
T
Article histo
r
y:
Received
Mar 10, 2015
Rev
i
sed
May 12
, 20
15
Accepte
d
J
u
n 2, 2015
Dela
y
s
in th
e us
er ac
cep
tan
ce of
inform
ation t
ech
nolog
y
(IT) s
e
rv
ice pro
j
e
c
ts
in Korea h
a
ve
occurr
ed freq
u
entl
y du
e to
various
ris
k
fa
ctors
.
Us
e
r
acc
eptan
c
e
d
e
la
ys
m
a
y h
i
nder
th
e
ach
iev
e
m
e
nt of
the
c
lien
t
’s proj
e
c
t
objectives and cause
sch
e
dule delay
s
or
cost
overruns. Furth
e
rmore,
the
cli
e
nt m
a
y
im
pose a d
e
la
y
cha
r
g
e
and
cl
aim
for
addition
a
l d
a
m
a
ges, c
a
using
serious disputes
between
bu
y
e
r
and supplier
.
The main
caus
e
s of user
acc
eptan
c
e
del
a
y
s
are
uncl
e
ar us
er
r
e
quir
e
ments, ch
anges in user
requirements, p
oor-quality
dev
e
lopment ou
tputs, excessive fun
c
tion
a
l
and
non-function
a
l
errors, lack of
user
involvement, unclear user
roles an
d
responsibilit
ies, and
uncl
ear crit
eria
of
user
acceptan
ce t
e
st.We help foster
the t
i
m
e
l
y
co
m
p
letion of us
er a
ccep
tan
ce
b
y
proposing
a
m
e
thod of
identif
yi
ng th
e r
i
s
k
facto
r
s
in us
er a
ccep
tan
ce d
e
la
y
and
crea
tin
g a proj
ec
t
management plan to weed
out
th
e iden
tif
ied r
i
sks. We propose
a g
u
idelin
e for
a
n
IT se
rvic
e ma
na
ge
me
nt
pl
a
n
tha
t
wee
d
s out or
lowers th
e r
i
sk
factors well
in adv
a
nc
e.
To
val
i
dat
e
the
gu
idelin
e’s ut
ili
t
y
,
we
appl
y
it
to
IT
servi
c
e
projects.
The results
show that the
gui
d
e
lin
e
is
effec
tive
in
id
en
tif
ying
and
removing risk
f
actors
aff
ecting
delay
s
in
the
us
er
ac
cept
a
nc
e of
IT
s
e
rvi
c
e
projects
.
Keyword:
IT se
rvice
project
Pro
j
ect
m
a
nag
e
m
e
nt
pl
an
Pro
j
ect
ri
sk
m
a
nagem
e
nt
Project s
u
ccess
and
failure
factors
User accepta
nc
e test
Copyright ©
201
5 Institut
e
o
f
Ad
vanced
Engin
eer
ing and S
c
i
e
nce.
All rights re
se
rve
d
.
Co
rresp
ond
i
ng
Autho
r
:
Seu
n
g
R
y
ul
Je
on
g,
Gra
d
uat
e
Sc
ho
ol
o
f
B
u
si
nes
s
IT,
Kook
m
i
n
Un
iversity,
7
7
Jeo
ngn
eung-
ro
,
Seung
buk
-g
u, Seou
l, Repu
b
lic
o
f
Ko
r
e
a
Em
a
il: srj
e
on
g@koo
k
m
in
.ac.k
r
1.
INTRODUCTION
User acce
ptance delays occur fre
quently in IT servi
ce projects in Korea
due t
o
va
rious
risks.
Use
r
acceptance
can be
either intermediate or
fi
na
l [1]. Interm
ediate user acce
pt
ances e
x
ecute
at the e
n
d stages of
pr
o
j
ect
m
i
l
e
st
ones, s
u
c
h
as
d
u
ri
ng sy
st
em
anal
y
s
i
s
and
de
si
gn
, de
vel
o
p
m
ent
,
or i
n
t
e
g
r
at
i
on a
nd sy
st
e
m
t
e
st
.
Final user acc
e
p
tance e
x
ec
ute
s
at the sta
g
e
of
project
c
o
m
p
l
e
t
i
on t
o
co
nfi
r
m
readi
n
ess f
o
r sy
st
em
opera
t
i
on.
The
res
u
lts
of use
r
ac
cepta
nce tests are
cl
osely rela
ted t
o
project
payments, whic
h
are m
a
de afte
r the
interm
ediate a
nd
final user a
cceptance tests
have
bee
n
pa
s
s
ed.
Delays in
interm
ediate or final use
r
acce
ptance
tests m
a
y i
m
p
e
d
e
pr
oj
ect
ob
j
e
ctiv
es an
d im
p
o
s
e
add
itio
n
a
l
co
sts i
n
tim
e an
d m
o
n
e
y
[
2
].
Th
e bu
yer m
a
y also
im
pose
del
a
y
char
ges
o
n
t
h
e
s
u
p
p
l
i
e
r
or
g
o
t
o
c
o
u
r
t
i
f
t
h
e
d
i
sput
es ca
n
not
be
resol
v
ed
bet
w
een
t
h
em
.
User acce
ptance delays ca
rry critical risks, suc
h
a
s
(categorize
d
by project
milestone) unclea
r
use
r
requ
irem
en
ts
d
u
ring an
alysis and design
, sch
e
du
le
d
e
lays an
d
po
or-qu
a
lity p
r
o
g
ram
co
d
e
s during
devel
opm
ent
,
an e
x
t
e
n
s
i
o
n
o
f
t
h
e i
n
t
e
grat
i
o
n t
e
st
pe
ri
o
d
,
c
h
an
ges
t
o
re
q
u
i
rem
e
nt
s du
ri
n
g
t
h
e i
n
t
e
g
r
at
i
o
n
t
e
st
,
and a
lack of
user i
n
volvem
en
t, a
n
d
unclear final
user acce
ptance
test cr
it
eria
during test
. T
o
e
n
s
u
re
tha
t
use
r
acceptance
tests com
p
leted
on tim
e
, we
propose t
h
at the
ri
s
k
factors
for
us
er acce
ptance
tests nee
d
t
o
i
d
entify
Evaluation Warning : The document was created with Spire.PDF for Python.
I
S
SN
:
2
088
-87
08
I
J
ECE Vo
l. 5
,
N
o
. 4
,
Au
gu
st 2
015
:
83
2
–
83
9
8
33
an
d th
at
d
e
tailed
p
r
o
cedures
an
d criteria
for p
r
ev
en
ting
th
e id
en
tified
risks in
ad
v
a
n
ce
need
to sp
eci
fy
in
th
e
pr
o
j
ect
m
a
nagem
e
nt
pl
an.
Most studies have disc
usse
d t
h
e failure a
nd
succe
ss
factors
in projects a
n
d us
er acce
pta
n
ce tests [3-
10]
as
wel
l
as pr
o
j
ect
m
a
nagem
e
nt
pl
an i
t
e
m
s
. Ho
we
ver
,
fe
w st
u
d
i
e
s
on
p
r
o
j
ect
m
a
nagem
e
nt
pl
an
s ha
ve
discuss
e
d proc
edures a
n
d c
r
iteria for preve
n
ting the
IT
se
rvice project ris
k
s of
user acceptance delays.
Ch
ap
ter
2 prov
id
es so
m
e
b
a
ck
gro
und
fo
r t
h
is st
ud
y. C
h
ap
ter 3 i
n
tr
odu
ces th
e
gu
id
elines for
t
h
e I
T
servi
c
e
m
a
nagem
e
nt
pl
an
p
r
op
ose
d
i
n
t
h
i
s
st
u
d
y
.
C
h
apt
e
r
4
val
i
d
at
es t
h
e
pr
o
pose
d
g
u
i
d
el
i
n
es
by
a
ppl
y
i
n
g
them
to IT service projects.
In
th
e last ch
apter, we
d
i
scu
s
s th
e resu
lts and
li
m
ita
tio
n
s
of th
is stud
y as well as
p
o
s
sib
ilities for fu
ture
research
.
2.
BA
C
KGR
OUN
D
KN
O
W
LED
G
E
2.
1.
Pro
j
ect
M
a
n
age
ment
Pl
an
A
p
r
oj
ect m
a
n
a
g
e
m
e
n
t
p
l
an is a
form
al, ap
prov
ed
d
o
c
u
m
e
n
t th
at
d
e
fin
e
s
h
o
w
proj
ect activ
ities are t
o
be e
x
ecut
e
d, m
oni
t
o
re
d, c
o
nt
r
o
l
l
e
d, a
n
d c
onc
l
ude
d.
It
t
y
pi
cal
l
y
co
m
p
ri
ses p
r
o
j
ect
b
a
sel
i
n
e
s
o
f
sc
ope
, sc
h
e
dul
e
,
an
d co
st an
d sub
s
i
d
iary
man
a
g
e
m
e
n
t
p
l
an
s su
ch as sco
p
e
, tim
e
,
co
st,
qu
ality
, hu
m
a
n
reso
urces,
com
m
uni
cat
i
on,
p
r
ocu
r
em
ent
,
ri
sk,
st
a
k
eh
ol
ders
, a
n
d
i
n
t
e
g
r
at
i
o
n
as
wel
l
a
s
ot
her
pl
an
ni
n
g
d
o
cum
e
nt
s s
u
ch
as
req
u
i
r
em
ent
s
and c
h
a
nge m
a
nagem
e
nt
(se
e
T
a
bl
e 1)
. T
h
e co
nt
ent
s
o
f
p
r
o
j
ect
m
a
nagem
e
nt
pl
ans
vary
depe
n
d
i
n
g
up
o
n
t
h
e
ap
pl
i
cat
i
o
n
area
an
d c
o
m
p
l
e
xi
ty
of
t
h
e project [1
1].
Project m
a
nage
m
e
nt plans
are ve
ry
im
port
a
nt
beca
use t
h
ey
are
ki
nd
of c
o
nt
ract
doc
um
ent
a
t
i
o
n
s
and
bec
o
m
e
a basel
i
n
e f
o
r
pr
o
j
ect
act
i
v
i
t
i
es an
d
execut
i
o
n.
I
f
any
seri
ous
di
sput
es
bet
w
ee
n t
h
e
su
p
p
l
i
e
r
an
d
buy
er
ar
i
s
e, t
h
e
pr
o
j
ec
t
m
a
nagem
e
nt pl
an
becom
e
s a
re
f
e
rence
fo
r
dec
i
si
on-m
a
ki
ng
or
asses
s
m
e
nt
of
di
sp
ut
es.
T
h
ere
f
o
r
e,
pr
o
j
e
c
t
m
a
nagem
e
n
t
pl
a
n
s
n
eed to
write clearly and
con
c
retely in
lin
e
with
th
e
g
u
i
d
el
i
n
es. M
a
nagem
e
nt
pl
ans
f
o
r
s
o
f
t
ware
p
r
o
j
ect
s
have
t
h
e f
o
l
l
o
wi
n
g
m
a
jor
sect
i
o
n
s
:
o
v
er
vi
ew,
p
r
o
j
ect
or
gani
zat
i
o
n, m
a
nageri
al
pr
ocess
pl
an
, t
echni
cal
pr
oce
ss pl
a
n
,
and s
u
pport
process
plan (see
Table
2).
Tabl
e 1. Sect
i
o
ns of
p
r
o
j
ect
m
a
nagem
e
nt
pl
a
n
[1
1]
Major Sec
tion
S
ection
Topi
cs
Project baselines
Scope baselin
e,
Schedule baselin
e, Cost
baseline, Project
ba
selines
management
Subsidiar
y
plans
Management p
l
ans(Scope, Co
st, Schedu
le,
Requirements,
Qua
lity
,
Risk, Proc
e
ss
improvement, H
u
man resource,
Procurem
ent,
Co
m
m
unications
, S
t
akeho
l
ders
)
Others
Life cy
cle; Pro
j
ect objectives; Other
Mana
g
e
ment Plans
(
C
hange
, Issue
s
, Proc
e
ss,
Configuration
)
Tabl
e
2. M
a
na
gem
e
nt
pl
an
fo
r s
o
ft
w
a
re
p
r
o
j
ect
s [1
2]
Major Sec
tion
S
ection
Topi
cs
Overview
P
u
rpos
e, s
c
op
e,
objec
tives
;
As
s
u
m
p
tions
and
co
n
s
traints; Project
deliv
erabl
e
s
;
S
c
hedule
and
budget summar
y
; Evo
l
ution
of
th
e plan
Project organization
Extern
al int
e
rface;
Ro
les and
r
e
sponsibilit
ies; Int
e
rnal
structu
r
e
Managerial process plan
S
t
art-up p
l
ans
(
es
tim
ation
,
s
t
a
ffin
g
, res
our
ces
acq
uis
ition,
and
proj
ect
s
t
aff
tra
i
ning
plans
)
;
Work plan(work
activities
,
sch
e
d
u
le, res
ource, an
d budget allocation); Contro
l plan;
Risk management plan; C
l
oseou
t
plan
Techn
i
ca
l pro
ces
s
plan
Process model;
Methods, too
l
s,
and techniqu
es
;
Infrastructur
e p
l
an; Product
acceptance plan
Supporting process
plan
Configuration
management
p
l
an;
Verifi
ca
tion
and
va
lida
tion
pl
an;
Docum
e
ntation
p
l
an;
Quality
assurance plan; R
e
views and audits
; Problem resolution plan; Su
bcontracto
r
management p
l
an; Process impro
v
ement plan
2.
2.
Ch
ar
acter
i
sti
c
s o
f
IT
Se
rvi
ce Pr
ojec
t
En
terp
rises
h
a
v
e
recen
tly increased th
eir
IT se
rvi
ce
pr
oject
s
,
p
r
ovi
di
ng
i
n
t
e
g
r
at
ed
i
n
f
o
rm
at
i
o
n
syste
m
s as require
d
by t
h
eir
clients, to ac
hieve thei
r
bu
si
ness go
als.
I
n
an
IT serv
ice
pr
oj
ect,
p
r
oj
ect
tea
m
me
m
b
er
s co
ndu
ct st
r
a
teg
i
c plan
n
i
ng
, an
alyze
u
s
er
r
e
qu
ire
m
en
ts,
d
e
sign th
e
I
T
system
b
a
sed on the
u
s
er
requ
irem
en
ts,
d
e
v
e
l
o
p and
test th
e in
teg
r
ated
info
rm
a
t
i
on sy
st
em
usi
n
g
h
a
rd
ware
an
d
s
o
ft
ware,
an
d
o
p
erat
e
an
d op
timize th
e in
teg
r
ated
i
n
fo
rm
atio
n
syste
m
. An
IT
se
rvice project c
r
eates ne
w se
rvices that integrate IT
p
r
o
f
ession
al tech
no
log
i
es
with
in
du
strial
k
nowle
dg
e to up
grad
e an
o
r
g
a
n
i
zatio
n’s co
m
p
etitiv
en
ess and
i
m
p
r
ov
e its
v
a
lu
e an
d
p
r
o
ducts u
s
i
n
g IT sk
ills [1
3
]
. Th
us, m
e
m
b
ers of IT serv
ice
pro
j
ect
team
s req
u
i
re
IT
p
r
o
f
ession
al tech
no
log
i
es, ind
u
s
t
r
ial kn
owl
e
d
g
e
, an
d th
e
sk
ills n
e
ed
ed to
m
a
n
a
g
e
p
r
oject facto
r
s su
ch
as
sco
p
e, sc
hed
u
l
e
, cost
, a
n
d ri
s
k
. P
r
oject
t
e
a
m
m
e
m
b
ers gat
h
er a
nd a
n
al
y
ze t
h
e use
r
s’
b
u
si
ness
re
qui
re
m
e
nt
s
Evaluation Warning : The document was created with Spire.PDF for Python.
I
J
ECE
I
S
SN
:
208
8-8
7
0
8
Gui
d
elines Ai
med at
Reduci
ng the
Risks
of
User A
ccept
a
nce Delay
in t
h
e
Context of …
(
S
eu
n
g
Ry
ul
Je
on
g)
83
4
an
d th
e system’
s
fu
n
c
tion
a
l an
d
n
on-
fu
n
c
ti
on
al
r
e
qu
ir
em
en
ts du
r
i
n
g
t
h
e an
alysis ph
ase.Th
e r
e
q
u
i
r
e
m
e
n
t
s
of
the use
r
s a
n
d
the system
might
be
unclear due to i
nvisi
ble softwa
re c
h
aracteris
tics.
During the
sy
ste
m
in
teg
r
ation
test
, m
o
reov
er, user requ
irem
en
ts are
o
f
ten
chan
g
e
d
.
Th
ese
ch
ang
e
s m
a
y a
ffect system
q
u
a
lity,
delay the sche
dule
of syste
m
integration
test, cause
cos
t
overruns
, and delay the
us
er accepta
nce
test. In
Ko
rea, s
u
ppl
i
e
rs an
d
buy
e
r
s
si
gn c
o
nt
ract
s usi
n
g
fi
rm
-fi
xed
pri
ces a
n
d a t
u
rn
key
f
o
r
IT se
rvi
ce
pr
o
j
ect
agreem
ents [14]. In a turnke
y contr
act, the
supplier
unde
rtakes t
o
deliver
the system
s
the us
er
requi
r
es
on
tim
e
, and the
buye
r
is
oblige
d
t
o
pay t
h
e
s
u
pplier de
pe
nding on the
res
u
lts
of the
use
r
acce
ptance
te
st (see
Fi
gu
re 1)
.
Fi
gu
re
1.
R
i
ght
s an
d
o
b
l
i
g
at
i
o
n
of
t
u
r
n
key
t
y
pe c
ont
ract
[
1
]
Pay
m
en
ts fo
r
IT serv
ice proj
ects
will p
a
y
wh
en th
e task
s
requ
ired for
p
r
oj
ect m
i
lesto
n
e
s ar
e
com
p
leted. Sa
m
p
le paym
ents
divide i
n
to
five installm
ents, each with its
own sc
he
dule and c
r
iteria. Pa
ym
ent
perce
n
t
a
ge
rat
e
s de
pe
nd
o
n
t
h
e de
gree
o
f
pr
o
j
ect
com
p
l
e
t
i
on
(see Ta
bl
e
3)
.
Tabl
e
3.
Sam
p
le pay
m
ent
s
sch
e
dul
e a
n
d c
r
i
t
e
ri
a [
15]
Pa
y
m
ents
Rate
(%)
Schedule
Criteri
a
Initial
20
Agreem
ent of
co
ntract
Issue contract
perform
ance bond
1
st
Middle
15
Completion of
analy
s
is and
design
Pass criter
i
a of d
e
sign completio
n
2
n
d
Middle
20
Completion of
p
r
ogram develop
m
ent
Pass criter
i
a of u
n
it test of
program code
3
r
d
Middle
15
Completion of
in
tegration
test
Pass criter
i
a
of
i
n
tegra
tion
test
Final
30
Completion of
final user
acceptance
te
st
Pa
ss c
r
ite
ria of s
y
ste
m
ope
nne
ss
a
nd
optim
izat
ion
2.2 F
a
ilure
and Succes
s F
a
c
t
ors
for Pr
oje
c
ts
The St
a
ndi
s
h
Gr
ou
p R
e
po
rt
l
i
s
t
s
t
h
e t
op
10
fai
l
u
re a
nd
suc
cess fact
o
r
s f
o
r
pr
o
j
ect
s. T
h
e
m
a
i
n
fact
ors
relate to
requ
ire
m
en
ts, u
s
er i
n
vo
lv
em
en
t, an
d th
e
proj
ect
plan
(see
Tabl
e 4). T
o
e
n
s
u
re that user ac
c
e
ptance
tests exec
ute
on tim
e, project
tea
m
m
e
m
b
ers shoul
d
write t
h
e project m
a
na
gem
e
nt
pl
an
cl
earl
y
an
d c
o
nc
ret
e
l
y
to pre
v
ent
project failure
and
addr
ess th
e
risk
facto
r
s related
to re
qu
ir
em
e
n
ts an
d pr
oj
ect
p
l
ann
i
ng
.
Tabl
e
4.
Pr
oj
ec
t
fai
l
u
re
an
d s
u
ccess fact
ors
[
16]
Failure factors
%
Success factors
%
Incomplete requirements
13.1
User involvement
15.9
Lack
of user
invo
lvement
12.4
Executive a
nd ma
nagement support
13.9
Lack of
resources
10.6
Clear
statement o
f
requirements
13.0
Unrealistic expec
t
ations
9.9
Proper pro
j
ect pla
nning
9.6
Lack
of exe
c
utive support
9.3
Realistic expectations
8.2
Changing
require
ments and spe
c
ificati
ons
8.7
Smaller project m
ilestones
7.7
Lack of
pro
j
ect planning
8.1
Competent
staff
7.2
Didn't need
it any
longer
7.5
Ownership
5.3
Lack
of IT
manag
e
ment
6.2
Clear vision an
d
objectives
2.9
Technological illiteracy
4.
3
Hard-working, fo
cused staff
2.
4
Bu
yer
Sup
p
lier
Rig
h
t
s to requ
ire th
e task
s on
ti
m
e
Ob
lig
ation
t
o
co
m
p
lete th
e req
u
i
red task
s
on
t
i
m
e
Obl
i
g
at
i
o
n t
o
p
a
y
depe
n
d
on
c
o
m
p
l
e
t
i
on
of
re
qui
red
t
a
sks
on
t
i
m
e
Evaluation Warning : The document was created with Spire.PDF for Python.
I
S
SN
:
2
088
-87
08
I
J
ECE Vo
l. 5
,
N
o
. 4
,
Au
gu
st 2
015
:
83
2
–
83
9
8
35
Tar
a
wn
eh
(
201
1)
categ
or
ized
so
f
t
w
a
r
e
p
r
o
j
ect
su
ccess
an
d failure
facto
r
s in
to organ
i
zatio
n
a
l,
technical, people, and c
u
lture
groups
(see Ta
ble 5)
[17] and each fact
or
ha
ve detail va
riables and m
a
de rank.
I
added t
h
e knowledge areas of proj
ect m
a
nagem
e
nt to each
variable of success and fa
il
ure fact
ors. The
m
a
j
o
r
k
nowledg
e areas o
f
p
r
oj
ect man
a
g
e
m
e
n
t
related
to
su
cce
ss an
d
failu
re facto
r
s
are
qu
ality,
stak
eho
l
d
e
r,
sco
p
e
,
tim
e
and
cost, and hum
an res
o
urce. W
i
de
rman
(1992) class
i
fies the
projec
t
risks acc
ordi
ng to t
h
eir im
p
act on
the
proje
c
t (se
e
Table
6)
[19]. He
categori
zes the
pr
oj
ect
r
i
sk
s
b
y
p
r
oj
ect kn
ow
ledg
e
ar
eas as lik
e sco
p
e
,
q
u
a
lity, sch
e
dule an
d cost.
Tabl
e
5.
Fact
o
r
s i
n
s
o
ft
ware
s
u
ccess a
n
d
fai
l
u
re
[
17]
[
1
8]
Factors
Variables
Rank
PM Kno
w
ledge Areas
Organizational Formal
methodology
Clear business o
b
j
ectives
Executive sup
por
t
Minimized projec
t scope
7
4
3
5
Q
u
ality
Stakeholder
Stakeholder
Scope
Technical
Understanding
requirements & management
requirement chan
ges
Standard softw
a
r
e
infrastructure
R
e
liable estimate
1
8
6
Scope
Scope
Time and C
o
st
People User
involvement
Experienced
pro
j
ect manager
2
9
Stakeholder
Human
Resource
Culture Organizational
cu
lture
10
Stakeholder
Tabl
e 6. Pr
oj
ec
t
ri
sks
[
19]
PM Areas
Risks
Scope
Changes
of sco
p
e
or the
subseque
n
t
need for
fi
xes to
achieve
the requi
red technical deli
verables
Q
u
ality
Failure to complete ta
sks to the required level of
technical or quality
performance
Schedule
Failure to complete tasks w
ithin the estimated time limits or risks a
ssociated w
ith dependency
netw
ork
logic
Cost
Failure to comple
te tasks w
ithin th
e estimated budge
t allowances
3.
GUI
D
ELINE
S FO
R P
R
O
J
ECT M
A
NA
GEMENTPL
AN
OF
IT SE
RVI
CE
We c
r
eat
e
gui
del
i
n
es
f
o
r
p
r
o
j
ect
m
a
nagem
e
nt
pl
ans
o
f
IT
servi
c
e
by
i
d
e
n
t
i
f
y
i
ng
t
h
e
o
b
j
ect
i
v
es
a
n
d
criteria, and i
d
entify the
dela
y factor
s of
us
er acce
ptance i
n
the
softwa
re
de
velopm
ent life cycle. The
n
,
we
su
gg
est
gu
id
elin
es
for elim
in
a
tin
g
th
e d
e
lay
facto
r
s and
ap
p
l
y th
em
to
actu
a
l p
r
oj
ects (see
Fig
u
re
2
)
.
Fi
gu
re 2.
Pr
oc
ud
u
r
e of
m
a
ki
n
g
gui
del
i
n
es [1
5]
3.1. User
Acce
ptance
Tes
t
Criteria
Haret
o
n
(1
997
) no
tes th
at so
ft
ware testing
con
s
ists of th
e follo
wing
p
h
a
ses: u
n
it test, in
teg
r
ation
test,
syste
m
test, user acce
ptance
test (UAT), a
n
d test objec
tives and c
r
iteria for eac
h s
o
ft
ware test
phas
e [20].
Kl
ei
n (
2
00
3)
n
o
t
e
s t
h
at
t
h
e “
s
oft
w
ar
e system test is th
e v
a
lid
atio
n
th
at
t
h
e s
o
ftwa
re m
eets its requi
re
m
e
nt”
Identif
y D
e
l
a
y F
actors
in Ac
cept
a
nce
T
e
s
t
Suggest Guidelines for R
e
moving Delay
F
actors
in
Acc
e
p
t
anc
e
T
e
s
t
Appl
y the
Guide
lines
to Actu
al
Projec
ts
Identif
y Ob
je
cti
v
es
and Cr
it
eria
of
Accept
a
nc
e T
e
s
t
Evaluation Warning : The document was created with Spire.PDF for Python.
I
J
ECE
I
S
SN
:
208
8-8
7
0
8
Gui
d
elines Ai
med at
Reduci
ng the
Risks
of
User A
ccept
a
nce Delay
in t
h
e
Context of …
(
S
eu
n
g
Ry
ul
Je
on
g)
83
6
and that “acce
ptance testing
checks the
syste
m
beha
vior
a
g
ainst t
h
e c
u
st
om
er’s re
qui
re
ments (the
‘c
ontract’)”
[21]. Ha
reton (1997) notes, “the use
r
acce
ptance
test is
an im
porta
nt s
t
ep as
the
last
line
of ve
rifica
tion t
o
check the
rea
d
iness
of a s
o
ft
ware deli
vera
ble against t
h
e
us
er’s e
x
pectation” [20]. T
h
e
objectives a
nd
c
r
iteria
of
user acc
ept
a
nce tests in the IT
se
rvice project lifecycle shown in Ta
ble 7.
Inte
rm
e
d
iate user acce
ptanc
e
tests occ
u
r during the
a
n
alysis, de
sign,
and test sta
g
es
,
and the
fi
nal
user acce
ptanc
e
test occ
u
rs i
n
t
h
e
acceptance test stage. The
criteria
of the
user accepta
nce test com
p
ri
se the
quality attributes of the
requ
irem
en
t specificatio
n
,
t
h
e syste
m
q
u
a
lity attrib
u
t
es
, the software
q
u
ality attrib
u
t
es, th
e
fu
n
c
tion
a
l and
no
n
-
f
unct
i
o
nal
sy
st
em
requi
re
m
e
nt
s, an
d t
h
e
readi
n
ess
of
sy
st
em
operat
i
on
[
22]
[
2
3]
.
Table
7.
Use
r
a
cceptance
criteria [22][24]
Stage
Acceptance
Ob
je
ctive
Acceptance
Criteria
Analysis
Requirements spe
c
ification,
ER
(Entity R
e
lation)
D
i
agram
Q
u
ality attributes of requirement specification
D
e
sign System
architecture
System quality attributes
Development
Program
speci
fication, Sourc
e
co
d
e
R
e
sults of unit tes
t
Softw
a
re quality attributes,
Component
quality attributes
Integration Test
R
e
sults of integration/system
test
Functional & no
n
-functional requirements
System test
R
e
sults of system test
System quality
Acceptance
test
Results of acce
ptance test
Readiness of
system operation
3.2. Delay Fac
t
ors
for User Acceptance
T
e
st
This re
searc
h
suggests t
h
at the m
a
jor
dela
y factor
s
in
us
er accepta
nce
tests
relate to
scope, tim
e,
q
u
a
lity, an
d stak
eho
l
d
e
r m
a
n
a
g
e
m
e
n
t
(see Tab
l
e
8
)
.
Nidu
m
o
lu
(19
96)
n
o
t
es, “Requ
i
rem
e
n
t
s un
certain
t
y had
a
significa
nt e
f
fect on
residual
pe
rf
orm
a
nce risk and a
dire
ct ne
gative
e
ffect on
proces
s
pe
rform
a
nce” [25].
User invol
vement is a
p
prop
ri
ate for s
o
lvi
n
g
unst
r
uct
u
re
d
problem
s whe
n
user acce
ptance
is im
porta
nt [26][3].
Scope m
a
nage
m
e
nt address
e
s cha
n
ges i
n
sc
ope a
n
d in
re
q
u
i
r
em
ent
s
(i
ncl
udi
ng
clarifications
). Tim
e
man
a
g
e
m
e
n
t
ad
dresses lack
o
f
sch
e
d
u
l
e man
a
g
e
m
e
n
t
sk
ills an
d
sho
r
t or u
n
realistic p
r
o
j
ect
p
e
ri
o
d
s
.
Qu
ality
m
a
nagem
e
nt
add
r
esses
uncl
e
ar i
n
t
e
grat
i
o
n
t
e
st
cri
t
e
ri
a,
exc
e
ssi
ve
f
unct
i
o
n
a
l
an
d
n
o
n
-
f
u
n
c
t
i
onal
sy
st
em
err
o
rs
,
and
po
or
-
qual
i
t
y
del
i
v
era
b
l
e
s
.
St
a
k
eh
ol
de
r
m
a
nagem
e
nt
add
r
esses
l
ack
of
u
s
er
i
n
vol
v
e
m
e
nt
i
n
req
u
i
r
em
ent
s
d
e
fi
n
itio
n
,
un
clear d
e
fi
n
itio
n o
f
t
h
e u
s
er’s ro
le, and
lack
of
u
s
er i
n
volv
e
m
e
n
t
d
u
r
ing
d
a
ta m
i
g
r
atio
n, th
e
integration test
, and the
user
acceptance test
. Hum
a
n re
source m
a
nagem
e
nt addres
ses lack of system
d
e
sign
and test com
p
etency an
d sy
st
e
m
opt
im
i
zat
i
on.
Table
8.
Use
r
a
cceptance
dela
y factors [15][27][28]
Stage
Acceptance
test d
e
lay factors
PM
Area
Analysis
Lack
of user
invo
lvement
Unclear req
u
irement
Stakeholder
Scope
Design
Lack
of requirem
e
nt definition, Re
quirement change
/add
Poor quality of
design
Scope
Q
u
ality
D
e
velopment
D
e
lay in development and
hardw
a
r
e
installation
Poor quality of
pr
ogram code
Time
Q
u
ality
Integration and sy
stem
test
Requirement cha
nge/add
Unclear criteria o
f
test
Lack
of user
invo
lvement
Scope
Q
u
ality
Stakeholder
System openness
Functional Errors
& Performance
i
ssues
D
e
lay in data migration
Q
u
ality
Stakeholder
Acceptance
Test
Poor quality of
da
ta migra
tion,
Lac
k
of
operation rea
d
iness
Quality
3.3.
Guideline
s
for IT
Serv
ic
e Project Manage
ment Plan
We c
r
eat
e
det
a
i
l
e
d g
u
i
d
el
i
n
es f
o
r
I
T
se
r
v
i
ce
pr
o
j
ect
m
a
nagem
e
nt
pl
ans
acc
or
di
n
g
t
o
se
ver
a
l
k
nowledg
e areas: ti
m
e
, sco
p
e
, qu
ality, an
d
hu
m
a
n
resou
r
ce an
d
stak
eho
l
der m
a
n
a
g
e
m
e
n
t
(see Tab
l
e 9). Each
kn
o
w
l
e
d
g
e are
a
cont
ai
ns se
v
e
ral
i
t
e
m
s
. Tim
e
m
a
nagem
e
nt
i
n
cl
u
d
es
pr
oject
peri
od a
nd m
i
l
e
st
one.
Sco
p
e
m
a
nagem
e
nt
i
n
cl
u
d
es t
a
rget
sy
st
em
confi
g
u
r
at
i
o
n
an
d
de
ta
ils on
wo
rk
per
f
o
r
m
e
d, ha
rd
w
a
re a
n
d
s
o
ft
wa
re lists
t
o
del
i
v
e
r
, c
h
a
nge m
a
nagem
e
nt
cri
t
e
ri
a an
d p
r
oc
ed
ure
s
,
basel
i
n
e sc
hed
u
l
e
f
o
r re
q
u
i
r
e
m
ent
and
desi
gn
, an
d
freezing
sc
hedule for system
cha
n
ges.
Qua
lity
m
a
nagem
e
nt incl
udes m
e
thodol
ogy,
quality obj
ectives a
n
d
assurance
,
use
r
accepta
nce
criteria and
proce
d
ures
, and
project c
o
m
p
le
tion proc
edures. Stake
hol
der
man
a
g
e
m
e
n
t
in
clud
es proj
ect
ex
ecu
tion
organ
i
zatio
n,
u
s
er
ro
les and respon
sib
ilities, and
u
s
er invo
lv
emen
t in
devel
opi
ng
u
s
e
r
re
q
u
i
r
em
ent
s
on
t
i
m
e
.
Evaluation Warning : The document was created with Spire.PDF for Python.
I
S
SN
:
2
088
-87
08
I
J
ECE Vo
l. 5
,
N
o
. 4
,
Au
gu
st 2
015
:
83
2
–
83
9
8
37
Tabl
e
9.
G
u
i
d
e
l
i
n
es f
o
r
IT
ser
v
i
ce p
r
oject
m
a
nagem
e
nt
pl
a
n
[1
1]
[
12]
[
2
0]
[
27]
PM
Areas
Item
R
e
lated to
Acceptance
Test
Guidelines for I
T
Service Pro
j
ect M
a
nagement Plan
Time
Period
Final acceptance
test date
Project p
e
riod mu
st align with co
nt
ract period, cover
i
ng start to end
using the
YY
YYMMD
D format, including the
optimization period.
D
e
tailed
Schedule
Intermediate
acceptance
test date
D
e
tailed proj
ect s
c
hedule must align w
ith
proj
ect per
i
od and milestones
and
w
ith other pr
oj
ect management ar
eas (e.g.,
scope,
quality,
risk).
Scope
Scope of
Project
Scope of
final
acceptance
test
Proj
ect scope must cover entire sys
t
em configuration.
Skilled
specialists should
review configura
ti
ons of business
application, system
including hardwa
re and
software f
o
r project.
Project
Work
Scope of
intermediate
acceptance
test
Proj
ect a
c
tivities need to
detail bas
e
d on
S
O
W
or pr
oposal.
Proj
ect
work
need
to brea
k do
wn
based
on
the WBS guidelin
es.
Assumptions
and co
nstraints of project
work n
e
e
d
to
specify
. Any
changes during
negotiation stage
need to
reflect clearly.
Har
d
war
e
,
Softw
a
re
Solutions
Scope of
acceptance test
for hardware and
softw
a
re solutions
Hard
ware installation schedule an
d
wa
rranty start date need to
w
r
ite
clearly. If custom
ers supply the
har
d
ware
and/or soft
ware solutions, th
e
customer’s role in supply a
nd
delivery schedule
of h
a
rdware
and
software need
to
write clearly.
Q
u
ality
Methodology
D
e
liverables for
acceptance test
Methodologies fo
r development a
n
d
solutions need
to customize
properly.
Outputs
and
deliverables
of each
stage n
e
e
d
tooptimize and
align with user
ac
ceptance tests sch
e
dule.
Q
u
ality
C
r
iteria
C
r
iteria of
acceptance test
Quality criteria of user ac
ceptance
test should be
mea
s
urable and
realistic.
Acceptance
Test
Procedures of
acceptance test
Procedures of
intermediate and fin
a
l user acce
ptanc
e
test need
to
write
cl
ear
l
y
(
e
.g
.,
t
ype,
s
c
hedul
e
,
t
e
s
t
cr
i
t
e
r
i
a)
.
C
o
mpletion
C
r
iteria of final
acceptance test
Completion proce
ss and criteria of
project a
nd syste
m
delivery need
todefine clearly.
Stake
holder
Rol
e
s and
Responsibilitie
s of
Organization
User involvement
Executive a
nd
management
support
R
o
les and responsibili
tiesof clients
an
d
users nee
d
to
define clearly to
develop business
and user
requirements on time. R
o
l
e
s of clients and
users need
to defi
ne for user
acce
ptances test.
Organization ch
arts of pr
oject team
s, including
clients, nee
d
to
include
all of subsystem a
nd functional de
p
a
rtments, including steering
committee and P
M
O. Roles and
re
sponsibilit
ies of e
ach pro
j
ect team
and functional d
e
partments need to
write clearly.
Integra
tion
Change
Scope change
Ob
jectives,
proce
dures, a
nd
criteria
of ch
ange
reques
t
s need to
write
clearly. Change
c
a
tegories and clas
ses
must align
w
ith proj
ect attributes
(e.g., sc
ale, areas).
B
a
seline
Scope baseline
Baseline schedule
of user
requirements and system
d
e
sign need
to
write
clearly.
Freezing
Freezing of
chang
e
Freezing sched
u
le of c
h
ange
reque
sts for As-Is an
d
To-Be
system nee
d
to w
r
ite clearly.
* SOW(
State
m
ent
Of W
o
r
k
)
,
W
B
S(W
o
r
k
Br
eakdown
Str
u
ctur
e)
, PMO(
Pr
oject Managem
e
n
t
Office)
4.
APPLI
CATI
O
N
OF
GUI
D
ELINES F
O
R
IT SER
V
I
C
E
PR
OJE
C
T
M
A
N
A
GE
MEN
T
PLAN
The
ent
e
r
p
ri
se PM
O
(Pr
o
gra
m
M
a
nagem
e
n
t
Of
fi
ce)
su
pp
l
i
es th
e gu
id
eli
n
es and
tem
p
lates of t
h
e
pr
o
j
ect
m
a
nagem
e
nt
pl
an t
o
t
h
e pr
o
j
ect
m
a
nager
,
w
h
o
t
h
en d
r
aft
s
a
versi
on
of t
h
e pl
an ba
sed
on t
h
e
g
u
i
d
e
lin
es and
te
m
p
lates. Th
e proj
ect m
a
n
a
ger th
en
send
s
it
to
th
e en
terpri
se PMO fo
r rev
i
ew. Th
e en
terprise
PMO s
u
gge
sts
changes
or
pas
s
es it along. M
eanwhile, t
h
e
project m
a
nager adjusts th
e d
r
af
t’
s
con
t
e
n
ts
du
r
i
ng
d
i
scu
ssi
on
s
wi
th
clien
t
s.
After they co
m
e
to
a m
u
tu
al ag
ree
m
en
t on
t
h
e
p
l
an
, th
ey
set
a b
a
selin
e
for
it. Th
e
plan’s gui
d
elines nee
d
to sta
n
dardize for
ent
e
rprise-wid
e ap
p
lication
.
Nidu
m
o
lu
(199
6)
notes t
h
at “Inc
reases
in
th
e stand
a
rdizatio
n
were d
i
rectly
asso
ciated
with
d
e
creases in
th
e resid
u
a
l
p
e
rform
a
n
ce risk
wh
ich led
to
increase
in both process
and product
pe
rform
a
nce” [25]. If it lac
k
s st
a
nda
rdized gui
d
elin
es, the
project
m
a
nagem
e
nt
p
l
an’s
ef
fect
i
v
e
n
ess m
a
y
vary
depe
n
d
i
n
g
o
n
t
h
e
project m
a
nager’s c
o
m
p
etence
or expe
rience.
In
addition, c
r
itical conte
n
ts concerni
ng t
h
e user accepta
nce
t
e
st
m
i
ght be missing
or i
n
acc
urate.
Any issues
or
disputes
related t
o
use
r
acceptance m
a
y seriously
affect
the s
u
pplier through delays
in
t
h
e project or paym
ent
sch
e
d
u
l
e. Proj
ect m
a
n
a
g
e
m
e
n
t
p
l
an
sare con
t
racts and b
e
come th
e
b
a
seline fo
r
p
r
oj
ect activ
ities an
d ex
ecu
tio
n.
The
pla
n
serves as
the
refe
rence
for
decision-m
ak
i
n
g
an
d a
ssessm
ent
du
ri
n
g
any
ser
i
ous
di
sp
ut
e
b
e
t
w
een
su
pp
lier
and
bu
yer
.
Th
er
efore,
th
e p
l
an m
u
st b
e
clear, realistic, an
d
d
e
tailed
in
lin
e
with
th
e gu
id
elin
es.
W
e
recom
m
end us
i
ng t
h
e p
r
oced
ure
desc
ri
be
d
bel
o
wt
o a
p
pl
y
t
h
e g
u
i
d
el
i
n
e
s
ent
e
r
p
ri
se-
w
i
d
e t
o
ad
d
r
ess t
h
e ri
s
k
s
of the
use
r
acc
eptance test
(se
e
Figure
3).
Evaluation Warning : The document was created with Spire.PDF for Python.
I
J
ECE
I
S
SN
:
208
8-8
7
0
8
Gui
d
elines Ai
med at
Reduci
ng the
Risks
of
User A
ccept
a
nce Delay
in t
h
e
Context of …
(
S
eu
n
g
Ry
ul
Je
on
g)
83
8
Fi
gu
re 3.
A
p
pl
i
cat
i
on pr
oce
d
u
r
es of
g
u
i
d
el
i
n
e
[
15]
We tried to app
l
y th
e
g
u
i
d
e
lin
e t
o
sev
e
ral
actu
al
p
r
o
j
ec
ts
as
lik
e la
rg
e
-
s
c
ale
n
e
w b
a
nk
ing s
y
s
t
e
m
a
n
d
security system
, and ins
u
ra
nce syste
m
developm
ent proje
c
ts. The
ris
k
s
related with
use
r
acce
ptance te
st can
b
e
weed
ou
t
o
r
lowered
.
In ad
d
ition
,
th
e
p
r
o
j
ect
m
a
n
a
g
e
men
t
team
can
set th
e
b
a
selin
e fo
r
u
s
er
requ
i
r
em
en
t
sp
ecification
on
ti
m
e
an
d
trace an
d
assess the requ
irem
en
t ch
ang
e
s t
o
im
p
act q
u
a
lity o
f
syste
m
, p
r
oj
ect p
e
ri
o
d
,
and c
o
st. M
o
reove
r, t
h
ey m
a
ke additional cont
ract
for
cont
ract am
ount increasi
ng
due t
o
re
quire
m
ents
chan
ges
[
15]
.
5.
CO
NCL
USI
O
N
Most IT se
rvi
ce projects contract
ed t
h
r
o
u
gh t
u
r
n
key
ag
reem
ent
s
, i
n
whi
c
h t
h
e sc
h
e
dul
i
n
g
of t
h
e
middle and
final paym
ents depends
on t
h
e
results
of th
e
user accepta
nc
e test. If the
test delays, the
project
also
delay and cau
se co
st
overru
n
s du
e t
o
th
e add
itio
nal resources required
.
Furth
e
rmo
r
e, th
e bu
yer can
i
m
p
o
s
e a
d
e
lay ch
arg
e
and
clai
m
fo
r an
y
d
a
mag
e
s
du
e to lo
st b
u
sin
e
ss oppo
rt
u
n
ities.
This study s
ought t
o
ide
n
tify
and rem
ove t
h
e
user
accept
a
nce test’s
risk factors that a
ppea
r
during
project planning. W
e
st
udie
d
the obj
ectives
, ite
m
s
, and crit
eria
of the
us
e
r
acce
ptance
te
st and ide
n
tified t
h
e
d
e
lay f
actor
s emer
g
i
ng
in th
e pr
oj
ect
lifecyc
l
e.
W
e
the
n
created a
n
d appl
ied
d
e
tailed guid
e
lin
es for a
proj
ect
managem
e
nt plan of IT se
rvi
ce. The
res
u
lts showe
d
th
at the project
delay factors
in t
h
e
user acce
ptance test
relatin
g
t
o
tight scop
e m
a
n
a
ge
m
e
n
t
, ch
an
ge, qu
ality, h
u
m
an
resou
r
ces, and
stak
eho
l
d
e
rs
were
red
u
c
ed
.
As a
baseline,
for i
n
stance, e
ffective requ
i
r
em
ent
defi
ni
t
i
on a
n
d
t
r
aci
ng
o
f
re
q
u
i
rem
e
nt change can
reduce t
h
e risk
of
sche
d
u
l
e
del
a
y
s
an
d c
o
st
o
v
e
rr
un
s.
These
g
u
i
d
el
i
n
es f
o
r
p
r
oject
m
a
nagem
e
nt
p
l
ans
of
IT
se
rv
i
ce sh
oul
d
hel
p
pr
o
j
ect
m
a
nagers
, PM
Os,
and quality
manage
rs
write and revie
w
t
h
eir plans
to
fa
cilitate ti
mel
y
com
p
letion
of
user acce
ptanc
e
test.
Howev
e
r, th
is
stu
d
y
is limite
d
in
b
e
ing
co
nfin
ed
to
IT se
rvice projects
based
on t
u
rnke
y agreem
ents. These
gui
del
i
n
es
nee
d
t
o
a
p
pl
y
t
o
pr
o
j
ect
s i
n
ot
h
e
r i
n
dust
r
i
e
s, s
u
ch a
s
co
nst
r
u
c
t
i
on a
nd s
h
i
p
bui
l
d
i
n
g
,
a
nd t
h
at
ar
e
base
d
on
di
f
f
er
ent
co
nt
ract
t
y
pes.
REFERE
NC
ES
[1]
Act on Con
t
ra
cts
to whi
c
h
the
sta
t
e
is a
part
y,
Min
i
stry of strategy
and finan
ce, Rep
ublic of Korea
, 2
012.
[2]
K.
B.
L
e
e, e
t
.
a
l
., “A St
udy
on t
h
e
In
flu
e
ncing f
a
ctors on
the Pro
f
it Improveme
nt Rate of
IT Serv
ice Projects”,
The
Korea Society of Manageme
nt In
formation System
”, pp
. 262-286
, 2010.
[3]
B.
Ives, M.
H. Olson,
“USER IN
VOLVEMENT
AND MIS SUC
C
ESS: A REVIEW OF RESEA
RCH”,
Manag
ement
Scien
c
e
, vol. 30
, no. 5, 1984, pp.
586-603.
[4]
O. Zwik
ae
l,
e
t
.
a
l.
,
“
F
rom
Critica
l
Suc
cess Fa
ctors
to Cr
iti
ca
l Suc
cess Proc
esses”,
In
ternational Journal o
f
Production
Research
, vol. 44
, no
. 17
, 2006
, pp
. 3
433-3449.
[5]
D.I. C
l
el
and,
et
al.
,
S
y
s
t
em
s
Analy
s
is
and Project Management,
McGraw Hill
, 198
3.
[6]
R.G. Coop
er, et.al., “Benchmar
k
ing th
e f
i
rm’s cr
itical success
factors
in n
e
w
product d
e
velop
m
ent”,
Journal of
Production
of In
novation
Manag
ement
, vol. 12
, 1
995, pp
. 374-39
1.
[7]
J. Johnson, et
al., “Colla
bo
rating
on project success”,
Software M
agazine
, 2001
.
[8]
P.
W.
Morris,
e
t
.a
l.,
The Ana
t
omy
of Ma
jor Projec
ts,
John W
iley
and Sons
, 1987
.
[9]
J.R.
Turner
, Th
e Handbook
of
Projec
t-based
Management:
I
m
proving the p
r
ocesses for
Achieving
Strateg
i
c
Object
ives
,
McG
r
aw-Hill
, 1999
.
Supply
Guid
elin
es for Writ
ing Pr
oject Manag
e
ment
Pla
n
by
PMO
Writing Project
Mana
gement Plan b
y
Project Manager
Discussing & A
d
justing, Agreement between
Clients
and Project Manag
e
r
Reviewed
b
y
P
M
O
Change R
e
quir
e
d
Pa
ss
Evaluation Warning : The document was created with Spire.PDF for Python.
I
S
SN
:
2
088
-87
08
I
JECE Vo
l. 5
,
N
o
. 4
,
Au
gu
st 2
015
:
83
2
–
83
9
8
39
[10]
J.K. Pinto
,
et
.a
l.,
“
C
riti
ca
l f
a
c
t
ors in
successf
ul proj
ec
t im
pl
em
entat
i
on”
,
I
E
EE Transaction
of
Engineerin
g
Management
, EM-34, 1987, pp.
22-27.
[11]
PMI Standard
Com
m
ittee, A
Guide to
the
Pr
oject Management Bod
y
of
Knowledge 5
th
Edit
ion,
Pr
oj
ec
t
Management Ins
titut
e
, 2013.
[12]
K. S
c
hwalb
e
,
Inf
o
rm
ation T
echn
o
log
y
Project M
a
nagement 7th
,
Course Technology
, 2013
.
[13]
Understanding o
f
IT Service Ind
u
str
y
,
Korea
Information Techn
o
logy S
e
rvice In
dustry Association
, 2013
.
[14]
H.S. Kim, “An I
m
provement
of
SI Contracting
Laws and
Regu
lations in
Korea”,
Korea Society of IT S
e
rvices
, vol. 1,
no. 1
,
2013
, pp
.
29-43.
[15]
Internal Project
Report, “A” IT service Compan
y, 2013
.
[16]
The Standish Gr
oup Report, 201
0,
th
e S
t
andish
Group.
[17]
H. Tar
a
wneh, “A Suggested Th
eoretical Fr
amework for Software Project Success”,
Journal o
f
software Eng
i
neerin
g
and Application
, vol. 4, 2011, pp. 646-651.
[18]
D.B. Khang,
et
.
a
l.
, “
S
ucces
s
Cr
iteri
a an
d F
acto
r
s
for In
terna
tio
nal Deve
lopm
en
t Projec
ts: A li
fe C
y
cl
e Base
d
F
r
am
ework”,
Pr
oject Managem
e
nt Journal
, vo
l.
39, no
. 1
,
2008
,
pp. 72-84
.
[19]
R. Max Wid
e
rman, Project & Program
Risk Management, A g
u
ide
to managi
n
g
project r
i
sks and opportunities
,
Project Manag
ement Institute
, 1
992, p
.
III-3
.
[20]
K.N. Leung Har
e
ton, et.al., “A st
ud
y
of user
acceptance tests”,
So
ftware Quality
Journal v
. 6, pp.
137, 1997
.
[21]
C.
S.
Kl
ei
n, “L
IMS USE
R
ACC
E
PTANCE TES
T
ING”,
Quality Assurance
, vol.
10, 2003
, pp
. 91
-106.
[22]
S.
Y.
Ry
u, S
y
stem Analy
s
is
and Requirement
En
gineer
ing,
Hanti Media
, 2013.
[23]
E. Hull, et.al., R
e
quirements
Eng
i
neer
ing,
Spring
e
r-Verlag, London
, 2002
.
[24]
I. Som
m
e
rville
,
Software Eng
i
ne
ering,
Add
i
son Wesley
, 2006
.
[25]
S.R. Nidumolu, “Standardizatio
n,
r
e
quiremen
t
s uncertainty
an
d so
ftware project
perform
an
ce
”,
Information &
Management
, vo
l. 31
, 1996
, pp
. 1
35-150.
[26]
R. Palan
i
sam
y
,
“Empirically
Testing
the Relationships between
User
Involv
e
ment, Information
Waste, and
MI
S
Success”, Journal of Serv
ices Res
earch
, vo
l. 1, 20
01, pp
. 70-103
.
[27]
W.I. Kwon,
et.al., Practical
Software Testing
Foundation
,
Softwa
r
e Testing
Allian
ces
, 2006
.
[28]
B.
P.
Li
e
n
tz
, et
.a
l.
, Ri
sk Ma
na
geme
nt
for IT
Proje
c
t
s,
BH
, 2006.
BIOGRAP
HI
ES OF
AUTH
ORS
Eun Joo Jeong
is
curr
ent
l
y
a
P
h
.
D.
candid
a
t
e
in
th
e Gradu
a
te Schoo
l of
Business IT at
Kookmin University
, Korea.
He obtained
a B.
S. in
Electr
onics Eng
e
in
eer
ing at Chosun
University
and
an M.A
.
in
MIS at Yonsei Univ
ersity
, Korea. M
r
. J
e
ong h
a
s ov
er 30
y
e
ars
of
industr
y
exp
e
riences
in th
e areas of I
T
Pr
oject Manag
e
ment, IT
Audit, and Contr
a
ct
M
a
nagem
e
nt.
He has
publis
h
e
d
s
e
veral p
a
pers
in
the pro
ceed
ings
and journ
a
ls
inc
l
uding J
ourna
l
of Intern
et Computing
and Services.
Ji Hwan Bae
is
currently
pursu
ing Master’s degree in
the Gr
ad
uate Schoo
l of
Business IT at
Kookmin University
, Korea. He holds a B
.
S.
in Computer Science
from Suwon University
,
Korea.
M
r
. B
a
e’s
res
e
arch
int
e
res
t
s
in
clud
e
Enterpr
i
s
e
Arch
ite
cture
,
Inform
ation
S
y
s
t
em
s
Planning, and
Project Manag
e
ment.
Se
ung Ry
ul Je
ong
is a Professor
in th
e Gradu
a
te
School
of Busin
e
ss IT at Kookmin University
,
Korea. H
e
holds
a B
.
A. in
Econ
omics from So
gang Univers
i
t
y
,
Korea,
an M
.
S
.
in M
I
S
from
Universit
y
of
W
i
sconsin,
and
a
Ph.D.
in
MIS fr
om
the
Universi
t
y
of
South
C
a
r
o
lina
,
U.S.A.
Professor Jeong has published
extensively
in
th
e
informatio
n s
y
stems field
,
with
over 60
publications
in
r
e
fereed
journ
a
ls
like Journal of
MIS, Communications
of
the AC
M, Information
and Manag
e
men
t
, Journal of
S
y
st
ems and Softwar
e
,
among others.
Evaluation Warning : The document was created with Spire.PDF for Python.