PM 1

Project Management
Manfred Roux
rouxsifi@gmail.com
1
0. Introduction
2
Organizational Topics
Who am I?
Some background & contact details
Schedule of lectures
07/29 - 09:00 18:00
07/30 - 09:00 18:00
07/30 - 09:00 18:00
08/01 - 09:00 - 12:00
Exam
Multiple choice
Date TBD What are your preferences?
Project Management I - 3
Useful References
Organizations
GPM Deutsche Gesellschaft fr Projektmanagement http://www.gpm-ipma.de
PMI Project Management Institute http://www.pmi.org/
Books & Articles

J. R. Meredith, S. J. Mantel, Jr., Project Management A Managerial Approach, Wiley &
Sons
K. Schwalbe, Information Technology Project Management, Thomson Course Technology
A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project
Management Institute, http://www.PMI.org/Marketplace
R. Mulcahy, PMP Exam Prep
Other Resources
PM Software Links: http://en.wikipedia.org/wiki/List_of_project_management_software
PM Software Directory : http://www.infogoal.com/pmc/pmcswr.htm
Good general PM reference site: http://www.maxwideman.com/index.htm
MBTI Personality Types: http://www.myersbriggs.org/my-mbti-personality-type/mbti-basics/
1. Why Project Management
The Case for Project Management
5
Project Management History
Project management has been around almost as

long as man kind
Early Projects : The Egyptian Pyramids or the
Chinese Great Wall
The Manhattan Project in the 1940 with a project
manager & a technical director
About 40 year ago PM started to become a
profession mainly driven by NASA
For the last 10 15 years it is a profession by
itself and people can become certified PMs
What is Project Management?
Project management is the application of

knowledge, skills, tools, and techniques to project
activities in order to meet project requirements
(PMI*, Project Management Body of Knowledge (PMBOK Guide), 2000, p. 6)
Projects that Failed : Example Denver
Airport
Building of new airport began 1989, planned opening 1993
Planned cost 1.7 billion USD
In 1991 BAE receives order to build automatic baggage handling

system
Objective: Speed, cost reduction, fail-proof, handling up to 1000
pieces/min
Planned cost : 192 million USD
Result
Test run 1994 failed
Opening of airport delayed until 02/1995
Adaptation of system created cost overrun of 1 million USD/day!
Damage of 500 million USD, an additional 71 million USD for manual
replacement system
BAE went broke
Example Denver Airport : What Went
Wrong?
Tight schedule
Complexity of system
New technology expected to perform faultlessly
Lack of planning
Changing requirements
Software not adaptable to changing rapidly
requirements
Denver Airport in the News
June 10, 2005 (Computerworld) -- After more than a

decade of trying to make Denver International Airport's
troubled $230 million computerized baggage-handling
system work as designed, United Air Lines Inc. is giving
up on the failed project.
"It's never worked up to its potential," said United
spokesman Jeff Green. "We've spent enormous amounts
of money over the last decade" to try to get it working,
but the only parts of the system that operate properly
are for luggage heading out of Denver on United and for
some baggage transfers between flights, he said. The
system has never been able to process luggage from
flights arriving at the airport.
Lessons Learned
Ref.: http://www.computerworld.com/managementtopics/management/project/story/0,10801,102405,00.html
"The first lesson is that the best way to build a large, complex
system is to evolve it from a small system that works. No one
bothered to get a small system up and running in the first place --
they went for the big bang."
But "once the system gets to a certain point," he said, "there is an
attitude that the project is too big to fail, that 'we have to make it
work now.' There is an unwillingness in upper management to
believe that things are as bad as they are."
Mark Keil, a professor of computer information systems at Georgia
State University and a researcher on failed IT projects, said the plug
should have been pulled in 1994, when the system failed to work as
designed.
"Whenever you talk about building the biggest system in the world,
the most complex, you should take pause. That is often a warning
sign with these projects."
Why Project Management in IT
IT projects have a terrible track record

A 1995 Standish Group study (CHAOS) found that only
16.2% of IT projects were successful and over 31%
were canceled before completion, costing over $81 B
in the U.S. alone
The need for IT projects keeps increasing
In 2000, there were 300,000 new IT projects
In 2001, over 500,000 new IT projects were started
2001 Report Showed Improvement in
Project Success
Time overruns significantly decreased to 163%
compared to 222%
Cost overruns were down to 145% compared to
189%
Required features and functions were up to
67% compared to 61%
78,000 U.S. projects were successful compared
to 28,000
28% of IT projects succeeded compared to 16%
(up to 35% success rate in 2006)
Why the Improvements?
"The reasons for the increase in successful projects vary.

First, the average cost of a project has been more than
cut in half. Better tools have been created to monitor
and control progress and better skilled project
managers with better management processes are
being used. The fact that there are processes is
significant in itself.*
*The Standish Group, "CHAOS 2001: A Recipe for Success" (2001)
Factors Leading to Project Success
Executive support
User involvement
Experienced project manager
Clear business objectives
Minimized scope
Standard software infrastructure
Firm basic requirements
Formal methodology
Reliable estimates
The Standish Group International, Inc. 2001
Lets Look @ IBM
16
IBMs Hardware Problem ... 1992
Slow time to market High development cost
Important Development Limitations
(early 1990s)
Conflicting business performance accountability

Stakeholder involvement late and incomplete
Development focus not market driven
Lack of development prioritization criteria
Weak link to customer requirements & feedback
Inability to meet project commitments
Poor discipline in early termination of projects
Proliferation of many customized tools
Overlapping portfolios
Integrated Product Development
A Product Development Management System
IPD Development Process : Key Elements
Cross Functional Teams

Executive ( IPMT )
Execution ( PDT )
Disciplined Process
6 Phases
4 Decision Checkpoints
Best-of-Breed Enablers
Market Planning Project Management
User Centered Design Reuse
$APPEALS Portfolio Analysis
Best Practices Tools & Guide
Common Building Blocks
Supporting Tools and Apps
Market Based Development Overview
Event Driven Formal Decision Check Points
(DCPs)
IPD Management Governance System
Strong Team Based Management
Metrics
IPD's Observed Benefits
Structure & Discipline

Common Framework & Decision Making Process
Persistent executive focus, perspective
Clearer Rules of Engagement
Increased integration of Marketing and Development
Business & Market Perspective

Increased business focus & accountability
Clarity across market segments, portfolio, and projects
Improved Execution
Checklists by phase minimize surprises
Customization by business area
Structured, planned activities; less react to problems
Cross-functional perspective to all major activities
Improved communication and change management
Repeatability and Lessons Learned
Documentation for clarity and general accessibility
Project Management @ IBM
In support of our strategy, IBM will manage its

