Modern Project Management: Essential Skills and Techniques 1

Modern Project Management: Essential Skills and Techniques

Iman Attarzadeh
Siew Hock Ow
Department of Software Engineering
Faculty of Computer Science & Information Technology
University of Malaya, 50603 Kuala Lumpur, MALAYSIA
Email: attarzadeh@perdana.um.edu.my, show@um.edu.my

Abstract industry, require a set of defined rules and principles

Modern project management is a well-understood
discipline that can produce predictable, repeatable
results. The methodologies of modern project
management are highly analytical, usually requiring
automated tools to support them on large projects.
Like most other disciplines, it is learned through both
practice and past experience. Project management
encompasses many different skills, such as
understanding the interdependencies among people,
technologies, budgets, and expectations; planning the
project to maximise productivity; motivating others to
execute the plan; analysing the actual results; and
reworking and tuning the plan to deal with the
realities of what really happens as the project is
executed. In order to manage a project and bring it to
a successful completion, its project manager must
have a complete understanding of the methodologies
being used for the management of different parts of
the project. Managers prefer specific project
methodology, while resist and face difficulties for an
opportunity to manage another project with different
methodology as they do not know how much
commonality exists between the preferred and the
new required methodology. This paper discusses the
issues involved in modern project management and
compares the differences between traditional and
modern project management skills and techniques.
1. Introduction
Many project management methodologies being used
today, are either the wrong methodologies or are not
applied fully [1]. Some project managers see
methodologies as impractical and bureaucratic,
relying on their gut instinct when it comes to
managing projects. If project management
methodologies come across as too complex to use in
real-world projects, project managers will look for
their own shortcuts. Given enough time, anyone can
be trained to adhere to a project methodology.
Projects are usually split into phases often along the
lines of initiation, control (Planning, Execution) and
closure. During each phase, a number of documents
are produced as part of the project control process.
All IT projects, regardless of their size, complexity or
to be managed effectively and come to a successful
conclusion. This area of managing projects is called
project management. This idea of project
management has been around for a long time. Today,
project management has emerged as its own field,
supported by bodies of knowledge and researches
across many discipline. Although still relatively new,
the field of Software Engineering has its own Bodies
of Knowledge that include various methodologies,
frameworks, tools and techniques supported by a
continuous growing base of research.
2. What is a Methodology?
A methodology is a set of guidelines or principles
that can be tailored and applied to a specific
situation [1]. In a project environment, these
guidelines might be a list of things to do. A
methodology could also be a specific approach,
templates, forms, and even checklists used over the
project life cycle. A methodology can also be defined
in other ways, for example [2, 3, 4]:
• A process that documents a series of steps and
procedures to bring about the successful
completion of a project.
• A defined process for accomplishing an end.
• A series of steps through which the project
progresses.
• A collection of methods, procedures, and
standards that define a synthesis of engineering
and management approaches designed to deliver
a product, service, or solution.
• An integrated assembly of tasks, techniques,
tools, roles and responsibilities, and milestones
used for delivering the project.
A formal project methodology should lead the work
of all team members throughout the life cycle of a
project. All members of a team should be familiar
with and use the chosen methodology throughout
their projects. Many project management
methodologies address the management of a single
project, without appreciating that many other projects
in a company compete for the very same resources

Communications of the IBIMA

Volume 2, 2008
 2 Iman Attarzadeh and Siew Hock Ow

and attention. The project management methodology
should also provide project managers with the
perspective that there is a project management
framework and associated methodologies present in
the company. In Fig. 1, we see that Project A has no
methodology and is filled with process issues as well
as problems that actually increase as the project
moves along [5]. Additionally, Project B, which has a
structured methodology with defined and operational
project processes, minimises the number of problems
that may occur on the project [5].
• Identify and correct errors early
• Avoid excessive documentation
2.2 Review on Project Methodologies
Project management has grown from the early
initiatives in the U.S. defense and aerospace sectors
in the late 1950s and 1960s [3]. The U.S. Department
of Defense and NASA achieved early project
management successes, mainly promulgated through
their internal policies, procedures, and lessons
learned. Many articles, seminars, and training
programs that expanded the project management
genre, although much of the theory centered on the
use of tools and techniques, such as [3]:
• PERT/Gantt charts.
• Critical path.
• Scheduling techniques.
• Organisational issues.
• Conflict management and others.

