Student Publications
Theo Van Stratum
Title: Why is it that Internal Project Management mostly fails
Area:
Country:
Program: Doctorate of Science in Information Technology
Available for Download: Yes
View More Student Publications Click here
Sharing knowledge is a vital component in the growth and advancement of our society in a sustainable and responsible way. Through Open Access, AIU and other leading institutions through out the world are tearing down the barriers to access and use research literature. Our organization is interested in the dissemination of advances in scientific research fundamental to the proper operation of a modern society, in terms of community awareness, empowerment, health and wellness, sustainable development, economic advancement, and optimal functioning of health, education and other vital services. AIU’s mission and vision is consistent with the vision expressed in the Budapest Open Access Initiative and Berlin Declaration on Open Access to Knowledge in the Sciences and Humanities. Do you have something you would like to share, or just a question or comment for the author? If so we would be happy to hear from you, please use the contact form below.
For more information on the AIU's Open Access Initiative, click here.
Acknowledgements
I wish to thank:
Mr. Iain Clark from Albanet Limited for the support he gave me in believing
that I could do this study and in the way he created the opportunity for me to
do this.
Dr. Franklin Valcin for his encouragement and advice during my time with the
Atlantic International University.
Last but not least my wife Maureen van Stratum for the unlimited support
during the time it took me to reach this point.
Inverness, 2 March 2006
Theo van Stratum
Page 1
19/03/2006
Why is it that Internal Project Management mostly fails?
Abstract
This paper discusses the reason why
there is a more likelihood that a
project,
led by an internal project manager,
fails the led by an external project
manager.
This research is done by
interviewing project managers in
software
development, internal and external,
to see if there is a common ground
for this
and if there is a way to follow and
avoid this failing. Although the
research is
done in this area there is enough
evidence to believe that the reasons
found
are similar in other project
management areas.
The paper describes the general
differences between the work
systems,
experience, and methods used by the
two groups of managers.
In general we see that the external
project managers have more
experience,
and with that the authority to
handle projects and their conflicts
in a way that
the project keeps on track. The
internal project manager lacks this
authority
by his colleagues and managers and
they could interfere with the
project in
more then one way and endanger the
project with those actions.
Further is the lack of the use of a
formal method to lead and register
the
project one of the biggest causes of
failure. Things like: User
requirements,
Feature creeping, Change and risk
management are more likely to be in
place
with am external project manager
then an internal project manager.
This is
sometime not even by choice but
forced due to costs. This is
especially the
case within the triangle of
constrain where we see the three
main control
places of a project: Cost, Time, and
Quality. No single person or group
should
be allowed to be in control of all
three of them, but in the case of
internal
project management we see that this
is mostly the case. If there is an
alteration in one of the three
points the project manager must be
allowed to
change the others accordingly and
this is not always done and brings
the
project in danger.
As recommendation we see that proper
training of the internal project
manager in a formal method is a
must, and if this is combined with a
mentor
during the first project, we will
increase the success rate of
internal project
manager drastically.
Theo van Stratum
Page 3
19/03/2006
Why is it that Internal Project Management mostly fails?
This page is intentionally left
blank
Theo van Stratum
Page 4
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 1: General Introduction
In the many projects I have done
over the years I came across a
phenomenon
that gave me the idea for this
research. It appears that projects
that are
carried out by internal project
managers have a higher failing rate
than the
same type of projects led by
external project managers. In a
small
investigation amongst my peers I
came to the conclusion that this
problem is
broader than expected and with and
average failing rate of 65% with
internal
project management or more against
28% with an external project
manager, a
research into this phenomenon seems
appropriate.
Failing rate
80
70
60
e 50
tag
Internal PM
40
cen
External PM
30
erP 20
10
0
Failed
Succesful
Figure 1: Failing percentage
Internal versus External PM.
In figure 1 we see that the failing
percentage of internal project
management
versus external project management
is too high to coincidental. These
figures
are taken over 593 projects, equally
divided over internal and external
project
management, over the last two years
(2004, 2005).
Companies are losing millions per
year due to this phenomenon still, i
t seems
that there is no learning curve
within those companies to stop this
from
happening again and losses are taken
on face-value. This is especially
true
with in organizations that are not
driven by profit like Government and
semi-
Government. As an example we can
take the construction of the
Government
Theo van Stratum
Page 5
19/03/2006
Why is it that Internal Project Management mostly fails?
building in Scotland (Edinburgh),
which went 10 times over it original
budget
and took 2.5 years more then
planned. There where external
project leaders
in place to do the actual work on
the floor but the overall project
management
was done by an internal project
bureau. Although there was an
enquiry, real
action to solve this wasn't taken.
If there is a common approach or
cause, then the knowledge of such
could
prevent project managers to make the
same mistake over and over again and
save the economy millions. The
intension of this research is to
find such a
common cause.
During the research it was necessary
to redefine the common definition of
failing of a project. Amongst the
enquired project managers we noticed
that
the definition about failing a
project was very diverse: from
abandoning a
project to failing to deliver on
time. The definition in this
document about
failing a project is as follows:
"A project appears to be failed
if the outcome of the project is not
within time,
cost, or quality, defined at the
start of the project or after
changes made
through approved change
requests."
The parameters: Time, Cost, and
Quality are parts of the triangle of
Constrain,
which plays, as we will later see,
an important role in project
management.
From this new perspective we can see
that a project can be finished with
the
desired product or service but still
is failed within the definition of
failing. The
project could have cost more, took
longer, or not all the requirements
where
implemented.
Research restrictions
The researched projects were limited
to software development projects
only.
These are the best documented and
traceable in historic events during
implementation. The enquired project
managers were in the range of
Theo van Stratum
Page 6
19/03/2006
Why is it that Internal Project
Management mostly fails?
professional project managers to the
occasional, temporary, project
manager.
The reason for this differentiation
was to get an insight in the
approach of
managing and failing of the
projects.
Theo van Stratum
Page 7
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 2: Definition of the
Investigation
As described in the previous chapter
this research is restricted to the
area of
software development. The problems
encountered are more general and not
restricted too software development
only but the area is take due to the
fact
that the processes used are more
approachable for research purposes.
Areas of project management
Figure 2: Areas of influence
(drawn by author)
In figure 1 we find the areas around
a project that are of influence of
the
outcome of that project.
As Richard Newton (2005) mentioned;
"A Project Manager needs to look
over
the boundaries of his or her
project". What he means by this is:
that beside
the problems a project manager
encounters in his or her project,
there are
external influences that could have
a bigger effect on the outcome of
the
project then at first evaluated.
There are influences were the
project manager,
nor the company, is in control off.
A few of those external influences
are, but
is not exclusive to this list:
External Influences:
- Funding,
- Market demand changes,
- Change of external politics and
values,
- Technology.
Theo van Stratum
Page 8
19/03/2006
Why is it that Internal Project
Management mostly fails?
Funding
In the case of losing external
funding, investors are rejecting
their funding to
the company or project, the project
is doomed to fail unless the company
could raise other funds. The project
manager is not in control of this
but needs
to investigate (as far as this is
known in this point in time), before
starting the
project, if adequate funding is
available and/or reserved for the
project. In
principal it means that an
investigation into the solvency and
cash flow of the
company needs to be done. In the
case of the project managers
interviewed
for this research I found that this
was never done and the
responsibility of the
funding towards the projects was
placed by the responsible directors.
Although this is a sound approach we
must remember that in the case of an
internal project manager this is
very difficult to do as the
directors involved
could be offended and it could be on
influence of the career path of the
persons involved, but on the other
hand we will have the same problem
when
the project fails and the finger is
pointed towards the project manager
as
cause of failing.
Market demand changes
This is happening when the product
or service developed in the project
is
overtaken by new demands and or
developments in the market. Most of
the
time caused by the fact that the
time to market for the product or
service is to
long and competitors have the time
to develop a new, better, product
before
the project is finished. Again not
something the project manager is in
control
off but adequate market monitoring
could indicate early enough that a
demand change is on the merge and
the project manager can react on
this
before the event occurs. Although
market monitoring should be an
active task
for the directors of a company, in
the case of a project of which the
outcome is
to fulfil a market demand the
project manager shares the
responsibility in this.
Theo van Stratum
Page 9
19/03/2006
Why is it that Internal Project
Management mostly fails?
Change of external politics and
values
When Ethical and/or Political values
are changing in a way that it has an
influence on the project outcome
(the product that is developed is
not ethical
or politically correct anymore)
means that the project is obsolete
and needs to
be abandon or changed in a way that
the product or service falls within
the
new legislation or ethical values.
Again monitoring this should be a
company/directors task but a project
manager could be active in this as
well.
Technology
When technologies changes during the
project, and this is especially
valid in
long running projects, a choice
needs to be made if the project is
still valid to
finish or if technologically
adjustments need to be included. As
usual this is a
question of funding and market
demands and should be made by the
directors
of the company. As an example we can
look at the new development of the
operation systems of Microsoft. In
the last few year this is changed
for
development advantages with the new
dot.net Framework. If you are
running
a development project you will face
the question: are we adopting the
dot.net
framework or not. Of course there
will be a lot of parameters included
in this
decision like: how far are we from
completing? What is the cost
involved in
changing: time, training, and so on.
Is it better to finish now on older
technology and adapt to dot.net in a
later version?
All of the external influences are
outside the scope of control of the
project
manager but close monitoring of the
external environment can give clues
early enough for the project manager
to react proactive.
Theo van Stratum
Page 10
19/03/2006
Why is it that Internal Project
Management mostly fails?
Triangle of Constrain
If there is one thing a project
manager should know about
engineering
something then it is the Triangle of
Constrain (see Figure 3)
Figure 3: Triangle of Constrain
Cost is the measure of how
many people, engineers and overhead
like
secretaries and so no, are working
for the project, Time is the
measure of how
long the project has to finish, and
Quality is the measure of how
mane
features (user requirements) and
testing (Quality Control) will be
allowed
within the project scope,
Controlling time, cost, and quality
are all important goals which need
to be
under control but nobody should
be in total control of all three of
them. If the
customer, or manager, arbitrarily
specifies all three corners of the
Triangle of
Constrain, then the project is
doomed to fail. Any change to one of
the corners
must be balanced off by changes in
the other corners. The moral is that
if the
project is to be successful, the
project manager must be permitted to
make
the necessary adjustments to at
least one of the goals.
Theo van Stratum
Page 11
19/03/2006
Why is it that Internal Project
Management mostly fails?
In the 1990s, NASA briefly adopted
the slogan `Faster, cheaper,
better.' This
was followed by a series of
unsuccessful projects and then
they abandoned
the slogan. It is important to
realize that, pushed to the limit,
the `Faster,
cheaper, better' slogan is
impossible to satisfy. It is absurd
a statement as `I
can fly'. There is a saying among
software engineers that corrects
the
statement of NASA's praiseworthy but
impossible goal: `Faster, cheaper,
better: pick two out of three.'
Ownership
Ownership of a project needs to lie
by a director, or somebody from
senior
management, is a must for a project
to succeed. The reason for this is
that it
gives a project status and priority
with in the company from a higher
management perspective. When
resources and funding needs to been
allocated to several projects the
owner is mostly in the position to
make
decisions and could influence that
the projects he owns, is responsible
for, will
get the needed funding.
Company politics / strategy
Company politics are very important
and are tied with company strategy.
They
could influence the future of a
project. If the companies' strategy
is changes it
could mean that project can becoming
obsolete. This doesn't mean that a
project fail in the sense of this
research but as priorities are
changing with
strategy it could mean that projects
are becoming lower in importance and
with that the change of failure
becomes more realistic.
Other projects
As always there are only limited
resources available within a company
and
several projects will compete for
those resources. As explained in the
Triangle
of Constrain: if there is a loss of
resources then alterations need to
be made
in the time and/or quality of the
project. This is a threat in a
running project
especially where a resources is just
lend for a small task to another
project.
Theo van Stratum
Page 12
19/03/2006
Why is it that Internal Project
Management mostly fails?
We must make sure that action is
taken against such activity and to
adjust the
project planning accordingly.
Office politics
This is a grey area within project
management and working for a company
in
general. Office politics is about
power play between colleagues and
can be of
an enormous influence on the
project. If the project manager is
respected and
the project has a high priority
within the company that this
influence will be low
or even be an advantage. But if the
project manager is temporary chosen
from the staff and bad feelings
about this are amongst the
colleagues then
this phenomenon could be the cause
of failure on its own.
All the above described `external'
influences on projects are mostly
not in the
power-reach of the project manager
and are difficult to manage, but if
the
project manager wants to finish his
project successfully then monitoring
of
those external influences is a
necessity at all times.
Theo van Stratum
Page 13
19/03/2006
Why is it that Internal Project
Management mostly fails?
Internal Project influences
The following issues in project
management are common and everybody
is
taking them on face-value, but a lot
of projects are failing just because
of that.
Keep in mind that according to the
interviewed project managers most of
the
problems within the project are
forced and with that not in their
own control
anymore.
Project definition
Although very logical, you must have
a project definition (a goal) you
are
working towards; it seems that this
is a mostly forgotten or
underestimated
part of the project. In the
questionnaire, which we will discus
in the next
chapter, we had a few questions
about Project definitions and user
requirements and we saw that in the
case of a project definition only
25% of
internal projects had one. This
means that in 75% of the internal
projects the
teams didn't really know what they
where making! In the case of
software
projects we see that the common line
from management is: "You know what I
want, don't you?"
As V.A. Vyssotsky (The Mythical
Man-Month (2004) pp 142), of Bell
Telephone Laboratories' Safeguard
Project says, "The crucial task is
to get
the product defined. Many, many
failures concern exactly those
aspects that
were never quite specified"
User requirements
As the project definition gives us a
general frame work of what the
customer
wants, the user requirements should
be very specific and non-ambiguous.
It
tells us what it is that the outcome
of the project should have or not
have. If
we take a software building project
then the user requirements should
tell us
exactly the business-rules for the
product. Appropriate time should set
aside
in the project planning to get all
the user requirements on paper.
Although we
must be aware that in very long
running projects it is not always
the right way
to go by defining all the user
requirements as an initial step. We
have seen in
the paragraph above that projects
are chancing over time and with that
the
Theo van Stratum
Page 14
19/03/2006
Why is it that Internal Project
Management mostly fails?
user requirements. We will see later
in the document how we can handle
this
in an appropriate way.
Feature creeping
Feature creeping is one of the
biggest causes of project failure,
in the
research done we saw that more then
95% of projects are suffering from
this.
A feature if nothing more then an
enhancement of the final product, it
can go
from a nice to have till a must have
and every project manager has to
deal
with them. They are un-avoidable in
real-life. It is only the way they
are dealt
with. If we are looking at the
triangle of constrain we that on the
right lower
corner we have quality as a measure
point. Qualities are the features in
a
product so according to the triangle
of constrain if we add features then
we
must accordingly alter one or all of
the other measure points, time and
costs.
With in feature creeping this is
normally not done. Under the saying:
"O, this is
only a small thing to adjust or to
add" a feature is added to the
project and the
project start to run out of cost and
or time before we know it.
Quality Control
Quality control is where the quality
of the project and product is
monitored. It
ensures us that all the user
requirements are implemented and
tested that
they work in the way it is described
in the requirements. This begins
long
before we are even starting to build
anything. As Brooks mentioned
(2004):
"Specifications, user requirements,
need to be tested on their
completeness
and clarity." and needs to be
handled by an outside testing group.
This is
especially true in software
engineering projects, as Vyssotsky
says; the
developers themselves cannot do
this: "They won't tell you they
don't
understand it; they will happily
invent their way through the gaps
and
obscurities".
Theo van Stratum
Page 15
19/03/2006
Why is it that Internal Project
Management mostly fails?
Project management methodology
There are several approaches that
can be taken to project management,
including phased, incremental, and
iterative approaches.
The "traditional" approach
identifies a sequence of steps to be
completed.
This contrasts with the agile
software development approach in
which the
project is seen as relatively small
tasks rather than a complete
process. The
objective of this approach is to
impose as little overhead as
possible in the
form of rationale, justification,
documentation, reporting, meetings,
and
permission. This approach may also
be called the "spiral" approach,
since
completion of one of the small tasks
leads to the beginning of the next.
Advanced approaches to agile project
management, applicable not only to
software development but to any
area, utilize the principles of
human
interaction management to deal with
the complexities of human
collaboration.
Technology switching
Technology switching during a
project is expensive and a dangerous
thing to
do. We see this type of actions
mostly in software projects where
designers,
programmers, and so on come across a
new language (like C# in the last
years) and start to redesign the
project in such a new language. Of
course
this is deadly from a project
management point of view, although
it is not
always possible to avoid this.
Especially in the case of Company
politic to
always follows the latest
technology.
All the subjects that are described
above are points of failure when not
proper
handled or monitored according to
the interviewed project managers
during
the research.
Theo van Stratum
Page 16
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 3: Dynamics of the
anticipated Solution
The goal and Objective of this
research
As described in the question of this
research: "Why is it that Internal
Project
Management mostly fails" I try to
find the reasons behind the
phenomenon
that over 65% of projects that are
led by internal project managers
fail. If there
is a specific reason for this then
knowledge about this can lead to a
solution or
methodology to increase the success
rate of future projects.
The questions that came up where:
- Is this happening due to
inexperience in project management?
- Is it more likely to happen in
projects that are in an unknown area
for
the project manager?
- Which methodology is used, if any?
- Is it market specific, in other
words: is it specific to a type of
project?
(software engineering, design and so
on)
In general literature about project
management we find everything about
methodology and techniques, how to
report and on what, but what they
don't
try to teach is the fact that
project management in the first
place is "managing
of people". When I was researching
this and interviewing project
managers
about the way they work and what
they were thinking the failure was,
then all
the points from chapter 2 where
mentioned but nobody was talking
about the
people behind this failure points.
Because of this and my feeling that
one of
the most difficult task a project
manager has is the human
interaction, if it is
the man on the work floor or the
director in the boardroom, the
project
manager must communicate on their
level but not only that, he must
also
translate between those levels to
make sure that they understand each
other.
Which brings me to the second goal
of this research; "Is communication
the
biggest point of failure within
project management?"
Theo van Stratum
Page 17
19/03/2006
Why is it that Internal Project
Management mostly fails?
Methodology used
For the main part of information
gathering I used quantitative
research via a
questionnaire. The reason for this
type of data gathering is that is
cheaper
and not that labour intensive. The
questionnaire was email based and
sent to
over 500 project managers over the
world. Because the questionnaire was
on
personal application the response
rate was very high, 76% of the
questionnaires sent, returned. As
said before the projects in this
research
came all from software engineering.
It is however my strongest believe
that
the results will be the same in
every other form of project
management due to
the fact that people will find the
same problems and solutions
everywhere.
Questionnaire
The questionnaire was built in 4
groups of questions:
1. Experience
a. Years in project management,
b. Professional certification,
c. Number of projects done,
i. How many successful,
ii. How many failed,
iii. How many abandon,
2. Methodology normally used,
a. Which one, if any
i. Officially trained in it,
ii. Waterfall method
iii. Agile method
b. If any followed completely,
c. If any, was it helpful,
d. How much time spend in following
the rules
e. If not, why,
f. Was risk management in place,
g. Was change management in place,
3. Projects
Theo van Stratum
Page 18
19/03/2006
Why is it that Internal Project
Management mostly fails?
a. How many External
i. On average:
1. Project budget
2. Number of resources
3. Estimated project time
b. How many Internal
i. On average:
1. Project budget
2. Number of resources
3. Estimated project time
c. Success rate External
d. Success rate Internal
e. Looking at the failed projects,
if any, what would be the area of
failing,
i. Time (project took longer then
estimated,
ii. Cost (project was more expensive
then estimated)
iii. Quality (not all the user
requirements where
implemented),
f. What was, according to you, the
main cause of failing (average
over the failed projects),
g. Do you have an exit plan in
place?
h. Do you hold post-mortem sessions?
i. Where users constantly involved.
j. How much time was taken for
testing, in percent of total project
time,
After the questionnaire 20 project
managers where selected, to get a
broad
range as possible, for personal
interviews to get a deeper
understanding on
the success and failing rate in this
area. The selection criteria for
those project
managers was that they all had to
have done internal and external
projects
whilst one half of the group needed
to have more failures in the
internal
projects and the other half needed
to be more successful overall.
Theo van Stratum
Page 19
19/03/2006
Why is it that Internal Project
Management mostly fails?
Interviews
The interviews where done in person,
over the phone, or by direct
internet
communication (chatting). All the
questions where open ended and none
of
the project managers where given the
questions in advance. Because of
this
we ended in most case in an open
discussion. This gave me a good
inside in
the way project managers are
thinking. I found in general that
first time project
managers are optimists and believe
in a happy ending.
Theo van Stratum
Page 20
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 4: Overall Outcomes
From the 500 questionnaires sent,
382 where returned which gives a
return
percentage of 76.4%. In total 593
projects where taken by those
project
managers in a time period of 2
years.
Years in project management
years in project management
9+
0 - 3
4 - 8
Figure 4: Years in Project
management
On the question: "How many years
experience of project management do
you
have we see that the division
between the group form 0 3 and 4
8 is
equal, respectively: 176 and 179,
whilst only a small group (27) has
more then
8 years of experience. The group
from 0 3 years of experience was
asked
the question if this was their first
project and 83 answered positive on
this
(46.36%).
Only 13.35%, 51, of the project
managers had a professional, all
PRINCE II,
certificate and from those 51
managers none of them was in the 0
3
experience group.
Theo van Stratum
Page 21
19/03/2006
Why is it that Internal Project
Management mostly fails?
Number of project done in the
last 2 years
Number of projects done
9+
31
4 - 8
0 - 3
248
314
Figure 5: Number of projects
On the question how many projects
are done in the last two years we
see that
in the experience group 0 3 the
most projects are done, 176 project
managers did 314 projects, This is
1.8 project per project manager,
whilst with
the more experienced project
managers this is lower, 1.4 in the
group 4 8
years, and 1.1 in the 9+ group.
On the sub-question: How many
projects do you run at the same
time? We
see that in the group with the less
experience the most projects are
done in
the same time or overlapping. With
the average of 2, whilst in the
group with
the highest experience all of the
project managers are doing only 1
project at
the time.
Theo van Stratum
Page 22
19/03/2006
Why is it that Internal Project
Management mostly fails?
On the question: "How many were
successful, according to this
research
success definition?"
Number of projects successful
9+
29
0 - 3
43
4 - 8
89
Figure 6: Projects successful
In the group 0 3 we see that only
13.7% of the projects done are
successful,
that is: within time, costs, and
quality expected. The group 4 8 is
slightly
better: 35.9%, whilst in the 9+
group 93.5% of the projects were
successful.
In total only 27.2% of the projects
were successful if measured again
the
research parameters, which is
worrying for the quality of project
management
in software engineering.
Theo van Stratum
Page 23
19/03/2006
Why is it that Internal Project
Management mostly fails?
Methodology used
200
180
160
140
120
Project managers
100
Methodology used
80
Officially trained
60
40
20
0
0 - 3
4 - 8
9+
Figure 7: Methodology used
On the question if a methodology is
used we see that the more experience
a
project manager has the more a
project methodology is used and
officially
trained in the method.
On the question which methodology
the answer was consistently PRINCE
II,
which is not surprising in software
engineering where PRINCE II is the
main
methodology. Within project
management we see that the agile
project
management method is rising but when
the question about this was asked we
saw that only 7% was using this, not
including the project managers that
where not using a methodology and
the rest, 93%, uses still a form of
waterfall method.
On the question if the method was
followed completely through none of
the
project managers did this and all
were using some form of adjustment
in the
workflow. Most of the ones that
where using a method found this
useful and
giving them peace of mind.
The project managers that didn't
follow an official methodology were
asked
why did was and 87% didn't know how
to but would be willing to learn
whilst
the other 13% did saw the need in
them due to the fact that their
projects
Theo van Stratum
Page 24
19/03/2006
Why is it that Internal Project
Management mostly fails?
where very small and they thought
that the hustle in maintaining the
documentation around the projects
would be too costly in time.
In the case of risk management, what
are the risks in the project that
could be
the cause for failing, we see that
only 45% of the project managers
actively
looks at the risks and register them
against the task involved. The idea
of risk
management is that contingency plans
are developed in the case the event
occurs.
Change management was in place in
over 55% of the projects.
Divided over the experience groups
give us the following overview
Change Management per experience
group
350
300
ects 250
roj 200
P
Project done
150
Change management
er ofb 100
um
50
N
0
0 - 3
4 - 8
9+
Years Experience
Figure 8: Change Management
Theo van Stratum
Page 25
19/03/2006
Why is it that Internal Project
Management mostly fails?
Projects
Ex versus Internal projects per
experience group
350
300
ects 250
roj
Projects done
200
P
External projects
150
er of
Internal projects
b 100
um
50
N
0
0 - 3
4 - 8
9+
Years Experience
Figure 9: External versus
Internal Projects
On the question how many external
versus internal projects are done
with in
the experience group we see that
there are more internal project done
by the
less experience groups than the
higher experienced ones. 60% in 0
3
group, 39% in the 4 8 group, and
only 13% in 9+ group.
The average project budget was
Table 1: Project Budgets
Experience group
Internal Projects
External Projects
0 3
$ 5.000 - $ 12.500
$ 10.000 - $ 26.000
4 8
$ 4.500 - $ 23.500
$ 17.000 - $ 150.000
9+
$ 8.000 - $ 50.000
$ 25.000 - $ 1.250.000
The budgets are recalculated to
dollars
The average number of resources in
projects
Table 2: Number of Resources
Experience group
Internal Projects
External Projects
0 3
3 5
3 5
4 8
2 7
5 12
9+
2 8
8 25
Theo van Stratum
Page 26
19/03/2006
Why is it that Internal Project
Management mostly fails?
The average project time (elapse
time)
Table 3: Project time
Experience group
Internal Projects
External Projects
0 3
13 15 weeks
12 14 weeks
4 8
12 17 weeks
13 20 weeks
9+
13 30 weeks
17 50 weeks
On the question: "Looking at the
failed projects, what would be the
area of
failing?" This question is very
subjective and the interviewed
project manager
could give more then one answer. The
idea behind the question was to get
a
feeling of what the project manager
him self though what the biggest
problem
was. The figures are in percentage
average over the projects
Table 4: Cause of failing
Experience group
Time
Cost
Quality
0 3
75%
95%
35%
4 8
87%
81%
40%
9+
56% 25% 10%
Exit plan
An exit plan is planning for
failure. If we are thinking of
project management
then most project managers are
thinking of success but if we see
the failing
rate then we should think about
failure as well. What are we going
do to if the
project fails, and need to be
abandoned? This is described in an
"exit plan".
When the question was asked only 1
project manager had used an exit
plan.
Post Mortem Sessions
To learn from previous projects it
is always good to have a post mortem
session after finishing a project,
if it was a success or failure you
can learn
from it and repeat the good things
and try to avoid the bad ones. From
the
project managers interviewed none
had used a post mortem at all. The
main
argument was that there was no time
and budget reserved for this.
Theo van Stratum
Page 27
19/03/2006
Why is it that Internal Project
Management mostly fails?
Involving Users
This was to see if users are
actively involved in the project.
The effect of
involving users can be good, if the
project manager handles this
correct. In
the agile project and development
methods it is common that the users
are
part of the project team. This way
they can make sure that the customer
gets
what he has paid for.
Only 36% of the projects done had a
close relationship with their users
and
this was the same in all the
experience groups.
Testing
Due to the fact that the project
managers interviewed came out of the
software development area we had a
question about testing, which is in
every
software development project a hot
item. On the question: "How much
time
was taken for testing, in percent of
the total project time" we got the
following
figures:
Table 5: Testing time
Experience group
internal
external
0 3
5%
7%
4 8
12%
17%
9+ 8%
21%
.
The interviews were more to get a
global overview about how a project
manager thinks when working on his
project. There are not direct
measurable
figure but the outcome from those
interviews are incorporated into the
analysis of this research.
Theo van Stratum
Page 28
19/03/2006
Why is it that Internal Project
Management mostly fails?
Elapse Time versus Working
Time
A common problem within project
management is the difference between
working time, man-days, and elapse
time, project time. The problem is
that
when project managers estimate the
task project times they take a
man-day
for an eight-hour working day and
this is unrealistic. Nobody is
working 100%
of its time per day. For my own
projects I did an investigation into
this and
used my own group of programmers to
write their time down, for a period
of 8
weeks, in everything they did. We
came to the conclusion that the
disturbance
of telephone, meetings, questions,
getting and drinking tea and coffee,
and
having sanitary stops is taking a
lot of time away from the working
hours.
Average over the group and
eight-weeks we saw that between 60
and 75%
effective working time was left for
planning. What does this means in
planning? When the project times are
estimated we must first calculate
the
man-days (man-hours) and value them
at the percentage we take for
effective
programming time for that
programmer, this can be different
for each of the
programmers involved, and then
recalculate them for project elapse
time. If
we say that a task cost 10 hours and
we have an effeteness of 70% then
the
elapse time for that task is 14
hours.
Theo van Stratum
Page 29
19/03/2006
Why is it that Internal Project
Management mostly fails?
This page is intentionally left
blank
Theo van Stratum
Page 30
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 5: Analysis
Experience
Although I couldn't find a lot of
project managers with 9+ years of
project
management experience we can see
that the success of bringing a
project to
a successful end is related to
experience,
success rate in % versus
experience in years
100.00
90.00
80.00
70.00
60.00
50.00
success rate in %
40.00
30.00
20.00
10.00
0.00
0 - 3
4 - 8
9+
Figure 10: Success rate versus
experience
We see that the project managers
with more experience are using a
methodology to manage their projects
in a structured way. In the
interviews
with the project managers it was
clear that when they had an official
training in
a method the chance in success was
higher. What was clear however, was
that when a method was used within
several projects, the manager was
changing the way the method was used
from a rigid following towards a
"use
what you need approach". The latter
was according to the managers more
useful. With the implementation of a
methodology we see the
implementation
of two techniques, which are a must
for successful project management.
Theo van Stratum
Page 31
19/03/2006
Why is it that Internal Project
Management mostly fails?
Risk Management
Generally, Risk Management is the
process of measuring, or assessing
risk
and then developing strategies to
manage the risk. In general, the
strategies
employed include transferring the
risk to another party, avoiding the
risk,
reducing the negative effect of the
risk, and accepting some or all of
the
consequences of a particular risk.
Traditional risk management, which
is
discussed here, focuses on risks
stemming from physical or legal
causes (e.g.
natural disasters or fires,
accidents, death, and lawsuits).
Financial risk
management, on the other hand,
focuses on risks that can be managed
using
traded financial instruments.
Regardless of the type of risk
management, all
large corporations have risk
management teams
Risk management versus Experience
80%
70%
60%
50%
40%
Risk management
30%
20%
10%
0%
0 - 3
4 - 8
9+
Figure 11: Risk Management versus
Experience
As we can see in figure 11, the
implementation of risk management
follows
the same line as in the
implementation of a project
management methodology
although there is a steeper line
after the 4 8 years experience
which let us
to believe that the insight in the
risks of a project and the need to
manage
them in a structured way come with
more experience over the years. What
was disappointed however is that
even with the most experienced of
the
interviewed project managers not all
of them saw the need to implement.
Theo van Stratum
Page 32
19/03/2006
Why is it that Internal Project
Management mostly fails?
Limitations of risk management
If risks are improperly assessed and
prioritised, time can be wasted in
dealing
with risk of losses that are not
likely to occur. Spending too much
time
assessing and managing unlikely
risks can divert resources that
could be
used more profitably. Unlikely
events do occur, but if the risk is
unlikely
enough to occur, it may be better to
simply retain the risk, and deal
with the
result if the risk does in fact
occur.
Prioritizing too highly the Risk
management processes itself, could
potentially
keep an organization from ever
completing a project or even getting
started.
This is especially true if other
work is suspended until the risk
management
process is considered complete.
Change Management
One of the biggest challenges of
project management is how to cope
with
feature creeping. Feature creeping
is the phenomenon that feature,
quality, is
added to the project without
adjusting the resources and/or time
components
of the triangle of constrain, see
figure 3.
The rules of the triangle of
constrain tells us that if we alter
one of the corners;
costs, quality, and time, we must
alter at least one of the other
corners to
compensate for the change.
Change management versus
experience
120%
100%
80%
60%
Change management
40%
20%
0%
0 - 3
4 - 8
9+
Figure 12: Change management
versus experience
Theo van Stratum
Page 33
19/03/2006
Why is it that Internal Project
Management mostly fails?
In figure 12 we see that the curve
of the implementation of change
management versus experience is the
opposite of the curve of
implementation of risk management.
The reason for this is clear in the
sense that added features have a
direct
noticeable effect of the project
progress and the need to protect the
project
team is high. Although in internal,
and in someway external, project
management we see that feature
creeping is done in a subtle way
like, "this
will only take a few minutes", or
"adding this will gives us time
later
because....". Most of the time this
is done by the sales team with the
backup
of directors and the project manager
is forced into a move that can cause
the
project to fail. The rules of the
Triangle of constrains are not
followed and that
is always a bad thing.
Estimating and Scheduling
In the interviews came across that
the estimating of cost and time
necessary
for the project on hands is not
always strait forward. Especially
beginning
project managers have problems with
this. In general estimating how much
time a task will cost is based on
historical data, previous projects
done. For
the beginning project manager, this
is not available other then projects
done
by other project managers. This
means that he must rely on the
assumed
correctness of this data. Another
way is doing the estimate is to take
mathematical models as described
below.
In the book "The Mythical
Man-Month", Brooks describes the
problem of the
man-month. The time unit used to
estimate effort versus time used.
Brooks
mentioned: "Cost varies as the
product of the number of men and the
number
of months. Progress does not." It is
very dangerous to use a man month
(week or day) to measure the task on
hand. It implies that men and months
are interchangeable. This is only
true if the task can be partitioned
amongst
many workers with no communication
amongst them. This is true of
picking
strawberries or cotton; but in any
task where communication between the
Theo van Stratum
Page 34
19/03/2006
Why is it that Internal Project
Management mostly fails?
team members is a necessity this
fails. When a task cannot be
partitioned
because of sequential constrains,
and then adding more men has no
effect on
the schedule. In software
engineering this is common due to
the sequential
nature of debugging.
In tasks that can be partitioned but
which require communication amongst
the
subtasks, the effort of
communication must be added to the
amount of work to
be done. Therefore the best that can
be done is somewhat poorer then a
trade of men for months.
Intercommunication
Intercommunication between team
members increase the effort needed
to
complete the task. If each part of
the task must be separately
coordinated with
each other, the effort increases
with n(n-1)/2. Three workers require
three
times as much pair-wise
intercommunication as two; four
requires six times as
two. If, moreover, there need to be
conferences among three, four, etc.
workers to resolve things jointly,
matters get worse yet.
Algorithmic cost modelling
The most systematic, although not
necessarily the most accurate,
approach to
calculate the estimate in man-months
in software engineering is
algorithmic
cost estimation. An algorithmic cost
model can be built by analysing the
costs
and attributes of successful
completed projects. A mathematical
formula is
used to predict costs based on
estimates of projects size, number
of
programmers and other process and
project factors. In its most general
form,
an algorithmic cost estimate for
software cost can be expressed as:
Effort = A x Sizeb x M
A is a constant factor which depend
on local organisational practices
and the
type of software that is developed,
Size may be either an assessment of
the
code size of the software or a
functionality estimate expressed in
function or
Theo van Stratum
Page 35
19/03/2006
Why is it that Internal Project
Management mostly fails?
object points. The value of exponent
B usually lies between 1.0 and 1.5.
It
reflects the disproportionate effort
required for large projects. M is
the
multiplier made up by combining
different process, product and
development
attributes.
All algorithmic models suffer from
the same basic difficulties:
- It is often difficult to estimate
Size at an early stage in a project
where
only a specification is available.
Function point and Object point
estimate are easier to produce than
estimates of code but may still be
inaccurate.
- The estimates of the factors
contributing to B and M are
subjective.
Estimates vary from one person to
another depending on their
background and experience.
The number of line of source code in
the finished system is the basic
metric
used in most algorithmic cost
models.
There are a number of algorithmic
models that have been proposed as a
basic for estimating the effort,
schedule and costs of a software
project. These
are conceptually similar but use
different parameter values.
COCOMO Model
COCOMO is a model designed by Barry
Boehm to give an estimate of the
number of programmer-months it will
take to develop a software product.
This "COnstructive COst MOdel" is
based on a study of about sixty
projects at
TRW, a Californian automotive and IT
company, acquired by Northrop
Grumman in late 2002. The programmes
examined ranged in size from 2000
to 100,000 lines of code, and
programming languages used ranged
from
assembly to PL/I.
COCOMO consists of a hierarchy of
three increasingly detailed and
accurate
forms.
Theo van Stratum
Page 36
19/03/2006
Why is it that Internal Project
Management mostly fails?
- Basic COCOMO - is a static
single-valued model that computes
software development effort (and
cost) as a function of program size
expressed in estimated lines of
code.
- Intermediate COCOMO - computes
software development effort as
function of program size and a set
of "cost drivers" that include
subjective assessment of product,
hardware, personnel and project
attributes.
- Advanced COCOMO - incorporates all
characteristics of the
intermediate version with an
assessment of the cost driver's
impact on
each step (analysis, design, etc.)
of the software engineering process.
One of the most important
observations in the model is that
personnel
motivation overwhelms all other
parameters. This would suggest that
leadership and team man ship are the
most important skills of all, but
this
point was largely ignored.
Researchers would rather create
tools.
Personnel motivation is not part of
the model. The single most important
driver is software complexity,
followed by personnel attributes
(capability and
experience, not motivation).
Methodology
In the research we saw that the more
experience a project manager is the
incline to use a project management
methodology. This is, however, less
in
internal projects. From the
interview we can deduct that by
pressure from
management there is mostly no time
taken for implementation of the
formal
method. The deadlines are set before
the project description is written.
Project description and Goal
No project manager should start a
project without a proper project
description,
we would say that this is obvious
but during the interviews it became
clear
that most of the less experienced
project managers had problems to get
a
proper description of what to build
from the customer. Especially in the
case
of internal projects we see that
statements like: "we want to monitor
servers
Theo van Stratum
Page 37
19/03/2006
Why is it that Internal Project
Management mostly fails?
on the network, you know what I
mean" as starting point for a
project are
common. Those statements are then
normally followed with; "how long do
you
think it will take?" expecting to
get a deadline for this project. The
biggest
problem the project manager faces is
that management is expecting that he
comes with a real estimate for this
project but realistically he cannot
even start
the user requirements gathering
because of no goal at all.
Christopher
Duncan describes in his book "The
Career Programmer! (2002) how a
beginner in project management can
deal with this behaviour, and I feel
that it
is a must to read if you are coming
from a programmer's career into
project
management.
The first thing a project manager
should do if faced with this problem
is buy
himself some time to write a project
description as he understand it and
use
this as a project proposal. In
reality he is leading the project as
project owner.
This project proposal is presented
to management and on which they have
to
sign-off. The document will go
through a number of iterations
before
everybody agree on the content and
the time that is put in to this is
not lost,
although management will think this,
but time invested in this will pay
itself
back. If consensus about the project
description is reach the project
manager
needs to make a choice in project
method; waterfall or agile.
Waterfall method
In the research we saw that the
waterfall method is still the most
used, but is it
the best for the project underhand?
In his 1970 paper, Royce proposed
what is now popularly referred to as
the
waterfall model as an initial
concept, a model which he argued was
flawed.
His paper then explored how the
initial model could be developed
into an
iterative model, with feedback from
each phase influencing previous
phases,
similar to many methods used widely
and highly regarded by many today.
Ironically, it is only the initial
model that received notice; his own
criticism of
this initial model has been largely
ignored. The "waterfall model"
quickly came
to refer not to Royce's final,
iterative design, but rather to his
purely
Theo van Stratum
Page 38
19/03/2006
Why is it that Internal Project
Management mostly fails?
sequentially ordered model. This
paper will use this popular meaning
of the
phrase waterfall model.
Despite Royce's intentions for the
waterfall model to be modified into
an
iterative model, use of the
"waterfall model" as a purely
sequential process is
still popular, and, for some, the
phrase "waterfall model" has since
come to
refer to any approach to software
creation which is seen as inflexible
and non-
iterative. Those who use the phrase
waterfall model as a general insult
for
non-iterative models that they
dislike usually see the waterfall
model itself as
naive and unsuitable for a "real
world" process.
Usage of the waterfall model
Figure 13: Waterfall method
The unmodified "waterfall model".
Progress flows from the top to the
bottom,
like a waterfall. In Royce's
original waterfall model, the
following phases are
followed perfectly in order:
- Requirements specification
- Design
- Construction (aka: implementation
or coding)
- Integration
- Testing and debugging (aka:
verification)
- Installation
- Maintenance
Theo van Stratum
Page 39
19/03/2006
Why is it that Internal Project
Management mostly fails?
To follow the waterfall model, one
proceeds from one phase to the next
in a
purely sequential manner. For
example, one first completes
"requirements
specification" -- they set in stone
the requirements of the software.
When
and only when the requirements are
fully completed, one proceeds to
design.
The software in question is designed
and a "blueprint" is drawn for
implementers (coders) to follow --
this design should be a plan for
implementing the requirements given.
When and only when the design is
fully
completed, an implementation of that
design is made by coders. Towards
the
later stages of this implementation
phase, disparate software components
produced by different teams are
integrated. After the implementation
and
integration phases are complete, the
software product is tested and
debugged; any faults introduced in
earlier phases are removed here.
Then the
software product is installed, and
later maintained to introduce new
functionality and remove bugs.
Thus the waterfall model maintains
that one should move to a phase only
when it's preceding phase is
completed and perfected. Phases of
development in the waterfall model
are thus discrete, and there is no
jumping
back and forth or overlap between
them.
However, there are various
modified waterfall models (including
Royce's final
model) that may include slight or
major variations upon this process.
Arguments for the waterfall model
Time spent early on in software
production can lead to greater
economy later
on in the software lifecycle; that
is, it has been shown many times
that a bug
found in the early stages of the
production lifecycle (such as
requirements
specification or design) is more
economical (cheaper in terms of
money, effort
and time) to fix than the same bug
found later on in the process. This
should
be obvious to some people; if a
program design is impossible to
implement, it
is easier to fix the design at the
design stage then to realize months
down the
track when program components are
being integrated that all the work
done
so far has to be scrapped because of
a broken design.
Theo van Stratum
Page 40
19/03/2006
Why is it that Internal Project
Management mostly fails?
This is the central idea behind Big
Design Up Front (BDUF) and the
waterfall
model - time spent early on making
sure that requirements and design
are
absolutely correct is very useful in
economic terms (it will save you
much time
and effort later). Thus, the
thinking of those who follow the
waterfall process
goes, one should make sure that each
phase is 100% complete and
absolutely correct before proceeding
to the next phase of program
creation.
Program requirements should be set
in stone before design is started
(otherwise work put into a design
based on "incorrect" requirements is
wasted); the programs design should
be perfect before people begin work
on
implementing the design (otherwise
they are implementing the "wrong"
design
and their work is wasted), etcetera.
A further argument for the waterfall
model is that it places emphasis on
documentation (such as requirements
documents and design documents) as
well as source code. More "agile"
methodologies can de-emphasize
documentation in favor of producing
working code - documentation however
can be useful as a "partial
deliverable" should a project not
run far enough to
produce any substantial amounts of
source code (allowing the project to
be
resumed at a later date). An
argument against agile development
methods,
and thus partly in favor of the
waterfall model, is that in agile
methods project
knowledge is stored mentally by team
members. Should team members
leave, this knowledge is lost, and
substantial loss of project
knowledge may
be difficult for a project to
recover from. Should a fully working
design
document be present (as is the
intent of Big Design Up Front and
the waterfall
model) new team members or even
entirely new teams should
theoretically be
able to bring themselves "up to
speed" by reading the documents
themselves.
However it should be noted that
agile methods do attempt to
compensate for
this: for example, extreme
programming (XP) advises that
project team
members should be "rotated" through
sections of work in order to
familiarize
all members with all sections of the
project (allowing individual members
to
leave without carrying important
knowledge with them).
Theo van Stratum
Page 41
19/03/2006
Why is it that Internal Project
Management mostly fails?
As well as the above, some prefer
the waterfall model for its simple
and
arguably more disciplined approach.
Rather than what the waterfall
adherent
sees as "chaos" the waterfall model
provides a structured approach; the
model itself progresses linearly
through discrete, easily
understandable and
explainable "phases" and is thus
easy to understand; it also provides
easily
mark-able "milestones" in the
development process. It is perhaps
for this
reason that the waterfall model is
used as a beginning example of a
development model in many software
engineering texts and courses.
It is argued that the waterfall
model and Big Design Up Front in
general can
be suited to software projects which
are stable (especially with
unchanging
requirements) and where it is
possible and likely that designers
will be able to
fully predict problem areas of the
system and produce a correct
design before
implementation is started. The
waterfall model also requires that
implementers follow the well made,
complete design accurately, ensuring
that
the integration of the system
proceeds smoothly.
The waterfall model is widely used,
including by such large software
development houses as those employed
by the US air force, the US
Department of Defense and NASA, and
upon many large government projects
Steve McConnell sees the two big
advantages of the pure waterfall
model as
producing a "highly reliable system"
and one with a "large growth
envelope",
but rates it as poor on all other
fronts. On the other hand, he views
any of
several modified waterfall models
(described below) as preserving
these
advantages while also rating as
"fair to excellent" on "working with
poorly
understood requirements" or "poorly
understood architecture" and
"providing
management with progress
visibility", and rating as "fair" on
"managing risks",
being able to "be constrained to a
predefined schedule", "allowing for
midcourse corrections", and
"providing customer with progress
visibility". The
only criterion on which he rates a
modified waterfall as poor is that
it requires
sophistication from management and
developers. (Rapid Development,
156)
Theo van Stratum
Page 42
19/03/2006
Why is it that Internal Project
Management mostly fails?
Criticism of the waterfall model
The waterfall model however is
argued by many to be a bad idea in
practice,
mainly because of their belief that
it is impossible to get one phase of
a
software product's lifecycle
"perfected" before moving on to the
next phases
and learning from them (or at least,
the belief that this is impossible
for any
non-trivial program). For example
clients may not be aware of exactly
what
requirements they want before they
see a working prototype and can
comment upon it - they may change
their requirements constantly, and
program designers and implementers
may have little control over this.
If
clients change their requirements
after a design is finished, that
design must
be modified to accommodate the new
requirements, invalidating quite a
good
deal of effort if overly large
amounts of time have been invested
into "Big
Design Up Front". (Thus methods
opposed to the naive waterfall
model, such
as those used in Agile software
development advocate less reliance
on a
fixed, static requirements document
or design document). Designers may
not
(or more likely, can not) be aware
of future implementation
difficulties when
writing a design for an
unimplemented software product. That
is, it may
become clear in the implementation
phase that a particular area of
program
functionality is extraordinarily
difficult to implement. If this is
the case, it is
better to revise the design than to
persist in using a design that was
made
based on faulty predictions and
which does not account for the newly
discovered problem areas.
Steve McConnell in Code Complete
(a book which criticizes the
widespread
use of the waterfall model) refers
to design as a "wicked problem" - a
problem
whose requirements and limitations
cannot be entirely known before
completion. The implication is that
it is impossible to get one phase of
software development "perfected"
before time is spent in
"reconnaissance"
working out exactly where and what
the big problems are.
"Many of the [systems] details only
become known to us as we progress in
the [systems] implementation. Some
of the things that we learn
invalidate our
design and we must backtrack."
McConnell, Steve (2004)
Theo van Stratum
Page 43
19/03/2006
Why is it that Internal Project
Management mostly fails?
The idea behind the waterfall model
may be "measure twice; cut once",
and
those opposed to the waterfall model
argue that this idea tends to fall
apart
when the problem being measured is
constantly changing due to
requirement
modifications and new realizations
about the problem itself. The idea
behind
those who object to the waterfall
model may be "time spent in
reconnaissance
is seldom wasted".
In summary, the criticisms of a
non-iterative development approach
(such as
the waterfall model) are as follows:
Many software projects must be open
to change due to external factors;
the
majority of software is written as
part of a contract with a client,
and clients are
notorious for changing their stated
requirements. Thus the software
project
must be adaptable, and spending
considerable effort in design and
implementation based on the idea
that requirements will never change
is
neither adaptable nor realistic in
these cases.
Unless those who specify
requirements and those who design
the software
system in question are highly
competent, it is difficult to know
exactly what is
needed in each phase of the software
process before some time is spent in
the phase "following" it. That is,
feedback from following phases is
needed to
complete "preceding" phases
satisfactorily. For example, the
design phase
may need feedback from the
implementation phase to identify
problem design
areas. The counter-argument for the
waterfall model is that experienced
designers may have worked on similar
systems before, and so may be able
to
accurately predict problem areas
without time spent prototyping and
implementing.
Constant testing from the design,
implementation and verification
phases is
required to validate the phases
preceding them. Constant "prototype
design"
work is needed to ensure that
requirements are non-contradictory
and
possible to fulfill; constant
implementation is needed to find
problem areas
and inform the design process;
constant integration and
verification of tbe
Theo van Stratum
Page 44
19/03/2006
Why is it that Internal Project
Management mostly fails?
implemented code is necessary to
ensure that implementation remains
on
track. The counter-argument for the
waterfall model here is that
constant
implementation and testing to
validate the design and requirements
is only
needed if the introduction of bugs
is likely to be a problem. Users of
the
waterfall model may argue that if
designers (etcetera) follow a
disciplined
process and do not make mistakes
that there is no need for constant
work in
subsequent phases to validate the
preceding phases.
Frequent incremental builds
(following the "release early,
release often"
philosophy) are often needed to
build confidence for a software
production
team and their client.
It is difficult to estimate time and
cost for each phase of the
development
process without doing some "recon"
work in that phase, unless those
estimating time and cost are highly
experienced with the type of
software
product in question.
The waterfall model brings no formal
means of exercising management
control over a project and planning
control and risk management are not
covered within the model itself.
Only a certain amount of team
members will be qualified for each
phase; thus
to have "code monkeys" who are only
useful for implementation work do
nothing while designers "perfect"
the design is a waste of resources.
A
counter-argument to this is that
"multi-skilled" software engineers
should be
hired over "specialized" staff
anyway.
Agile Method
Most agile methods attempt to
minimize risk by developing software
in short
time boxes, called iterations, which
typically last one to four weeks.
Each
iteration is like a miniature
software project of its own, and
includes all the
tasks necessary to release the
mini-increment of new functionality:
planning,
requirements analysis, design,
coding, testing, and documentation.
While
Theo van Stratum
Page 45
19/03/2006
Why is it that Internal Project
Management mostly fails?
iteration may not add enough
functionality to warrant releasing
the product, an
agile software project intends to be
capable of releasing new software at
the
end of every iteration. At the end
of each iteration, the team
reevaluates
project priorities.
Agile methods emphasize real-time
communication, preferably
face-to-face,
over written documents. Most agile
teams are located in a bullpen and
include
all the people necessary to finish
software. At a minimum, this
includes
programmers and their "customers."
(Customers are the people who define
the product. They may be product
managers, business analysts, or
actual
customers.) The bullpen may also
include testers, interaction
designers,
technical writers, and managers.
Agile methods also emphasize working
software as the primary measure of
progress. Combined with the
preference for face-to-face
communication, agile
methods produce very little written
documentation relative to other
methods.
This has resulted in criticism of
agile methods as being undisciplined
hacking
(a.k.a. Cowboy coding).
Theo van Stratum
Page 46
19/03/2006
Why is it that Internal Project
Management mostly fails?
The Agile Manifesto
Agile methodologies are a family of
methodologies, not a single approach
to
software development. In 2001, 17
prominent figures in the field of
agile
development (then called
"light-weight methodologies") came
together at the
Snowbird ski resort in Utah to
discuss the unifying theme of their
methodologies. They created the
Agile Manifesto, widely regarded as
the
canonical definition of agile
development.
"Manifesto for Agile Software
Development
We are uncovering better ways of
developing software by doing it and
helping
others do it. Through this work we
have come to value:
Individuals and interactions
over processes and tools
Working software over
comprehensive documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
That is, while there is value in the
items on the right, we value the
items on
the left more."
Kent Beck, Mike Beedle, Arie van
Bennekum, Alistair Cockburn, Ward
Cunningham, Martin Fowler, James
Grenning, Jim Highsmith, Andrew
Hunt,
Ron Jeffries, Jon Kern, Brian
Marick, Robert C. Martin, Steve
Mellor, Ken
Schwaber, Jeff Sutherland, Dave
Thomas, © 2001, the above authors
this declaration may be freely
copied in any form, but only in its
entirety
through this notice.
The Agile Manifesto is accompanied
by the Principles behind the Agile
Manifesto, a complete list of agile
principles.
Theo van Stratum
Page 47
19/03/2006
Why is it that Internal Project
Management mostly fails?
Comparison with other types of
methodologies
Agile methods are often
characterized as being at the
opposite end of a
spectrum from "plan-driven" or
"disciplined" methodologies. This
distinction is
misleading, as it implies that agile
methods are "unplanned" or
"undisciplined."
A more accurate distinction is to
say that methods exist on a
continuum from
"adaptive" to "predictive." Agile
methods exist on the "adaptive" side
of this
continuum.
<--Agile--> <--Iterative-->
<--Waterfall-->
<--------|----------------|-------------------|----->
Adaptive Predictive
Adaptive methods focus on adapting
quickly to changing realities. When
the
needs of a project change, an
adaptive team changes as well. An
adaptive
team will have difficulty describing
exactly what will happen in the
future. The
further away a date is, the vaguer
an adaptive method will be about
what will
happen on that date. An adaptive
team can report exactly what tasks
are
being done next week, but only which
features are planned for next month.
When asked about a release six
months from now, an adaptive team
may
only be able to report the mission
statement for the release, or a
statement of
expected value vs. cost.
Predictive methods, in contrast,
focus on planning the future in
detail. A
predictive team can report exactly
what features and tasks are planned
for the
entire length of the development
process. Predictive teams have
difficulty
changing direction. The plan is
typically optimized for the original
destination
and changing direction can cause
completed work to be thrown away and
done over differently. Predictive
teams will often institute a change
control
board to ensure that only the most
valuable changes are considered.
Theo van Stratum
Page 48
19/03/2006
Why is it that Internal Project
Management mostly fails?
When to use agile methods
Agile development has been widely
documented as working well for small
(<10 developers) collocated teams.
Agile development is particularly
indicated
for teams facing unpredictable or
rapidly changing requirements. While
there
are experience reports of teams
succeeding with agile development
outside of
these parameters, there are too few
experiences reported as of April
2005 to
draw firm conclusions.
Agile development's applicability to
the following scenarios is open to
question:
- Large scale development efforts
(>20 developers)
- Distributed development efforts
(non-collocated teams)
- Mission- and life-critical efforts
- Command-and-control company
cultures
Boehm and Turner's risk-based
approach
Barry Boehm and Richard Turner
suggest that risk analysis be used
to
choose between adaptive ("agile")
and predictive ("plan-driven")
methods. The
authors suggest that each side of
the continuum has its own home
ground:
Agile home ground:
- Low criticality
- Senior developers
- High requirements change
- Small number of developers
- Culture that thrives on chaos
Plan-driven home ground:
- High criticality
- Junior developers
- Low requirements change
- Large number of developers
- Culture that demands order
Theo van Stratum
Page 49
19/03/2006
Why is it that Internal Project
Management mostly fails?
By analyzing the project against
these home grounds, the risk of
using an
agile or plan-driven method can be
determined.
Criticism on the Agile Method
Agile development is sometimes
criticized as cowboy coding. Extreme
Programming initial buzz and
controversial tenets, such as pair
programming
and continuous design, have
attracted particular criticism, such
as McBreen
and Boehm and Turner.
In particular, Extreme Programming
is reviewed and critiqued by Matt
Stephens' Extreme Programming
Refactored.
Criticisms include charges that
agile development:
- fails to provide an adequate level
of structure and necessary
documentation
- only works with senior-level
developers
- incorporates insufficient software
design
- requires too much cultural change
to adopt
What choice to make?
This is depending on team that is
led. If the project manager has a
programmers back-ground then the
Agile method would be more
appropriate,
as I feel that each software
engineering project should be run,
but if the
project manager doesn't have the
right background that this could be
difficult.
Theo van Stratum
Page 50
19/03/2006
Why is it that Internal Project
Management mostly fails?
Chapter 6: Conclusion
Looking at the overall outcome of
the research then we are noticing
that there
is no single solution this problem.
In general the problem lies in
experience of
the project manager. We saw that the
more experience project manager is
using project management methods to
help him steering and managing his
project, the stakeholders, and
project team; whilst the less
experience project
manager the project leads without
these tools.
Due to the fact that most of the
less experience project managers is
not using
a proper project manager method
could lead to:
- Not properly estimating the work
on hand,
- Feature
creeping,
- Failing to make deadlines.
When a project starts the project
manager needs to access the work on
hand
in a way that time, cost, and
quality could be correct estimated.
This is
especially a problem by internal
project management. The triangle of
constrain tells us that the three
parameters of a project: Time,
Costs, and
Quality cannot be in control of one
person (team). Especially first time
project
managers fall in this trap. Instead
of being able to do a proper
assessment
they are told what the project needs
to accomplish (quality), when it
needs to
be ready (time) and how must they
can to spend (cost). In other words
he is in
no control whatsoever. If they are
lucky then there is a functional
description
of the project goal, but more often
that is not the case.
With this comes the second problem:
Feature creeping:
During the project user expectations
changes and that is normal, if it is
done
under controlled circumstances
(change management) and forces
within the
triangle of constrain are managed.
But more often the project manager
gets
Theo van Stratum
Page 51
19/03/2006
Why is it that Internal Project
Management mostly fails?
changes, with the comment: "cost
only a few hours to do", and none of
the
parameters are changed with it. This
makes that a project fails.
The more experience project manager
recognises this and will handle
accordingly to get the project in
control by introducing a proper
functional
specification, signed-off by the
stakeholders, and change management
to
handle the changes on the functional
specification.
This last part is more of a problem
if the project is handled according
the
"Waterfall" method as it is by the
"Agile" method. Remember that
feature
creeping isn't a big thing in the
"Agile" method due to the fact that
the end-
users, stake-holders and project
members are involved in the each
stage and
decide together what are the
features included. The time line is
not altered but
features will.
What we further discovered was that
in internal projects the project
manager
is, in general, not in control of
the resources assigned to the
project. Most of
the times they are taken from other
work within the company and have
still
work in their "old" departments.
This generates a conflict of
interest in the
sense that their loyalty lies with
their workplace, after the project
they need to
go back. As soon as there are
"problems" or colleagues asking for
help they
could abandon their work on the
project, or in worse cases their
manager
could take them of the project, just
for a few days. This endangers the
project
in a way that is not traceable and
reflects on the project manager.
So why does it seems to be that
those problems not, or less, occur
in projects
led by an external project managers?
It seems that this is due to two
things:
1. Experience
2. Authority
Theo van Stratum
Page 52
19/03/2006
Why is it that Internal Project
Management mostly fails?
As discussed before: the external
project manager is "normally" longer
in his
profession and has more experience
in leading bigger projects, they
"see"
problems arising before they are
happening and react pro-active
towards
them. But besides that there seems
to be a more important "skill" that
an
external project manager has:
authority.
Generally spoken: the external
project manager gets, as a
specialist, the
responsibility and authority to
handle all things concern the
project, including
the hire of resources. Because the
project manager is seen as an expert
he
has the ear of the board of
directors and much of the problems,
the internal
project manager has, disappear. Most
of the time the project, done by
external project managers has the
highest priority in the company,
whilst
projects done by internal project
leader are lower on the list of
priorities. As I
have noticed during the interviews,
the internal project manager gets
the
responsibility but not the
authority, which makes it difficult
when decisions
need to be made and office politics
starts to kick in.
Theo van Stratum
Page 53
19/03/2006
Why is it that Internal Project
Management mostly fails?
Communication lines
Board
Internal
Project
Project
team
Manager
Departments
Figure 14: Communication Internal
PM
Figure 14 shows the communication
lines a internal project manager has
to
deal with and we see here that this
should be of great concern. Not only
flows
the communication between the
project manager, the Board, project
team,
and departments but also between the
individual objects themselves with
the
biggest problem that this bypasses
the project manager who starts
loosing
control.
Board
Departments
Project Manager
Project team
Figure 15 Communications External
PM
Theo van Stratum
Page 54
19/03/2006
Why is it that Internal Project
Management mostly fails?
In figure 15 we see the more
structural project management
approach, which
is normally implemented with
external project management with the
project
manager in the middle. This doesn't
imply that the Board and Department
are
not talking with the project team
member but there are no decisions
made
without the project manager.
How to avoid the failing of
internal projects? (Recommendations)
To avoid the failing of internal
projects due to the causes found in
the
research is not easy. It demands a
cultural change in the managing of
companies, which start with training
for the internal project manager.
The
problem with this is that making the
choice to go for an internal project
manager most of the time is made to
save costs, the salary of the
project
manager is already a cost for the
company (and most of the time NOT
calculated in the project costs).
This means that we must get a budget
for
training, not only the project
manager but also the project team,
if only in
training in new techniques for the
project. This is something that is
mostly
forgotten or not in the budget. We
must however keep in mind that those
cost
will result in a better change in
finishing the project and the
trained project
manager could be used in other
projects what will spread the cost.
Further needs "normal" management
hand over the authority over the
project
resources to the project manager and
not interfere by taken resources
back,
even for a short time without
adjusting the project deliverables
(triangle of
constrain). Management needs to
tread the internal project manager,
as was
he external, with all the
responsibilities and authority.
Especially for fresh starting
project managers coaching would be a
good
alternative. An experience project
manager coached the junior project
manager through the project,
learning on the job. This could be a
hired or
internal project manager, but we
must take in consideration that the
coach
needs to have a minimal 6 years of
project management experience in the
area the project. Especially in the
start-up of the project this would
be valuable
Theo van Stratum
Page 55
19/03/2006
Why is it that Internal Project
Management mostly fails?
in the sense that the coach forces
the junior project manager in the
use of a
methodology and helps with writing
the first drafts of the project goal
document and functional
specification. After that first
period a bi-weekly
meeting between the coach and
project manager would be enough,
depending on the project size.
Choosing the right methodology is
crucial, especially in software
development
projects. As stated before we have
two main lines: Waterfall and Agile
development methods. With all the
pro and cons regarding the two
methodologies I tend to favour for
the Agile methodology especially
when the
project manager is from the
development field, which with most
of the starting
project manager is the case. The
research revealed that more then 90%
of
the internal project managers are
the more senior developer promoted
to do
this job. Waterfall could still be
used in smaller, sort term projects.
The main
reason for this is, as discussed,
that in long term projects,
functional
specifications and user requirements
could become out of date due to
several
changes, ex and internal.
Get from day one change management
in place! This is not only for
development task but for everything
that has to do with the project:
Documentation, User Requirements,
Functional, and Technical
specifications.
Make sure that everything done is
traceable. By making this a habit
the
project manager can make sure that
there are no questions during the
project.
Last but not least we have the point
of quality. To measure quality we
must
have a non-ambiguous User
Requirements document with the
applied change
documents. This together is what the
goal for the project is. User
Acceptance
Testing can prove that what is build
is in the documentation and on
correct the
working of it. This means that the
project manager needs to make sure
that
the appropriate test reports are
made before the testing begins.
Those report
are a combined User Requirements,
Change documentation and users
manual. In the last document are the
operating steps noted, and needs to
be
used as test document.
Theo van Stratum
Page 56
19/03/2006
Why is it that Internal Project
Management mostly fails?
Final statement:
Project Management is a hectic
profession and needs to be managed
from
the start: Time, Costs, and Quality
are the basic parameters that
measure a
project on success and failing. By
applying the recommendations the
project
manager makes sure that he or she is
in control of those parameters and
not
the other way around. This makes his
way to a successful project
possible.
Theo van Stratum
Page 57
19/03/2006
Why is it that Internal Project
Management mostly fails?
This page is intentionally left
blank
Theo van Stratum
Page 58
19/03/2006
Why is it that Internal Project
Management mostly fails?
References
- Adler, P. A. & Adler, P. (1987).
Membership roles in field research.
Sage, Newbury Park, CA:.
- Beck,
Kent.(1999)
Extreme Programming Explained:
Embrace Change.
Addison-Wesley, Boston.
- Boehm, B. and Turner, R. (2004),
Balancing Agility and Discipline: A
Guide for the Perplexed,
Addison-Wesley, Boston.
- Brooks, Frederick P. (2004), The
Mythical Man-Month, Addison-
Wesley, Boston, USA
- Bruce, Andy et al (2000), Project
Management, Dorling Kindersley,
Londen
- DeWalt, K. M. & DeWalt, B. R.
(2002). Participant observation.
AltaMira
Press , Walnut Creek, CA:.
- Duncan,
Christopher.
(2002),
The Career Programmer, Après,
Berkeley, CA
- Fowler, Martin.( 2001) Is Design
Dead?. (Appeared in
Extreme
Programming Explained), G.
Succi and M. Marchesi, ed., Addison-
Wesley, Boston..
- Giddens, A. (1990). The
consequences of modernity. Stanford
University Press, Stanford, CA:.
- Malinowski,
B.
(1922/1961).
Argonauts of the Western Pacific. E.
P.
Dutton, New York:.
- McConnell, Steve (2004). Code
Complete, 2nd edition, Microsoft
Press.
- McConnell, Steve (1996). Rapid
Development: Taming Wild Software
Schedules, Microsoft Press
- Newton, Richard. (2005), The
Project Manager: Mastering the Art
of
Delivery, Financial Times Prentice
Hall, Indiana, USA
- Stephens M., Rosenberg D..( 2003)
Extreme Programming
Refactored:
The Case Against XP. Apress L.P.,
Berkeley, California.
- Wolcott, H. F. (1995). The art
of fieldwork. AltaMira Press,
Walnut
Creek, CA:.
- Wolcott, H. F. (1999).
Ethnography: A way of seeing.
AltaMira Press,
Walnut Creek, CA:.
Theo van Stratum
Page 59
19/03/2006
