p15
Project Management challenges - Personnel, Estimating, Authority, Controls

p20
Success – it must be On time, on budget, high quality (scope, performance).
Success is defined by perception of others, so include all the right stake holders ( set, manage, deliver realistic expectations).

p21
Project Ground work –
P. definition - *) Why, what is success, etc. *) PM controls (accountability)
P. details - goals, constraints, schedules, estimates, etc
P. control – progressive measurement, correction action

P23
Project Life Cycle (LC) is NOT same as project management
Phases of Proj LC = Define->Plan->Execute->Close out
Define and plan = initiation

P24
Product Development Life Cycle – Requirement, Design, Construct, Operate

P25
Product vs. Project Life Cycle – Prod. LC is industry specific where as Proj. LC is industry independent.
Prod. LC focus of work require d to create prod. Proj. LC focus on managing the work
Prod. LC may contain many proj, each of which must go through the full proj LC

P26
Functional org, projects that span functional group have no func. authority.

P27
Matrix org is required when many projects span functional boundaries

P28
Project oriented org – is the program. Boeing project is responsible for everything from selling the aircraft to developing customer service process

P30
PM are leaders, otherwise, PM techniques wont work

P31
Reason for PM popularity – growing number of products. Product development process is roughly similar to that of projects

 

Chapter 3

 

P38
1^st PM task – identify stakeholders – many projects fail because they did not include one or more critical stakeholders.
stakeholders fall into a predictable set of roles.
Who will make a contribution? Who will be affected?

P39
PM questions:
What is my authority? Whom do I report to? What are expectations?
In PM, be clear about everyone’s responsibility

P40
It is not unusual for customer to have specific project tasks under definition and design phase

Process start to finish:
Break tasks down to requirements, staff, negotiate involvement, clarify plan, document responsibilities

P41
Communicate any progress related to a team/person task before the individuals actually get involved

P42
Three primary stake holders – 1) proj sponsor, 2) decision authority, 3 ) resource – func mgr

P42
Project sponsor role – independent of any proj, which enables the sponsor to act as a connection between a project and the normal decision-making process
* Ultimately responsible for success of project
* Primary task is to help proj team to be successful
* Best sponsors know that they are NOT sponsoring a project, rather a project manager and a team
    - Charter / announce project
    - Develop responsibility matrix
    - Approve SOW
    - Maintain Priority
    - Overcome PM challenges

P44
Decision authority checklist –
* Managers whose operations will be effected
* Managers representing other stakeholders
* PM reporting to
*Who will be involved in approving curriculum – has the veto power
* Who is indirectly affected by decision
* Who judges if the money was spent wisely

P45
Two primary stakeholder contributors: 1) supply requirement, 2) funding

P47
External stakeholders: Federal, state, and local government agencies- laws - (need a permit)

 

Chapter 4

 

P56
Project Rules :
1) Agreement on goals (stakeholders who agreed on terms, must approve change in rules)
2) control scope
3) Management support – Insure agreement (proj sponsor, SOW, resp. matrix, com. Plan)

P58
Project charter – demonstrate management support by proj announcement. Simple, but powerful.

P60
Statement Of Work (SOW) – a) Goals, constraints, success criteria. b) Directed solely at stakeholders. c)Intended to deal with change.
* Purpose statement – why need support, time, money – does not describe what it needs in detail
* Scope – all the work required to meet proj objective
* Deliverable – i.e. detailed product desc
* Cost & schedule – how fixed? What is the range of success? How determined?
* Objectives – specific and measurable,
* stakeholders
* chain of command – who reports to who
* responsibility matrix

P63
Product vs Project scope – prod is feature specific, proj is the work to meet objective
i.e. Installing a light switch – selection and buying of switch adds to proj scope

P68
Responsibility Assignment Matrix (RAM) – Who will make the decision? When each group needs to be involved?
* List Major activities of the project
* List the stakeholder group (rather than individuals)
* Code responsibility matrix – R=Responsible for exec, A=Approval auth. C=must Consult, I=must Inform
* Incorporate RAM into project rules. All changes must be approved by those who approved the orig.

