SE 477 Software and Systems Project Management Dennis Mumaugh, Instructor dmumaugh@cdm.depaul.edu Office: CDM, Room 429 Office Hours: Monday, 4:00 – 5:30 April 28, 2014 SE 477: Lecture 5 1 of 133 Administrivia Comments and feedback Midterm Examination this coming week [April 30 – May 5] Will use Desire2Learn See important information about Taking Quizzes On-line On-line tutorial: http://www.itd.depaul.edu/website/documentation/d2l/mp 4based/quizzes/quizzes.html On-line guide: http://www.itd.depaul.edu/website/documentation/d2l/Qui zzes.pdf Midterm study guide [note solution to some problems on last page]. April 28, 2014 SE 477: Lecture 5 2 of 133 Team Project Start working on Project Time Management Perform activity definition, sequencing, and duration estimation; Perform activity resource estimation; Develop schedule based on estimates April 28, 2014 SE 477: Lecture 5 3 of 133 Assignment 3 Effort conversion factors 8 working hours per day, 5 days per week person-months = person-days times 19 person-months = person-hours times 152 Holidays – include them in the scheduling Memorial Day, Independence Day, Labor Day Thanksgiving and the day after, Christmas Eve, Christmas, New Year’s Start each major phase on a new day. Unit Testing vs. Code Inspection [order can be reversed depending on team’s process] Preparation and reviews; choice of participants April 28, 2014 SE 477: Lecture 5 4 of 133 SE 477 – Class 5 Topics: Size and complexity Estimation Activity Resource Estimating Activity Duration Estimating Project Planning – Schedule Development Scheduling Schedule network analysis Calculating float Schedule compression Resource leveling April 28, 2014 Schedule development output Mythical Man Month Project Planning – Schedule Development Workflow and Example Reading: PMP Study Guide: Chapters 5 and 7 Appendix PERT Estimation Critical Path Method (CPM) Forward and backward pass analysis SE 477: Lecture 5 5 of 133 Thought for the day “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, April 28, 2014 Shafer, Shafer, “Quality Software Project Management” SE 477: Lecture 5 6 of 133 Last time Charter Project Planning WBS details Activity: » Activity Definition » Activity Sequencing April 28, 2014 SE 477: Lecture 5 7 of 133 Project Planning Project Time Management I Size and Complexity Estimation Activity Resource Estimating Activity Duration Estimating April 28, 2014 SE 477: Lecture 5 8 of 133 Estimating Project Size And Complexity April 28, 2014 SE 477: Lecture 5 9 of 133 Estimations Very difficult to do, but needed often Created, used or refined during Strategic planning Feasibility study and/or SOW Proposals Vendor and sub-contractor evaluation Project planning (iteratively) Basic process 1) Estimate the size of the product 2) Estimate the effort (person-months) 3) Estimate the schedule NOTE: Not all of these steps are always explicitly performed April 28, 2014 SE 477: Lecture 5 10 of 133 Estimations Remember, an “exact estimate” is an oxymoron Estimate how long will it take you to get home from class tonight On what basis did you do that? Experience right? Likely as an “average” probability For most software projects there is no such ‘average’ Most software estimations are off by 25-100% April 28, 2014 SE 477: Lecture 5 11 of 133 Estimation Target vs. Committed Dates Target: Proposed by business or marketing » Do not commit to this too soon! Committed: Team agrees to this » After you’ve developed a schedule Size: Small projects (10-99 FPs), variance of 7% from postrequirements estimates Medium (100-999 FPs), 22% variance Large (1000-9999 FPs) 38% variance Very large (> 10K FPs) 51% variance April 28, 2014 SE 477: Lecture 5 12 of 133 Estimation Methodologies Top-down Bottom-up Analogy Expert Judgment Priced to Win Parametric or Algorithmic Method Using formulas and equations Let’s look at each of these … April 28, 2014 SE 477: Lecture 5 13 of 133 Top-down Estimation Based on overall characteristics of project Some of the others can be “types” of top-down (Analogy, Expert Judgment, and Algorithmic methods) Advantages Easy to calculate Effective early on (like initial cost estimates) Disadvantages Some models are questionable or may not fit Less accurate because it doesn’t look at details April 28, 2014 SE 477: Lecture 5 14 of 133 Bottom-up Estimation Create WBS Add from the bottom-up Advantages Works well if activities well understood Disadvantages Specific activities not always known More time consuming April 28, 2014 SE 477: Lecture 5 15 of 133 Expert Judgment Use somebody who has recent experience on a similar project You get a “guesstimate” Accuracy depends on their ‘real’ expertise Comparable application(s) must be accurately chosen Systematic Can use a weighted-average of opinions April 28, 2014 SE 477: Lecture 5 16 of 133 Estimation by Analogy Use past project Must be sufficiently similar (technology, type, organization) Find comparable attributes (ex: # of inputs/outputs) Can create a function Advantages Based on actual historical data Disadvantages Difficulty ‘matching’ project types Prior data may have been mis-measured How to measure differences – no two exactly same April 28, 2014 SE 477: Lecture 5 17 of 133 Priced to Win Just follow other estimates Save on doing full estimate Needs information on other estimates (or prices) Purchaser must closely watch trade-offs Priced to lose? April 28, 2014 SE 477: Lecture 5 18 of 133 Algorithmic Measures Lines of Code (LOC) Function points Feature points or object points Other possible Number of bubbles on a DFD Number of ERD entities Number of processes on a structure chart LOC and function points most common (of the algorithmic approaches) Majority of projects use none of the above April 28, 2014 SE 477: Lecture 5 19 of 133 Code-based Estimates LOC Advantages Commonly understood metric Permits specific comparison Actually it is easily measured LOC Disadvantages Difficult to estimate early in cycle Counts vary by language Many costs not considered (ex: requirements) Programmers may be rewarded based on this » Can use: # defects/# LOC Code generators produce excess code April 28, 2014 SE 477: Lecture 5 20 of 133 LOC Estimate Issues How do you know how many in advance? What about different languages? What about programmer style? Stat: avg. programmer productivity: 3,000 LOC/yr Most algorithmic approaches are more effective after requirements (or have to be after) April 28, 2014 SE 477: Lecture 5 21 of 133 Function Points Software size should be measured by number & complexity of functions it performs More methodical than LOC counts House analogy House’s Square Feet ~= Software LOC # Bedrooms & Baths ~= Function points Former is size only, latter is size & function Four basic steps April 28, 2014 SE 477: Lecture 5 22 of 133 Function Point Process 1. Count # of business functions per category Categories: outputs, inputs, db inquiries, files or data structures, and interfaces 2. Establish Complexity Factor for each and apply Simple, Average, Complex Set a weighting multiplier for each (0 –>15) This results in the “unadjusted function-point total” 3. Compute an “influence multiplier” and apply It ranges from 0.65 to 1.35; is based on 14 factors 4. Results in “function point total” This can be used in comparative estimates [This is covered in detail in SE 468. See the SE 468 reading list for more information]. April 28, 2014 SE 477: Lecture 5 23 of 133 Wideband Delphi Group consensus approach Rand corp. used orig. Delphi approach to predict future technologies Present experts with a problem and response form Conduct group discussion, collect anonymous opinions, then feedback Conduct another discussion & iterate until consensus Advantages Easy, inexpensive, utilizes expertise of several people Does not require historical data Disadvantages Difficult to repeat May fail to reach consensus, reach wrong one, or all may have same bias April 28, 2014 SE 477: Lecture 5 24 of 133 Effort Estimation Now that you know the “size”, determine the “effort” needed to build it Various models: empirical, mathematical, subjective Expressed in units of duration person-months (or ‘staff-months’ now) Efficiency/productivity of people Motivation Ability of team Application experience Range of personnel April 28, 2014 SE 477: Lecture 5 25 of 133 Duration What is the duration? The duration of a project is the elapsed time in business working days, not including weekends, holidays, or other nonworking days. Duration is different from work effort. Work effort is labor required to complete an activity. That labor can be consecutive or nonconsecutive hours. Duration is work effort divided by number of people doing the work: Or, work effort is the duration multiplied by the number of people doing the work E.g. five people reviewing a document; the duration may be 10 hours but the work effort is 50 staff-hours April 28, 2014 SE 477: Lecture 5 26 of 133 Duration When we talk about estimates and duration, there are two types of time that are not the same: Labor Time Clock time For example, if we estimate that a task would require 40 hours of labor to complete, then in a normal business setting we need at least 50 business hours, Why? April 28, 2014 SE 477: Lecture 5 27 of 133 Duration Your average business day may include few of the following activities or perhaps a number of each: Meetings – non-project related Phone calls E-mails Coffee breaks Lunches Friendly chat with your teammates The duration of the activity is the clock time or “Elapsed” time” that we want to estimate. Productivity is usually 50-75% of a business day April 28, 2014 SE 477: Lecture 5 28 of 133 Variation in Activity Duration Since we cannot know what factors will be effective when work is underway on an activity, we cannot know exactly how long it will take. One of the goals in estimating the activity duration is to define the activity to a level of granularity that estimates have a narrow variance; the estimate is as good as you can get it at the planning stages of the project. There are several causes of variation in the actual activity duration: Varying skill levels – see Journal Exercise Unexpected events Efficiency of work time Mistakes and Misunderstandings Let’s look at these in a bit more detail … April 28, 2014 SE 477: Lecture 5 29 of 133 Causes of Variation Causes of Variation in the Actual Activity Duration Varying skill levels. Our estimate of the activity duration is based on average skilled engineer. We may get a higher or lower skilled engineer assigned to the activity, causing the actual duration to vary from the planned duration. Unexpected events. Random acts of nature, vendor delays, traffic jams, power failures, etc. Efficiency of work time. Every time a worker is interrupted it takes more time to get up to the level of productivity prior to the time of the interruption. These interruptions may have little or substantial impact on the worker’s productivity Mistakes and Misunderstandings. In organizations that have a documented process, rework may have its toll on the actual activity duration. April 28, 2014 SE 477: Lecture 5 30 of 133 Estimation Issues Quality estimations needed early but information is limited Precise estimation data available at end but not needed Or is it? What about the next project? Should have determined just how accurate your original estimate was. Best estimates are based on past experience Politics of estimation: You may anticipate a “cut” by upper management For many software projects there is little or no data for estimation Technologies change Historical data unavailable Wide variance in project experiences/types Subjective nature of software estimation April 28, 2014 SE 477: Lecture 5 31 of 133 Over and Under Estimation Over estimation issues The project will not be funded » Conservative estimates guaranteeing 100% success may mean funding probability of zero. Parkinson’s Law: Work expands to take the time allowed Danger of feature and scope creep Be aware of “double-padding”: team member + manager Under estimation issues Quality issues (short changing key phases like testing) Inability to meet deadlines Morale and other team motivation issues April 28, 2014 SE 477: Lecture 5 32 of 133 Estimation Guidelines Estimate iteratively! Process of gradual refinement Make your best estimates at each planning stage Refine estimates and adjust plans iteratively Plans and decisions can be refined in response Balance: too many revisions vs. too few April 28, 2014 SE 477: Lecture 5 33 of 133 Know Your Deadlines Are they ‘Real Deadlines’? Tied to an external event Have to be met for project to be a success Ex: end of financial year, contractual deadline, Y2K Or ‘Artificial Deadlines’? Set by arbitrary authority May have some flexibility (if pushed) April 28, 2014 SE 477: Lecture 5 34 of 133 Estimation “Presentation” How you present the estimation can have huge impact Techniques Plus-or-minus qualifiers [6 months ±1 month] Ranges [6-8 months] Risk Quantification » ± with added information • +1 month if new tools not working as expected • -2 weeks for less delay in hiring new developers Cases [Best / Planned / Current / Worst cases] Coarse Dates [Q4 13] Confidence Factors [April 1 – 10% probability, July 1 – 50%, etc.] April 28, 2014 SE 477: Lecture 5 35 of 133 Other Estimation Factors Account for resource experience or skill Up to a point Often needed more on the “low” end, such as for a new or junior person Allow for “non-project” time & common tasks Meetings, phone calls, web surfing, sick days There are commercial ‘estimation tools’ available They typically require configuration based on past data April 28, 2014 SE 477: Lecture 5 36 of 133 Other Estimation Notes Remember: “manage expectations” Parkinson’s Law “Work expands to fill the time available” The Student Syndrome Procrastination until the last minute (cram) and term projects April 28, 2014 SE 477: Lecture 5 37 of 133 Activity Resource Estimating Resource Management Assessing Competencies and Skills Resource allocation Estimating tools Personal Software Process (PSP) Activity resource estimating output April 28, 2014 SE 477: Lecture 5 38 of 133 Introduction Resource estimating is concerned with who/what, how much, and when Who/what Resource requirements of people or equipment Matching the right resources to activities May be generic (n Java programmers) or resourcespecific (Richard Parker as senior architect) How much. Amount of resource(s) needed for activity When. When the resource will be needed for activities April 28, 2014 SE 477: Lecture 5 39 of 133 Introduction Controlling factors in resource estimating Enterprise environment. May be defined by constraints and assumptions identified in Project Scope Statement Organization policy. How the organization allocates and manages resources from within and from without » Note: Enterprise environment and organization policy may be closely-coupled Resource availability. When the resource will be available for activities and whether dedicated or part-time April 28, 2014 SE 477: Lecture 5 40 of 133 Estimating tools Expert judgment. One of the most effective tools for estimating. May be used in conjunction with other tools Alternative analysis. Examines different approaches to applying resources, such as in-house development vs. contracting vs. COTS Published estimating data. May be available in-house in form of historical project data or may be available from outside sources (e.g. unclassified U.S. Government-funded projects) April 28, 2014 SE 477: Lecture 5 41 of 133 Estimating tools Project management software. PM software can provide automated assistance in defining resources, calendars, rates, etc. Bottom-up estimating Use if activity is a natural work package but still complex Decompose activity into more manageable (estimable) pieces Adhere to 100% rule: sum of activities should exactly equal work package (mind the scope!) Example: Architectural quality and cost/benefit analysis (ATAM and CBAM) April 28, 2014 SE 477: Lecture 5 42 of 133 Sidebar: Personal Software Process (PSP) All the estimating tools in the world won’t help if you don’t have good estimates Historical data has its limits – sometimes you need to estimate completely new activities PSP is a highly-disciplined approach to software engineering (in this context, any software development) PSP includes techniques in: Time management and tracking through use of a design notebook and logs Product planning, size measurement and estimation Basic project scheduling and planning Managing defects and product quality Goal is to have developers who can provide accurate and meaningful estimation data See SEI at CMU: http://www.sei.cmu.edu/tsp/tools/bok/ April 28, 2014 SE 477: Lecture 5 43 of 133 Activity Resource Estimating Output Activity resource requirements Identify what and how much of resource(s) are needed for each activity in a work package Activity resource requirements are summed to provide estimate for entire work package Resource calendar Documents working and non-working days Resource-specific holidays may be identified Requested changes Activity resource estimating process may generate requests for changes to activity list Processed within the Integrated Change Control process April 28, 2014 SE 477: Lecture 5 44 of 133 Activity Duration Estimating Estimating tools PERT estimation technique April 28, 2014 SE 477: Lecture 5 45 of 133 Introduction Focuses on estimating the number of work periods needed to complete individual schedule activities Estimates originate from person or groups most familiar with the type of work needed in the activity Estimate is progressively elaborated: duration estimates are improved as project progresses Activity duration output Quantitative activity duration estimates, including range of possible values April 28, 2014 SE 477: Lecture 5 46 of 133 Introduction Controlling factors in duration estimating Historical data. If available, enterprise- or industryspecific historical data can be used as starting point for estimates Activity resource requirements. The type and number of resources applied to an activity must account for » Resource qualifications » Quantity-quality productivity trade-offs: putting more people on a task may reduce productivity Resource calendars. Must account for full/part time commitments April 28, 2014 SE 477: Lecture 5 47 of 133 Sidebar: A useful rule of thumb Keep all times in the same units Don't mix increments Example: Schedule everything in hours, then convert to days and fractions as a last step Note: Most PM software tools enforce this rule by using a uniform time unit and increment April 28, 2014 SE 477: Lecture 5 48 of 133 Estimating tools Expert judgment. As in resource estimating, one of the most effective tools for estimating. May be used in conjunction with other tools Analogous estimating. Estimation based on similar activities performed in a previous project Most useful if both activity and project are more similar than different Document similarities and differences Example: Developing the database schema for a project in the same domain and of similar scope April 28, 2014 SE 477: Lecture 5 49 of 133 Estimating tools Reserve analysis. Contingency or time reserves can be added to schedule to allow for schedule risks Contingency reserves may be used or adjusted as more precise project information becomes available Aka buffer time. Do not confuse with slack time. Three-point estimating techniques use a mathematical combination of three different estimates: Most likely, Optimistic, and Pessimistic There are variations in defining each of these estimates among different techniques April 28, 2014 SE 477: Lecture 5 50 of 133 Three Point Estimating Used whenever there is a potential variance in an estimate. Assumes a Gaussian distribution of estimates. Duration Effort Size Three-point estimating techniques use a mathematical combination of three different estimates: Get estimates from experts: Most likely, Optimistic, and Pessimistic Compute an average: (Optimistic + 4(Likely)+ Pessimistic)/6 ☛ See Appendix: PERT Estimation Technique for more details and a worked example. April 28, 2014 SE 477: Lecture 5 51 of 133 Example: Estimation of LOC CAD program to represent mechanical parts Estimated LOC = (Optimistic + 4(Likely)+ Pessimistic)/6 Optimistic 1,500 Most Likely 2,300 Pessimistic 3,100 Estimated LOC 2,300 2DGA 3,800 5,200 7,200 5,300 3DGA 4,600 6,900 8,600 6,800 DBM CGDF 1,600 3,700 3,500 5,000 4,500 6,000 3,350 4,950 1,400 7,200 23,800 2,200 8,300 33,400 2,400 10,000 41,800 2,100 8,400 33,200 Major Software Functions ID User interface and control facilities Two-dimensional geometric analysis Three-dimensional geometric analysis Database management Computer graphics display features Peripheral control Design analysis modules Estimated lines of code UICF April 28, 2014 PC DAM SE 477: Lecture 5 52 of 133 Schedule Development April 28, 2014 SE 477: Lecture 5 53 of 133 Definition Schedule development is the culmination of the other Project Time Management processes we have discussed: Activity definition Activity sequencing Activity resource estimating Activity duration estimating It is an iterative process to determine planned start and finish dates for activities It is a continuous process throughout project, addressing approved changes and risks April 28, 2014 SE 477: Lecture 5 54 of 133 Controlling factors in schedule development Project scope statement Scope statement is the source of assumptions and constraints on the project (PMI) “Assumptions are those documented, schedulerelated factors that, for schedule development purposes, are considered to be true, real, or certain.” (PMI) “Constraints are factors that will limit the project management team’s options when performing schedule network analysis.” Date constraints (contract dates, market windows, external deliveries) and milestones (deliverable dates) are of greatest importance in schedule development April 28, 2014 SE 477: Lecture 5 55 of 133 Controlling factors in schedule development Project management plan Almost any of the many sub-plans and other elements in the Project Management Plan may exert an influence on schedule development One of the most critical elements for schedule development in the PM Plan is the risk register and riskassociated plans We will discuss risk and risk-related planning in an upcoming lecture April 28, 2014 SE 477: Lecture 5 56 of 133 Network Analysis The First Steps April 28, 2014 SE 477: Lecture 5 57 of 133 Network Analysis Network analysis is the technique that generates the project schedule Network analysis may use several different analysis methods to calculate the early and late start dates for project activities. These methods may be combined and include: April 28, 2014 Gantt Charts Critical Path Method (CPM) Critical Chain Method (CCM) What-if analysis Resource leveling SE 477: Lecture 5 58 of 133 Network Analysis There are a number of network analysis techniques available – we will concentrate on the Critical Path Method (CPM) We have already seen a significant component of another network analysis technique, the PERT estimates for activity duration The Precedence Diagram Method (PDM) is a graphical network technique that establishes activity sequencing Network analysis may also make use of mandatory or discretionary parallelism in project activities to allow schedule compression April 28, 2014 SE 477: Lecture 5 59 of 133 Network Analysis Terminology Activity. An activity always consumes time and may also consume resources. I use task and activity equivalently Critical. A critical activity or event is one that must be achieved by a certain time, having no latitude (slack or float) Critical path. The critical path is the longest path through a project network. Because it has no slack, all activities on the critical path must be completed as scheduled, or the end date will slip Events. Beginning and ending points of activities are known as events. An event is a specific point in time Milestone. An event representing a point in a project of special significance. Usually the completion of a major phase of the work. Project reviews are often conducted at milestones April 28, 2014 SE 477: Lecture 5 60 of 133 Creating a precedence table A Precedence table documents task durations and interdependencies Estimating duration of each task Duration estimated from historical information: » Ideally, based on organization’s historical experience, if available » More likely: ‘expert’ knowledge Estimation done by task leaders or functional managers Any potentially risky task (technology, skills, dependencies) should include contingency factor Include contingencies to mitigate potential resource shortages April 28, 2014 SE 477: Lecture 5 61 of 133 Creating a precedence table Determining task interdependencies Goal is to determine predecessor/successor relations Understanding interdependencies allows proper ordering in scheduling tasks Understanding interdependencies also helps in finding possible parallel tasks, which can shorten schedule Parallel tasks should be truly independent to minimize risk of backtracking Determining task interdependencies must be a team effort to avoid unpleasant surprises April 28, 2014 SE 477: Lecture 5 62 of 133 Sample evolutionary precedence table April 28, 2014 SE 477: Lecture 5 63 of 133 Planning Project Time Management II PERT Chart CPM April 28, 2014 SE 477: Lecture 5 64 of 133 What is a PERT? Program Evaluation & Review Technique or PERT Identify the tasks (or activities) required to complete the given project Use the WBS List the activities in a structured fashion, along with their interdependencies Use a Gantt Chart Precedence table A "network" of the activities and their dependencies is drawn up. In MS Project, PERT is called Network Diagram Each event may be represented by a node Before any activity can begin, all its predecessor activities must have been completed April 28, 2014 SE 477: Lecture 5 65 of 133 • Program Evaluation and Review Technique. • Help understand relationship between tasks and project activity flow. Slack Time Slack time, also known as float, is the amount of delay expressed in units of time that could be tolerated in the starting time or completion time of an activity without causing a delay in the completion of the project. Slack time is the difference between the late finish and the early finish (LF-EF). If the result is greater than zero, then the activity has a range of time in which it can start and finish without delaying the project completion date, as shown in the figure below: A Duration Slack E S April 28, 2014 E F SE 477: Lecture 5 LF 67 of 133 Slack Time If an activity has zero slack, it determines the project completion date. In other words, all the activities on the critical path must be done on their earliest schedule or the project completion date will suffer. If an activity with total slack greater than zero were to be delayed beyond its late finish date, it would become a critical path activity and cause the completion date to be delayed. The sequence of activities that has zero slack is defined as the critical path In general, the critical path is the path that has minimum slack. April 28, 2014 SE 477: Lecture 5 68 of 133 Critical path method The critical path method (CPM) focuses on calculating theoretical start and finish dates for every activity in the project. In the context of the CPM, the following definitions are essential: Critical. A critical activity or event is one that must be achieved by a certain time; a critical activity has no latitude (slack or float) Critical path. The critical path is the longest path through a project network. Because it has no slack, all activities on the critical path must be completed as scheduled, or the end date will slip CPM performs these calculation without regard for resource limitations, which can lead to resource overallocation or inefficient multitasking April 28, 2014 SE 477: Lecture 5 69 of 133 Critical path method A forward pass analysis performs schedule calculations that identify the ☛ early start and finish dates of activities and the project A backward pass analysis performs schedule calculations that identify the late start and finish dates of activities and the project, as well as total and free float Total float (TF) is the amount of time an activity can be delayed without delaying the project as a whole Free float (FF) is the amount of time an activity can be delayed without delaying its successor (dependent) activities Note that total float is global to the project, while free float is local to the neighborhood of the activity See Appendix: CPM Details and Example for more details and a worked example of CPM calculations April 28, 2014 SE 477: Lecture 5 70 of 133 Simple critical path example Critical Path April 28, 2014 SE 477: Lecture 5 71 of 133 Carrying out the example critical path analysis above shows us: April 28, 2014 • That if all goes well the project can be completed in 10 weeks • That if we want to complete the task as rapidly as possible, we need: • 1 analyst for the first 5 weeks • 1 programmer for 6 weeks starting week 4 • 1 programmer for 3 weeks starting week 6 • Quality assurance for weeks 7 and 9 • Hardware to be installed by the end of week 7 • That the critical path is the path for development and installation of supporting modules • That hardware installation is a low priority task as long as it is completed by the end of week 7 SE 477: Lecture 5 72 of 133 Project Planning Tools Gantt Chart April 28, 2014 SE 477: Lecture 5 73 of 133 What is a Gantt chart? A Gantt Chart (named for Henry Laurence Gantt) consists of a table of project task information and a bar chart that graphically displays project schedule, depicting progress in relation to time and often used in planning and tracking a project. Horizontal bar chart format, with bars representing the phases and activities of the WBS Time extends along the horizontal axis Able to show planned and actual progress on tasks as well as task dependencies Effective communication tool but with limitations Very low information density: lots of wasted space Not very useful for large projects April 28, 2014 SE 477: Lecture 5 74 of 133 GANTT Schedule • View Project in Context of time. • Critical for monitoring a schedule. • Granularity 1 –2 weeks. • 2 week window approach Sample evolutionary Gantt chart April 28, 2014 SE 477: Lecture 5 76 of 133 Gantt Example: Suppose a project comprises five activities: A,B,C,D, and E. A and B have no preceding activities, but activity C requires that activity B must be completed before it can begin. Activity D cannot start until both activities A and B are complete. Activity E requires activities A and C to be completed before it can start. If the activity times are A: 9 days; B: 3 days; C: 9 days; D: 5 days; and E: 4 days, determine the shortest time necessary to complete this project. Identify those activities which are critical in terms of completing the project in the shortest possible time. [Critical path ] 1 2 3 4 5 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 A B C 1 6 1 7 1 8 Time is 16 days Critical path is B, C, E D E April 28, 2014 SE 477: Lecture 5 77 of 133 Critical chain method The critical chain method (CCM) focuses on the resources required for project activities, attempting to keep them leveled throughout the project CPM scheduling is rigid and brittle: most activities have little or no float, while the critical path, by definition, has no float whatsoever— any delay in a critical path activity leads to a project delay CCM, by contrast, assumes that all activities have a statistically-probable range of durations and uses this assumption to create a more flexible and resilient schedule April 28, 2014 SE 477: Lecture 5 78 of 133 Critical chain method Each activity is assigned two durations: a ‘most likely’ or ‘best guess’ duration and a ‘pessimistic’ or ‘safe’ duration The most likely duration represents the time it would take to complete the activity 50% of the time; half of the time it would take less time, half of the time it would take more time The pessimistic duration represents the time it would take to complete the activity 90% of the time; 90% of the time it would take less time, only 10% of the time it would take more time Resources are assigned to the activities using the most likely durations The longest sequence of activities in the project is called the critical chain April 28, 2014 SE 477: Lecture 5 79 of 133 Critical chain method The pessimistic time ‘surpluses’ of all activity durations in the critical chain are summed together to create a buffer that is placed at the end of the project, the project buffer The pessimistic time surplus of an activity is the difference between the 50% (most likely) duration of the activity and the 90% (pessimistic) duration Example: For an activity with a 50% duration of 5 days and a 90% duration of 9 days, the pessimistic time surplus is 4 days All sequences of activities that feed into the critical chain have buffers (feeding buffers) placed at the points that they join the critical chain During execution, project resources focus on completing the current activity within the 50% duration and avoiding multitasking CCM project management focuses on monitoring and controlling buffer usage rather than on monitoring and controlling individual activity completion dates April 28, 2014 SE 477: Lecture 5 80 of 133 Critical chain method April 28, 2014 SE 477: Lecture 5 81 of 133 What-if analysis Scenario-based analysis of schedule to determine effects of various scenarios on different aspects of the project Example: Delay delivery of a critical component by various amounts to determine effect on schedule Example: COTS supplier is unable to provide a critical component at all What-if scenario analysis effectively tests the robustness of the project schedule in response to adverse circumstances Most common technique uses Monte Carlo analysis to generate a population of possible project schedule outcomes Think of executing the same project 10,000 times with the same resources, different boundary conditions, and no memory between executions Very useful in preparing contingency and response plans for project risks (to be discussed in upcoming lecture) April 28, 2014 SE 477: Lecture 5 82 of 133 Resource leveling Resource leveling is applied to a schedule analyzed by CPM Addresses situation where resource availability is constrained by time or amount of the resource available May also be used to keep resource usage at a constant level during certain time periods in the project Resource leveling is needed when resources have been over-allocated or assigned to two or more activities in the same time period May change the critical path in the schedule model ☛ Beware of automated resource leveling—the project schedule network may be nearly unrecognizable after leveling April 28, 2014 SE 477: Lecture 5 83 of 133 Resource leveling Uses a number of different approaches, including: Assign under-allocated resources to multiple tasks to keep them busy Move key resources off of non-critical tasks Delay start of task until required resources are available, possibly using lags Split tasks into two or more subtasks so the subtasks can be assigned to different resources April 28, 2014 SE 477: Lecture 5 84 of 133 Keeping a sense of perspective Project management is not just scheduling. (Though sometimes it seems that way.) April 28, 2014 SE 477: Lecture 5 85 of 133 Applying leads and lags Applying leads and lags allows refinement of a schedule once the major schedule network analysis effort has been completed Use of leads and lags may be used to meet imposed constraints, help in resource leveling, or incorporate contingency reserves into a schedule April 28, 2014 SE 477: Lecture 5 86 of 133 Calendars Identify days and dates when work can be performed Affect all project-related activities General project calendars govern overall limitations on when project work may be performed Example: Work is performed at a client site, and the client shuts down for three weeks during the summer Resource calendars govern limitations on when particular resources (or resource groups) may perform project work Example: Individual project team member vacation schedules Example: Development team training schedules April 28, 2014 SE 477: Lecture 5 87 of 133 Schedule development output Project schedule network diagrams Show both project network logic (sequencing) as well as critical path schedule activities Usually displayed as an activity-on-node diagram Gantt charts Specialized bar charts format to show activity start and end dates, along with durations Easy to read but limited by low information density Milestone charts ‘Stripped-down’ version of Gantt chart, showing only milestones April 28, 2014 SE 477: Lecture 5 88 of 133 Reducing Project Duration How can you shorten the schedule? Via Reducing scope (or quality) Adding resources Concurrency (perform tasks in parallel) Substitution of activities April 28, 2014 SE 477: Lecture 5 89 of 133 Schedule compression Shortens the project schedule without changing the project scope, to meet schedule constraints, imposed dates, or other schedule objectives There are two types of schedule compression, crashing and fast-tracking Crashing. Analyzes cost and schedule trade-offs to get the greatest amount of compression with the least cost Examples: Use of additional resources, being more efficient, changing approach used to perform work, work overtime Schedule crashing only works for activities where additional resources may shorten the duration of the activity April 28, 2014 SE 477: Lecture 5 90 of 133 Schedule compression Fast-tracking. Activities that would normally be done sequentially are done in parallel. Fast-tracking can lead to rework and increased risks due to unforeseen dependencies Fast-tracking only works when activities can be overlapped to shorten the total duration April 28, 2014 SE 477: Lecture 5 91 of 133 Compression Techniques Shorten the overall duration of the project Crashing » Looks at cost and schedule tradeoffs » Gain greatest compression with least cost » Add resources to critical path tasks » Limit or reduce requirements (scope) » Changing the sequence of tasks Fast Tracking » Overlapping of phases, activities or tasks that would otherwise be sequential » Involves some risk » May cause rework Barry Boehm says you cannot compress more than 25% April 28, 2014 SE 477: Lecture 5 92 of 133 Task Name ID Description of work Duration (days) Start Date (Earliest, Latest) Finish Date (Earliest, Latest) Resources (People and equipment) Effort (In staff-days) Predecessors (other tasks) Inputs (documents, decisions, information) Successors (other tasks) Outputs (documents, decisions, information) April 28, 2014 SE 477: Lecture 5 93 of 133 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) Sample Quotes “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” April 28, 2014 SE 477: Lecture 5 94 of 133 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 interchangeable 3. Because of estimation uncertainty, manager lack courteous stubbornness 4. Schedule progress is poorly monitored 5. When schedule slippage is recognized, the natural response is to add manpower. Which, is like dousing a fire with gasoline. April 28, 2014 SE 477: Lecture 5 95 of 133 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 probabilities Cost (overhead) of communication (and training) » His formula: n(n-1)/2 How long does a 12 month project take? • 1 person: 12 months • 2 persons = 7 months (2 man-months extra) • 3 persons = 5 months (3 man-months extra) Fix: don’t assume adding people will solve the problem April 28, 2014 SE 477: Lecture 5 96 of 133 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 warning Higher costs: primary and secondary Fix: Allocate more test time Understand task dependencies April 28, 2014 SE 477: Lecture 5 97 of 133 Mythical Man-Month Reliance on hunches and guesses What is ‘gutless estimating’? The myth of additional manpower Brooks Law: “Adding manpower to a late project makes it later” Q: “How does a project get to be a year late”? A: “One day at a time” Studies Each task: twice as long as estimated Only 50% of work week was programming Fixes No “fuzzy” milestones (get the “true” status) Reduce the role of conflict Identify the “true status” April 28, 2014 SE 477: Lecture 5 98 of 133 Schedule Development Workflow and Example April 28, 2014 SE 477: Lecture 5 99 of 133 Scheduling workflow Define activities Use of WBS template helps guide definition process and organize activities Perform activity sequencing Develop schedule framework according to what is logically possible – perform resource allocation later Estimate effort – the total number of labor units (e.g. staffdays) for each activity Identify resources for each activity Apply calendars to schedule framework April 28, 2014 SE 477: Lecture 5 100 of 133 Scheduling workflow Estimate activity duration based on resources for activity Perform forward pass or backward pass critical path analysis to generate schedule model Perform ‘what-if’ scenario analysis to identify contingency and risk response needs Apply resource leveling to schedule model Apply schedule compression, if needed April 28, 2014 SE 477: Lecture 5 101 of 133 WBS template Component groups with a ‘+’ in front of them are ‘rolled up’ – subcomponents are hidden to reduce clutter April 28, 2014 SE 477: Lecture 5 102 of 133 Activity definition Added System architecture definition WBS component Note expansion and detailing of WBS template Architecture design modeling entry; renamed Software architecture description to Document software architecture Note expansion and detailing of WBS template Design demonstration planning and conduct entry Note rework of WBS template Elaboration phase assessment entry Note expansion and detailing of WBS template Critical component coding demo integration entry April 28, 2014 SE 477: Lecture 5 103 of 133 Activity sequencing Note dual predecessors. Default relationship is Finish-to-Start. Here, we have defined a Start-to-Start relationship with an added lag of 5 days Here, we have defined a Finishto-Finish relationship: this is common for implementation/integration task pairs Effort Estimation Effort (called work in MS Project) is the total number of labor units needed to complete a task Measured in staff units (-hours, days, -weeks, etc.) Effort allocated among resources provides duration estimates April 28, 2014 SE 477: Lecture 5 105 of 133 Activity resource estimating Walk through activities and identify classes of resources needed If possible, do not specify individuals at this point, only their role/title Identify specific individuals as resources only if necessary April 28, 2014 SE 477: Lecture 5 106 of 133 Duration estimation The effort estimated in the effort estimation step is the total labor units needed to complete a task Duration estimation results from taking the effort and distributing it among the resources for task April 28, 2014 SE 477: Lecture 5 107 of 133 Duration estimation The resource allocation for this task is detailed on the preceding slide. Note the 20 day work (effort) estimate vs. the 8 day duration Long durations for these summary components are due to incomplete data entry for all subcomponents April 28, 2014 SE 477: Lecture 5 108 of 133 Critical path: early/late start and finish with float (slack) Schedule compression Use Finish-to-Start dependency with 5 day negative lag (-5) for successor to get reasonable relationship between two tasks. Equivalent to a 5 day lead for successor Alternatively: Use Start-to-Start dependency with 5 day lag for successor to get reasonable relationship between two tasks Note schedule compression of 5 days April 28, 2014 SE 477: Lecture 5 110 of 133 Determining resource utilization Resource graphs show the utilization of individual resources as a function of time Resource graphs can be used to identify over- and under-utilized resources Resource leveling can be used to balance utilization and/or to shift tasks to lower-cost resources April 28, 2014 SE 477: Lecture 5 111 of 133 Next Class Topic: Risk Management: Planning, risk identification, quantification and prioritization; Risk analysis, response planning, avoidance, mitigation, monitoring. Reading: PMP Study Guide: Chapter 6 Kerzner: Chapter 17 Taylor: Chapter 7 Taylor (Survival Guide): Chapter 13 Assignment 3 – due May 5 April 28, 2014 SE 477: Lecture 5 112 of 133 Journal Exercises Read the paper: Programmer Productivity: The "Tenfinity Factor” <http://www.devtopics.com/programmer-productivity-thetenfinity-factor/> Comment. Given the above, what about the impact on estimating? Also, think about programmer style and lines of code measurements. April 28, 2014 SE 477: Lecture 5 113 of 133 Midterm Examination “Nobody expects the Spanish Inquisition!” – Monty Python April 28, 2014 SE 477: Lecture 5 114 of 133 Mid-term Examination Midterm Examination will be on the Desire2Learn system starting Wednesday, April 30, through Monday, May 5 See important information about Taking Quizzes On-line Login to the Desire2Learn System (https://d2l.depaul.edu/) On-line tutorial: http://www.itd.depaul.edu/website/documentation/d2l/mp4based/quiz zes/quizzes.html On-line guide: http://www.itd.depaul.edu/website/documentation/d2l/Quizzes.pdf Take the Mid-term examination. It will be made available Wednesday, April 30, 2014. You must take the exam by COB Monday, May 5, 2014. Allow 3 hours (should take about one hour if you are prepared); note: books or notes should not be used. Midterm study guide [note solution to some problems on last page]. April 28, 2014 SE 477: Lecture 5 115 of 133 SE 477 – Class 5: Appendices This is material that is relevant but not used often enough to present in the main part of the class. Topics: Scheduling PERT Estimation technique Critical Path Method (CPM) Forward and backward pass analysis Calculating float April 28, 2014 SE 477: Lecture 5 116 of 133 Appendix: PERT Estimation Technique April 28, 2014 SE 477: Lecture 5 117 of 133 PERT estimation technique Most widely used three-point estimate is PERT (Program Evaluation and Review Technique) Defines three estimate points as: Most likely: estimate that occurs with greatest frequency Optimistic: shortest duration, taken as 10th percentile value Pessimistic: longest duration, taken as 90th percentile value PERT activity duration estimate TE and its standard deviation (sE or σ) are calculated according to: TE ( Eoptimistic 4 Emost _ likely E pessimistic ) / 6 sE ( E pessimistic Eoptimistic) / 6 April 28, 2014 SE 477: Lecture 5 118 of 133 Duration estimates distribution Most Likely Estimate is peak of distribution. For symmetric distributions, Most Likely Estimate and mean coincide. However, for skewed distributions the peak will be shifted off-center and differ from the mean. Optimistic Estimate For this activity, only 10% of the time activity will take less time than this. Conversely, 90% of the time activity will take more time than this. Pessimistic Estimate For this activity, 90% of the time activity will take less time than this. Conversely, only 10% of the time activity will take more time than this. Note that this is a symmetric, continuous distribution. Actual data will be discrete, will likely be skewed, and will best be displayed in a histogram. 10th Percentile ~ μ -2.24σ μ 90th Percentile ~ μ +2.24σ Duration April 28, 2014 SE 477: Lecture 5 119 of 133 How to calculate PERT estimates This is for statistics majors and rarely used except when analyzing data. Calculate the sample mean: 1 x N N x i i 1 Calculate the sample standard deviation: s 1 N 2 ( x i x ) N 1 i 1 Use Chebyshev’s rule to approximate optimistic and pessimistic estimates: At least (1 − 1/k2) · 100% of the values are within k standard deviations from the mean So, solving for k when this equation equals 80% (for the 20% outside the 10 and 90 percentiles), we get approximately: Optimistic x 2.24s April 28, 2014 Pessimistic x 2.24s SE 477: Lecture 5 120 of 133 PERT calculation example You have the following estimates for an activity, in staff-hours: 24, 24, 24, 40, 48, 48 Calculate the sample mean: 1 x (24 24 24 40 48 48) 6 1 x (208) 34.7 6 Calculate the sample standard deviation (s or σ): 1 6 s (xi 34.7 ) 2 6 1 i1 s 1 ((24 34.7) 2 (24 34.7) 2 (24 34.7) 2 (40 34.7) 2 (48 34.7) 2 (48 34.7) 2 ) 5 s (0.2)(114.5 114.5 114.5 28.1 176.9 176.9) s 0.2 725.4 s 145.1 s 12 April 28, 2014 SE 477: Lecture 5 121 of 133 PERT calculation example Now, calculate the PERT estimates : Optimistic x 2.24s 34.7 (2.24 12) Optimistic 34.7 26.9 7.8 Most _ Likely 24 Pessimistic x 2.24s Pessimistic 34.7 (2.24 12) 34.7 26.9 61.6 Finally, the PERT estimated activity duration is: TE ( Eoptimistic 4 Emost _ likely E pessimistic ) / 6 TE (7.8 (4 24) 61.6) / 6 165.4 / 6 TE 27.6 sE ( E pessimistic Eoptimistic) / 6 (61.6 7.8) / 6 sE 8.97 9 April 28, 2014 SE 477: Lecture 5 122 of 133 PERT calculation Beta Distribution See Journal exercise April 28, 2014 SE 477: Lecture 5 123 of 133 Journal Exercises Think about the problems with getting a good estimate. The PERT and three point estimations all rely on the assumption that the distribution of estimates are Gaussian in nature. What if they are not? What if there is a large tail for pessimistic? Hint: lookup Beta Distributions: Hint: Better Project Management Through Beta Distribution http://www.isixsigma.com/methodology/project-management/betterproject-management-through-beta-distribution/ April 28, 2014 SE 477: Lecture 5 124 of 133 Appendix: CPM Details and Example April 28, 2014 SE 477: Lecture 5 125 of 133 Critical path method A forward pass performs schedule calculations that identify the early start and finish dates of tasks and the project A backward pass performs schedule calculations that identify the late start and finish dates of tasks and the project, as well as total and free float April 28, 2014 SE 477: Lecture 5 126 of 133 Critical path method A forward pass analysis performs schedule calculations that identify the early start and finish dates of activities and the project April 28, 2014 Early Start Date (ES). ES represents the theoretically earliest date a activity can start ‣ ES = Maximum EF of predecessor activity(-ies) Early Finish Date (EF). EF represents the theoretically earliest date a activity can finish ‣ EF = ES + duration of activity SE 477: Lecture 5 127 of 133 Critical path method A backward pass analysis performs schedule calculations that identify the late start and finish dates of activities and the project, as well as total and free float April 28, 2014 Late Start Date (LS). LS represents the theoretically latest date a activity can start without delaying the project ‣ LS = LF – duration of activity Late Finish Date (LF). LF represents the theoretically latest date a activity can finish without delaying the project ‣ LF = Minimum LS of successor activity(-ies) SE 477: Lecture 5 128 of 133 Critical path method Total float (TF) is the amount of time a activity can be delayed without delaying the project as a whole TF = LF - EF If LF < EF then TF < 0 If a project has a fixed finish date constraint then TF might be less than zero, meaning it must complete before LF to satisfy the finish date constraint Free float (FF) is the amount of time a activity can be delayed without delaying its successor (dependent) activities FF = Minimum ES (successor activities) – EF Note that total float is global to the project, while free float is local to the neighborhood of the activity April 28, 2014 SE 477: Lecture 5 129 of 133 Critical Path Method List all activities in plan. Plot tasks onto chart. (Tasks = arrows. End Tasks = dots) Show dependencies. Schedule activities Sequential activities on critical path. Parallel activities. Slack time for hold-ups. Find longest path through chart. This is the critical path What is the difference between critical path and critical chain? Critical chain also manages buffer activity durations and resources April 28, 2014 SE 477: Lecture 5 130 of 133 Performing forward pass CP analysis 10 TF ES = Maximum EF of predecessor task(s) EF = ES + duration of task 5 days 2 A 5/11 5/7 30 1 4 days C 5/16 1 TF 20 TF 4 5/19 10 days B 5/7 5/16 2 Key 3 ID TF DUR Name EF ES LS LF April 28, 2014 SE 477: Lecture 5 131 of 133 Performing backward pass CP analysis 10 TF LF = Minimum LS of successor task(s) LS = LF – duration of task 5 days 3 A 5/11 5/7 30 5/12 4 days 5/16 C 4 4 TF 20 TF 10 days 5/16 5/19 5/16 5/19 1 B 5/7 5/7 April 28, 2014 Key 5/16 5/16 3 2 SE 477: Lecture 5 ID TF DUR Name EF ES LS LF 132 of 133 Calculating float FF = 6 10 6 days TF = LF - EF FF = Minimum ES (successor task) – EF 5 days A 5/11 5/7 30 5/12 0 days 4 days Critical path 5/16 C 20 0 days 10 days 5/16 5/19 5/16 5/19 B Key 5/16 5/7 ID 5/7 TF DUR Name EF ES LS LF 5/16 FF = 0 April 28, 2014 SE 477: Lecture 5 133 of 133