INTERNATIONAL PROJECT MANAGEMENT

ASSOC. PROF. ROXANA VOICU-DOROBANTU, PH.D.

ROVODO@GMAIL.COM
 TRADITIONAL PROJECT MANAGEMENT
Preparations for the project

Planning the Project Traditional PM Focus

Managing the Project In-Progress
PRODUCT VS PROJECT LIFE CYCLES
Source: Dinsmore, 2006
 THE IDEA BEHIND FORMALIZING PM…
Use structure to combat scale and complexity
Make future possibilities more predictable, foresee problems,
develop contingency plans
Thoroughness – Checklists as a way of being sure
Forces us to confront things that are hard to think about in
detail
Helpful even when the details don’t unfold if expected
Eisenhower: “The plan is nothing. Planning is everything.”
The danger…
Structure can become an end in itself
Obsession with documents,
milestones
A distraction or, worse, a constraint on the ability to adjust
STRATEGIC MODEL FOR MANAGING PROJECTS
Source: Dinsmore, 2006
 CREATING A PROJECT ORGANIZATION
Define who is going to do what
Define roles and responsibilities
Identify people, resources; ensure their commitment to project
Identify a project leader, specify her/his authority and
responsibilities
Important questions:
• Who is the PM? What decisions are within PM’s area of authority? Is this
authority sufficient to carry out the project?
• Who is on team? Full-time or part-time? What are their areas of expertise?
Their roles?
• Who is the project sponsor? Is he or she at sufficiently high level in the
organization to provide the project with support and a good chance of
success?
PROJECT MANAGEMENT PROCESS GROUPS’ INTERACTIONS
Source: Dinsmore, 2006
 THE PROJECT MANAGEMENT PLAN
1. Introduction/overview
2. Mission and objectives
3.Work scope
4. Planning basis: deliverables, requirements, constraints, approaches,
assumptions, exclusions
5. Work breakdown structure - WBS
6. Organization development plan
7. Resource plan
8. Procurement and logistics plan
9. Logic and schedules: Gantt Chart, Critical Path
10. Cost estimates, budgets, and financial management
11. Risk analysis and contingency plan
12. Quality and productivity plan
13. Environmental, safety, and health protection plan
14. Security plan
15. Project planning, control, and administration plan
16. Documentation and configuration management plan
17. Appendix – if the case
 DEFINING THE PROJECT’S OBJECTIVES AND SCOPE
Make sure the proposed project is well understood an that all
stakeholders agree on what it will accomplish
Clearly spell out expected outcomes, deliverables, objectives
Agree scope – what’s in, what’s not in
Document agreements formally, in writing, to surface/eliminate ambiguity in
different stakeholders’ expectations
Important questions:
• What is the scope?
• What does the project need to accomplish?
• By when?
 FORMAL OBJECTIVE STATEMENT
A Formal Objective Statement
Short, simple language, unambiguous
Should Scope, Resources, and Schedule

A Famous Example: “Put a man on the moon and return him safely to
Earth by the end of the decade at a cost of $9 billion.”
Scope – “Put a man on the moon and return him safely to Earth.”
Schedule – “By the end of the decade.”
Resources –”At a cost of $9 billion.”
The advantage in keeping it short and simple: Longer statements
offer greater opportunity for people to come away with different
understanding of what the project will accomplish while mistakenly
assuming they have reached agreement
 WHAT’S IN/OUT LIST FOR PROJECT WORK PRODUCTS
What’s In/Out List

List 1: Things included in the work

product
List 2: Things excluded from the
work product
Work Product Example: A Business Plan
Is included: 30 pages + 10 pages of appendix, spiral bound, cover sheet with
300 word executive summary, one section must be financial projections,
another must spell out marketing plans
Not included: Potential customer market segment analysis, a formal
presentation
 SETTING UP PROJECT NORMS
