2 WBS: quick recap Types: Process, product, hybrid Formats: Outline or graphical org chartHigh-level WBS does not show dependencies or durationsWhat hurts most is what’s missingBecomes input to many things, esp. schedule
3 WBS examples http://www.dir.state.tx.us/eod/qa/planning/wbs.htm The next two wbs’: two (fictitious) wbs taken from PMBOK
6 Project Scheduling Split project into tasks (= create a WBS) Estimate time and resources required to complete each task.Organize tasks concurrently to make optimal use of workforce.Minimize task dependencies to avoid delays caused by one task waiting for another to complete.Dependent on project managers intuition and experience.
7 Estimation“The single most important task of a project: setting realistic expectations. Unrealistic expectations based on inaccurate estimates are the single largest cause of software failure.”Futrell, Shafer, Shafer, “Quality Software Project Management”… now: just a couple of slides to keep going.In the next few lessons: more detailed and accurate description (tools and techniques)
8 Estimation Activities/task characterized by: Effort: how much work will the activity need to be completedResources: how many resources will be working on the activityDuration: how long will the activity last for… estimation technique provide (at least) two of the quantities specified above
9 EffortYour best shot for providing estimations (how complex/how much work does the activity require?)A.K.A. “Work”Measured in man/month (3 m-m = 1 person working for 3 months; 3 people working for one 1 month)Mind you though: communication increases the time to complete activities
10 Duration How much time will the activity last for Measured in (work-)hours, (work-)days, (work-)months, …Calendar time != duration: calendar time includes non-working days, holidays, …Usually:A duration of 5 days == 40 hours (8 hours a day) = 1 calendar week (sat and sun rest time)
11 Duration (II) Some more relationships: A (work-month) maybe: In some countries/contexts: 1 calendar week = 36 work-hours (7.12 hours/day)A (work-month) maybe:20 days17 days(… where are the missing days?)
12 A (simplicistic) view D = E / M Fix any two among D, E, and M, and you get the third(once again) a simplification, but good enough for us (we embed the non linearity in the effort)
13 A (simplicistic) view (II) When working with planning tools, you change one variable at a time.Standard characterisation:Fixed Unit. A task in which the assigned resources is a fixed value and any changes to the amount of work or the tasks duration do not affect the tasks units. (Duration x Units = Work).Fixed Work. A task in which the amount of work is a fixed value and any changes to the tasks duration or the number of assigned resources do not affect the tasks work. (Duration x Units = Work).Fixed Duration. A task in which the duration is a fixed value and any changes to the work or the assigned resources, don't affect the tasks duration. (Duration x Units = Work).
14 Some general considerations… Estimating the difficulty of problems and hence the cost of developing a solution is hard.Productivity is not proportional to the number of people working on a task.Adding people to a late project makes it later because of communication overheads.The unexpected always happens. Always allow contingency in planning.
15 SchedulingOnce tasks (from the WBS) and size/effort (from estimation) are known: then schedulePrimary objectivesBest timeLeast costLeast riskSecondary objectivesEvaluation of schedule alternativesEffective use of resourcesCommunications
16 Some rules of the thumbOrganize tasks concurrently to make optimal use of workforce.Minimize task dependencies to avoid delays caused by one task waiting for another to complete.Dependent on project managers intuition and experience.
17 Scheduling (II) … according to Sommerville: while project has not been completed or cancelled loopDraw up project scheduleInitiate activities according to scheduleWait ( for a while )Review project progressRevise estimates of project parametersUpdate the project scheduleRe-negotiate project constraints and deliverablesif ( problems arise ) thenInitiate technical review and possible revisionend ifend loop
18 Terminology Precedence: Concurrence: Leads & Lag Time A task that must occur before another is said to have precedence of the otherConcurrence:Concurrent tasks are those that can occur at the same time (in parallel)Leads & Lag TimeDelays between activitiesTime required before or after a given task
19 Terminology Milestones Have a duration of zero Identify critical points in your scheduleShown as inverted triangle or a diamondOften used at “review” or “delivery” timesOr at end or beginning of phasesEx: Software Requirements Review (SRR)Ex: User Sign-offCan be tied to contract terms
21 Terminology Deliverable: a deliverable is a measurable and verifiable work products (we saw it already!)… in current practice sometimes milestone and deliverable are used interchangeably (both used to identify products - milestones may represent key-products)
22 Terminology Slack & Float Float & Slack: synonymous terms Free Slack Slack an activity has before it delays next taskTotal SlackSlack an activity has before delaying whole projectSlack Time TS = TL – TETE = earliest time an event can take placeTL = latest date it can occur w/o extending project’s completion date
27 Network Diagrams Two classic formats Each task labeled with AOA: Activity on ArrowAON: Activity on NodeEach task labeled withIdentifier (usually a letter/code)Duration (in std. unit like days)There are other variations of labelingThere is 1 start & 1 end eventTime goes from left to right
29 Network Diagrams AOA consists of AON Circles representing Events Such as ‘start’ or ‘end’ of a given taskLines representing TasksThing being done ‘Build UI’a.k.a. Arrow Diagramming Method (ADM)AONTasks on NodesNodes can be circles or rectangles (usually latter)Task information written on nodeArrows are dependencies between tasksa.k.a. Precedence Diagramming Method (PDM)
30 Critical Path“The specific set of sequential tasks upon which the project completion date depends”or “the longest full path”All projects have a Critical PathAccelerating non-critical tasks do not directly shorten the schedule
32 CPM Critical Path Method The process for determining and optimizing the critical pathNon-CP tasks can start earlier or later w/o impacting completion dateNote: Critical Path may change to another as you shorten the current
34 Forward PassTo determine early start (ES) and early finish (EF) times for each taskWork from left to rightAdding times in each pathRule: when several tasks converge, the ES for the next task is the largest of preceding EF times
41 Network Diagrams Advantages Disadvantages Show precedence well Reveal interdependencies not shown in other techniquesAbility to calculate critical pathAbility to perform “what if” exercisesDisadvantagesDefault model assumes resources are unlimitedYou need to incorporate this yourself (Resource Dependencies) when determining the “real” Critical PathDifficult to follow on large projects
42 4 Task Dependency Types Mandatory Dependencies “Hard logic” dependenciesNature of the work dictates an orderingEx: Coding has to precede testingEx: UI design precedes UI implementationDiscretionary Dependencies“Soft logic” dependenciesDetermined by the project management teamProcess-drivenEx: Discretionary order of creating certain modules
43 4 Task Dependency Types External Dependencies Resource Dependencies Outside of the project itselfEx: Release of 3rd party product; contract signoffEx: stakeholders, suppliers, Y2K, year endResource DependenciesTwo task rely on the same resourceEx: You have only one DBA but multiple DB tasks
44 Task Dependency Relationships Finish-to-Start (FS)B cannot start till A finishesA: Construct fence; B: Paint FenceStart-to-Start (SS)B cannot start till A startsA: Pour foundation; B: Level concreteFinish-to-Finish (FF)B cannot finish till A finishesA: Add wiring; B: Inspect electricalStart-to-Finish (SF)B cannot finish till A starts (rare)
45 PERT Program Evaluation and Review Technique Based on idea that estimates are uncertainTherefore uses duration rangesAnd the probability of falling to a given rangeUses an “expected value” (or weighted average) to determine durationsUse the following methods to calculate the expected durations, then use as input to your network diagram
46 PERT Start with 3 estimates Optimistic Most likely Pessimistic Would likely occur 1 time in 20Most likelyModal value of the distributionPessimisticWould be exceeded only one time in 20
47 PERT FormulaCombined to estimate a task duration
48 PERT Formula Confidence Interval can be determined Based on a standard deviation of the expected timeUsing a bell curve (normal distribution)For the whole critical path use
49 PERT Example Description Planner 1 Planner 2 m 10d a 9d b 12d 20d PERT time10.16d11.5dStd. Dev.0.5d1.8dConfidence interval for P2 is 4 times wider than P1 for a given probabilityEx: 68% probability of 9.7 to 11.7 days (P1) vs days (P2)
50 PERT Advantages Disadvantages Accounts for uncertaintyDisadvantagesTime and labor intensiveAssumption of unlimited resources is big issueLack of functional ownership of estimatesMostly only used on large, complex projectGet PERT software to calculate it for you
51 CPM vs. PERT Both use Network Diagrams CPM: deterministic PERT: probabilisticCPM: one estimate, PERT, three estimatesPERT is infrequently used
52 Milestone Chart Sometimes called a “bar charts” Simple Gantt chart Either showing just highest summary barsOr milestones only
55 Gantt Chart Disadvantages Advantages Does not show interdependencies wellDoes not uncertainty of a given activity (as does PERT)AdvantagesEasily understoodEasily created and maintainedNote: Software now shows dependencies among tasks in Gantt chartsIn the “old” days Gantt charts did not show these dependencies, bar charts typically do not
56 Reducing Project Duration How can you shorten the schedule?ViaReducing scope (or quality)Adding resourcesConcurrency (perform tasks in parallel)Substitution of activities
57 Compression Techniques Shorten the overall duration of the projectCrashingLooks at cost and schedule tradeoffsGain greatest compression with least costAdd resources to critical path tasksChanging the sequence of tasksFast TrackingOverlapping of phases, activities or tasks that would otherwise be sequentialInvolves some riskMay cause rework
58 Mythical Man-Month Book: “The Mythical Man-Month” Author: Fred Brooks“The classic book on the human elements of software engineering”First two chapters are full of terrific insight (and quotes)draw graphsTraining == ramp-upSoftware is a ‘systems effort’
59 Mythical Man-Month“Cost varies as product of men and months, progress does not.”“Hence the man-month as a unit for measuring the size of job is a dangerous and deceptive myth”Adding manpower to a late project makes it later”draw graphsTraining == ramp-upSoftware is a ‘systems effort’
60 Mythical Man-Month Why is software project disaster so common? 1. Estimation techniques are poor & assume things will go well (an ‘unvoiced’ assumption)2. Estimation techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable3. “… software managers often lack the courteous stubbornness of Antoine's chef.”4. Schedule progress is poorly monitored5. When schedule slippage is recognized, the natural response is to add manpower. Which, is like dousing a fire with gasoline.
61 Mythical Man-Month Optimism “All programmers are optimists”1st false assumption: “all will go well” or “each task takes only as long as it ‘ought’ to take”The Fix: Consider the larger probabilitiesCost (overhead) of communication (and training)His formula: n(n-1)/2How long does a 12 month project take?1 person: 12 month2 persons = 7 months (1 man-months extra)3 persons = 5 months (1 man-months extra)Fix: don’t assume adding people will solve the problem
62 Mythical Man-Month Sequential nature of the process “The bearing of a child takes nine months, no matter how many women are assigned”What is the most mis-scheduled part of process?Testing (the most linear process)Why is this particularly bad?Occurs late in process and w/o warningHigher costs: primary and secondaryFix: Allocate more test timeUnderstand task dependenciesI don’t agree with his formulaHe advocates 50% of schedule to TestLateHighest cost: most staffed timeChanges cost moreSecondary costsYou need to understand Critical Path and other dependencies
63 Mythical Man-Month Q: “How does a project get to be a year late”? A: “One day at a time”StudiesEach task: twice as long as estimatedOnly 50% of work week was programmingFixesNo “fuzzy” milestones (get the “true” status)Reduce the role of conflictIdentify the “true status”what does Brooks mean by this?Termites not tornadoesImperceptibly but inexorablyHard to recognizeReduce conflict: status vs. action meetings
64 One final word…The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling,irrational commitments, unprofessional estimating techniques,and carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably.T. Capers Jones
Your consent to our cookies if you continue to use this website.