Most projects share a common life cycle. This is not

Fig. 1: Difference in using a methodology.
2.1 Strategy with Methodologies
For any company to be world class, the strategy is
clear, survey the entire landscape and then put the
objectives. In negative economic times, always
remember that what comes down must come up [3].
In other words, after identifying and selecting the
correct methodology, it may be the best defense if
you want to:
• Avoid mistakes
• Reduce cost
• Reduce risk
• Meet project schedules
to say that these projects are all designed and
executed the same way, but they remain universal, as
they pass similar phases during the life cycle of the
project.
3. How Many Development Methodologies are
there?
There are no similar development methodologies.
Some companies have their own unique customised
methodology for developing products or services;
others simply use standard commercial off-the-shelf
methodologies. With the incorrect methodology,
discovering, designing, building, testing, and
deploying projects can be chaotic [6]. At least 20
different methodologies are competing to be the best
methodology, and this list of methodologies keeps on
growing. Some of the assessing project development
methodologies are shown in Table 1.

Table 1: Assessing project development methodologies.

Methodology Risk Easy to Frequent Easy to Scope Reliability Document Project
/Life Cycle Implement Changes Manage Creep Oriented Approach
Open Source Low Easy √ √ √ √ × Iterative
XP-Extreme Med High √ √ √ √ × Iterative
Pharma Med Average √ × √ √ × Phased
Object Oriented High Difficult √ × √ √ × Iterative
Spiral / MBASE High Difficult × √ √ √ √ Phased
RAD Low Easy √ √ × √ × Phased
Crystal Med Easy √ √ √ √ × Iterative
Incremental Med Average × √ × √ √ Phased
Prototyping Low Easy √ × √ √ √ Phased
UniCycle Model Low Easy × √ √ √ × Phased

Communications of the IBIMA

Volume 2, 2008
 Modern Project Management: Essential Skills and Techniques