P72
Communication plan –
* Who needs info (sponsor, func mgr, customer, proj team, vendors, etc)
* What info needed (authorization, status change[report], coordination)
*Setup escalation procedure
* Include regular scheduled progress meetings in writing

P73
Sponsor who won’t sign up for frequent status meetings or reports is signaling his or her intention to support the project from a far.

 

Project proposal content –
* State goals
* State problem/opportunity definition
* Propose solution
* Project selection / ranking – urgency, align with org, benefit (+revenue, -cost, compliance/regulatory)
* Cost benefit – (tangible, intangible, required, financial return)
* Business requirement – many completed projects are disappointment because don’t meet bus. need.
* Scope
* Obstacles and risks
* Schedule overview – high level
* project will be judged successful when we know____, we have ____, we can ____, we are ____

P146
Planning overview
* Project definition – purpose, scope, deliverable
* Risk management
* Work Breakdown Structure
* Task relationships
* Calc init schedule
* Assign and level resources

P147
Concurrent tasks – tasks that can be performed at the same time

P147
Graphing task relation –
1) relation between work packages
2) reflect constraints between work packages not resources (common error)

P149
Millstones – significant events in project. Zero duration
* Useful anchors for network
* Mark input from one party to another
* represent significant events that are not represented by a work package

P149
Every work package has specific completion criteria and tangible result

P150
Cost estimate sources
* Labor estimates
* Equipment estimates
* Material estimates
* Fixed-price bids – includes labor, equipment, material, etc. Vendor takes responsibility

P152
Total materials cost should be estimated from product specifications – not from bottom up WBS breakdown

P157
Constant productivity – total labor hours do not change despite the addition of extra people to task

P160
Float or Slack time – Subtract Early start time from late start time. All non critical paths have float.

P161
Critical path – all tasks with zero or negative float – longest duration (not necessarily most tasks)

P164
Negative float – When all the floats have been used up. Renegotiate time-cost-quality.

P169
It is the most productive to have consistent, continuous use of the fewest resources possible.

P174
Resource Leveling
Resource leveling is the last step in creating realistic schedule.
Without it – unrealistic work (over/under worked), underutilized resources, move resource from proj to proj

P174
Resource Leveling steps -
* Forecast resource requirement through the project for initial schedule (unecon. Peaks)
* Identify resource peaks
* At each peak delay noncritical tasks within their float
* Eliminate remaining peaks by reevaluating work package estimates 
    -one person do work longer
    -Add people to shorten duration
* rebuild schedule due to effect of resource & floats

 

Chapter 8

 

P183
Unpredictable factors - unknown team to PM, skills, knowledge, new technology, incorrect timing

P 184
Strategy for avoiding unrealistic estimates
* Assume thoughtful, concerned expression. State there are a lot of factors that will impact effort. List a few. And the state “I wouldn’t want to mis-lead you”
* Offer to get a sheet of paper. Start listing questions. If questionnaire is having a hard time to be specific, highlight too many unknowns for valid estimate
* Take your very best guess double it, and then double it again
* Refuse to give estimate without further investigation

P184
Building Contractors never work without a blue print, but technology professionals make mistake of working without it

P185
Estimate - Actual cost of project
Bid – includes profit + actual cost

P185
Right Estimators
* Estimators must be experienced with work
* People doing the work should be involved with estimating
    -know their own limitation
    - More motivated to achieve the estimate since they suggested
* Understand the goals and techniques of estimating. Must learn before can estimate

P186
Estimate bases – Constantly use new performance data (database)

P187
Three types of estimates
* Ballpark – idea /evaluation; avoid giving – used to evaluate whether worth to get accurate estimate
* Order Of Magnitude (ROM) – project selection
* Detailed estimate – bottom up estimate, used to manage the project and evaluate its success. Based on spec.