Determine how the project will “operate” from day to day
Set norms for meetings, updates, communication
Establish “official” processes for logging, reviewing, updating progress on
issues
Set norms and escalation procedures for disagreements and unresolved
issues
Important questions:
• What do we do when we encounter a new problem?
• Who do we go to for help in making decisions?
• How do we check progress on a known issue?
 THE HUMBLE CHECKLIST
One of the most useful concrete tools in issue
tracking

A running list of “open issues”

Log issue, assign priority and problem
solving owner, current status, resources
assigned to address
Revisit list on a regular basis (daily, weekly)
 PROJECT “WORKBOOK”
It’s a good idea to have a common collection
point for all project documentation

Objective statements
Organization definitions and roles
Issue checklists
Etc.
 THE WORK BREAKDOWN STRUCTURE
Need to identify all of the work required by a project
Identify tasks and sub-tasks
Assign “owners” for each task
Estimate how long each task will take
Important questions:
• Are all tasks identified?
• Do all tasks have owners?
• How long will it take to do each task?
WBS – WORK BREAKDOWN STRUCTURE
Work breakdown structure, or the WBS = hierarchical structure
defining tasks that can be completed independently of other tasks,
facilitating resource allocation, assignment of responsibilities, and
measurement and control of the project.
Task 1 Subtask 1.1 Work package 1.1.1
Work package 1.1.2
Work package 1.1.3
Subtask 1.2 Work package 1.2.1
Work package 1.2.2
Task 2 Subtask 2.1 Work package 2.1.1
Work package 2.1.2
Work package 2.1.3
Work package 2.1.4
Subtask 2.2 Work package 2.2.1
Subtask 2.3 Work package 2.3.1
Work package 2.3.2
Terminology for Different Levels
-tasks, sub-tasks, and work packages
-phases, entries, and activities.

Organization by Deliverables or Phases

•deliverables or phases of the project life cycle.
•higher levels in the structure generally are performed by groups.
•lowest level in the hierarchy often comprises activities performed by individuals,
• a WBS that emphasizes deliverables does not necessarily specify activities.

Level of Detail
facilitates resource allocation and the assignment of individual responsibilities.
! Beware: micro-management OR tasks too large to manage effectively.

Defining tasks so that their duration is between several days and a few months
works well for most projects.
 THE 100% RULE
The 100% rule states that
the WBS includes 100% of the work defined by the project scope and
captures all deliverables – internal, external, interim – in terms of the
work to be completed, including project management.

The rule applies at all levels within the hierarchy: the sum of the work at the “child”
level must equal 100% of the work represented by the “parent” and the WBS should
not include any work that falls outside the actual scope of the project, that is, it
cannot include more than 100% of the work…

It is important to remember that the 100% rule also applies to the activity level.

The work represented by the activities in each work package must add up to 100%
of the work necessary to complete the work package.
 TOP DOWN VS. BOTTOM UP
You can create a WBS top down or bottom up

Top down – Start with largest work groupings and

break into smaller and smaller pieces
Bottom up – Brainstorm specific low level tasks, group
them into larger groupings
 ESTIMATING IS DONE IN MANY WAYS…
Guestimates by task owners
Guestimates by a group, including experts who have “done this kind of work
before”
Other group consensus processes
Statistical models that relate “size” of a project result to time and effort
estimates
Suppose a project is expected to produce a software product with about
60,000 Lines of Code (written software)
According to statistical model: 60,000 Lines of Code translates into 200
person months of effort
200 person days of effort = it’ll take 20 people 10 months, or 10 people 20
months (or 2 people 100 months, etc.)
 “BROOKS’S LAW”
Frederick Brooks, author of The Mythical Man Month:
“Adding more people to a late project makes it later”

“Adding more people to a late project helps less than you

might think, and it helps less and less the more people you
add ” -- 20 people for 10 months is not the equivalent to 10
people for 20 months (or 2 people for 100 months) –

The more people work on a project, the more overhead

required to coordinate work (and the less spent on value-
adding work)

Overall
Productivity

Number of people
 DEVELOPING A PROJECT SCHEDULE