The project methodology that is chosen represents
merely the framework for the real work to be done
and indicates where creativity is needed. Many times,
project managers simply select the available
methodology and continue to develop their projects
with that same methodology. When unpredictable
results occur on a project, they raise issues and risks
and try to manage reactively [3]. Project managers
often lack the controls to measure and respond to the
unpredictable. Therefore, they must first determine
that the methodology is the correct one.
Many project managers find it difficult to give up
control as provided in traditional development. There
is no guarantee that the team will deliver if it just
follow a chosen methodology. Clients seldom
complete requirement specifications because their
requirements are constantly changing. The most
logical solution is to simply evolve the product as the
client's needs change along the project development
process. This shows the need for a methodology to be
more flexible than a formal waterfall approach. In
fact, the trend is shifting to the more iterative or
incremental style of methodologies [3, 7].
Most project developments are wrongly approached
with the assumption that the methodology used is
well-understood, and the project can be easily
planned and estimated. When a project begins to fail,
the development process is immediately provided
with more resources and attention to get it back on
track. Thus, cost and schedule overruns start
occurring. These step-by-step approaches do not
work because they do not cope with human and
technical unpredictability. Inflexible processes are
often too constraining and fall short of delivering a
project to operations or production [7].
4. Requirements for Selecting a Methodology
The essential decisions that a project manager must
make when selecting a methodology are below [1, 3].
• Budget
Budgets play a big role in any project, and the
type of methodology to be used is important.
Formulated fairly early in the project's planning
stage, the budget estimate is most often based
on analogous estimating. With the budget
estimate, we start at the top and work our way
down into the project details.
• Team size
Methodologies are directly proportional to the
team size. Use light methodologies for smaller
teams and heavy methodologies for larger
teams. The choice of light or heavy
methodologies discussed in section 4.1.
Communications of the IBIMA
Volume 2, 2008
3
• Technology used
The technology used on a project affects the
direction and type of methodology selected.
Unfamiliar technology slows progress. On many
projects today, simulation and testing of new
technologies is actually considered a phase of
the methodology.
• Tools and techniques
Some project methodologies require more tools
and techniques than others. For example, some
projects need databases, visual modeling tools,
and project management tools; while others
require hardly anything. If a project manager
must manage multiple design changes, he or she
will need a configuration management tool and
technique.
• Project criticality
Any critical project with a "must-deliver" target
date needs to have the correct choice of
methodology. The project might require
additional resources to finish by the required
date. If the methodology is too small, the project
manager loses control; too large and formal, he
or she slows the project down. A project
manager's experience and skills will help in
choosing the best approach.
• Existing processes
In any company, the maturity and ease of use of
existing project processes largely influence the
methodology. Some company processes may be
totally unreliable and ad hoc, slowing down
completion of tasks.
4.1 Light or heavy methodology
The choice between using a light or heavy
methodology determines the success of the
project [3].
4.1.1. Light Methodologies
Ever-increasing technological complexities, project
delays, and changing client requirements, brought
about a small revolution in the world of development
methodologies. A totally new breed of methodology,
which is agile, adaptive, and involves the client,
every part of the way, is starting to emerge. Many of
the heavyweight methodologists were resistant to the
introduction of these "light weight" or "agile
methodologies". These methodologies use an
informal communication style. Unlike heavyweight
methodologies, lightweight projects have only a few
rules, practices, and documents. Projects are designed
and built on face-to-face discussions, meetings, and
the flow of information to the clients.
4 Iman Attarzadeh and Siew Hock Ow
The immediate difference of using light
methodologies is that they are much less document-
oriented, usually emphasising a smaller amount of
documentation for the project. The great thing about
light methodologies is that they are learning
methodologies. After each build or iteration, the team
learns to correct issues on the project and
improvement cycles form throughout the project.
Additionally, with light methodologies, the project
teams are smaller and rely on working more closely,
fostering knowledge sharing, and having almost
instantaneous feedback. The project manager does
not need to develop heavy project documentation, but
should instead focus on the absolute necessary
documentation [3].
4.1.2. Heavy Methodologies
The traditional project methodologies are considered
bureaucratic or "predictive" in nature and have
resulted in many unsuccessful projects. These heavy
methodologies are becoming less popular. These
methodologies are so laborious that the whole pace of
design, development, and deployment actually slows
down, and nothing gets done. Project managers tend
to predict every project milestone because they want
to foresee every technical detail. This leads managers
to start demanding many types of specifications,
plans, reports, checkpoints, and schedules [3]. Heavy
methodologies attempt to plan a large part of a
project in great detail over a long span of time. This
works well until things start changing, and project
managers inherently try to resist change.
If the project manager does not obtain a complete list
of user requirements from clients for the heavy
weight project, it is very likely that the heavy
methodology will not work effectively because the
project will be racked with change, slippages, and
rework on the project documentation. A heavy weight
methodology works on the assumption that the more
rules and coordination there are, the better the project
result will be. A complex project requires sufficient
documentation just to jog the memory of the many
team members on the project. However, excess
methodology is very costly and inept, there are more
updates to reports, plans, and schedules.
Alternatively, there are times when a heavyweight
methodology may be appropriate for super projects
where it is necessary to gain stricter control and
coordination between phases, and to improve the
lines of communication between team members [3].
Communications of the IBIMA
Volume 2, 2008
4.2. Importance of methodology and life cycles
Successful implementation of any project
methodology is a project itself. The hard part is to
roll it out and make it part of the company's everyday
culture. Although managers can manage projects
without a formal methodology, having one can be a
big help. Project management methodologies have
been around for decades, but first started to become
popular in Information System (IS) in the early
1970s [2]. These methodologies usually have two
components. The first is an overall process for doing
things, while the second consists of templates or
forms required at specific portions of that process.
While the process itself is the true methodology, most
project managers consider the templates and forms to
be part and parcel of the methodology.
Project management methodologies are important for
two reasons. First, they standardise the way in which
an organisation manages its projects. This allows
people from anywhere in the organisation to talk with
one another using the same terms and the same
definitions for those terms. Presenting a consistent
approach to project management via standards also
allows project managers to cover for one another
when the need arises. The second reason that
methodologies are important is that they provide
novice project managers with the tools to manage
projects, without requiring a long learning curve.
Project life cycles generally go hand in hand with
project methodologies. Such life cycles break a
project’s life into a series of phases or stages. The
end of each phase provides a convenient project
review point for senior management to institute go or
no-go decisions, and also allows project managers to
plan the next phases in more detail. While project life
cycles can have many phases, the majority have three
to five. They include some type of project start-up or
initiation, a project construction or implementation
stage, and, finally, a project evaluation or post-
implementation review [2, 8]. The Project
Management Life Cycle has four phases: Initiation,
Planning, Execution and Closure as shown
in Fig. 3 [9].
 Modern Project Management: Essential Skills and Techniques