business as a project-based business. Projects
are the means by which we will create solutions
to satisfy specific client needs.
The corporation will fully apply and integrate
project management into all core business
processes and systems.
IBM Corporate Executive Committee, November 1996
Project management is a critical professional discipline @

IBM
Project Management A Core Competence
Work is organized along project lines

Projects are consistently funded, staffed and managed in
all business units,and project management has a
consistent role in overall business processes
Individuals involved in project management understand
their roles inindividual and multiple projects, in terms of:
Planning
Implementing
Evaluating
Project outcomes can be predicted with high degrees of
certainty; when predictions are incorrect, you have the
knowledge and ability to adjust decisions and take
proper corrective actions early.
Project Management Organizations
Project Management Institute - PMI

Worldwide organization with roots in the US
Has several chapters in Germany
Provides certification
Gesellschaft fr Projekt Management - GPM

Organization based in Germany
Provides certification
2. Getting Started
29
Getting Started
What is a project?
What is project management?
Project life cycle and phases
The project environment
Sources of conflict in a project environment
Project management, complexity, and change
Objectives
At the end of this module, you will
Know the characteristics that define a project

Be able to describe the project life cycle
Be able to describe the project environment and
its sources of conflict
Appreciate how complexity and change influence
project management decision making
What Is a Project?
A project is a temporary endeavor undertaken

to accomplish a unique product or service
Attributes of projects
unique purpose
temporary
require resources, often from various areas
should have a primary sponsor and/or customer
involve uncertainty
The Triple Constraint
Every project is constrained in different ways by

its
Scope goals: What is the project trying to
accomplish?
Time goals: How long should it take to complete?
Cost goals: What should it cost?
It is the project managers duty to balance these

three competing goals
Project Management The Magic Triangle
Scope
Effectiveness Productivity
Quality
Budget Time
Project Size
What is Project Management?
Formal definition -
The process of bringing a project to fruition in as effective a manner
as possible
What project managers say -

Project management concerns getting the job done
On time
Within budget
According to scope
PMI definition -
"Project management is the application of knowledge, skills, tools,
and techniques to project activities to meet project requirements."
Advantages of Project Management
Better control of financial, physical, and human

resources
Improved customer relations
Shorter development times
Lower costs
Higher quality and increased reliability
Higher profit margins
Improved productivity
Better internal coordination
Higher worker morale
Project Stakeholders
Stakeholders are the people involved in or

affected by project activities
Stakeholders include
the project sponsor and project team
support staff
customers
users
suppliers
opponents to the project
Project Management Tools and
Techniques
Project management tools and techniques assist
project managers and their teams in various
aspects of project management
Some specific ones include

Project Charter, scope statement, and WBS (scope)
Gantt charts, network diagrams, critical path analysis,
critical chain scheduling (time)
Cost estimates and earned value management (cost)
How Project Management Relates to
Other Disciplines
Much of the knowledge needed to manage
projects is unique to the discipline of project
management
Project mangers must also have knowledge and
experience in
general management
the application area of the project
PM Knowledge Areas & Processes
Project
Management
9 Project Management Knowledge
Areas
Knowledge areas describe the key competencies
that project managers must develop
4 core knowledge areas lead to specific project
objectives (scope, time, cost, and quality)
4 facilitating knowledge areas are the means through
which the project objectives are achieved (human
resources, communication, risk, and procurement
management)
1 knowledge area (project integration management)
affects and is affected by all of the other knowledge
areas
Overview: 5 Process Groups and 44 Processes
Initiating (2) Planning (21) Executing (7) Monitoring & Controlling (12) Closing (2)
Project
Activity Scope
Proj. Charter Management Verification Close
Sequencing Monitor &
Plan Project
Activity Direct & Manage Control Project
Definition Project Execution Work
Scope
Preliminary Scope Activity Control
Scope Stmt Planning Duration
Activity Estimating
Resource Quality Schedule
Estimating Assurance Control
Scope
Definition
Cost Schedule
Estimating Acquire Cost Control
Development Project Team
Create WBS Cost Quality

Budgeting Team Control
Communic. Development
Planning
Manage
Human Res, Project
Risk Planning Request Seller Team
Management
Planning Response
Quality
Planning Performance
Reporting
Plan Select
Risk Plan Seller Manage
Purchases &
Identification Contracting Stakeholders
Acquisitions
Quantiative Risk Contract Contract

Qualitative
Risk Analysis Response Admin. Closure
Risk Analysis Planning
Information Integrated
Risk
Distribution Change Control Monitoring &
Control
Project Life Cycle
PMI Project Life Cycle
Example: IBMs Integrated Product
Development Model
The Project Environment
High-stress environment
Ambiguous roles and responsibilities
Multiple bosses and multiple projects
Strong competitive pressures
Sources of Conflict in a Project Management
Environment
Project priorities
Administrative procedures
Technical opinions and performance tradeoffs
Staff resources
Expenses
Schedule
Personalities
Unclear measurement
Cross-project dependencies
Project Management, Complexity & Change
Complexity is influenced by both internal and

external change
Changing players
Budgetary instability
Changing technology
Changing competitive environment
People changing their minds
Changing macro economics forces
Project Management Complexity
Complexity is a fact of life in project management
Project manager Brand managers

Sponsor(s) Executive management
Customers Production and fulfillment
Marketing & sales Procurement
Finance
Global Projects Increase Complexity
Number of interfaces
Time differences
Physical distance
Language issues
Cultural differences
Country-specific laws and regulations
Key Messages
Projects are unique and aligned with strategic

imperatives, with clear objectives, deliverables, budgets,
and schedules
Projects have a start and an end
Project managers (PMs) must know the project life cycle
and their roles in managing that life cycle
The project environment is a complex one, rife with
potential conflict - PMs must be prepared to deal with
that conflict
PMs must identify and be aware of potential conflicts
that may arise and how to manage them
3. Kicking Off the Project
52
Objectives
At the end of this module, you will be able to
Identify different forms of project organization

and the effect each has on project
communications
Describe the matrix organization
Apply project survival techniques
Prepare a project charter
Prepare a team charter
Types of Organizations Used in Projects
Functional
Projectized
Functional vs Project Work
How to Organize
Organizations in Development
Types of Organizations Used in Projects
Matrix Organization
Project Organization
The matrix form of organization affects the

Relative authority of the project manager
Relative authority of the functional manager
Communication flows
within team (intra-team communication)
with stakeholders (inter-group communication)
Effectiveness and success of the project
Project Types and Preferred Organizational
Structures
Organizational Structure Influence on
Projects
Projects in a Matrix Organization
Matrix organizations evolved from the traditional

