Project Management Certification Notes

Rishabh Dev | Blog: rishabhdev.com | Twitter: @reachrishabh
Project Management
Notes for
Certiﬁcation

Introduction >
Project
Temporary and speciﬁc, has a start and end, delivers a
product or service or result.

Introduction >
Project vs Operations
“Usual business operations” are different as they are
recurring or repeating

Introduction >
PMP
Project Management Professional, a certiﬁcation given by the Project
Management Institute (PMI), exam based on the book called PMBOK (Project
management body of knowledge)

Introduction >
PMBOK5
47 processes, 5 process groups, and 10 knowledge areas, Vs
PMBOK 4 which has only 9 knowledge areas and only 42 processes

Introduction >
Process groups, Knowledge areas & processes
Process groups: Initiating > Planning > Execution > Monitor & Control > Closing
Knowledge Areas: Integration, Scope, Time, Cost, Quality, HR, Communications,
Risk, Procurement, Stakeholder
47 processes under classiﬁed under knowledge areas and process groups

47 processes by knowledge area

47 processes by process groups

Introduction >
ITTO
Inputs, Tools & Techniques, and Output (ITTO) are part
of each of the 47 processes

Introduction >
Project Management
Application of knowledge, skill, tools and techniques to
project activities to meet project requirements

Introduction >
Triple Constraints
SCOPE, TIME & COST. A perfect project balances all 3
without affecting the quality.

Introduction >
StandardsVs Regulations
Standard: approved by a recognised body, provides guidelines to achieve optimal results Vs.
Regulation: Gov imposed requirement, including provisions & other mandatory compliances.

Integration >
Culture
Culture affects PM directly:
Process orientation, standards and plans followed by team
Governance of management to make sure they are followed
Trainings provided by the organisation
Structure and size of the organisation

Integration >
Project Charter
Authorise the project, approval on funding
Project overview, business case, high-level requirements, project organisation,
budget estimated, assumptions, constraints and risks, formal approval

Integration >
Preliminary scope statement
Project name, Project charter, Project owner, sponsors, and stakeholders
Project statement, goals and objectives, requirements, deliverables.
Non-goals (Out of the scope), Milestones, Cost estimates

Integration >
Project CharterVs Preliminary Scope
The charter’s purpose is to formally authorise the project, the preliminary
scope statement’s purpose is to provide the overall project intent.
Audience of scope statement = anyone who wants to know about the
project, internal or external.

Integration >
Project Plan
Project schedule: key milestones
Cost plan: estimates along with degree of variation from plan to reality
Resources: people (or material) and people’s roles and responsibilities
Risks: assessing risk before the kick off is an art of experience
Quality: compliance with quality reqs of stakeholders (discussed & put into writing beforehand)
Communications: regular comm. + the medium of comm. is planned
(Example: Weekly email / Monthly video con call / etc)
Changes: a plan to address change and how it will affect other aspects.

Integration >
Integrated Change Control
Review change requests > Determine whether to schedule
them or not > manage effects on deliverables and plan

Integration >
Change Control Board (CCB)
The CCB is the change control board, which has change control meetings to
approve or reject change requests.

Integration >
Why Integrate Change Management?
Enables a shared objective
Enables proactive steps
Enables sequencing and alignment
Enables exchange of info