Fig. 3: The Project Management Life Cycle
4.3. Selecting project management methodologies
First, an exploration of the benefits and drawback of
vendor methodologies is in order. The greatest
benefit of a vendor methodology is that the work is
already done, which can save an organisation literally
years of developing an internal methodology. The
vendor methodology has also been tested and proven
to work, saving both the time and headaches involved
in smoothing out process wrinkles. On the downside,
however, purchased methodologies require an
organisation to change its existing practices to match
those of the methodology [2, 10].
If it does not, then the organisation must customise at
least some of the methodology. These customizations
can vary from minor tweaks of the process, to
customisations so severe that the original purchased
methodology is virtually obliterated. Another
drawback of purchased methodologies is their price.
Some of the more popular methodologies for IS
projects include Dynamic Systems Development
Method (DSDM) from Computer Associates and
PRIDE from Computacenter [2].
4.4. Implementation of project management
methodologies
Once an organisation has either selected a vendor
methodology or developed one in-house, it is ready to
start the long, often tedious process of creating
project standards. While some of the purchased
methodologies come with standards for various
project components, organisations will need to
develop standards for those that do not have them.
One of the first steps in implementing a project
methodology is good planning. The only thing that
really distinguishes projects from non-projects is the
project life cycle. To develop a broad understanding
of the generic discipline of the management of
Communications of the IBIMA
Volume 2, 2008
5
projects, both project managers and executives
should address the broad range of issues affecting all
stages of the life cycle in all kinds of projects [2].
This is certainly a tough challenge as it requires a
substantial breadth of analysis and understanding.
Maintaining a coherent conceptual view of the
discipline at this broader level is generally difficult.
We can, however, create a simple structure
comprising project methodology; project team; tools
and templates; business processes and development
techniques in three separate levels to show this
relationship (Fig. 4).
Fig. 4: Project structure and composition.
4.4.1. Creating WBS, Estimating, and Tracking
Standards
The first standard to be established is how project
WBSs will be created. Many organisations develop
project templates for the most common types of
projects developed in the organisation, and then
specify that project managers work from these
templates. The advantage of this is that project
managers are not “reinventing the wheel” on each
project [2, 10]. In turn, this speeds up planning, and
allows better project tracking. After WBS standards
are established, the organisation must decide how
estimates will be created. Estimates can be
determined from expert opinions, weighted averages,
statistics from previous projects, or from techniques
such as function point analysis [10].
If organisations track their projects accurately and
religiously, they can use statistics from previous
projects to provide the most accurate estimates. This
highlights the need for standards in tracking projects.
Most organisations use some type of automated time,
keeping package to track time against projects. Time
6 Iman Attarzadeh and Siew Hock Ow
tracking has three project-related purposes. The most
critical is to accurately judge where a current project
stands. However, other reasons that are almost as
important are the uses of time tracking for project
cost accounting, and for data collection, in order to
better estimate the next project. To provide the best
database for estimating future projects, these
packages should allow tracking against each task in
the WBS, reinforcing the desirability of standard
WBSs [10].
4.4.2. Change Control, Quality Control, and
Communications Standards
Standards for change control, quality control, and
communications are equally important to project
success. Change control in this context does not refer
to changes in functioning production systems, but
rather to changes in the project itself. The most
common modifications to be managed are scope
changes, generally expressed as a need for increased
or different functionality. Because estimates are
based on functionality as originally conceived,
changes to initial functionality will obviously impact
the project’s cost and schedule [2].
To minimise this effect, change control policies
outline the project manager’s range of discretion for
approving changes, and spell out escalation levels
and procedures. While these two standards can be
negotiated at the beginning of each project, general
guidelines can prove helpful. Quality standards in an
IS department tend to address how the department
handles testing and production turnover. Some
examples include how unit testing, system testing,
and user acceptance testing will be performed.
Communications standards are also important to
successful projects.
The main reason that projects change as often as they
do is that someone misunderstood a communication,
be it the systems person or the client [2]. The
organisation can significantly reduce the number of
changes to a project in its later stages by setting clear
communication guidelines during planning, and then
constantly updating everyone involved in the project
as it progresses, and doing so in a standard manner.
5. Methodology Training
While it is attractive to start training employees on
the new methodology as soon as it is selected, this
‘jumping the gun’ can be hazardous to the ultimate
success of methodology implementation. Certainly,
the methodology will evolve as employees start using
it, but there should be a base of standards in place
prior to training, lest employees, at a minimum,
require retraining. In some organisations, employees
Communications of the IBIMA
Volume 2, 2008
have actually revolted and chosen not to use the
methodology at all, until standards have been
established [2, 10]. With at least tentative project
tracking, estimating, change control, quality control,
and project communication standards in place, the
organisation is ready to conduct IS departmental and
client training. This training can be performed in
three ways [2, 10]:
• Using outside consultants, who often develop
the training as well; via internal employees; or
using a combination of consultants and
employees. If the organisation chooses the
combination approach, external consultants
often develop the training, whereupon they train
the internal employees regarding how to deliver
the training.
• Since both project managers and project
participants must understand the new
methodology, it often makes sense to have two
separate classes. The more in-depth class, for
project managers and project leaders, ideally
provides case studies, so they can actually
practice the critical portions of the
methodology. Although this type of training
initially takes longer, the learning curve is less
steep when project managers and leaders start
following the methodology on “real” projects.
• The training for project participants can be less
detailed, focusing on their roles in the new
methodology. It need not specifically train them
to use all the pieces of the methodology.
5.1. The Agile Methodologies
Project or development managers are still facing
controversy between the agile and heavyweight
methodologies. Currently, many companies favour
the agile methodologies. Agile methodologies present
new, nontraditional ways of building complex
products and systems. Projects that use agile
methodologies are now starting to report improved
time line and cost savings, compared to those in the
heavyweight family [3].
Additionally, project teams are hailing the agile
family of methodologies as remarkable because, at
last, a series of methodologies contributes directly to
the business. Many managers tend to stick with the
heavyweight methodology because they want to
predict the entire project until the last man-hour,
whereas the project teams tend to stick with dynamic
shorter cycles [3, 7, 11]. Industries that use agile
methodologies include financial, IT, telecom,
utilities, and many more service industries.
Furthermore, this trend is starting to emerge
worldwide [7]. The following are the most commonly
used agile methodologies [3, 7, 11]:
 Modern Project Management: Essential Skills and Techniques 7