management structure
Its multi-disciplinary team members are drawn from
various line or functional units in a hierarchical
organization
Using a matrix, a project organization is superimposed
on a functional organization
Matrix organizations are complex and present a difficult
challenge to the project manager
Challenges involve -
Authority/responsibility of the project manager and functional
manager
Communications flow (within the team and to and from other
groups)
Making the Matrix Work
Successful operation depends on the attitudes,

actions, and activities of the people involved
A project charter is extremely helpful
Project managers and functional managers must
develop good working relationships
Project managers should realize that they get
their job accomplished primarily through the
process of negotiation and leadership
Project team members must adapt a two-boss
situation
Project Organization Survival Techniques
Have a project charter

Learn how to anticipate and constructively channel
conflict
Establish a clear scope of project with team members
Develop methods to promote teamwork
Document approval of objectives, plans, and budgets
Reduce uncertainty and risk through careful and
continual planning
Develop political awareness
Know the key players
Know their goals
Know your strength and weaknesses
Project Charter
Clear statement of project intent

Preliminary delineation of roles and responsibilities
Reference of authority for the future of the project
Project charter fundamentals

Set boundaries of scope
Be as concise as possible
Identify names and titles for reasonability
Map out the flow of documentation and information in
advance
Establish expectations for change control, budget, and
status reports
How Do You Build a Team?
Select the right team members

Identify the project skills needed
Validate required skills and resources
Organize the team
Identify all subproject managers/team leads
Prepare organization chart
Establish delegation levels
Ensure open communications
Establish communication plan
Inspire team members to do their best
Incorporate new team members as they join the project
during its life cycle
Considerations for a Multi-Cultural Team
Social customs
Time zone differences
Language
Protocol practices
Documentation practices
Team Charter
Set broad performance objectives

Joining the team implies its acceptance
Sets expectations for the success of the project
Sets the roles and responsibilities for the project
team members
Sets the ground rules for the operation of the
project team, including
Administration guidelines
Conflict management
Escalation
Code of Conduct
Defines behavioral expectations

Created in a forum by the team
In seven steps
Solicit suggested behaviors from team members
Compile a list of suggested behaviors
Identify overlap
Narrow the list
Write down the Code of Conduct
Establish group commitment
Live it!
Elements of a Useful Team Charter
Team performance Rules of engagement

objectives Meeting protocols
Mutually agreed on Decision making
Signature of team members Discussion protocols
Support of agreements
Expectations of team
members / Code of Administrative procedures
Conduct Communication management
Behaviors Document control
Timeliness Point of contact
Respect Escalation procedure
Commitment Work hours (including
Openness overtime)
Key Messages
The project manager is the focal point - the person

responsible for the success of the project; he or she may
or may not be involved at the start of the project
The project manager must -
Learn to maximize the benefits of any organizational structure
used
Motivate the team to enhance its ability to function
Develop a political awareness - within company and with
clients/project sponsors, suppliers, and other stakeholders
A project charter gives the project manager authority to
apply organizational resources to project activities
A team charter sets broad performance objectives for
the team and expectations for the project; performance
objectives should be measurable
Team Member Selection :
Meyers-Briggs Personality Types
72
Personality Types
Theory of psychological type was introduced by Carl Jung

Theory was adapted and expanded by I. Myers-Briggs to make
theory accessible to individuals & groups
16 Myers-Briggs personality types (MBTI) based on
Favorite world: Do you prefer to focus on the outer world or on your
own inner world? This is called Extraversion (E) or Introversion (I).
Information: Do you prefer to focus on the basic information you take
in or do you prefer to interpret and add meaning? This is called Sensing
(S) or Intuition (N).
Decisions: When making decisions, do you prefer to first look at logic
and consistency or first look at the people and special circumstances?
This is called Thinking (T) or Feeling (F).
Structure: In dealing with the outside world, do you prefer to get
things decided or do you prefer to stay open to new information and
options? This is called Judging (J) or Perceiving (P).
Attitudes of Orientation
Reflect the ways in which you are energized and how

you structure, or live, your life.
Those who prefer Extraversion, direct energy outwardly and are
energized by the outside world.
Those who prefer Introversion, direct energy inwardly and are
energized by reflecting on their inner world.
People who prefer the Judging attitude are likely to come to
conclusions quickly and enjoy the structure provided by reaching
closure.
People who prefer the Perceiving attitude are likely to take more
time to gather information before comfortably coming to closure,
enjoy the process, and are more comfortable being open-ended.
The Four Mental Functions
Sensing, Intuition, Thinking, and Feeling.

Two of the mental functions are for gathering informationthat
is, they are used for perception:
Sensing (S) perception pays attention to details and current realities
Intuition (N) perception pays attention to meanings, patterns, and
future possibilities.
Two of the mental functions are for organizing information and
for making decisionsthat is, they are used for judgment:
Thinking (T) chooses decisions based on principles and logical
consequences.
Feeling (F) chooses decisions based on values and consequences for
people.
The Explorer - Explorer or entrepreneur type project leaders have a vision of the future and
projects are the stepping stones. They are bold, courageous and imaginative. There is a constant
search for opportunities and improvements. They are comfortable in the lead, and exude
confidence and charisma. They are good at networking and selling. They may, however, have
little time for day-to-day problems which are delegated to others. Their project power derives
from past experience, enthusiasm, and superior ability to communicate.
The Driver - Drivers are distinctly action-oriented and are both hard-working and hard driving.
They are pragmatic, realistic, resourceful and resolute, and their focus is on project mission and
precise project goals. They are generally well planned and self-disciplined, so for those who have
similar traits, they are easy to work with. Conflict is likely with those who are not so inclined.
Their power is derived from authority and they are quite prepared to use it.
The Coordinator - Coordinators are just as important when the project phase or situation calls
for "facilitation". They generally take a more independent and detached view of their
surroundings. Coordinators are responsive to the views of project team members who must take
responsibility for their own decisions. Therefore, their role is to ensure that team issues are
surfaced, discussed and resolved to the team's mutual satisfaction. These individuals tend to be
humble, sensitive and willing to compromise. The Coordinator's power is derived from his or her
ability to persuade others to compromise.
The Administrator - Administrators recognize the need for stability, typically in order to
optimize productivity through maximizing repetition to the extent possible on a project and to get
the work finished. Often, requisite information must be assembled and carefully analyzed, with
thought given to the trade-offs and how conflicts and problems can be resolved and disposed of
in advance. Work must be carefully scheduled and procedurized if potential gains are to be
realized and "all the pieces are to be carefully put in place". The Administrator's power derives
from intellectual logic and organizational achievement.
Leadership Types
More Detail Available
http://www.myersbriggs.org/
http://www.maxwideman.com/papers/profiles/intro.htm
4. Project Selection
80
Objectives
Understand project selection and its role in the