Given what you need to do, figure out when things will happen
and when you’ll be finished (when you’ll deliver project results)
Identify dependencies between tasks (e.g., task A must be
done before task B can be started)
Use task time estimates and dependencies to create a
schedule, typically by generating a “Gantt Chart”
Important questions:
Have all dependencies been identified?
Is there a way to eliminate dependencies?
Does estimated completion fit with project objectives?
PERT – PROGRAM EVALUATION AND REVIEW TECHNIQUE
 PERT
• 1957 - the Critical Path Method (CPM) was developed as a network
model for project management.
• a deterministic method that uses a fixed time estimate for each
activity
• does not consider the time variations that can have a great impact
on the completion time of a complex project.

PERT = a network model that allows for randomness in activity

completion times.

Assumptions to create the network diagram:

an activity is a task that must be performed and an event is a milestone marking
the completion of one or more activities.
before an activity can begin, all of its predecessor activities must be completed.
project network models represent activities and milestones by arcs and nodes.
 STEPS IN THE PERT PLANNING PROCESS
a. Identify the specific activities and milestones.
b. Determine the proper sequence of the activities.
c. Construct a network diagram.
d. Estimate the time required for each activity.
e. Determine the critical path.
f. Update the PERT chart as the project progresses.
 STEPS IN THE PERT PLANNING PROCESS
a. Identify Activities and Milestones
• The activities are the tasks required to complete the project.
• The milestones are the events marking the beginning and end of one or
more activities.
• It is helpful to list the tasks in a table that in later steps can be expanded to
include information on sequence and duration.

b. Determine Activity Sequence

• This step may be combined with the activity identification step since the
activity sequence is evident for some tasks.
• Other tasks may require more analysis to determine the exact order in
which they must be performed.

3. Construct the Network Diagram

• You may use software for this step
 STEPS IN THE PERT PLANNING PROCESS
d. Estimate Activity Times
• Weeks are a commonly used unit of time for activity completion, but any
consistent unit of time can be used.
• For each activity, the model usually includes three time estimates:
• Optimistic time - generally the shortest time in which the activity can be
completed. It is common practice to specify optimistic times to be three
standard deviations from the mean so that there is approximately a 1%
chance that the activity will be completed within the optimistic time.
• Most likely time - the completion time having the highest probability. Note
that this time is different from the expected time.
• Pessimistic time - the longest time that an activity might require. Three
standard deviations from the mean is commonly used for the pessimistic
time.
• PERT assumes a beta probability distribution for the time estimates. For a beta
distribution, the expected time for each activity can be approximated using the
following weighted average:
• Expected time = ( Optimistic + 4 x Most likely + Pessimistic ) / 6
• This expected time may be displayed on the network diagram.
• To calculate the variance for each activity completion time, if three standard
deviation times were selected for the optimistic and pessimistic times, then
there are six standard deviations between them, so the variance is given by:
• [ ( Pessimistic - Optimistic ) / 6 ]2
 STEPS IN THE PERT PLANNING PROCESS – CRITICAL PATH
e. Determine the Critical Path
• That sequence of tasks that are the “bottleneck” in the schedule
•The critical path is determined by adding the times for the activities in each
sequence and determining the longest path in the project.
• The critical path determines the total calendar time required for the project.
• If activities outside the critical path speed up or slow down (within limits), the total
project time does not change.
• The amount of time that a non-critical path activity can be delayed without
delaying the project is referred to as slack time.

If the critical path is not immediately obvious, it may be helpful to determine the
following four quantities for each activity:
ES - Earliest Start time
EF - Earliest Finish time
LS - Latest Start time
LF - Latest Finish time
 STEPS IN THE PERT PLANNING PROCESS – CRITICAL PATH
ES - Earliest Start time EF - Earliest Finish time
LS - Latest Start time LF - Latest Finish time