P189
Phase gate – decision point for evaluating whether the development should continue

P190
There is uncertainty at the beginning of every development life cycle.

Phased estimating - looks as far as what can be called a “realistic planning horizon”.
* Risk reduction – safeguards against runaway budget – always used in construction projects
* When first phase is initiated, it has “order-of-magnitude” estimate for the project and detailed estimate for the initiation phase.
* At the end of the first phase, the second phase begins with a detailed estimate for its phase and a new project order-of-magnitude estimate.
* Repeat above cycle in every phase.

P192f
Successful project managers treat every phase of development life cycle as a project.

P192
Apportioning – top down estimate
Begins with project estimate, and then assigns a percentage of total to each phases and task of proj.
Requires: 1) historical data on similar project, 2) accurate only if over all estimate is accurate.
It is order-of-magnitude estimate to identify which estimate to pursue.

P193
Parametric – Use historic data as parameter to estimate (break cost down per tile to estimate an area).
Usually applied in construction phase of a project cycle.

P198
Bottom-up-estimate – works only to build the detailed phase estimates

P199
Burdened rate - average cost of an employee to the firm. Every company has established labor rate.
Look to finance department to establish standard burdened labor rate instead of actual pay.

P199
Common mistake is to leave out cost of internal staff and non-routine internal equipment

P204
Estimating equipment used on multiple projects – spreading its cost across several projects

P204
Cost-plus contract – Labor and equipment rates are written into the contract, and the vendor bills the project for the amount of labor, equipment and materials supplied to project

P216
Estimation model
1) Establish a baseline project
2) Calibrate the time growth factor (find 6-10 proj with same team size and more complexity [i.e more features]). Make a plot of complexity count against time.
3) Calibrate people with penalty factor – find 6-10 proj with similar complexity, but with different number of developers. Plot num developers against time.
4) calibrate and validate new model.

 

Chapter 9

P222
Project leveling
1) Project, 2) Business case, 3) Enterprise

P222
Leveling at project - must have authority to change project ( cost, schedule, quality, etc)
-Re-estimate the project schedule/cost (P223)
-Change task assignment to take advantage of floats - move people to critical paths (P224)
-Add people to project
    - may decrease time, but increases cost & comm. coordination 
    - Laws of diminishing returns (P224)

P222
Leveling Business case - Beyond the authority of Proj. Mgr

P223
Leveling Enterprise - Firm has to choose which projects to pursue - Beyond authority of sponsor

P226
Integrated product teams - a team of all disciplines required to develop a component of the product

P226
Task independence and product development strategy are both factors to consider when adding people to a project. 
Greater independence = Greater constant advantage to adding more people

P226
Software development schedule is not strictly divisible by the number of people on project

P227
Actual construction of any part of a product should begin only after the design for component has been synchronized and stabilized against the design for interfacing components.

P228
Higher performer expert, may double output; however, other projects will suffer in their absence

P230
1) Create experts by putting the same people on the related tasks
2) Using WBS, ND, etc, to identify tasks that benefit most from top talent

P230
Top performers
- Complex tasks produce highest return
- Put on critical tasks
- Make good technical leads by making major design decisions
- Involve them in Risk Mngmt, estimating, task assignment

P231
Dis-advantage of vendor experts
 -Not every expert delivers
- Lost expertise

P231
Outsourcing
Benefits:
    - Specialized skills not possessed
    - Shorter duration due to experts working
Disadvantages:
    - Less control
    - Risk
    - May lead to too late to "switch horse"
   
Successful keys to outsourcing:
    1) Find qualified vendor  with clear agreements ( responsibility matrices, WBS, Network diagrams, gantt charts)
    2) Finding qualified subcontractor for large projects amounts to major sub-project itself.
    * Don't underestimate the risks & challenges of outsourcing.

