1. PERT REVIEW (last part of Ch 7) 2. Time and Cost Estimation TODAY.
-
Upload
veronica-hudson -
Category
Documents
-
view
215 -
download
0
Transcript of 1. PERT REVIEW (last part of Ch 7) 2. Time and Cost Estimation TODAY.
1. PERT REVIEW (last part of Ch 7)
2. Time and Cost Estimation
TODAY
PERT (Program Evaluation and Review Technique)
Not supported by MS Project Gives you probabilities of completion of a
project by a certain time Calculates a standard normal random
variate and uses a probability table to find its probability
PERT INPUTS
A = most optimistic time M = most likely time B = most pessimistic time
PERT formulas
Task mean = (A + 4*M + B)/6 Task Std. Dev. = (B-A)/6 Project mean = sum of all the task means of
tasks on the critical path Project std. Dev = sum of all the task
standard deviations of tasks on the critical path
Where does Estimating occur within PMBOK?
What process group? What knowledge areas? Can you name some of them?
Answers
The planning process group In the Time Management and Cost
Management Knowledge Areas Time Management
– Estimate Activity (Task) Resources– Estimate Activity (Task) Durations
Cost Management– Estimate Costs
Estimation
What are the inputs to these processes? What tools and techniques?
Estimation: An ART
That made McDonnell (of McDonnell/Douglas Aircraft) wealthy
Accurate intelligence information is a help
INPUTS
1. Activity list2. Constraints3. Assumptions4. Resource requirements5. Resource capabilities6. Historical information
TOOLS
1. Expert judgment
2. Historical data3. Analogous estimating4. Simulation
OUTPUTS
1. Activity duration estimates
2. Basis of estimates3. Activity list updates
Tools and Techniques Calibration and Historical Data Individual Expert Judgment Decomposition and Recomposition Estimation by Analogy Proxy-based Estimates Expert Judgment in Groups Software Estimation Tools Use of Multiple Approaches
Estimation Methodologies
Most firms have their own methodology Standard Procedures Once again, what do we estimate?
– Resources– Time– Cost
The Cost estimation Story—Steve McConnell
You can’t tell exactly what its going to cost
until you know exactly what IT is.
(Which is why we spent so much time
talking about thorough product conceptualization and definition)
Differentiate Estimates from Targets and Commitments
“We will have it done in three months” “Why three months???” “Because that is when the trade show
happens…”
Is it better to overestimate or under estimate
Effect Cost
Schedule
100%<100% >100%
Underestimation Overestimation
Target as a Percentage of Nominal Estimate
A Rule of Thumb
The time to design, document and code a module =
equals the time to debug it (TEST IT)
According to Gildersleeve
Estimating Rules (Rakos) Never use inexperienced persons to estimate Get group estimates if possible Never force an estimate on a programmer Never take an average of different estimates Granularize down to FOUR or less weeks, roughly Always add for contingency Always quote a range when giving estimates
Rakos’ Conclusions to Estimating
Our weakest talent Estimating is iterative Estimating is still an art
Review: Project Time Management Processes
Project time management involves the processes required to ensure timely completion of a project. Processes include:– Define activities– Sequence activities
– Estimate Activity resources– Estimate Activity durations– Develop Schedule– Control Schedule
Which of these gets performed in the Planning and Budgeting Stage??
A Typical Task Duration Process
Assign the task to a project player Ask the player how long it will take him or her to
complete the task (This gives the player ownership in the planning)
Player provides their best estimate The player understands that they will be required
to complete the task within their estimate—their feet will be “held to the fire”
Time Estimation: Goldratt
Claims team players add safety to their estimates
What is safety?? Can determine how much by asking the
question, “How sure are you that you will finish your task in the time you allotted?”
Time Estimation--programmers
Naïve programmers have a horrible reputation for underestimating task durations and costs
Time Estimation—making time for creativity: SLACK
Keep in mind that customers unintentionally put projects under extraordinary schedule pressure—more for less
A consideration in schedule development is to take the tasks requiring creativity and place them on ____?!?
Needed: A Rule-based Expert System for adjusting individual
task durations IF ESTIMATER IS SEASONED
(EXPERIENCED) AND IF THE WORK PACKAGE REQUIRES CREATIVITY ON THE PART OF THE ESTIMATOR, THEN LEAVE ESTIMATE AS IS.
IF ESTIMATER IS NOT SEASONED AND ESTIMATE APPEARS TO BE OPTIMISTIC, THEN INCREASE ESTIMATE BY 30%.
ANOTHER AI RULE
IF ESTIMATOR IS SEASONED AND ESTIMATOR ASSERTS 90% OR ABOVE CONFIDENCE HE WILL COMPLETE WORK WITHIN HIS ESTIMATE AND IF WORK PACKAGE DOES NOT REQUIRE SIGNIFICANT CREATIVITY, REDUCE ESTIMATE BY 40% -- 50%
Time Estimation
What are the three approaches to time estimation??– Expert judgment– History database– Computer model or formula
Project Cost Management Processes Plan Cost Management Estimate Costs: developing an estimate of
the costs and resources needed to complete a project
Determine Budget: allocating the overall cost estimate to individual work items to establish a baseline for measuring performance
Control Costs: controlling changes to the project budget
Cost Estimating
We need to speak the language and understand the terminology:ROI, IRR, NPV, Sunk costsTangible and intangible costsDirect and indirect costsLearning curve theoryReserves ($ included in a cost estimate to
mitigate cost risk; also called contingency reserves)
Cost Estimating
An important output of project cost management is a cost estimate
There are several types of cost estimates and tools and techniques to help create them
It is also important to develop a cost management plan that describes how cost variances will be managed on the project
Proposal Pricing Strategies--Kerzner
Type I Acquisition: One of a kind project with little or no follow-on opportunity
» win the project, perform well and make a profit
Type II Acquisition: New Program with potential for large follow-on business or representing a desired surge into a new market
» win the project, perform well and gain a foothold in a new market segment, usually at a loss
Table 6-2. Types of Cost Estimates
Type of Estimate When Done Why Done How Accurate
Rough Order of Magnitude (ROM) WAG SWAG
Very early in the project life cycle, often 3–5 years before project completion
Provides rough ballpark of cost for selection decisions
–25%, +75%
Budgetary Early, 1–2 years out Puts dollars in the budget plans
–10%, +25%
Definitive Later in the project, < 1 year out
Provides details for purchases, estimate actual costs
–5%, +10%
Estimation in General—COST or TIME
History data base Expert judgement a model like COCOMO
Cost Estimation Tools and Techniques 4 basic tools and techniques for cost estimates
(Schwalbe—Ch 6):– Analogous or top-down: use the actual cost of a previous,
similar project as the basis for the new estimate
– Bottom-up: estimate individual work items and sum them to get a total estimate
– Parametric: use project characteristics in a mathematical model to estimate costs
– Computerized tools: use spreadsheets, project management software, or other software to help estimate costs
Constructive Cost Model (COCOMO)
Barry Boehm helped develop the COCOMO models for estimating software development costs
Parameters include source lines of code or function points
COCOMO II is a computerized model available on the web
Boehm suggests that only parametric models do not suffer from the limits of human decision-making
Stop here—will not test you on anything else
Lefkon’s Methodology
1. Divide the software project into as many individual steps/tasks/modules as possible.2. Predict the level of effort required to complete each task and multiply that prediction by 2. 3. Add up the numbers and multiply by 2.0 again to account for testing and debugging.4. Take the total and multiply by 1.25 to account for meetings, administration, and paperwork.5. Multiply this level of effort by your company’s “magic number” for labor costs.
Lefkon’s Methodology
6. Present this to management as a range. Take the cost as predicted above and present the range as –10 percent and +25 percent.
7. Stand your ground and remind management that you did not arbitrarily come up with these numbers and they cannot be adjusted arbitrarily. You may have to suggest reducing scope and cost if management does not agree with your estimate.
8. Revise your project budget as you undertake and complete the project.
Typical Problems with IT Cost Estimates
Developing an estimate for a large software project is a complex task requiring a significant amount of effort. Remember that estimates are done at various stages of the project
Many people doing estimates have little experience doing them. Try to provide training and mentoring.
IT People have a bias toward underestimation. Review estimates and ask important questions to make sure estimates are not biased
Management wants a number for a bid, not a real estimate. Project managers must negotiate with project sponsors to create realistic cost estimates
Table 6-3. Business Systems Replacement Project Cost Estimate Overview
Category DescriptionObjective Install a suite of packaged financial applications
software which will enable more timelyinformation for management decision-making,easier access to data by the ultimate end user, andallow for cost savings through productivityimprovements throughout the company.
Scope The core financial systems will be replaced byOracle financial applications. These systemsinclude:
General Ledger Fixed Assets Ops Report [AU: spell out Ops] Accounts Payable Accounts Receivable Project Accounting Project Management
Assumptions Oracle's software provides
Minimal customization No change in procurement systems during
accounts payable implementationCost/Benefit Analysis& Internal Rate of Return (IRR)
BSR was broken down into a three-year cashoutlay without depreciation. Costs arerepresented in thousands. Capital and expensesare combined in this example.
Table 6-4. Business Systems Replacement Project Cash Flow Analysis
FY95
($000)
FY96
($000)
FY97
($000)
3 YearTotal($000)
Future AnnualCosts/Savings
($000)CostsOracle/PM Software(List Price)
992 500 0 1492 0
60% Discount (595) (595)Oracle Credits (397) 0 (397)
Net Cash for Software 0 500 500Software Maintenance 0 90 250 340 250Hardware & Maintenance 0 270 270 540 270Consulting &Training 205 320 0 525 0Tax & Acquisition 0 150 80 230 50Total Purchased Costs 205 1330 600 2135 570Information Services &Technology (IS&T)
500 1850 1200 3550 0
Finance/Other Staff 200 990 580 1770Total Costs 905 4170 2380 7455 570
SavingsMainframe (101) (483) (584) (597)Finance/Asset/PM (160) (1160) (1320) (2320)IS&T Support/Data Entry (88) (384) (472) (800)Interest 0 (25) (25) (103)Total Savings (349) (2052) (2401) (3820)
Net Cost (Savings) 905 3821 328 5054 (3250)
8 Year InternalRate of Return
35%
Cost Budgeting Cost budget involves allocating the project
cost estimate to individual work items and providing a cost baseline
For example, in the Business Systems Replacement project, there was a total purchased costs estimate for FY97 of $600,000 and another $1.2 million for Information Services and Technology
These amounts were allocated to appropriate budgets as shown in Table 6-5
Table 6-5. Business Systems Replacement Project Budget Estimates for FY97 and Explanations
Budget Category Estimated Costs ExplanationHeadcount (FTE) 13 Included are 9 programmer/analysts, 2
database analysts, 2 infrastructuretechnicians.
Compensation $1,008,500 Calculated by employee change notices(ECNs) and assumed a 4% pay increase inJune. Overload support was planned at$10,000.
Consultant/PurchasedServices
$424,500 Expected consulting needs in support of theProject Accounting and Cascadeimplementation efforts; maintenanceexpenses associated with the Hewlett-Packard (HP) computing platforms;maintenance expenses associated with thesoftware purchased in support of the BSRproject.
Travel $25,000 Incidental travel expenses incurred insupport of the BSR project, most associatedwith attendance of user conferences andoff-site training.
Depreciation $91,000 Included is the per head share ofworkstation depreciation, the Cascade HPplatform depreciation, and the depreciationexpense associated with capitalizedsoftware purchases.
Rents/Leases $98,000 Expenses associated with the Mach1computing platforms.
Other Suppliesand Expenses
$153,000 Incidental expenses associated with thingssuch as training, reward and recognition,long distance phone charges, miscellaneousoffice supplies.
Total Costs $1,800,000
Designing the Baseline One of the most crucial inputs to the pricing
decision Baseline design should be started early so its cost
estimates can be included in the proposal Effective pricing should begin a long time before
proposal development– Gives management an opportunity to terminate a bid
initiative before too many resources get committed to proposal development, presentations, negotiations, etc..
Pricing Process This activity schedules the development of
the work breakdown structure and provides management with two of the three operational tools necessary for the control of a system or project
The third tool is the WBS
The WBS as price estimating tool Provides the basis for effective and open
communication between functional management and program/project management
After pricing is complete the WBS forms the basis of a communications tool by documenting the performance agreed on in the pricing effort.
Organizational Input Requirements
After the WBS and activity schedules are established, an organizational meeting is called.– The WBS is described in depth– Responsibilities are clarified– Costing information is solicited and collected from the
responsible parties A short time fuse is usually involved in
estimating/pricing which makes it all the more risky – RFP’s sometimes require a response within 30 days of
their submittal
Labor Distributions Functional units supply their input in the form of
man-hours» See Figure 14-2
Man-hours submitted are often over-estimated Man-hours are converted to dollars by multiplying
by the labor rates Rates are only averages Base rates are then escalated as a % factor, based
on past experience
Labor Distributions--Conflict Resolution
The reduction of man-hours is often the source of heated discussions between project and functional management
Most common solution rests with the project or program manager
This becomes the usual turf-fight How would you resolve all such
conflicts???
A Proposal Manager Integrates the activities of the program and
functional managers Insures that a robust proposal gets
submitted to the REQUESTER on time
Overhead Rates Program/project costs involve both direct labor
and indirect (OVERHEAD) costs Each team member should understand overhead
rates If overhead rates are more than 50% of direct
regular time and not chargeable to overtime, then overtime at 150% regular time may be cheaper
Overhead rates in manufacturing can be 300-450%
Elements of Overhead Rates (Indirect Costs)
Building maintenance Building rent Cafeteria Clerical Consulting Corporate Salaries Depreciation of equip. Executive Salaries
Group insurance Holidays Moving/storage exp. Personnel recruitment Retirement plans Sick leave Telephone/Utilities Vacation
Why are Overhead Rates of Interest to Project Management???
These rates must be included in any project cost calculation!!!
The contractor is going to pay both your direct and your indirect overhead costs if yours is the winning bid
Where do the costs associated with bidding and proposing go? Does anybody pay for them or are they just a SUNK cost???
Let’s REVIEW: What are the Major Cost Components?
Salary structure Overhead structure Labor hours required Cost of materials and support
Cost of Materials?? Required Software Diet coke, pizza
Materials Support Costs Are submitted by month for each month of
the project An escalation factor for material costs must
be applied
Pricing out the Work—STEPS (from Kerzner, p. 738)
Provide a complete definition of the work requirements
Establish a logic network with checkpoints Develop the work breakdown structure Price out the WBS
Pricing out the Work--STEPS, Cont’d
Review WBS costs with each functional manager
Decide on the basic course of action Establish reasonable costs for each WBS
element Review the base case costs with upper-level
management
Pricing out the Work--STEPS, Cont’d
Negotiate with functional managers for qualified personnel
Develop the linear responsibility chart Develop the final detailed and PERT/CPM
schedules Establish pricing cost summary reports Document the result in a project plan
Smoothing out Department Man-hours
Ramp-up at project initiation and Ramp-down at project completion cause step functions in manpower requirements, as shown in Figure 14-8
Functional managers attempt to SMOOTH this out QUESTION?? Does the department have
sufficient resources to fulfill the requirements?
Smoothing out Department Man-hours
ANOTHER QUESTION?? Can the departments ramp-up fast enough?
The Pricing Review Procedure Based on Kerzner’s work Remember only 30 days to get the proposal
out and this is one of 13 steps Many contractors require the actual team
members to be identified in the proposal What solution comes to mind?
Systems Pricing The project pricing model (also called the
strategic planning model) acts as a management information system
Also provides management with an invaluable tool for performing perturbation analysis on the base case costs
Developing the Supporting/Backup Costs
Some proposals require backup support When required backup support must be
included in the pricing An issue is the type of contract
Types of contracts Fixed-price (developer assumes all of the
risk) Cost-plus (contractor pays for every hour
invested and thus assumes all the risk) An infinite array in between these
The Low-Bidder Dilemma The price of your contract will definitely
affect the viability of your proposal A low price on cost-plus type proposals is
suspect A low price on fixed-price contracts may be
perceived as impossible and undoable, or if accepted will lead to a disaster
The Price on the Proposal is always relative to:
the competitive prices the customer budget the bidder’s cost estimate IN ANY CASE, LOW PRICING
WITHOUT MARKET INFORMATION IS MEANINGLESS
If its a new market for the Developer:
Cost sharing may be an effective strategy Bidding below your actual costs is
commonplace Contractor’s objectives might include
system life cycle cost or unit production cost
The Bottom Line on Price THE LOWEST BIDDER IS NOT
NECESSARILY THE AUTOMATIC WINNER– Makes project a risky image regarding cost,
performance or schedule The ability to perform under contract is a definite
consideration A compliant, technically and managerially sound
proposal based on past experience, with realistic, well-documented cost figures, is often chosen over the lowest bidder
Special Problems• Pricing must include an understanding of cost control--
how costs are billed back to the project
• There are three situations:
– Work is priced out at the department average, and all work performed is charged to the project at the department average, regardless of who performed the work
– Work is priced out at the dept.. average, but all work performed is billed back to the project at the actual salary of the employees who performed the work
– Work is priced out at the actual salary of those employees who will perform the work, and the cost is billed back the same way.
» This is the ideal situation
This is as far as we will go with these slides—ignore the
remainder
Estimating Pitfalls• The “buy-in” decision is the most serious pitfall
because it means that the project will be under-funded
• If the customer initially defines the requirements and you (the developer) further refine them and the customer doesn’t understand what you’ve done, whose fault is it?
Estimating High-Risk Projects• Validity of historical estimates determine the
difference between high-risk and low-risk projects
• Estimating high-risk projects is commonly done by means of the rolling wave or moving window approach– For a 12-month project the first six months are
estimated to level 5, while the last six months are estimated to level two only.
– As the project proceeds more and more of the last six months is estimated to level 5
– See Figure 14-13, Kerzner
Project Risks RISKS--Factors that increase the
probability that the project’s goals of time, cost and performance will not be met
• See Figures 14-14, 14-15 and Table 14-13 (Especially useful)
Common Risks include: Poorly defined requirements Lack of qualified resources Lack of management support Poor estimating Inexperienced project manager
Tools to Aid in Risk Identification
Decision Support Systems Expected value measures Trend analysis/projection Independent reviews and audits
Six steps to risk management are: Identification of the risk Quantification of the risk Prioritizing the risk Developing a strategy for managing the risk
– A contingency plan Project sponsor/executive review Taking action
The Disaster of Applying the 10 % Solution to Project Estimates
10% is taken from every on-going project to create a budget out of thin air
The result is havoc on top of chaos Most high-level executive committees do not
realize the impact of adopting the 10% solution A REDUCTION IN BUDGET MUST BE
ACCOMPANIED BY A TRADEOFF IN TIME OR PERFORMANCE
The Disaster of the 10% Solution, Cont’d
90% of the budget generates 10% of the desired service or performance levels and the remaining 10% will generate the last 90% of the desired service or performance
If there is FAT, i.e., padding, it may, however, be possible to sustain a cut in the project budget without major consequence– Most projects do not have FAT
Cost vs. Performance I much prefer the word performance to
quality here A 10% reduction in cost can be expected to
produce much greater than a 10% reduction in performance
More on the 10% Solution 10% reduction solutions should be
undertaken only after a careful impact study has been completed
A far better choice is for the executive committee to cancel or de-scope some projects in order to release funds
14.19 Life-Cycle Costing (LCC) These are the total costs to the organization
for the ownership and acquisition of a product over its full life
Especially appropriate for in-house software development projects, but is used in some (outhouse) contracted projects as well
Life-cycle cost breakdown R & D Costs (Definition, Analysis) Production cost (Design) Construction cost (Programming and
testing) Operation and maintenance cost Product retirement cost
Life-cycle costing process Define the problem Define the requirements of the cost model
being used Collect historical data-cost relationships Develop estimates and test results
Successful applications of LCC will:
Provide downstream resource impact visibility
Provide life-cycle cost management Influence R&D decision making Support downstream strategic budgeting
Estimating Methods for LCC Method choice is based on the problem context,
operational considerations, etc. Informal estimating methods
– Judgment based on experience– Analogy– SWAG method, ROM method– Rule-of-thumb method
Formal estimating methods– Detailed (from industrial engineering standards)– Parametric
Figure 14-18 For every $12 DOD puts into R&D, $28 are
needed downstream for production and $60 for operation and support
After Conceptual definition and demonstration/validation, 85% of the lifecycle decisions are made and cost reduction opportunities are down to 22%
14.20 Logistics Support A frequent occurrence in software development
where the developer is paid to provide after-market support in the form of operation and maintenance on the product (deliverable)
Recall that after the design phase 85% of the deliverable’s life-cycle cost has been committed and the majority of the total life-cycle cost is still ahead >> 60%
Performance metrics for Products requiring Logistics Support
Suppportability--the ability to maintain or acquire the necessary human resources to support the system
Readiness--measure of how good we are at keeping the product performing as planned and how quickly we can make repairs during a shutdown
Ten elements of logistics support Maintenance planning Manpower and
personnel Supply support Support equipment Technical data See page 765
Training and training support
Computer resources support
Facilities Packaging,
handling, storage and transportation
Design interface
Estimating --
An iterative process– Definition, Analysis, Design
After Definition, 50-100% off After Analysis, 25-50% off After Medium level design--within 10% A good WBS is absolutely essential to do
estimating
Estimating Techniques
Professional Judgment Developer estimate History (database) Formulas
Use of Professional Judgment Based on WBS, an expert judgment
estimate is made for each work package Amazingly accurate when experts are
available Often, however experts aren’t available
Developer Estimate
The programmer assigned to the work package will make every effort to complete the task in the time he estimated it would take
Use of History Database
For this to work, your firm must keep a history database
The database should record how long each task took and who did the task
Break new projects up into tasks that have a history database
8 to 1 productivity ratio between best to worst professional
Questions, Cont’d
How much of the total time does Brooks devote to Definition, Analysis and Design?
1/3
How much time to coding? 1/6 to Coding
How much time to testing? 1/4 to component test and early system test 1/4 to total system test
So how much time are you going to devote to testing in your projects?????
Use of Formulas
COCOMO--project cost, effort, schedule, staffing for each of the phases:– Preliminary design– Detailed design– Code and unit test– System test
COCOMO was developed by Barry Boehm in 1981--COnstructive COst MOdel
Inputs to COCOMO
Monthly cost of staff involved Factors indicating the general level of
complexity of the software Programming practices and tools used Experience of staff Lines of LOSC--rendering COCOMO
unusable
Function Points
A user input User display Peripheral I/O Restructuring data Condition checking Calculation Branching
Function point approach--BEFORE YOU LEAP
Vendor is Gordon Group It must know how many LOSC are required
for each function point. It calculates LOSC based on function points
it knows about and feeds this into the COCOMO algorithm
Estimacs from CA (Computer Associates)
Can take into account modern code generation tools
Determines effort, but also – Hardware required– financial break-even analysis– risk analysis– maintenance costs
Expensive > $20K
Estimating Programming: Function Points
D = C * ( G + J) D is the task duration in person-days C is the complexity of the task G is the assigned persons’ general
experience J is the assigned professional’s job
knowledge factor
Complexity Must break task down into its smallest possible
repeatable functions Then add up the complexity of each function User input, user display, peripheral I/O,
restructuring data, condition checking, calculation, etc.
Repeatable functions are called function points. Function points are graded as SIMPLE, COMPLEX and VERY COMPLEX
Productivity
Your average programmer gets a productivity factor of 1 for G
Slower programmers get factors > 1 Faster programmers get factors < 1
Formula method conclusions
Will work if you develop accurate factors Can be used for any task from building a
house to developing software Depends on how well you granularize
Estimating The Analysis Phase
Interviews Analyze Existing Documents and Systems Prepare Functional Specification Presentation
RATIOS
PHASE PERCENTAGE Definition phase -- 10% Analysis phase -- 20% Design phase -- 10% Programming -- 20% System test -- 17% Acceptance -- 7% Operation -- 16%
This breaks down to:
PLAN -- 40% BUILD -- 20% TEST -- 40%
Another Rule of Thumb
The time to design, document and code a module =
equals the time to debug it
According to Gildersleeve
Can you use RATIOS for Forecasting?
Suppose you found that it took 20 days to do definition.
How long, based on ratios will it take to do the project?
Estimating Rules Never use inexperienced persons to estimate Get group estimates if possible Never force an estimate on a programmer Never take an average of different estimates Granularize down to one week or less Always add for contingency Always quote a range when giving estimates
Conclusions to Estimating
Our weakest talent Estimating is iterative Estimating is still an art
Scheduling --
Also assists with estimating, especially when PM software is used
PM software supports
WBS Gantt PERT Calendar(s) Resources and their assignments
PERT
Use activity on node approach– doesn’t require dummy activities
Understand what float is--it is slack Critical path is the longest path shows precedent activities, relationships doesn’t show what will be done when, by
whom
Resource allocation
Assign tasks to individuals whose skill level suits the task
Assign similar tasks to the same person Assign time-critical tasks to your most reliable
people Assign tasks that communicate to the same
individual to minimize people’s interaction Don’t assign too many different tasks to any one
individual
Reducing task duration by adding manpower
Add 20% direct time for each additional member on a professional team
If it takes 10 person days for one person, it will take 12 person days for two people, 14.4 person days for three people, etc.
Cost effects of adding resources
More resources, gets the project done sooner, USUALLY
But it also costs more The PM must come up with the best
balance, depending on the priorities set by management or the user
Shortening the duration of projects
Fast tracking Crashing
– Adding resources to the critical path– Allowing your current CP teams members to
work overtime
Crashing projects
Crash tasks on the critical path only, only as long as no other path becomes critical
If other paths become critical, the analyst must crash those as well
Gantt Chart
a time bar chart Invented by Henry Gantt in 1910 Determine the units of time Mark all known calendar events at bottom Schedule each activity from PERT
Use three sets of Gantt’s
one for yourself alone, with all float and contingency visible
second for the individuals involved--their resource Gantt, contingencies hidden
third for distribution to upper management--contingencies hidden
Include a 10% contingency into all estimates
Conclusions to Scheduling
Use PM software--worth every penny Do at least one PERT and one GANTT
manually, just to get a feel for the process
Recitation
What is the probability of completing a project by its estimated completion time??
What is the formula for calculating the completion time for a PERT network?
What is the formula for calculating the standard deviation of the completion time for a PERT network?
Name some processes that are part of project integration management