• Extreme Programming (XP) process. Because Single-Time Effort projects are

• Scrum only performed once, and in many cases, have
• Crystal methodology never been done before [5]. It is impossible to
• Dynamic Systems Development create final, stable plans early in the life of the
Methodology (DSDM) project.
• Rapid Application Development (RAD)
• Adaptive software development While preliminary and highly speculative
projections may and should be produced, these
• Lean development
early plans must be repeatedly “re-base lined” as
• Feature-driven development
new information becomes available. A complete
discovery process is typically required before
Agile methodologies better suit small projects where
stable plans are feasible. Because of their
smaller project teams are involved. With larger team
experience with the early, stable plans of
size and the complexity and duration of the project,
Continuing Effort, many organisations falsely
the choice of a heavyweight methodology is purely
assume they may simply “command” early
from a command and control perspective. Many
planning data for Single-Time Effort. This often
smaller companies do not use heavyweight
dooms a project to failure as it is operating with
methodologies and prefer the more agile approach to
totally invalid set of expectations and
building solutions [7].
strategies [5].
6. Differences between traditional and modern
6.2. Leading
project management
i. Traditional Leading
Comparisons between traditional project management
Leading any human organisation requires
and modern project management from the four
managers, working in a benevolent manner with
perspectives of planning, leading, organisation and
their subordinates, helping them learn how to
controlling are explained below.
accomplish assigned work. In Repeating Effort
and Continuing Effort, the manager is often the
6.1. Planning
task expert and is fully qualified to perform any
i. Traditional planning
work within their managerial domain. If not, they
Planning for an operational environment consists
can easily retain an advisor or consultant who fills
primarily of establishing the schedules people
this role. These traditional supervisors and
work, assigning individual tasks, scheduling
managers are expected to make the hard
vacations and adjusting for expected and
decisions, even when others do not agree with
unexpected time away. Plans for Continuous
their conclusions [5].
Efforts may assume highly stable
end-products, a well-defined process and task-
ii. Modern Leading
based workers. This yields plans that are very
Due to the complexity and diversity of skills
predictable early on and highly stable over time.
needed to perform Single-Time Effort, it is
Many of the project management techniques and
impractical for the project manager to be the task
current day expectations were based on these
expert of all work that must be done. When these
assumptions. Staff planning for a Single-Time
managers attempt to blindly dictate direction, they
Effort is complicated by dynamic teams
are quickly exposed by their impractical or
comprising of people who typically do not report
unreasonable edits. Instead, modern managers
administratively to the Project Manager. Matters
work to solicit individual contributions, create
become seriously complicated when these people
consensus within the project team, facilitate group
are available on a limited, unpredictable basis [5].
decisions and create an environment where it is
possible for people on the project to accomplish
ii. Modern planning
their work with a minimum of distractions. The
Project planning focuses on breaking down the
modern Project Manager plans, organises and
total effort into assignable units, estimating this
controls the project with the team and not for the
work, defining the most efficient order in which
team [5].
the work should be performed, and then
deploying available staff to specific work packets
6.3. Organisation
for specific windows of time. Perhaps the most
i. Traditional Organisation
significant influence of modern project
The operational manager is primarily concerned
management is on project plans and the planning
with creating a structure within his or her control