• These times are calculated using the expected time for the relevant
activities.
• The earliest start and finish times of each activity are determined by working
forward through the network and determining the earliest time at which an
activity can start and finish considering its predecessor activities.
• The latest start and finish times are the latest times that an activity can start
and finish without delaying the project. LS and LF are found by working
backward through the network.
• The difference in the latest and earliest finish of each activity is that
activity's slack.
• The critical path then is the path through the network in which none of the
activities have slack.
CRITICAL PATH - EXAMPLE
Source: syque.com
 STEPS IN THE PERT PLANNING PROCESS – CRITICAL PATH
The variance in the project completion time can be calculated by summing the
variances in the completion times of the activities in the critical path.

Given this variance, one can calculate the probability that the project will be
completed by a certain date assuming a normal probability distribution for the
critical path.

The normal distribution assumption holds if the number of activities in the path is
large enough for the central limit theorem to be applied.

Since the critical path determines the completion date of the project, the project
can be accelerated by adding the resources required to decrease the time for the
activities in the critical path.

Such a shortening of the project sometimes is referred to as project crashing.

 CRITICAL PATH “WHAT IF” ANALYSIS
The results of this process for arriving at a project schedule are often poorly
received
“That project completion date is far too late!”
So a “what if” exercise ensues
To shorten a project’s overall duration (to be “done” sooner), you must
shorten tasks on the Critical Path (“What if task 14, on the critical
path, could be done faster?) or remove tasks from the Critical Path
(Does task 15 really depend on task 14 – what if we can, by making an
adjustment, do them at the same time, thus moving task 14 off the
Critical Path?)
Sometimes when you shorten the Critical Path, a different sequence of
tasks becomes the new Critical Path (the “bottleneck” shifts) – that is,
you’ve shortened the old Critical Path to a point where it is no longer
the Critical Path
 STEPS IN THE PERT PLANNING PROCESS
f. Update as Project Progresses
Make adjustments in the PERT chart as the project progresses. As the
project unfolds, the estimated times can be replaced with actual
times. In cases where there are delays, additional resources may be
needed to stay on schedule and the PERT chart may be modified to
reflect the new situation.
 PERT
Benefits
Expected project completion time.
Probability of completion before a specified date.
The critical path activities that directly impact the completion time.
The activities that have slack time and that can lend resources to critical path activities.
Activity start and end dates.

Limitations
The activity time estimates - subjective and depend on judgement.
Even if the activity times are well-estimated, PERT assumes a beta distribution for these time
estimates, but the actual distribution may be different.
Even if the beta distribution assumption holds, PERT assumes that the probability distribution
of the project completion time is the same as the that of the critical path.
Because other paths can become the critical path if their associated activities are delayed,
PERT consistently underestimates the expected project completion time.
The underestimation of the project completion time due to alternate paths becoming critical
is perhaps the most serious of these issues. To overcome this limitation, Monte Carlo
simulations can be performed on the network to eliminate this optimistic bias in the expected
project completion time.
 CRITICAL PATH “WHAT IF” ANALYSIS
The results of this process for arriving at a project schedule are often poorly
received
“That project completion date is far too late!”
So a “what if” exercise ensues
To shorten a project’s overall duration (to be “done” sooner), you must
shorten tasks on the Critical Path (“What if task 14, on the critical
path, could be done faster?) or remove tasks from the Critical Path
(Does task 15 really depend on task 14 – what if we can, by making an
adjustment, do them at the same time, thus moving task 14 off the
Critical Path?)
Sometimes when you shorten the Critical Path, a different sequence of
tasks becomes the new Critical Path (the “bottleneck” shifts) – that is,
you’ve shortened the old Critical Path to a point where it is no longer
the Critical Path
 ASSIGNING PROJECT RESOURCES
With tasks and dependencies identified, assign people and other resources
(e.g., specialized equipment) to tasks
Allocate resources across tasks
Make sure resources available can cover tasks
Make sure key there are no conflicts for key resources (same
person/machine can’t be two places at once)
Analyze the merits of different ways of allocating resources
Re-examine scope, schedule, and resources
Important questions:
Is work spread reasonably across resources?
Should we make adjustments to scope, schedule, or resources?
Assigning more resources is one way of shortening the CP
 KEY RESOURCES AND “SWITCHING COST”