P223
Overtime
- No one can really work much more than 40hr/wk continually & w. intensity required for creative work.
- There is about same under time as there is overtime
- under-time = non-work activities - personal phone calls, bull sessions, resting.

P223
Effective usage of Overtime
- Overtime should be perceived by Project Manager (PM) as over and above normal expected performance
- PM should demonstrate clearly ways in which OT can benefit individual/team
- Use OT sparingly, only where it produces great result.

P234
- Reducing Quality should never be an option.
- Cost of doing something twice is greater than doing it right the first time
- Costs: recalls, reputation, time, money
 
P223-234
Project balancing methods:

P235-240
Business case leveling
1) reduce Product scope - reduce features
2) Fixed-phase scheduling - phased estimation
3) Fast-Tracking - overlap old & new technology
4) Phased product delivery - modular build and delivery
5) Do it twice - quickly & correctly (quick & dirty, and go back)
6) Change profit requirement - may win a big project

P235 -
Remember difference between reducing product scope vs project scope.
product scope - functionality & performance
project scope - work required to deliver product

P235
Quality is defined as "conformance to requirements."  Therefore, reducing product scope to meet requirement can improve value.

P236
Fixed-phased-scheduling (phased estimating) - project phases are apportioned from top down & scheduled according to the required completion date.  At the end of each phase, the scope of the project is reevaluated.

P236
Benefits of Fixed-phased-scheduling:
   1) Since functionality can be added & removed, the schedule can be re-scoped  several times.
   2) Quality-oriented tasks won't be sacrificed.

P236
Pitfalls of Fixed-phased-scheduling
    Not everything lends itself.  For example, it doesn't make sense to add another bathroom, just because your ahead of schedule

P237
Software is a perfect candidate for fixed-phased-estimating (because it's modular)

P237
Project Manager must be ready to present hard choices to stakeholders, because fixed-phased-scheduling involves scope change

P237
Fast-Tracking
    Definition - Overlapping tasks that are traditionally done in sequence.  Building before design is complete.
    Benefits  -  Decrease scheduling - by as much as 40%
    Pitfall - Risky - slow the project down to no schedule benefit, and cost over-run

P238
Fast-Tracking assumptions
    1) 15%-30% of total design work can provide a stable design framework.
    2) Product must be capable of modular, and top-down design
    - In software risk maybe reduced because product is built incrementally

P238-239
Phased product delivery - Implement one subsystem at a time
    Best implemented in product with core functionality that other parts rely on.
    Benefit:
        a) Delivers ASAP    
        b) In IT change happens incrementally,
        c) Get feedback while product in development
        d) Longer period means smaller team & more team expertise
        e) Phased payments

    Negative:
        Parallel processing (running) of old & new methods maybe required; therefore, higher costs

P239
Do It Twice - Quickly & Correctly
    - Do it quick and dirty, and the go back
    - Best for urgent cases, where everyday, or even hour is expensive

P241
Enterprise leveling
    - Outsourcing - allows to pursue more projects
    - Phased product deliver
    - Shift work to customer
    - Reduce product scope
    - Use productivity tools - i.e. process improvement techniques

P241
Balancing requires stakeholders to face the fact about what is possible and what isn't.



Chapter 12

P329
Towards the end of the project, you have the least amount of control over cost & schedule.

P330
0-50-100 rule - As long as tasks are small, no ask will have more than 50% completion for two status meetings in a row.
0=task not started, 50%=started, but not finished, 100%=task completed.

P332
Management by exception - Keeping critical path on schedule, while ignoring non-critical tasks, which can lead to delayed project

P332
Measuring portion is useful when working with many similar tasks (move hundreds of piles of x)
However, may not differentiate between easy and difficult tasks.

P334
Status reports
Employees may complains about losing productivity to spend writing status reports - experience show rarely more than 5 minutes a day is lost.

P334
Addressing employee complaints regarding status reports
    1) explain legitimate need to track - help them understand it could help in detection of early warning signs.
    2) make report easy in increments