overall project
Understand processes that drive the project
selection processes
Describe financial analysis approaches used for
project selection
Projects for Selection
Where do projects come from?

Ideas are sought from business unit managers
At the start of each corporate planning cycle
And presented in some standard format
Perhaps an elemental Business Case
Or a project concept document
Note: PM service organizations

Respond to project needs but rarely initiate projects
The Project Selection Process
Projects are typically
Identified by the sponsoring organization

During the corporate planning process, e.g. as part of a portfolio
management exercise
Subjected to a screening or selection process
That is formal and consistent
Based on a viable business case
Or specific criteria, e.g. a simple risk assessment
Consistent with corporate goals and objectives
Unless a "pet project" of a corporate executive !
Managed from idea to product delivery
Portfolio Analysis in Project Selection
Analytical tool to determine investments in

products, systems, businesses, and services
Results in -
Investment priorities
Alternative strategies
Performance improvement initiatives
Financial measurements
Typically used by corporate planning, business
segments, and portfolio management/market
planning teams
Portfolio Management Logical View
Selection Responsibility
Project selection
Is the responsibility of a group of senior
managers
Representing the various corporate functional
departments
Usually rests with a corporate steering
committee
Or the "Selection committee"
Who are responsible for ensuring that the corporate
vision and objectives are implemented
Project Categories
Projects typically fall into one of the following

categories
1. A regulatory requirement
E.g. Sarbanes-Oxley, Basel II, EU Data Protection
2. A need to satisfy public safety concerns
3. An operational efficiency improvement
4. Environmental improvement or public relations
opportunity
5. New business, or economic opportunity
6. Morally the "Right thing to do"
Selection Criteria - 1
Selection criteria may include

"First cut" categorizing
Strategic fit, value and balance amongst projects
Some variation of numerical scoring

Based on a checklist and relative weighting
Or other decision models
Selection Criteria - 2
Selection criteria may also include

Comparative criteria such as
Financial analysis including
Return on investment, or internal rate of return
Cost/benefit analysis
Economic analysis
Cash flow or pay-back analysis
Financial sensitivity to risk
Next Steps
Depending on the size of the project

Allocate "investigative" funding
To fully develop the Business Case
Or
Fund a feasibility study
Or
Authorize the conceptual phase of the project to
Research the technology, its practicality
Confirm the economics
Estimate budget and resources required
Identify risks and alternatives
Sell concept, obtain approvals
Project Ranking
Compares benefit/cost by
Three types of contribution to corporate goals
Strategic improvement
Efficiency improvement
Operational continuity
Versus cost effort or size
Size may imply high risk for a small organization
Swamping of resources
Think about: Time, effort, complexity, money, resistance, resources, tradeoffs, disruption
Ranking Categories
Strategic
Directly contributes to corporate goals
Adds new revenue sources, products or services
Establishes new positioning
Efficiency
Increases production
Reduces costs
Operational
Equipment servicing to maintain output
System upgrades
To match current technology
Plotting Results
Strategic
Top Priority Medium

Low-Hanging Fruit Priority
Efficiency
High Low
Priority Priority
Operational
Effort
Small Large
Ranking Secondary Factors
Risks
Schedule risk
Cost estimate accuracy risk
Technological risk
Opportunities
Public relations
Marketing
Learning and competence
Impact on organization
Consequence of not doing
Degree of urgency
Benefits
Broadness of application
Return on investment
Non-Numeric Models
Sacred cow
Suggested by Executive
Operating necessity
Major loss without project
Competitive necessity
Address competitive pressures
Product line extensions
Fill gap, eliminate weakness, extend life of product line
Comparative benefit model
Selection based on comparison of multiple investment
opportunities
Just do it!
Easy!
Numeric Selection Models
Portfolio Analysis
Opportunities
Future
Perceived
Why not
Profitability measures
Return on sales
Return on investments and return on assets (ROA)
Net present value (NPV)
Life-Cycle Cost
Technique assesses "total cost" of project

from Concept to End-of-Life
Normalizes all risks to measure their effect on

baseline life-cycle cost (LCC)
Usually uses computer model
Generally used for complex projects that are
relatively expensive and multi-year in duration
Profitability Measures
Assess the relative levels of return to an organization

from various alternatives
May be applied to factors having nothing to do with
monetary profit or loss - are a means to evaluate the
relative desirability of a given option
Are selected for use based on the relative length of an
option, the level of investment, and the timing of inflow
and outflow
In order of increasing complexity, the most common
profitability measures are -
Net Present value
Return on sales (ROS) or simple profit
Return on assets (ROA) or return on investment (ROI)
Economic value added (EVA)
Using Financial Measures to Select Projects
and Alternative Strategies
Present value = PV
Payment today is worth more than payment

tomorrow
Present value is the value of a future payment
For a given future payment t years from now -
PV = Mt / (1 + r)t
Mt = amount of payment t years from now
r = interest rate (sometimes called "discount rate")
NPV Example
N
CashFlown
NPV =
n =0 (1 + q )n
Assume a Discount Rate of 10%

A cash flow of 10.000 EUR Present Value
today NPV = 10.000 / (1 + 0.1)0 = 10.000
in 1 year NPV = 10.000 / (1 + 0.1)1 = 9.091
in 2 years NPV = 10.000 / (1 + 0.1)2 = 8.264
in 3 years NPV = 10.000 / (1 + 0.1)3 = 7.513

Sample Calculation Net Present Value

Return on Sales (ROS)
ROS is a simple, time-independent measure of

net profit or return as a percentage of a
project's total sales or revenue generated
ROS = Net Profit / Sales
Negative return on sales indicates a loss

ROS Example
Components of a compute system are purchased

for $500,000. Additional systems integration and
programming work is performed for $200,000.
Indirect (overhead) expenses of 50% of labor
costs are allocated to the project.
Once assembled, the computer system is sold
for $1 million.
Income taxes are 40%.
Calculate net profit and return on sales.

ROS Example - Calculated
Sales = 1,000,000
Material = 500,000
Labor = 200,000
Overhead = 100,000
Profit = 200,000
Taxes = 80,000
Net Profit = 120,000
ROS = Net Profit/ Sales

ROS = $120,000 / $1,000,000
ROS = 12 %

Profit & Loss Calculation
Revenue - Cost (royalties, warranty, maintenance, base manufacturing cost, goods,...) =
Gross profit (GP); % GP (percentage from revenue)
- Unique expenses (development expense, direct marketing and services,...)
- SG&A (sales, general administration & allocations)
= NEBT (net earnings before tax) = Profit contribution
% NEBT (percentage from revenue)