A very common problem: Some resources are over allocated while others are
under allocated
People working on some tasks are overwhelmed, while others have nothing
much to do
Over allocated resources end up being asked to multi-task
Literally, work on more than one task at once
Their time gets allocated in smaller and smaller fractions
But there are big hidden costs in doing this…
Switching tasks takes effort
People work more hours
Value-add
Burn out, morale issues time on
Worst for key people each task

Number of tasks
THE GANTT CHART – EXAMPLE A SHEDULE
THE GANTT CHART – AN EXCEL EXAMPLE
 GANTT CHARTS
Gantt charts illustrate the start and finish dates of the terminal elements and
summary elements of a project.
Terminal elements and summary elements comprise the work breakdown
structure of the project.
 Some Gantt charts also show the dependency (i.e., precedence network)
relationships between activities.

Pitfalls:
Attempt to define the project work breakdown structure at the same time that
they define schedule activities.  the WBS should be fully defined to follow the
100% Rule, then the project schedule can be designed.
Difficult to grasp for projects with more than 30 activities
The equal horizontal dimension of activities does not take into consideration the
resource load of each activity
 MAKING TRADEOFFS
With tasks, CP, and resource assignments in place, you are positioned to make
explicit planning tradeoffs
Analyze the impact on schedule of different feasible allocations of available
resources
Determine impact on schedule and budget of adding (or subtracting)
resources (keeping in mind Brooks’s Law)
Determine impact of changes in project scope
Important questions:
Are schedule and cost consistent with project objectives?
If not, can they be made so?
Or should we change the objectives?
Can we eliminate dependencies by working differently?
Are we trying to do too much?
 PROJECT STRUCTURE – HOW MANY “CHUNKS”?
In considering scope, resource, and schedule tradeoffs, often the question of
how you might “chunk” the project comes up

What if we divide this project into smaller projects?

Can improve fit between available resources and schedule
Might allow most important objectives to be delivered sooner, at the cost of
waiting longer for some other, less important objectives

Can also have budget implications – dividing a project up into smaller chunks can
make it appear more expensive
Although it can sometimes turn out cheaper if the smaller projects have
fewer problems than the big one would have…
Which brings us to…
 PLANNING FOR PROJECT RISKS
As much as possible during planning stages of a project, draw attention to project
risks and develop plans for managing them.
Identify likely sources of risk
Develop plans to minimize probability that risks will materialize
Might result in new tasks being identified, which will require additional
resource requirements
Develop plans to minimize impact if risks do materialize
Important questions:
Have we identified all the risks we can?
Which should we worry most about (because the are very likely or would have
major impact on the project)?
 PROJECT STRUCTURE AND RISK
There is a relationship between project structure and risk
In general, larger projects involve greater risks than a series of smaller projects
(smaller projects are less complex and constitute smaller failures even when
something does go wrong)
An additional advantage in “chunking” large projects into smaller ones: Can
incorporate learning from early chunks into later chunks

Certain projects have characteristics that make risks harder to anticipate and make
smaller chunks more beneficial
If project outcomes are difficult to specify in advance (thus must be
“discovered” to some extent – such as when a user of a product can’t easily
envision how the product might be used differently)
If project objectives are likely to change while the project is in progress (due to
changes in technology, moves by competitors, etc.)
 ONGOING STATUS MONITORING
The challenge is to keep the PM and project team focused on areas that that
provide the best indication of project progress, and to maintain access to high
quality information about the progress of the project

Important questions:
How will status information be collected?
What will be monitored and how?
Are we confident in the quality of our measures of progress?
The problem of open communication: To do a good job of collecting status
information, you need people to be really honest about the problems they’re seeing
 “SWEEPING THINGS UNDER THE RUG”
A very common sequence of events on projects
Team members discover problems that will delay the project
PM and senior managers are not happy to hear of the delay and convey the
impression (often unintentionally) that the person who discovered the
problem is to blame for the delay
People get the idea that identification of problems that result in project
delays is an unwelcome behavior
They start “sweeping things under the rug”
After problems accumulate “under the rug” for some time, something goes
terribly wrong with the project…
 IN PROGRESS ADJUSTMENT AND ADAPTATION…