Communications of the IBIMA

Volume 2, 2008
8 Iman Attarzadeh and Siew Hock Ow
that monitors the work flow. They must insure the
proper number and alignment of employees to
accomplish the work in a consistent manner.
Well-defined career paths are established with the
promise of a “in-line” promotion for length of
service. A manager’s personal ranking in an
organisation is often directly related to the
number of people in their employ. In this setting,
the traditional manager often has both
administrative and functional authority over their
employees. Administrative duties include the
“care and feeding” of their employees such as
salary administration, training plans and
employee evaluations. Functional authority is the
right to assign work to an individual and have that
work be accountable back to the boss. When this
view dominates an organisation, it creates serious
conflicts for managers of Single-Time Efforts [5].
ii. Modern Organisation
A modern Project Manager must establish clear
roles and responsibilities needed for the success
of their project. A project staff often includes
many people who do not report administratively
to this manager and may even be at a higher
corporate level. Organising a project structure
begins with defining what is expected of the
Project Owner along with each member of the
Project Team. The Project Manager must also
define and explain the responsibilities they will
have to the project. Further, these managers
typically have only functional authority over their
team.
This “authority” is often compromised by the
priorities, views and occasional interference of the
actual administrative managers. It becomes
illogical and unfair to hold a Project Manager
responsible for deliverables and dates when they
have such limited and tainted authority over their
team. Even more vexing is the tendency of out-of
control organisations to improve the “look” of
productivity by deploying the same people to
multiple simultaneous projects. Organisations
must address this condition with well-defined
roles, clearly stated responsibilities, full release of
people to a project and a corporate resource
management process that insures team members
are never over-deployed to multiple projects [5].
6.4. Controlling
i. Traditional Controlling
Controlling an operational organisation includes
establishing organisational performance goals and
then determining what each individual’s
contributions should be. Individual goals are
Communications of the IBIMA
Volume 2, 2008
assigned and measure to insure the employee is
meeting their goals. Control is usually established
around target performance over a standard period
of time, such as a quota measured within an hour,
day or week [5].
ii. Modern Controlling
Single-Time Efforts are measured based on
creating quality, not quantity. It is critical to first
verify the completion of promised deliverables.
Objective criteria for completeness and quality
must be met before a deliverable is considered
“done.” Performance and productivity may then
be measured by comparing planned hours,
durations, start dates and finished dates against
the actuals. However, instead of comparing
performance against the original plans created
during the first days of a project, measurements
must be against revised and relevant baseline
plans [5].
7. Conclusion
Selecting a Project Management methodology can be
one of the most difficult parts and can have real
impact on the fate of the project. Normally the
Project Managers' criterion for choosing a
methodology for any project is mainly based on an
expert’s opinion, past working experience,
government rules and regulations, organisation,
senior management, stakeholder’s preferences and
client location. All of these can have positive or
negative impact on the underdevelopment projects.
However, all of the above mentioned criterion have
inbuilt quality of rigidness. None of these provide
any opportunity to analyse the nature of project and
then decide the future course of action related to the
selection of project management methodology.
Decisions in which a methodology is chosen or used
based on a single criteria can have serious negative
impacts on the project especially if the project
manager, development teams do not have the
knowledge or the pros and cons of the selected
methodology. No project management methodology
is meant to be taken verbatim. It must be customised
in the context in which it is being applied in order to
increase the rate of adoption and the opportunity for
success. It has been observed and evident from the
above text, that all the methodologies discussed have
some common tools and procedures. There are points
where one methodology has some powerful tool and
procedure than the others. In that case and in order to
make the most of these established methodologies, a
combine, mixed approach is required to get the best
possible results.
 Modern Project Management: Essential Skills and Techniques 9