Integration >
Dimensions of integration
People dimension (who is doing the work)
Process dimension (what work is being done)
Tool dimension (what tools are being used)
Methodology dimension (moves beyond “in project” integration to creation of common set
of steps applied to any project to make a common methodology though a one-size-ﬁts-all
approach has it’s own potential risks

Integration >
Conﬁguration Management
Protects from unauthorised change
Speciﬁes versioning
Issues tracking and logging
Audits
Security

Integration >
Monitor and control project work
Identify variances
RCA, Problem solving, Corrective action
Manage risks, manage change
Updates on the project docs and plans

Integration >
Close Project
Check objectives met
Obtain formal acceptance
Make sure maintenance and operations arrangements are made
Make project end report
Lessons learned report (internal)

Scope >
Scope Creep
The scope is what needs to be delivered
Piling up of small changes refers to Scope Creep

Scope >
Scope Planning
Detailed scope statement based on preliminary scope statement
Formulation of WBS
How to monitor and manage change

Scope >
Scope Definition
Project objectives, Project scope description, Project requirements,
Project boundaries, Project deliverables, Product acceptance criteria
Project constraints, Project assumptions, Initial project organisation - defines stakeholders
Initial defined risks, Schedule milestones - important dates
Fund limitation, Cost estimate, Project configuration management requirements (access,
versioning, etc), Project specifications, Approval requirements

Scope >
Managing Resources
PEOPLE: Having the right people, right skills in the right numbers at
the right time. Motivating people to take ownership of the project.
EQUIPMENT: Have the right equipment at the right place and time
and the required supplies. Example: Staging servers, hosting
MATERIAL: Managing material include material requirements and
purchasing. Example: Instruction manuals

Scope >
Managing time & schedule
Figure out tasks and task durations,
determine predecessors of tasks
Done using critical path project management

Scope >
Critical Path & Float (also underTime)
When all tasks have been LISTED, RESOURCED and
SEQUENCED, some tasks will have flexibility in their
required start and finish date called FLOAT.
Other tasks have no flexibility, called ZERO FLOAT. A line
through all the ZERO FLOAT tasks is called the critical path.
All tasks on this path (and there can be multiple, parallel
paths) must be completed on time if the project is to be
completed on time.

Scope >
How to find the critical path
Start with the earliest / first task > see what tasks can’t
start until that one is finished > then pick the longest of
these tasks and it will be the next task in the critical path
> now figure what tasks depend on the completion of
that 2nd task and pick the longest of them to become
the 3rd task > continue until reaching end of the project.

Scope >
Managing Money, Cost, Proﬁt
Cost can be labor hours, tools, etc.
A design allowance or contingency allowance is added when their is any
uncertainty of cost
PROJECT BUDGET = COST + CONTINGENCY ALLOWANCE + PROFIT
Keep the actual cost at or below the estimated cost AND use as little of the
contingency allowance as possible, to maximise the proﬁt the company earns on
the project
Don’t allow the project scope to ‘creep’ upward WITHOUT GETTING BUDGET AND /
OR SCHEDULE ADJUSTMENTS TO MATCH IT.

Scope >
Scope creep types
Business scope creep: lack of requirement deﬁnition or
failure to include users till the later stages
Features or technology creep: Added by technologists
to either please customer or for gold-plating the
requirement toward perfection

Scope >
Cost Overrun
Technical: Result of imperfect forecasting techniques, inadequate data, etc
Psychological: Result of optimism bias in forecasters
Political-economic: Result of strategic misrepresentations of scope or
budget
All 3 can be considered forms of risk. A project’s budget should always
include contingency funds to cover risks OTHER THAN the scope changes
imposed on the project.

Scope >
Requirement collection doc
Doc should contain: Requirements specs for management purposes,
Statement of key objectives - ‘cardinal points’, Description of
environment in which system will work, Background info & references
to other relevant material, Info on major design constraints

Scope >
Requirement collection rules
Don’t assume you know what the customer wants, ask.
Involve users from the start
Ensure requirements are specific, realistic, and measurable
Create a clear, concise and thorough requirements documents and share it with the
customer
Confirm your understanding of the requirements with the customer by PLAYING IT BACK
Avoid talking technology or solutions until the requirements are FULLY UNDERSTOOD
Get the requirements agreed with the stakeholders before kick-off
Create a prototype if required to confirm OR refine the requirements

Scope >
Requirement collection mistakes
Basing a solution on complex / cutting edge technology which cannot be
rolled out easily to the ‘real world'
Not prioritising the requirements for example: not having lists for ‘must
have’, ‘could have’, ‘would have'
Not enough consultation with real users and practitioners
Solving the ‘problem’ before you know what it is
Lacking a clear understanding and making assumptions rather than asking

Scope >
Creating WBS
It is graphical representation of the hierarchy of the project tasks
based on 8/80 rule for WBS - NO tasks should be less than 8 hours or
more than 80 hours
Each WBS component is cross-referenced, as appropriate, to other
components in the WBS dictionary.

Scope >
Decomposition
Decomposition: The subdivision of project deliverables into
smaller, more manageable components until the work
deliverables re defend to the work package level.
The work package level is the lowest level in the WBS, and is the
point at which cost and schedule for the work can be estimated.

Scope >
Rolling Wave Planning
Decomposition may not be possible for future deliverables / or future sub-
projects. The PM team waits until the deliverables or subproject are
clariﬁed so the details of the WBS can be developed, a technique called
ROLLING WAVE PLANNING.
Example: If a project is expected to complete in 8 months, but we only
have clarity for the ﬁrst 3 months. Then, we would plan only for 3 months.
This technique uses progressive elaboration.

Scope >
Other structures
Organisation breakdown structure (OBS): hierarchical depiction of project
matching it to the units of the org
Bill of Materials (BOM): hierarchical tabulation of the physical assemblies and
components to fabricate a manufactured product
Risk Breakdown Structure: Hierarchical depicted of identiﬁed risks by
categories
Recourse Breakdown Structure: Hierarchical depiction of the resources by
type to be used on the project

Scope >
ScopeVeriﬁcation
Stakeholders formal acceptance of the completed scope
and associated deliverables, different from quality control.

Scope >
Scope Control
Change control system - tracks down changes and classifies them if they
conform to the project scope management plan
Variance analysis - evaluate the magnitude of variation relative to the
scope baseline and decide course of action
Re-planning - updates and modifications on the scope management plan
Configuration of management systems - states procedures for the status
of the deliverables and requested changes

Time >
Activity Deﬁnition
Identify the deliverables at the lowest level in
the WBS called the work package. Work
packages are decomposed into smaller
components called schedule activities

Time >
Activity Sequencing
Review all activities in the WBS to identify relationships between them, and
classifying all dependencies.
Dependencies can be external like unavailability of a new version of the tool
in the market - or internal, like unavailability of a developer for the complete
project.
Once all dependencies have been identiﬁed, a network diagram can be
created to schematically show the sequencing of projects.

Time >
Sequencing techniques: PDM
Precedence diagramming method (PDM): Construct a network diagram
using nodes to represent activities and connect them with arrows to
show dependencies.
Sample: [Start] => [Phase1] => [Phase2] => [Finish]
This is a very simplistic representation of PDM. It is also called Activity
on Node (AON).
Dependencies are important as they show the direction (sequence) in
which activities should occur.

Time >
Activity relationships
Finish-to-start relationship: if one activity must finish for another activity to start
Start-to-finish relationship: if one activity must start before another can finish
Start-to-start relationship: if one activity cannot start until another activity starts
Finish-to-finish relationship: if one activity cannot finish until another activity finishes
Note: FS is the most common one

Time >
Sequencing techniques:ADM
Arrow Diagram Method: Construct a project network
diagram using arrows for representing activities and
connecting them at nodes to show dependencies. It is
knows as Activity on Arrow and is less common than PDM.

Time >
Sequencing techniques: Conditional diagramming
Conditional diagramming methods like GERT (Graphical Evaluation and Review
Technique) and System Dynamics models allow for non-sequential activities
such as loops and conditional branches. Neither PDM nor ADM allows for these.

Time >
What affects duration estimation
Constraints: Anything that restricts a project.
Example: a developers vacation.
Assumptions: Need to be documented
Law of diminishing returns: Controls yields vs amount of labor available. Not
all activities are effort-driven and many are of ﬁxed duration. Hence, adding
more programmers would not always mean reduced time.
Parkinson’s Law: States that work expands to ﬁll the amount of time allowed.
Risks: Business risks can delay project work, need to be taken into
account.

Time >
Resource Estimation
Resources include: Equipment, Material and supplies, Money, People
Expert judgement, Alternative analysis, Published estimating data,
Project management software, Bottom-up estimating
are used for estimation

Time >
Schedule development tools
Schedule network analysis - graphical representation of project
activities - using Gantt charts & PERT charts
Critical path analysis - to check min time for completion
Schedule compression - by decreasing the time for project activities
Crashing - more resources to decrease time where possible
Fast -tracking - rearranging activities to allow parallel work where
possible

Time >
Schedule review
‘What if’ scenario analysis - risk plan based on what if questions like
what if x person goes on leave, etc
Resource levelling - rearrange sequence of activities to address the
possibility of unavailable resources
Critical chain method - Extra time between activities added to manage
work disruptions
Risk multipliers - Add extra time for high-risk activities and add time
multipliers to certain tasks or resources

Time >
Gantt Chart
A type of bar chart which illustrates start and finish dates or terminal elements
and summary elements of a project.
Terminal and summary elements comprise the WBS of the project.
It is useful for small projects that can fit on a single screen and have < 30
activities.
This is because they communicate little info per unit area of display.
The main focus is on schedule management
The horizontal bars of a Gantt have fixed height, hence can misrepresent the
resource requirements of a project, causing confusion esp. in large projects.

Time >
Project schedule control
1. Analyse schedule to determine areas which need corrective action
2. Decide speciﬁc corrective actions
3. Revise the plan to incorporate the chosen corrective action
4. Recalculate the schedule to evaluate efforts of the planned
corrective action
Repeat these steps if planned corrective action does not result in an
acceptable schedule.

Cost >
Project cost management
Ensure the project is completed within the
approved budget
Includes: Resource planning, Cost Estimating,
Cost Budgeting, Cost Control

Cost >
Life-cycle costing
Broader view of cost management to
consider the effects of cost decisions.
Example: limiting design iterations can
reduce cost but increase operating
costs for the customer

Cost >
Estimating
Uses historical data, helps determine expenses were
accurately budgeted, monitor & control overspending.

Cost >
PlannedValue, EarnedValue,Actual Cost &
Estimate at completion
PV (Planned Value) or BCWS (Budgeted cost of work scheduled): What the project
should be worth at this point in the schedule.
Earned Value (EV) or BCWP (Budgeted Cost of Work Performed): Physical work
completed to date and the authorised budget for the same.
AC (Actual Cost) or ACWP (Actual cost of work performed): Actual amount of money
spent so far.
EAC (Estimate at completion): Estimated total cost of the project at completion

Cost >
Formulas
Budget at completion (BAC) = EAC * CPI or EAC = BAC / CPI (BAC is the budget
of the project)
Estimate to completion (ETC) = EAC - AC
Variance at completion (VAC) = BAC - EAC
Cost performance index (CPI) = EV/AC (If CPI < 1, project is over budget)
Cost Variance (CV) = EV - AC
Schedule Performance Index (SPI) = EV / PV
Schedule Variance (SV) = EV - PV (Negative value means behind cost or schedule)

Cost >
Remembering the formulas

Cost >
Estimation
Enables current stage, check on funds
Budget includes direct costs (salaries, supplies,
travel for project, subcontracts) as well as indirect
costs (overhead - ofﬁce space, employee
beneﬁts, furniture, admin - accounts, legal, etc)

Cost >
Tools for estimation
Analogous Estimating: based on past projects (historical info),
top-down approach, less time and less accurate compared to
bottom-up, expert judgement based
Paramaetric Modeling Estimation: Can be Regression analysis
(mathematical modeling on historical data) OR Learning curve
model (basis: cost per unit decreases as work gets completed)
Bottom up estimation: WBS estimation

Cost >
Depreciation
To compute estimative value of any object after a few years
Straight line depreciation: same amount depreciated each year
Double-declining balance: higher deduction in the 1st year
Sum of year depreciation: Say the life is 5 years, then 1st year
deduction = 5/(1+2+3+4+5), 2nd year deduce 4/(1+2+3+4+5)
and so on.

Cost >
Cost baseline & life cycle costs
What is expected to be spent on the
project, usually an S-curve i.e. expense is
less in the start and during closure.
After project costs are called life cycle
costs

Cost >
Reserve Analysis
Estimate method which takes risk factors (which
can come during implementation) into account.
Contingency reserves required are calculated

Cost >
Budgeting
Budget is different than project cost. First find costs, identify risks, assign
a % for each risk factor, then:
Budget = Total costs + Risk % of the cost
Budget is also different than invoice, sales team adjusts profits further on
this.
It is then an Estimate until finalised and approved
100 = COST
10% = RISK
110 = BUDGET
40 = PROFIT
150 = ESTIMATE

Cost >
Determining budget
Cost Aggregation: Aggregate costs from activity level to work package
level, ﬁnal sum applied to the cost baseline.
Reserve Analysis: Contingency buffer or management reserve, not part
of the cost baseline but the budget
Historical data: From past projects
Funding Limit Reconciliation: In case of funding limitations - May lead
to revisions in schedule and resource allocation

Cost >
Risk Assessment
Risk values should be built in the project estimate, not in the sales markup.
Should take into account team experience, technology used, time
shortage, location of team, number of modular components,
dependencies on 3rd party tools, other unknowns.
Each risk item will have it’s own scope and a %

Cost >
Budget Management
Continually forecast budget, Regularly forecast
resource usage, Keep the team informed about
forecasts, Manage scope & changes
meticulously.

Quality >
Quality management
Plan Quality: identify standards and requirements
Perform QA: audit results from quality
measurements to ensure standards
Perform QC: Monitor and record results to assess
performance and make changes

Quality >
Examples of bringing quality
Prototype requirements with user managers, Designers to
consider alt approaches, All docs to include control info,
Designs to be reviewed by a different team, All completed
work to be signed off, Developers don’t test their own
work, Re-examine other deliverables when one deliverable
is changed, developers not to access live systems directly

Quality >
Standards
Format of docs, techniques used, languages
used, naming conventions, documentation
standards, processes being followed

Quality >
Reviewing quality
Check everything completed, compare with acceptable
standards, check changes, sign-off the end of the phase

Quality >
Kaizen Theory
Apply small continuous improvements to ensure
consistency and reduce costs

Quality >
Marginal Analysis
Compare the cost of incremental improvements against
the revenue increase from quality improvements.
For optimal quality, cost of improvements = cost to
achieve

Quality >
Six Sigma
Six Sigma translated to a 99.9997% yield or
99.997% defect free processes or products.
If a company is following six sigma for their
project, the expected quality will be 99.997%

Quality >
Gold-plating
Giving extras for customer happiness or
technological perfection

Quality >
Plan Quality (Inputs & Outputs)
Inputs are scope baseline, stakeholders, schedule, risk, org. process, enterprise environment.
Outputs are quality plan, quality metrics, process improvement plan, quality check lists, project doc
updates

Quality >
Plan Quality (Tools)
Control charts: Checks if a process is in control or not by plotting statistical variations
Flowcharting: Cause and effect, how components relate within a system
Cost beneﬁt analysis: Cost of quality activities must be < or = beneﬁts
Cost of quality (CoQ): Includes all of the costs to achieve level of quality
Benchmarking: As quality standard
Deign of experiments (DoE): Experiments to access output
Statistical Sampling: Select a random sample to represent a unit.

Quality >
Quality Assurance
Monitoring speciﬁc results to check compliance to standards
Has inputs like metrics and performance and outputs like doc
updates and change requests
Uses tools like audits and analysis

Quality >
Quality Control
Compare actual work to pre-determined quality standards.
Uses inputs like metrics, checklists, org. processes and
outputs like change requests and doc updates
Uses tools like charts and diagrams

Human Resource >
HR Management
Identify the team, plan for stafﬁng, get funds and workspace,
understand strengths and weaknesses of the team, review
performance, acknowledge and reward good performers,
provide leadership, guidance and training.

Human Resource >
HR management processes
4 processes: Develop HR plan > Acquire project
team > Develop project team > Manage project
team

Human Resource >
Develop HR plan
Inputs are resource requirements, org.
processes and output is the HR plan.
Tools used are Org. charts, networking, and
org. theory

Human Resource >
Organisation charts
Documents team members roles & responsibilities
Hierarchical type: top down, similar to WBS, also called OBS
Matrix-based: To clarify roles & responsibilities in cross-func.
projects. In this, RACI are the 4 key responsibilities
(Responsible, Accountable, Consulted, Informed)
Text-oriented format: written ﬁle for roles & responsibilities

Human Resource >
Project interfaces
Org. interfaces: formal and informal reporting relationships b/w units
Tech. interfaces: formal and informal reporting b/w technical
disciplines
Interpersonal interfaces: formal and informal reporting b/w
individuals

Human Resource >
Project team selection
Staff acquisition takes stafﬁng plan and
recruitment practises as inputs.
Tools used are negotiations, assignments,
and procurement.
Outputs are staff assignments and team
directory updates.

Human Resource >
Develop project team
Inputs from performance reports, and plan. Tools
like training, team-building activities, reward and
recognition, co-location. Outputs are performance
improvements.

Human Resource >
Manage project team
Inputs from assignments, reports, and plan. Tools
like conﬂict management, observation, issue log.
Outputs are process updates, plan updates and
change requests.

Human Resource >
Managing styles
Authoritative: “boss” setting will little inputs from team
Participative: project team and PM work together to
solve issues and make decisions
Laissez Faire: PM leaves it to the team to make
decisions

Communication >
Types
Ext. communication to public
Ext. communication to regulatory bodies
Governance communication to senior execs
Inter-departmental communications
Project team communications

Communication >
Communications management
Communications planning: determining communication needs of
stakeholders
Info distribution: making info available in a timely manner
Performance reporting: collecting and disseminating performance info
Administrative closure: info collection to formalise phase completion

Communication >
Identifying Stakeholders
Sponsor, Governance (org.), end users,
functional managers, project team, sub-
contractors, other employees in the org.,
the community / general public

Communication >
Stakeholders Analysis
Identify Stakeholders (map them) >
Prioritise stakeholders (high power, high
interest to low power, low interest) >
understand key stakeholders

Communication >
Stakeholders Planning
Post stakeholder analysis, gain
support from powerful stakeholders
and communicate early and frequently

Communication >
Communication framework
Communication management plan,
based on communication
requirement analysis

Communication >
Info Dissemination
Define audience, define schedule, find responsible
the team members, define medium, prep content.
Communicative via meetings, reports, dashboards,
exception reports, charts, plans, email IM, Telecon,
video presence, calls.

Communication >
Manage expectations
Important to manage both realistic and
unrealistic expectations of stakeholders.
Issue log, change log, process assets,
change requests need to be managed.

Communication >
What to include in a weekly report?
Overall project status, risks and
dependencies, issues and next steps,
summarise recent discussions and
assignments, accomplishments.

Communication >
Performance reporting
Regular weekly reports, end of
project report, future analysis.

Risk >
Risk Management Plan
Includes methodology, roles and responsibilities,
budgeting, timing, risk categories, risk portability
& impact, stakeholder tolerances, reporting and
tracking formats

Risk >
Risk Types
Business (Gain or Loss)
Pure Risk (Only risk of loss)

Risk >
Attitude toward Risk
Communication about risks about be honest
and open, Org’s risk response reﬂects if it is
risk taking or risk avoiding (or risk averse).

Risk >
Attitude toward Risk
Tolerance - areas of risk acceptable or unacceptable
Threshold - amount of risk acceptable
Levels of risk can be assigned to each work
package

Risk >
Risk Identification
Documentation reviews, Info gathering, Brainstorming,
Delphi technique (facilitator uses questionnaire on
which responses are summarised), Interviewing, RCA,
SWOT, Assumption analytics, checklist analytics,
diagrammatic techniques (cause and effect techniques,
system or process flow charts, influence diagrams)

Risk >
Risk management process
Planning tools, Qualitative tools,
Quantitative tools, Plan risk response, Plan
risk management, Identify risks, Perform
qualitative analysis, Perform quantitative
analysis, Monitor and control risks

Risk >
Highest risk phase
The initiating phase has the highest
risk of failure

Procurement >
Project funding
Externally funded: projects where an
org. is contracted to supply a product
Internally funded: projects where an
org. wants to change its operations

Procurement >
Procurement processes
Plan, conduct, administer, and
close.

Procurement >
Plan procurement
Inputs like requirements, scope, risk, cost, funding,
market conditions, constraints. Outputs like
procurement plan, SOW, selection criteria. Tools
like internal and ext. resources, resource expertise,
selection methodology, contract type selection

Procurement >
Types of contracts
Lump sum (ﬁxed price)
Time based
Retainer / Contingency fee
Percentage
Indeﬁnite Delivery (price agreement,
payment based on time and units billed)

Procurement >
Provisions
Currency (differences to be adjusted), price adjustment (to
take care of inﬂation for long duration contracts), payment
provisions (schedule and procedure of payments), bid and
performance securities, borrowers contribution (shared staff
and resources), conﬂict of interest, professional liability, staff
substitution (consultant should provide same or better staff in
such case), applicable law and settlement of disputes

Procurement >
Make or buy analysis
Consider cost, quality, and
availability. Include both qualitative
and quantitative factors.

Procurement >
Considerations
SOW, specify nature and level of
skills to be deployed, clarity on
responsibility, estimated time
schedule, acceptance criteria

Procurement >
Market Conditions
Sole source: market condition where only one seller exists
Single source: market condition where a company prefers to contract
only one seller
Oligopoly: where few sellers exist, and the action of one seller will
impact prices of other sellers
Bidder conferences: Meetings between buyer and seller before bids
are submitted, to get info from all sellers

Procurement >
Proposal evaluation
Administrative requirement (proposal deadlines, security,
signed with proper auth, company legal status
documentation, compliance)
Technical requirement (prev experience, regional
experience, after sales or tech support ability,
responsiveness)
Financial requirements (pricing)

Procurement >
Evaluation methodologies
RFQ (request for quotation): the lower price offer among
the technically compliant and responsive offers is
selected. Pass / fail method
ITB (Invitation to bid): Generally same as above, again
focused on pricing and not on ideas or concepts
RFP (request for proposal): Either based on a point system
with a min. threshold OR based on cumulative analysis.
Usually mix of merit and price though cost is not the main
criteria in this case

Procurement >
Administer procurements
Contract change control system: process to
modify contract
Inspection and audits: Acceptance criteria for
each SOW
Performance reporting
Payment system
Claims administration
Records management

Procurement >
Centralised vs decentralised
Centralised contracting: separate contracting
ofﬁce handles contracts for all projects
De-centralised: contract administrator is
assigned for each project

Procurement >
Close procurements
Inputs like project plan update, contract
doc. Outputs like formal closure,
contract ﬁle. Tools like procurement
audits, claims settlements

Procurement >
Facilitating functions
Facilitating functions of project
management are COMMUNICATION
and PROCUREMENT.

General >
Preventive vs corrective action
• Preventive action is to prevent and eliminate
occurrence of negative consequences
associated with risk
• Corrective action is to prevent recurrence and
eliminate cause of non conformities

General >
Project archives
• Once the project is complete, the
set of project records go in project
archives

General >
Enterprise benefits
• Enterprise benefits measurements
methods include scorecard modelling,
cost benefits analysis, payback
periods, and internal rate of return.

General >
First Industry
• Project management techniques
were ﬁrst accepted by the
construction industry.

General >
Delphi technique
• Delphi technique is a tool used to
secure expert judgement

General >
Project Crash
• Project crash = least cost, max
schedule compression, no
compromise on the scope

General >
Grade
• Grade = level of product or service

General >
Formal technical review
• Formal technical review performs
error check in logic, function, or
implementation (Quality)

Project Management Certification Notes

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Project Management Certification Notes

Similar a Project Management Certification Notes (20)

Último

Último (20)

Project Management Certification Notes