Return on Assets on (ROA)
A relative measure of profitability comparing an

organization's return on an effort with its overall
investment in assets required to perform the
effort
Sometimes referred to as return on investment

(ROI)
ROA = Net Profit / Total assets

ROA Example
In the previous example, assume the computer

assembly operation required an asset base of $2
million to support its operation.
Calculate ROA.

Economic Value Added (EVA) and Economic
Value Lost (EVL)
Approach that evaluates the return-on-capital
percentage versus the cost-of-capital percentage
Can be calculated using various methods
Assesses the effectiveness of creating value for
shareholders

What is Cost of Capital?
Represents the cost of financing an organization's

operations
Reflects the minimum rate of return required by
investors
Debt holders require interest and principle re-payment
Shareholders require dividends and stock price
appreciation
Focusing on the cost of capital enables an organization
to identify development projects that create value for
shareholders

EVA Approach & Example
EVA is used to measure financial value created for shareholders

EVA = net operating profits after taxes minus the weighted average
cost of capital (NOPAT - WACC)
Using the same information from the ROS and ROA examples,
assume the weighted average cost of capital for your company is
determined to be 10%.
Calculate EVA.

Raising EVA
There's nothing fancy or complicated about how to make economic value added
(EVA) go up. It's a fundamental measure of return on capital, and there are just
three ways to increase it:
Earn more profit without using more capital

You probably spend much of your time thinking of ways to do this; cost cutting is
today's favorite method. Nothing wrong with that, but focusing on it often blinds
companies to other ways of raising EVA.
Use less capital

In practice, this is often the method that companies adopting EVA find most
effective. Coke uses plastic containers for concentrate instead of costlier metal ones.
CSX figures out how to operate with 100 locomotives instead of 150. Quaker
reschedules production to require fewer warehouses.
What to do with the capital saved? Companies can return it to shareholders through
higher dividends or stock buybacks, or can ...
Invest capital in high-return projects

This is what growth is all about. Just make sure you expect these projects to earn
more than the total cost of the capital they require.
From "The Real Key to Creating Wealth", Fortune, September 20, 1993

Summary of Profitability Measures

5. Project Definition &
Requirements
113
Objectives
Recognize the need to validate requirements

Recognize pitfalls in defining requirement
Describe how to define a requirements baseline
Prepare a scope definition document for
effective project planning

Basic Questions
The first step in the project definition process needs to

address the following questions:
Precisely who is affected by the project?
What are the requirements of those affected?
Who is involved in the delivery of work?
Where are we now?
Where should we end up?
What are the technical performance requirements?
What are the expense limitations?
What is the project's duration including time-to-market, time-to-
profitability, and total life cycle?
What are the risks?
What are most important aspects of deliverables, that is,
technical, ease of use, distribution?

Terminology & Definitons
Goals Ends that the firm strives to attain - e.g.,

become the preferred database provider of
SAP installations
Objectives What Specific targets that further the goal - e.g.,
delivering a product release world-wide by
Jan 2009 delivering certain functionality
Requirements The needs of the customer that refine the
objectives in sufficient detail to plan the
Specifications work
The firm's approach to meeting the
requirements, goals, and objectives, spelled
out in considerable detail

Project Objectives
Establish unambiguous and realistic objectives

Good objectives are unambiguously stated and contain
a measure of how to assess whether or not they have
been achieved
To be realistic, objectives must be determined jointly
by project managers, functional managers, and those
who perform the work - a top-down, bottom-up
process
Periodically evaluate whether project objectives
are being achieved
Act on results of the evaluation

Ensuring Good Product Objectives
When an objective meets the criteria it

Can survive the departure of a key sponsor or project
management team member without diluting its clarity
Matches firm's approaches to doing business
Serves the customer need without restricting how the

job is accomplished
Serves as a foundation for the work breakdown structure
(WBS)
Is S.M.A.R.T.
Specific - Measurable - Agreed to / Alingned- Realistic Timebound
Spezifisch Messbar Attraktiv Realistisch - Terminiert

Requirements Baseline & Exclusions
Needs: Client/project sponsor requests, ideas, and business requirements

Requirements: Statement of desire for a future system
Exclusions: Statements of "not-included" for a future system
Requirements Baseline: Statements of commitment for future system
Requirements Baseline is frequently also referred to as Specification

Identify & Validate Requirements
Developing a proposal
Beginning a project
Taking over a project already in process
(revalidating)
Reassessing the requirements of a project (mid-
project)

Why Establish a Requirements Baseline
The requirements baseline
Incorporates the original requirements for a

project plus or minus approved changes
Serves as the basis for managing requirements
Must be signed and approved
Helps serve as the basis of ensuring that the
project is complete
Defines the scope of the project

Requirements Baseline = Requirements-
Exclusions

Specification Questions
A review of fundamental questions can provide insight on a

project's requirements
What should it do?

Who are the customers?
How much will it cost the customer?
How will it be marketed?
Where will it be bought?
How will it be ordered?
How long will it last?