P3354-335
Problem with graphing cost performance
    1) rate at money spent does not indicate anything about the work being done
    2) Accounting lag time can take months before info is available


P337
BAC = Budget At Completion
BCWP = Earned Value = Budgeted cost of work performed - Your budget from Work Breakdown Structure that is completed, multiplied by percent of completed task.
This may mean work done ahead of schedule of BCWS, or work completed even if you are behind BCWS.
ACWP = Actual Cost = Actual cost of work performed
CV = Cost Variance = BCWP - ACWP
CV% =  CV÷BCWP ,  If CV% <0 Then you have cost over-run, else your under budget
CPI = Cost Performance Index = BCWP÷ACWP, If CPI<1, Then cost over-run, else your under-budget
ETC = EAC - ACWP = Estimate to Complete = budget amount needed to finish the project based on current CPI
VAC = BAC - EAC = Variance At Completion = Difference between the budget and actual cost at the end of the project
EAC = Estimate at completion = BAC * ACWP ÷ BCWP

Lecture handouts on EAC
EAC = Estimate at completion assuming everything goes as planned = ACWP + (BAC - BCWP)
EAC = Estimate at completion based on cost performance to date        = BAC÷CPI
EAC = Estimate at completion based on cost & schedule performance=BAC÷(CPI*SPI)
   
P339
BCWS = Planned Value = Budgeted cost of work scheduled - how much should have been spent by now
SV = Schedule Variance  = BCWP - BCWS
SV% = SV÷BCWS,     If CV%<0 then project is late, otherwise, your ahead of schedule
SPI = Schedule Performance Index =  BCWP÷ACWP,     If SPI < 1, then project is late, otherwise, your ahead of schedule

P339
Earned Value charts - Show cost, schedule and performance trends

P340
Secret to effective Earned Value
    - Work Breakdown Structure task must have start & end dates
    - tasks must produce tangible results
    - Cost must be assigned to tasks

P340
WBS tasks should rarely represent ongoing activities.
There will always be some tals with a planned Level Of Effort (LOF), i.e. Project management tasks,, security monitoring service

P341
CPI & SPI trends are more useful than snapshots

P342
It is possible to have SVI>1, but critical path is behind schedule.  Watch for it!

P342
Putting infrastructure for data gathering can pose a formidable task on a major project; but the alternative is even worse.

P342
Escalation thresholds - preset variances that signal severity of a problem.  For example, immediately escalate to senior manager with 10% cost/schedule variance

P343
threshold escalation can
    - skip normal project status process
    - signal upper management to get actively involved

P344
Keeping baseline cost & schedule goals visible is one-way of holding the focus on the original goals

P344
Changing baseline is a big deal; because it represents a new cost-schedule-quality equilibrium; thus, it requires stakeholders approval.

P346
Financial analysts on wall street wouldn't stand for companies releasing quarterly results based on gut feeling; they demand hard data to show quantifiable results.  Every project must hold the same standards.



Chapter 5

P95
Risk management
    - P95, means by which uncertainty is systematically managed
    - P97, specific set of activities you'll consciously perform to identify & manage risks
    - P96,  reduced uncertainty is well illustrate by insurance industry.
 
P100
Risk types:
    - Known unknowns - rain may haul cement pooring
    - Unknown unknowns - Couldn't have seen it; but seasoned project managers expect them

P98
Risk planning must happen repeatedly throughout the project.

P98
Risk control
- Known risks are watched
- risks that don't materialize are removed
- new risks are added
- repeat above steps

P98
Selecting the right project is business risk
Managing uncertainty to meet stakeholder objectives is project risk

P99
Risk management process
- Identify risks
- Analyze & prioritize - quantify potential of damage and its probability, then rank/sort them
- Develop a response - strategies for reducing risk
- Establish reserves - for both un/known risk
- Continuous risk management - monitoring, fine-tuning, communicate with stakeholders, risks are avoided & reserves are spent