8. References
[1] Howes, N. R. Modern Project Management
Successfully Integrating Project Management
Knowledge Areas and Processes. American
Management Association Press, New York, 2001.
[2] Tinnirello, P. C. New Directions in Project
Management. Auerbach Publications, Inc. Florida,
2001.
[3] Charvat, J. Project Management
Methodologies: Selecting, Implementing, and
Supporting Methodologies and Processes for
Projects. John Wiley & Sons, Inc. Canada, 2003.
[4] Haughey, D. Project Management
Methodology. Retrieved March 2, 2008 from
www.projectsmart.co.uk., 2006.
[5] Tryon, C. A. New Business Realities
Challenge Traditional Assumptions: MODERN
PROJECT MANAGEMENT. Retrieved March 5,
2008 from www.TryonAssoc.com, 2003.
[6] Fowler, M. The New Methodology.
Retrieved March 3, 2008 from
http://www.martinfowler.com/articles, 2005.
[7] Wasileski, J. S. Learning Organization
Principles & Project Management. Proceedings of
SIGUCCS'05, ACM 2005, Pages 20-29.
[8] Rehman, A. and Hussain, R. Software
Project Management Methodologies/Frameworks
Dynamics "A Comparative Approach". Information
and Emerging Technologies (ICIET), July 2007.
[9] Project Management Life Cycle. Retrieved
March 4, 2008, from
http://www.method123.com/project-lifecycle, 2003.
[10] Brock, S. A Balanced Approach to IT
Project Management. Proceedings of SAICSIT,
ACM 2003, Pages 2–10.
[11] Hayes, S. A. An Introduction to Agile
Methods. Retrieved March 4, 2008 from
www.wrytradesman.com/articles/IntroToAgile-
Methods, 2003.

Copyright © 2008 by the International Business Information

Management Association. All rights reserved. No part or all
of this work should be copied or reproduced in digital, hard,
or any other format for commercial use without written
permission. To purchase reprints of this article please e-
mail: admin@ibima.org

Communications of the IBIMA

Volume 2, 2008