Specification Questions (cont'd)
Are similar products already in development or

operation?
What is the expense plan?
How long is the development process?
How will it be serviced?
Can the firm's existing infrastructure support it?
What outside support is required?
How will success be defined?
What support system will firm keep in place?

Identifying & Validating Requirements
Work jointly with clients / project sponsors

Obtain detailed descriptions of problems to be
solved
State the requirements explicitly and have
project staff and clients / project sponsors sign
off
Be realistic: assume that if a requirement can be
misinterpreted it will be misinterpreted
Use a scope definition document

Identifying & Validating Requirements
(cont'd)
If possible, include pictures, graphics, models and other
non-verbal exhibits in requirements formulation
Ensure that project deliverables are directly related to
requirements
Establish a system to monitor changes made to the
requirements
Educate the project staff and clients / project sponsors
about problems in specifying requirements
Obtain client / project sponsor signature on requirement
baseline

Role of Scope Definition Document
Creates a baseline for measuring and managing

change
Set measures within which to control
Prevents team from jumping in and wasting
effort
Ensures clarity of scope before detail planning
begins

What is a Scope Definition Document
Is an overview document
Sets project bounds
Establishes what the project will do and will not
do
Begins to organize project into manageable form
Is not a project charter
Is not a team charter

Contents of Scope Definition Document
Background and summary of project

Where did this project come from?
Why is it being done?
What does the customer receive or not receive by project end?
Project objective(s)
What is the target of the project?
What problem should the project solve?
What are the major components of work on the project?
Project deliverables
What are the major products required to meet the objectives?
Customer deliverables
Project deliverables
Process deliverables

(cont'd)
Key milestones
What major points in time are important to communicate?
What major points in time are important to measure against?
What are the bureaucratic milestones?
Assumptions
What unknowns are being made into knowns?
What are the operating rules and standards?
Risks
What obstacles could jeopardize project success?
Cost
Schedule
Requirements
Quality

(cont'd)
Key resource requirements
What specialized resources are necessary to complete this
project?
Human
Material
Constraints
What issues are restricting this project?
Technology
Human resources
Political
Interrelated projects
What effects are there on other programs?
What other projects are addressing related issues?
What other projects have a potential impact on this project?

(cont'd)
Acceptance criteria
What technical performance is required?
What checkpoints are in place to ensure that the right product is
being delivered in the right way?
How will success be measured?
Signatures
What reviews will be done? When?
Who approves project reviews?
Reviews
At what points will management reviews be conducted?
At what points will customer reviews be conducted?
At what points will informal (team, peer) reviews be conducted?
For what purpose?

(cont'd)
Communication plan
How will team members communicate?
What types of meetings will be held? Frequency? Purpose?
What type of reports will be written? Frequency? Purpose?
Change management plan
What process will be followed when project change occurs?
Financial analysis
Net present value (NPV)
Benefit-cost ratio
Return on sales (ROS)
Return on assets (ROA)

Pitfalls in Defining Needs
Dealing with inherently fuzzy needs

Dynamic
Uncertainty regarding who will use the product
Identifying solutions prematurely
Addressing the needs of multiple customers
Developers' values may color and distort end-user
needs
Gold-plating needs
Selective filtering of customer needs
"Father knows best" approach to recognizing and articulating
needs

Customers Frequently Cant Articulate What
They Need
They know what they don't need
As the product develops and takes on tangible
forms, customers see new possibilities
Customers know what they want when they see
it (prototype)
Customers must be taken seriously - a project
may be considered a failure if the product is not
utilized, is underutilized, or is mis-utilized by the
intended customer

Key Messages
Always do requirements analysis and validation

Ensure that you ask the right questions
Use a systematic approach
State requirements explicitly - have project staff and the
client/project sponsor sign off
Consider requirements definition between the project team and
client/project sponsor
Know the differences among requirements, exclusions, and
requirements baseline
Issues will occur that require management and resolution may
result in change
Baselines are essential to controlling the evolution of requirements
As the project manager, assume responsibility for screening change
requests, avoid scope creep, and revising the baseline

6. Developing a Work
Breakdown Structure (WBS)
137
Objectives
Develop a WBS for a project

Define the WBS dictionary
Describe the importance and uses of the WBS
for managing a project
Distinguish between cost accounts and work
packages

WBS - Work Breakdown Structure
Dominant prerequisite for successfully

integrating and controlling the total project
Framework on which a project is built and the"
map" for executing the project
Graphically depicts the hierarchy of the project

Benefits of Using a WBS
Provides the framework to identify development

projects separately from geographies,
accounting systems, funding sources, and so on
Clarifies responsibilities
Focuses attention on project objectives
Encourages detailed planning and
documentation
Identifies specific work packages for estimating
and assigning work

WBS Definitions
WBS - A task- or product-oriented family-tree division of hardware,

software, services, data, and other work tasks that completely
define the project
Size and number of WBS levels vary with project, but the WBS must
be complete to relate all elements to one another and to the total
product.

WBS Definitions (cont'd)
Cost account
One level above the work package where costs are
accrued - lowest management and control level
Work package
Lowest level of the WBS consisting of required tasks
to complete each product - used to budget and
schedule with a defined delivery date
Rule of Thumb: Work package should consist of

approximately 80 hours of labor effort
(PMI standard)

WBS Development Process
Develop and/or review project goals and

objectives
Prepare a summary (high-level) WBS
Total project: Level 1
Major subsystem and project services: Level 2
Major subsystems and project services elements:
Level 3
Meet with responsible project team members,
sponsors, and other project stakeholders
(internal and external)
WBS Development Process (cont'd)
Responsible departments and geographies

further define to lowest meaningful level, which
produces work packages, including -
Technical performance parameters
Schedule (with a defined delivery date)
Expenses
Prepare detailed WBS dictionary

WBS Dictionary
WBS dictionary must include
Work item number

Work item title
Description of work
Predecessors and successors
Work to be accomplished
Deliverable/objective
How do you know you are done?
Who needs the output?
Ownership/participation
Who is responsible?
Who else will be involved?

Use of WBS
Planning and budgeting

Funding
Estimating
Scheduling
Performance measurement
Change management

Key Points on WBS
Identify all tasks to accomplish the project

Use good judgment as the key to an effective
WBS - no hard and fast rules
Structure WBS as work will be done
Levels of detail should allow for realistic
estimating
Levels of detail should allow assignment to
single organizational control unit

Key Points on WBS (cont'd)
Limit level of detail to level of control

Each lowest level task should result in a
deliverable
Each WBS description should include an action
verb, for example -
Establish manufacturability criteria
Prepare final product proposal package
Update common software
Each task should have single, identifiable owner

Key Messages
The WBS is the cornerstone of quality project

planning
The WBS is a tool, not an end unto itself
There are multiple uses of the WBS
The WBS is not a schedule
The WBS is a good project team-building tool

7. Risk Fundamentals
"On large projects, a healthy respect for significant risks is the

difference between success and failure; and on the large
projects, the financial consequences-as well as the legal,
social, and political consequences-can be devastating.
Edward Yourdon
150
Objectives
At the end of this module, you will
Know the three items that characterize risk and

the difference between risk and uncertainty
Understand the characteristics that distinguish
risk
Know how the risk management is done and
who does risk management

Facts of Project Life
Project risk is the possibility that something may

go wrong
Or, at least, not happen as planned
It is unrealistic to assume that everything will
work as expected
Hence risk management
Tries to deal with adverse events in an organized and
systematic manner
Attempts to abate or mitigate potential risk events
Is an essential part of project management

Risk Management: What Is It?
An approach to managing that is based on

identification and mitigation of areas and events
that have the potential for causing unwanted
change in the process or product or offering
Doing so in a way that is in the best interests of

the projects objectives especially during the
implementation or execution phases

Why Engage in Risk Management?
Protect
Cost
Schedule
Specifications
Gain competitive advantage by recognizing opportunities
before competitors do
Focus on building the right offering the first time
Prevent surprises
Prevent management by crisis
Prevent problems from occurring, or if they do, from
escalating

Risk Characteristics
A definable event
Probability of occurrence
Consequences (impact) of occurrence
Risk is almost always viewed as having a loss

associated with it.

Risk as a Function of Its Components

Characteristics that Distinguish Risk
Situational
No textbook answer
Must rely on sound use of tools to deal with risk
Interdependent
One risk event can affect others
Quantity of risks may affect perceptions
Magnitude dependent
Risk acceptability is ambivalent: the greater the pay-
off, the more risk is acceptable
Break point makes any pay-off unacceptable

Characteristics that Distinguish Risk (cont'd)
Value based
Personal values affect company risk taking
Company values affect individual choices
Time based
Risk is future phenomenon only
Time affects risk perception
Risks are reversible

What Affects Risk Perception?
Control (choice)
One can be placed at risk by -

Oneself
Another
"Acts of nature" (or the government)

Information available
Inadequate
Unfamiliar
Unreliable
Unpredictable

Time
The further into the future, the greater the

degree of uncertainty
Lack of time to identify risk and perform risk
management
Can we change our actions today to make a
better situation tomorrow?

When is Risk Management Done?

Risk Preference

Who Does Risk Management?
Project manager issues request for risk

assessment to project team members
Project management team develops risk
assessment report
Project management team members develop
risk management plans based on risk
assessment report

Risk Management Process
Risk management planning

Risk identification
Qualitative risk analysis
Quantitative risk analysis
Risk response planning
Risk monitoring and control
Risk [management] does not deal with future decisions,

but with the future of present decisions. - Robert Charette, 1989

Risk Management Planning
Deciding how to approach and plan the risk

management activities for a project
Inputs -
Project charter
Risk management policies
Stakeholder risk tolerance
Templates for the organization's risk management
plan
WBS

Risk Management Planning (contd)
Risk Management Plan

Methodology
Roles and responsibilities
Budgeting
Timing
Scoring and interpretation
Thresholds
Reporting formats
Tracking

Risk Identification
Determining which risks might affect the project and

documenting their characteristics
Inputs -
Risk management plan
Project planning outputs
Risk categories
Historical information
Outputs
Risks
Triggers
Inputs to other processes

Practical Approach to Risk Identification
Use comprehensive project structure (the WBS)

and questionnaires (if available) as basis for risk
identification
Be thorough, but not absurd
Develop as complete a list of risks as possible
Assign identification tasks to appropriate team
members
Do not analyze risks at this time

Tools & Techniques for Risk Identification
Documentation reviews
Information-gathering techniques
Brainstorming
Delphi technique
Interviewing
SWOT analysis (strength, weaknesses, opportunities,
and threats)
Checklists
Assumption analysis
Diagram techniques

Brainstorming
Single brainstorming session should not last much

longer than an hour.
All ideas should be recorded.
Two basic rules should be observed during
brainstorming sessions:
1. Criticism, judgment, or analysis of the generated ideas is
absolutely prohibited during the session. Criticism can be
conducted after the idea-generation sessions have been
completed.
2. Quantity is encouraged. Variations, extensions, and combinations
of previously generated ideas are often more valuable than the
originals. Seemingly wild ideas are welcomed without comment,
just as conservative ideas are.

Delphi Technique
Group information-gathering technique without personal interaction.

Focuses the collective knowledge of the group on identifying, forecasting,
and solving problems.
Adds a formal structure to the group process and avoids bias usually
associated with the presence of strong individual personalities in the group.
Opinion Gathering and Distribution

Opinions are written and anonymous
Written ballots are collected by the process administrator, who aggregates the
responses in statistical form, and given to all panel members
Iterative Balloting
Reevaluation, voting, and further substantiation
Reasons and Consensus
Process may be accompanied by anonymous written arguments concerning why
some judgment is correct or incorrect
Iterative feedback continues until no further substantial change results (usually 4
or 5 iterations)

Risk Categories
Technical, quality, or performance risks

Reliance on unproven or complex technology
Unrealistic performance goals
Changes to the technology used or to industry
standards during the project
Project management risks
Poor allocation of time and resources
Inadequate quality of the project plan
Poor use of project management disciplines

Risk Categories (cont'd)
Organizational risks
Cost, time, and scope objectives that are internally
inconsistent
Lack of prioritization of projects
Inadequacy or interruption of funding
Resource conflicts with other projects
External risks
Shifting legal or regulatory environments
Labor issues
Changing owner priorities

Financial Risks
Project sponsor budget or funding availability

Accuracy and detail of requirements
Pricing strategy and accuracy
Competitors' pricing
Current profit potential and future business
potential
Contract type and remedies
Product cost
Warranty cost

Schedule Risk
Customer requirements
Resource availability and skill mix
Schedule realism
Startup difficulties
Cascading delays
Inadequate planning
Time-to-market
Maturity of technology

Technical Risks
Technical expertise
Developmental level of technology maturity
Size or complexity
Integration requirements
Maintenance concerns

Legal Risks
Licenses, royalties
Patent rights
Lawsuits
Data rights
Copyrights

Procurement Risks
Vendor failure to fulfill delivery commitments

Below-standard quality of parts


Other Risks
For non-software projects other risk areas may

exist, e.g.
Manufacturing Risks
Insufficient manufacturing capability
New or changed manufacturing processes

Distribution Risks
Inaccurate or changing volume production data
Distributor unable to meet schedule


Qualitative Risk Analysis
Performing a qualitative analysis of risks and conditions

to prioritize their effects on project objectives
Tools and techniques
Risk probability and impact
Probability/impact risk rating matrix
Project assumptions testing
Data precision ranking
Outputs
Overall risk ranking for the project
List of prioritized risks
List of risks for additional analysis and management
Trends in qualitative risk analysis results

Risk Management
Risk Monitor &
Identification Control
What Can Go wrong? Risk

Risk-adverse culture Analysis
Poorly defined
requirements
No integrated project Characterize the Risk Risk
schedule Probability/Likelihood Planning
Poor configuration Potential Impact /
management Consequence
Poor quality controls Risk Mitigation Risk
Risk Exposure (RE) =
High staff turnover Probability x Impact Options Tracking
Undocumented processes Risk Level: Low, Medium, Accept risk level and
High continue on current plan
Poorly defined acceptance Risk Status Monitoring
criteria Risk Type; Budget, Avoid by eliminating risk Submit weekly Top 10 Risk
Schedule, Function/Scope cause and/or consequence Report
Early/Late Impact Dates
Control the cause or Hold monthly reviews
consequence Enable risk visibilty &
Transfer the risk communicate with all
stakeholders
Actively monitor risk
mitigation actions

Qualitative Risk Rating System
High
Likely to cause significant serious disruption to schedule, increase in
cost, or degradation of performance - even with special supplier
emphasis and close customer monitoring
Medium
Has potential to cause some disruption of schedule, increase in cost,
or degradation of performance - special supplier emphasis and close
customer monitoring, however, will probably overcome difficulties
Low
Has little potential to cause disruption of schedule, increase in cost,
or degradation of performance - normal supplier effort and normal
customer monitoring will probably overcome difficulties

Evaluating Risk Impact
If the risk materializes, what would be the magnitude of the impact?
Level Scope Schedule Budget
Severe degradation in scope; loss of Cannot meet key project

5 critical function; will jeopardize project milestones. Exceeds budget by > 20%
success Slippage > xx months
Significant degradation in scope; loss Project critical path affected.

4 of significant function; may jeopardize
Slippage < xx months
Exceeds budget by 10 - 20%
project success
Minor schedule slip. Able to meet
Moderate reduction in function with key milestones with no schedule
3 limited impact on project scope float. Exceeds budget by 5 10%
Item Slippage < xx months
Minor area in scope affected; can be Able to meet key dates.

2 tolerated with little or no impact Slippage < xx months
Exceeds budget by < 5%
1 Minimal or no consequence to scope Minimal or no impact Insignificant increase in budget

Evaluating Probability of Risk Materializing
What is the probability or likelihood the risk will materialize?
Probability of
Level Likelihood
Occurrence
E Near Certainty ~ 90%
D Highly Likely ~ 70%
C Likely ~ 50%
B Low Likelihood ~ 30%
A Not Likely ~ 10%

Probability Impact Matrix
Risk Exposure
E
Probability / Likelihood
High
D
C
Medium
B
A Low
1 2 3 4 5
Impact / Consequence

Quantitative Risk Analysis
Measuring the probability and consequences of risks and

estimating their implications for project objectives
This process uses techniques to:
Determine the probability of achieving a specific project objective

Quantify the risk exposure for the project, and determine the size
of cost and schedule contingency reserves that may be needed
Identify risks requiring the most attention by quantifying their
relative contribution to project risk
Identify realistic and achievable cost, schedule, or scope targets

Tools and Techniques for Quantitative Risk
Analysis
Interviewing
Optimistic
Pessimistic
Most likely
Sensitivity analysis
Decision tree analysis
Simulation
Project simulation using Monte Carlo technique
Cost risk analysis based on WBS as its model
Schedule risk analysis using PDM (Preference Diagramming
Method)

Cost Estimates and Ranges from the Risk
Interview
The risk interview determines the three-point estimates for each

WBS element.
The traditional estimate of 41, found by summing the most likely

costs, may be relatively unlikely.

Decision Tree Analysis

Risk Response Planning
Developing procedures and techniques to enhance

opportunities and reduce threats to the project's objectives
Avoidance
Mitigation
Seeks to reduce the probability and/or consequences of an
adverse risk event to an acceptable threshold
Acceptance
Active acceptance (contingency plan)
Passive acceptance (no action)
Transference (Deflection)
Shifts consequences & responsibility for managing a risk to a
third party but does not eliminate the risk

Output from Risk Response Planning
Risk response plan

Residual risks
Secondary risks
Contractual agreements
Contingency reserve amounts needed
Inputs to other processes
Inputs to revised project plan

Factors Affecting Mitigation Strategies
Project phase and application

Size
Priority
Complexity
Expense
Time available
Cost of technique
Required level of detail
Ease of use
Resource availability
Project manager and sponsor commitment

Risk Monitoring & Control
Monitoring residual risks, identifying new risks, executing

risk reduction plans, and evaluating their effectiveness
throughout the project life cycle
The purpose of risk monitoring is to determine if -
Risk responses have been implemented as planned
Risk response actions are as effective as expected, or if new
responses should be developed
Project assumptions are still valid
Risk exposure has changed from its prior state, with analysis of
trends
A risk trigger has occurred
Proper policies and procedures are followed
Risks have occurred or arisen that were not previously identified

Risk Management : A Few Questions to Ask
Yourself
Can you list the current top ten project risks?
Has a Risk Management role been assigned to the project?
Are risks determined through established processes for risk
identification, assessment, and mitigation?
Is there a database that includes all nonnegligible risks in terms of
probability, earliest expected visible symptom, estimated and actual
schedule, and cost effects?
Are all project personnel encouraged to become risk identifiers?
Is the database of topten risks updated regularly?
Are user requirements reasonably stable?
Do you know how the risks are changing over time?

Key Messages
Every risk consists of an event, a probability, and an

amount at stake - none of which can be ignored
Risk presents the opportunity for exposure and leverage
A process approach to risk management enhances the
possibilities for risk mitigation and abatement
Risk assessment is initiated during the concept phase
and continued through the end-of-life phase
Risk mitigation strategies should be developed during
the plan phase
Project and functional managers collaborate to assess
and mitigate risk

End Section I
197

PM 1

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PM 1

Загружено:

Авторское право:

Доступные форматы

Project Management

Books & Articles

The Case for Project Management

Project management has been around almost as

Project management is the application of

In 1991 BAE receives order to build automatic baggage handling

June 10, 2005 (Computerworld) -- After more than a

IT projects have a terrible track record

"The reasons for the increase in successful projects vary.

*The Standish Group, "CHAOS 2001: A Recipe for Success" (2001)

Slow time to market High development cost

Conflicting business performance accountability

Cross Functional Teams

Supporting Tools and Apps

Structure & Discipline

Business & Market Perspective

In support of our strategy, IBM will manage its

Project management is a critical professional discipline @

Work is organized along project lines

Project Management Institute - PMI

Gesellschaft fr Projekt Management - GPM

At the end of this module, you will

Know the characteristics that define a project

A project is a temporary endeavor undertaken

Every project is constrained in different ways by

It is the project managers duty to balance these

What project managers say -

Better control of financial, physical, and human

Stakeholders are the people involved in or

Some specific ones include

Create WBS Cost Quality

Quantiative Risk Contract Contract

Complexity is influenced by both internal and

Complexity is a fact of life in project management

Project manager Brand managers

Projects are unique and aligned with strategic

At the end of this module, you will be able to

Identify different forms of project organization

The matrix form of organization affects the

Matrix organizations evolved from the traditional

Successful operation depends on the attitudes,

Have a project charter

Clear statement of project intent

Project charter fundamentals

Select the right team members

Set broad performance objectives

Defines behavioral expectations

Team performance Rules of engagement

The project manager is the focal point - the person

Theory of psychological type was introduced by Carl Jung

Reflect the ways in which you are energized and how

Sensing, Intuition, Thinking, and Feeling.

At the end of this module, you will be able to

Understand project selection and its role in the

Where do projects come from?

Note: PM service organizations

Projects are typically

Identified by the sponsoring organization

Analytical tool to determine investments in

Projects typically fall into one of the following

Selection criteria may include

Strategic fit, value and balance amongst projects

Some variation of numerical scoring