P100
Planing ongoing risk management is usually documented in either communication plan or risk management plan

P100
Techniques for identifying risks
1) Ask stakeholder - interview, brainstorm w/o evaluation & w/o resolution (identification only)
2) Make your own list (risk profile)
3) Learning from the past
4) Focus on risk in the schedule and budget

P101
Include different perspectives in regards to risk - Proj. Mgr, Proj. Sponsor, team members, subcontractors, functional managers, ,etc.

P101
Risk Profile
- Build a list of questions that refine over time in regards to similar projects.
- Profiles are industry specific
- Organization/department specific
- Address product & management risks (team is geographically dispersed)
- Predict magnitude of risk
- Generated & maintained by a person independent of individual projects (see profiling questions on p102)

P103
Software Engineering Institute offers detailed list of questions for evaluating risk on software projects in its Continuous Risk Management Guidebook

P103
Historical records - Be your own historian
- Planned vs actual performance
- Problem logs
- Post project reviews
- Customer satisfactions records

 P103
Watch for tasks that are difficult to estimate schedule and budget.  Identify the reason & create strategy for risk.
 
P107
There is a temptation to flee from the hard work of developing a probability estimate for each risk.

P108
Because there are infinite number of possible risks, it is more important to quantify, prioritize, and put a budget for known risks.
Expected Value = Probability*Impact

P108
Create a Probability (y-axis) vs Impact matrix (x-axis)  - say 3x3
Put risks in quadrants based on severity.
Do something now for risks with High impact & High probability
Monitor & have contingency risks with High probability & low impact, or high impact & low probabilities
No immediate action for low risk & low probabilities
 
P110
Risk Responses
1) Accepting - recognize w/o contingency.  Will react to risk
2) Avoiding - remove the risk - change scope
3) Contingency plan - alternative course of action
4) Transfer risk - purchase insurance, fixed-price contract, cost-plus contract
5) Mitigate - work hard to reduce risk

P111
Contingency response plan  - Detectability & trigger events
1) Detection in time to respond.  Monitoring effort reflects impact, probability, and ability to monitor
2) Trigger event - illustrated example; through frog in boiling water, hell jump out;  bring cold water to boil, he'll cook to death.

P113
Identify risks that are within your control.  communication breakdown vs federal law labor dispute

P115
Steps to contingency budget
1) Identify risk & strategies to monitor
2) Estimate additional cost of executing contingency (Expected value = cost of contingency * probability)
3) Sum Expected Contingency value - which management will choke on.
4) Negotiate - there is no good/bad guy in budget allocation

P116
Set aside a specific amount for unknown unknowns

P116
High risk industries like Software, can have as much as 30% budget for risk, where as other industries may require only 5%

P117
Risk Scheduling activities
1) Monitor risk with activity log - even for no change
2) Check for new risk at regular interval of status meetings. Build climate to routinely discuss risks
3) Repeat major risk identification activities in milestones or beginning of phases
4) Check for sufficient contingency for identified risks
5) Retire the risks that don't materialize  from risk log, and log why not
6) Repeat above steps

 

P48

Project Driven / Project Mgm	Hybrid / Program Mgm	Non-Project-Driven / Product Mgm
- Has Profit & Loss responsibility - Is a recognized profession - Has multi-career paths - Income comes from projects	- Primarily production driven, but with many projects - Emphasis on new prod development - Marketing-oriented - short product life cycles - Need for rapid development  process	- Very few projects - Profitability from production - Large brick walls - Long life-cycle products

P55
Product managers usually have a much longer time frame than project managers, and never want to see their program come to an end.  Even if demand for the product diminishes.  The product manger will always look for a spin-offs to keep a product alive.

Project scope - defines work that must be done to accomplish deliverable with features and functions

Product scope - defines features or functions that characterized the deliverable

Technically oriented project mangers tend to get too involved with technology details, and lose sight of when and how to "kill" a project.  Which is why some org will have PM report to marketing