2. Software Tools for Project Management
• PM computer tools can organize calendar information:
• Holidays
• Vacations
• Other non-project factors
• Tools can provide both tabular resource reporting and
resource histogram analysis, for identifying
overcommitments and undercommitments.
3. Computer Tool Considerations
• Select a tool that meets your needs without excessive
overhead or a steep learning curve.
• Coordinate tool selection with peers.
• Favor options with available training and mentors.
• No tool provides “artificial intelligence.”
• Date formats: On global projects, never use default date
formats. Select a display format that will be
unambiguous for everyone.
(What is“12/6?” Is it June 12 or December 6?)
4. Analyze Project Constraints
• Identify differences between the bottom-up plan and
the stated project objective.
• Review project priorities.
• Determine which changes to consider first.
Time/
Schedule
Cost/
Resources
Scope/
Deliverable
Time CostScope
Least Flexible
Moderately Flexible
Most Flexible
5. Explore Plan Tradeoffs
• Seek alternatives.
• Using priorities, explore options:
• Consider alternate plans
Shift resourcesModify workflow
A B C
BA
C
Cut features
6. Optimize Plans
• Computer tools can help with ‘What if?”
• Make project changes you are empowered to
make.
• Seek guidance from project sponsor where
needed.
• Gain agreement and buy-in for revisions.
• Revise your plans.
• Document one or more project options.
9. Example Project Risks
Schedule risks:
• Critical path activities with long durations
• Interfaces with other projects...
Resource risks:
• Loss of contributors with unique skills
• Work requiring remote (or unknown) resources...
Scope risks:
• Activities requiring new, untried processes
• Technical and performance challenges...
General risks:
• Communications problems
• Reorganizations, loss of sponsorship...
12. Risk Probability
Risks are associated with uncertain, future
events.
• Estimates of probability (likelihood) are between
0% and 100%.
• Probabilities may be assessed as percentage ranges
(Qualitative) or percentages (Quantitative).
Qualitative probability ranges (such as H/M/L)
are generally sufficient for rank-ordering risks.
13. Risk Impact
Impact estimates the consequences for your project,
should the risk occur.
• Impact may be assessed as ranges or categories of impact to one or
more project objective parameters, or as estimates of time lost, money
spent, extra effort, or other impact.
• Impact measures may have no upper bound.
Qualitative assessment based on defined categories is
generally sufficient for rank-ordering risks, such as:
• High: Threatening the project objective
• Medium: Requiring significant replanning
• Low: A nuisance
14. Example Risk Register
Risks
Probability
(H/M/L)
Impact
(H/M/L)
Software expert unavailable
Contractor Incompetent
Purchased component late
Software development too slow
Test gear not available
M H
M M
HL
L M
L L
HM
M
M
ML
L
Overall
Risk
“Overall Risk” combines the estimates for probability and impact, and is used to rank
order the risk register’s list.
16. Response Techniques
Brainstorm responses to risks, considering:
• Avoidance (Replan project to remove the risk)
• Mitigation (Revise plans to lower risk probability
and/or impact)
• Transfer (Shift all or part of risk impact to others)
• Acceptance (Leave plans unchanged, but monitor the
risk, and where appropriate, establish contingency
plans for recovery.)
17. • Identify specifics, not just general risks.
• List the “Top 10”—Keep risks visible.
• Document contingency plans.
• Assign triggers and owners.
• Plan responses to all big risks
and document all risks.
• Assess project size (effort months).
• Establish project contingency reserves, based on risk (time
and/or budget).
Responding to Project Risks
20. Negotiate Project Changes
If you have a plan that is consistent with the project objective,
commit to the project and use it.
If your plans fail to meet the project objective, propose several
project options, with a recommendation, to your sponsor. For
example:
• Adjust the deadline
• Increase the budget
• Reduce the scope or deliver it in phases
• Improve (or train) resources
• Make other project changes
Negotiate agreement on a realistic, plan-based project with your
sponsor and key stakeholders.
21. Adjust Project Plans
Use project information:
• High-level charter and summary of objectives
• High-level WBS and summary project schedule
• Assessment of resource requirements and capacities
• Major assumptions and risks
Knowledge is power. Use project information to clearly
show what is and is not feasible, and use fact-based,
principled negotiation to avoid “the impossible project.”
23. Assemble Project Documents
Project definition documents
• Project Charter
• Requirements, constraints, assumptions, and priorities
• Staffing roster
Project planning documents
• WBS, schedule, resource plans, and risk register
• Quality, communications, procurement and other ancillary
plans
Project status documents:
• Status reports
• Change logs, issue reports, and project reviews
24. Set the Project Baseline
• Get sponsor and stakeholder approval
• Freeze project specifications
• Initiate change control
• Set the baseline in computer scheduling tool
• Publish and distribute approved plans
25. Sponsor and Stakeholder Approval
Validate your project plans.
Plan
Project
Plan
Sponsor
(Customers/Stakeholders)
Objectives
Project Manager/
Team
26. Freeze Project Specifications
Project deadlines, resource commitments, and
scope are linked.
For your baseline plan, (or at a minimum for the
upcoming phase of work), clearly document the
specific scope requirements that are “In Plan” and
define the project Statement of Work (SOW).
27. Initiate Change Control
Gain agreement on a sufficiently formal change control
process:
• Log and publicly document all change requests.
• Identify who will be responsible for change management
decisions.
• Determine how to analyze all proposed changes.
• Establish criteria for accepting, rejecting or deferring a
change; reject most of them.
• Communicate and document status of all requested changes.
28. Scheduling Tool Baseline
If using a computer scheduling tool, lock the
baseline schedule in the tool’s database.
Begin tracking all activities and using the tool to
highlight all variances.
29. Publish and Distribute Plans
Inform all stakeholders of the details of the project
baseline decisions.
Store all project baseline documents in a public
“Project Management Information System” (PMIS)
that is easily assessed by all project team members
and stakeholders.
31. Project Execution Decisions
Finalize and document:
• Frequency and methods for collecting status
• Frequency and types of reporting
• Frequency of meetings
• Practices for storing project information
• Tools and systems to be used
• Other significant project processes
32. Project Metrics
Chose metrics that:
• Support overall project objectives
• Positively influence team behavior
• Assist good decision-making
• Focus on process performance, not punishment
Some typical metrics:
• Critical path activity slippage
• Issues opened and closed
• Number of approved scope changes
• Excess consumption of effort or funds
• Missed milestones
33. Project Checkpoints
For each defined project checkpoint (life cycle
phase transition, cycle or iteration completion,
interim scope delivery, or stage-gate), verify:
• Timing
• Required data and other input deliverables
• Stakeholder involvement
• Decisions to be made
• Decision criteria
• Checkpoint output deliverables
37. Scope Change Management Process
No
Yes
Document
Proposed
Change
Proposal
Complete?
Log the
Change
Analyze the
Proposed
Change
Approved?
Approved with
Modifications?
Publicize,
Document, and
Implement Change
Reject or Defer
the Change;
Communicate
Resolution
Yes Yes
No No
38. Change Proposals
Document proposed changes, including:
• Description of the change
• Business justification for the change, including
credible estimates
• Known consequences of making the change
• Stakeholder support for the change
39. Assessment of Scope Changes
• Log changes requested
• Verify proposal information
• Characterize the change
• Mandatory (Analysis gap, Dependency, Problem)
• Discretionary, Scope Creep
• Analyze the proposed change
• Benefits
• Costs
• Other impact
41. Change Follow-up
Communicate decisions:
• If rejected, document the reason.
If accepted, take action:
• Update planning documents
• Implement accepted changes
• For major changes, review and update the
project baseline.
45. Status Tracking and Reporting
Manage both inbound and outbound project
communications.
Commit to a tracking frequency (generally weekly).
• Track activities from WBS.
• Monitor status every cycle.
• Intensify collection when needed.
• Focus on schedule, cost, and other significant
metrics.
46. Status Strategies
Too little status
information:
• No information
• Low effort
• Creates confusion
Too much status
information :
• Information overload
• Lots of work
• Creates confusion
So:
• Keep your process simple
• Collect important data you will use
• Be consistent
47. Status Collection Methods
• Electronic Mail
• One-on-One Discussions
• Online Collection Systems
• Reports and Forms
• Project Office
48. Status Collection Pitfalls
• Lack of Discipline / Frequency
• Not Using Collected Data
• Killing the Messenger
• Poor Data Quality
49. Analyze Variances
• Compare actual status data with the expectations of
the baseline plan.
• Calculate differences and identify significant
variances.
• Identify any trends in the project that may impact
later work.
50. Variance Trends
Identify:
• All slippage on the critical path.
• Excess consumption of money or effort.
• Slippage on non-critical tasks that are similar
to critical tasks later in the project.
• Staff performance problems.
• Other significant problems.
51. Assess Variance Impact
For each significant variance:
• Focus on root causes, not on “who to blame.”
• Use soft data to detect the source of project
problems
• Determine whether impact is short-term, long-
term, or repeating.
• Be proactive; begin to address small problems
while they are small.
52. Manage Issues
Create an issue log as part of your PMIS and ensure that
your project team and appropriate stakeholders have
access. A sample log:
Confirm issue ownership, and secure commitments for
resolution timing. Track status of open items with other
project status.
ID Description Opened Due date Priority Owner Status Comments
41 Part
shipped late
03 Jan
20xx
31 Jan
20xx
High Radar Open Expediting
from alternate
source
53. Plan Responses
Brainstorm as a team.
Work to address problems, not just symptoms.
Possible strategies:
• Responses that worked on earlier problems
• Documented contingency plans
• Revisions to schedule logic
• Small resource shifts
• Revisions to scope
54. Implement Responses
• Analyze change proposals.
• Apply your change
management process
• Select the best option.
• If the change affects
your project objective,
revalidate the project.
• Implement the change.
Changes Validation
Sponsor
(Customers/Stakeholders)
Issues
Project Manager/
Team
55. Evaluate and Follow Up
• Verify that the response was effective.
• Test for unintended consequences, on this and other
projects.
• If problems persist, try again (or escalate).
56. Escalate Persistent Problems
Escalate issues and other project problems only as a last
resort, following unsuccessful attempts at resolution
through issue management and other efforts. Process:
• Promptly recognize problems that are beyond your control.
• Outline options and recommendations for resolution.
• Document status and consequences of failure to resolve the
problem.
• Involve your project sponsor and appropriate stakeholders in
taking corrective action.
• Track activities and ensure resolution.