In every project, there is a need to adjust the ongoing project to account for
unexpected problems (or opportunities)
A continuation of the process of making planning tradeoffs
Change scope, eliminate dependencies, or add resources
Manage “scope creep” – enlarging project scope without really acknowledging
that the project is getting bigger, and without assigning additional resources or
otherwise accounting (e.g., moving deadline later) for the increase in work that
accompanies the increase in scope
Important questions:
Are mid-project requests for changes really requirements?
Should we make adjustments to the project?
Should we abandon the project?
 LEARNING FROM PROJECT EXPERIENCES
Important to capture key learning that will improve management of future projects
Conduct “post mortem” meetings
Capture and communicate key learning to others on other projects and
throughout the larger organization
Often not done, so learning gets lost
Important questions:
What worked?
What didn’t?
Have we acknowledged and celebrated good work?
 THE THREE MAIN “LEVERS” OF PM
Scope
Adjust what is included in the project
e.g., decide to drop Feature 7 from the project objectives
Resources
Adjust who is working on a project
e.g., decide to add two more people to the project
Schedule
Adjust target completion target
e.g., decide to allow another month to complete the project

You decide these things as you plan, then revisit during a project
COSTS AND SCHEDULE
 PROJECT CONTROL COST BASELINE
Develop a project cost control baseline from the project cost
estimate
Important questions:
+ How many individual cost elements can the office and field
personnel be expected to break actual project costs into for
reporting purposes?
+ How many individual cost elements can the project
management team effectively review and monitor?
+ How can Pareto’s Law be taken into account—that 80
percent of the total project cost is probably represented by
only 20 percent of the cost items?

! Beware: cost escalation

 ESTIMATING COSTS – BASIC TECHNIQUES
1. Expert opinion
2. Analogy - reviewing costs from previous, similar projects
Costproposed = Costanalogy x (Capacityproposed/Capacityanalogy)

3. Parametric - an estimate derived from an empirical or

mathematical relationship – eg. a multiple regression model that links
material cost to floor space to receiving docks in a building

4. Cost engineering - detailed cost analysis of individual cost

categories at the work package or task level. It is a bottom-up
approach.
 DETERMINING EARNED VALUE
1. Units completed:
For example, suppose that 420 linear feet (LF) of 4-inch diameter steel pipe has been
installed. If the total project requires 2,100 LF of pipe, then the percentage of completion is
20 percent (420 LF divided by 2,100 LF).

2. Incremental milestones:

When the work task involves a sequential series of subtasks, the percentage of completion may
be estimated by assigning a proportionate percentage to each of the subtasks.

For example, the installation of a major item of equipment might be broken down as follows:
Construct foundation pad 10 percent
Set equipment on foundation 60 percent
Connect mechanical piping 75 percent
Connect electrical 90 percent
Performance testing and start up 100 percent.

Percentage of completion is estimated by determining which of the milestones have been

reached.
The accuracy of this procedure depends upon a fair allocation of percentage to the subtask in
relation to costs.
 DETERMINING EARNED VALUE
3. Cost to complete:
The cost to complete the remaining work for a given task is first estimated. This detailed cost
estimate utilizes both the original cost estimate and any historical cost data acquired so far on
the project.

For example, if the actual cost to date for structural steel erection is $18,500 and the
estimated cost to complete the task is $6,500, the percentage of completion is 74%.

Earned value = % of completion x original budget cost for the task

EXAMPLE OF COST CONTROL STATUS REPORT
ELEMENTS OF A COST CONTROL SYSTEM
DO NOT FORGET ABOUT VALUE!
 COST CONTROL SYSTEMS
-Based on the variance in costs, caused by
• Resources used to accomplish the work have been paid more than was
planned.
• Resources used to accomplish the work have been consumed in more
quantity than was planned.
COST MANAGEMENT INDICES
Implementing change