Project Planning and Control: Estimation and Work Breakdown Structure

1. Chapter 7: Estimation project planning - what to do project control make sure it’s done right estimation of detailed system design

2. determine requirements from objectives specify work activities plan project organization develop schedule develop resource plan and budget establish control mechanisms each project is unique Planning Process

3. Project objectives are set early Determine requirements Statement of Work, which contain product description, constraints, schedule requirements, budget limit, and roles of project participants. See figure 7.1 for example of SOW Set objectives and Requirements

4. Is a formal document that captures and defines the work activities, deliverables, and timeline a vendor must execute in performance of specified work for a client Areas that are typically addressed by a SOW are as follows: Purpose: Why are we doing this project? Scope of Work: This describes roughly the work to be done in detail. Work: This describes where the work is to be performed. Period of Performance: such as start and finish time, number of hours Deliverables Schedule: This part lists the specific deliverables, describing what is due and when. Applicable Standards: This describes any industry specific standards that need to be adhered to in fulfilling the contract. Acceptance Criteria: This specifies how the buyer or receiver of goods will determine if the product or service is acceptable. Special Requirements: This specifies any special hardware or software, requirements. Type of Contract/Payment Schedule. Miscellaneous: There are many items that do not form part of the main negotiations but are nonetheless very important to the project. SOW

5. Specify work activities STATEMENT OF WORK: product descriptions constraints schedule requirements budget limits roles & responsibilities Identify Specific work to be Done

6. once objectives set, TRANSLATE INTO WORK ELEMENTS what needs to be done easy to overlook some, or duplicate WORK BREAKDOWN STRUCTURE divide project into major work categories Subdivide .”Running a project without a WBS is like going to a strange land without a roadmap” WORK DEFINITION

7. How Do you eat an elephant? Just One slice at a time……

8. Work Breakdown Structure is a deliverable oriented decomposition of a project into smaller components.

9. WBS example

10. level 1 - overall project level 2 - category major project sub element level 3 - task Sub element of category level x - subtask level bottom - WORK PACKAGE specific activity, summary of work to be done is the work Package. Work Breakdown Structure

11. WBS can be focused on PRODUCT FUNCTION etc. when work packages identified, estimate requirements by resource WHAT IS NEEDED WHEN WHAT MUST PRECEDE Detailed Task List

12. needs to be checked, approved provides good definition of work how long it will take resources required estimated costs planning & control assignments, budget, basis for control Work Breakdown Structure

13. A Work Package is a deliverable or work component at the lowest level of its WBS branch. Is the basic building block of a work breakdown structure. It can be considered as a sub-project. It is composed of one or several tasks. Is a subset of a project that can be assigned to a specific party for execution. It is the lowest level of the WBS where both the cost and the duration can be reliably estimated. chunk of required work relatively small cost and short duration includes summary of work inputs required (predecessors) manager responsible product specifications resources required (including budget, dates) deliverables Work Packages( for Tasks)

14. system design activity predecessor time A2 identify req’d info A1 10 days A31 basic software A2 3 days A32 data access req’d A2 1 day A33 vendor software A2 1 day list of work packages(activities)

15. A workpackage is not a separate function or data object in the Project System. You can create a workpackage according to your needs using a WBS element or an activity. Work packages can be on any level in the work breakdown structure and are characterized by: Start and finish dates Texts describing the work to be performed Responsible cost centers Cost centers carrying out the project related tasks without definable end results (overhead & management; inspection; maintenance) should be included as task-oriented work packages for COST purposes How is a Work Package Organized?

16. Identify resources required by work package RESPONSIBILITY MATRIX Which functions do what work packages Cost account structure start & finish date budget responsibilities Plan Project Organization

17. lists activities on one axis lists people on other axis shows who is primarily responsible also involved has approval authority must be notified Project Management System

18. BASIS for RESOURCE ALLOCATION ESTIMATED COST plan for monitoring & control EVENTS or MILESTONES when activity completed (or started) INTERFACE EVENT when responsibility passes Develop the Schedule

19. project schedules project master schedule - top management overview rather than detail task schedules specific activities required more detail Kinds of Schedules

20. Work expands to fill the time available for its completion - Parkinson's law The key is not to prioritize what's on your schedule, but to schedule your priorities. The only reason I'm coming out here tomorrow is the schedule says I have to.. If you don’t plan, it doesn’t work. If you do plan, it doesn’t work either. Why plan! The nice thing about not planning is that failure comes as a complete surprise rather than being preceded by a period of worry and depression. quotes

21. Activities often compete for the same resources hire more reschedule Resource plans show critical resource schedules bottlenecks around which schedule is built Develop Resource Plans & Budgets

22. visual aids Gantt Charts plan - activities by time (work in outline) implement - fill in as work done doesn’t show relationships well very good at seeing where things are (IF ACCURATE) Expense Charts - cumulatively graph $ spent Charts

23. Includes milestones, at completion of sub component or phase, to keep each element of the organization informed of what is going on. checkpoint reviews, held at the conclusion of each phase to determine whether or not to proceed with the rest of the project. status review meetings, gather cost , quality, and schedule information. staff meetings, regularly held to maintain communication. Control Points

24. Planning - key to accurate bidding need to know what it will cost in order to know how to price need to know resources required, complex projects take a long time MIS projects activities, predecessor relations, resource use Recap

25. Software Estimation

26. Avoid the entire project estimation trap, you can not estimate the project with any degree of accuracy. The schedule is the one way the project will not proceed. Use date range estimate, “ well based on the 3 minutes if information you’ve told me about the project. It looks like we could deliver something in Q2 of next year”. Remember that an estimate is an approximation- a guess. The bigger the guess the more error you will have Many software people are optimistic. Tasks they take longer that you think they will Tips for estimating

27. It is easier to estimate smaller chunk of work. If you have given a project deadline, you do need to estimate anything al all. Timebox phases (build the system by feature) if you have an over constrained project. Estimating with multitasking. You don’t. you can’t. don’t even try it. In multitasking you guarantee that your project will be late. Estimating using inch-pebbles (one to two days tasks that either done or not done) wherever possible. Tips for estimating

28. Program, A program is what we all have developed. It's simple piece of software that is useful to the programmer and/to some set of users who are directly involved in defining its requirements. Programming System, are programs intended to be reused as parts of larger systems. It is a code usable by anyone Programming Product, In theory, all commercial applications and mature bespoke (custom-made) applications are programming products. It is a code that tested, documented, maintained, ready to be marketed. Programming System Product, It has all the behavior of both a programming product and a programming system. It is useful to a wide range of users and can be effectively extended and/or embedded for the creation of larger systems. It involved a continual effort of development team over time. Microsoft office suite and Microsoft Project. Programming Products (scale of project size)

29. Scale of project size effort

30. First, techniques of estimating are poorly developed. More seriously, they reflect an unvoiced assumption which is quite untrue, i.e., that all will go well. Second, estimating techniques fallaciously confuse effort with progress, hiding the assumption that men and months are interchangeable. Third, schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering. Fourth, when schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like putting off a fire with gasoline, this makes matters worse, much worse. More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster. Fifth,Scheduling tendency to assume all will go well causes of project failureAccording to Brooks

31. partitionable project Independent activities, adding more people will help but not at a proportional rate. non-partitionable project Activities are inter-related and need to be coordinated, no benefit at all from adding people, this is true for most of IS project. complex interactions - must separately coordinate each task with all others first few have declining marginal contribution after some number, adding people slows down project impact of adding people

32. testingis the activity most difficult to predict planning 1/3 of project coding 1/6 of project component testing 1/4 of project system testing 1/4 of project most projects are on schedule UNTIL TESTING Brooks’s Law: Adding manpower to a late project makes it later software project activities

33. There is wide variation in productivity between good and fair programmers The concept of surgical team was proposed. A surgical team assigned to specific system task, and should not consist of more than 10 people. programmer productivity

34. Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value. Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value. Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value. Budget estimate, Early in the planning phase, top down estimate, -10 percent to + 25percent. Definitive estimate, late in the planning phase (?) , bottom up estimate, -5 percent to +10 percent. Estimate types

35. Estimated cost Software estimation is very difficult. The of one real software project was reported to vary by almost 800% using 12 different software estimation models duration is exponential (bigger jobs take more than proportionally longer) analogous to run 100 meters, running 1 kilometer. one manager noted programming taking twice as long as estimate only getting 20 hours of work/week machine down, divert to emergencies, meetings, paperwork, sick Software Estimation Methods

36. Failure is not an option. As always, victory finds a hundred fathers but defeat is always an orphan. Sweat plus sacrifice equals success. A life without mistakes is a mistake within itself. To give anything less than your best is to sacrifice the gift. Quotes….

37. SLOC is a software metric used to measure the size of a software program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced. There are two major types of SLOC measures: physical and logical. Source lines of code (SLOC)

38. SLOC is particularly ineffective at comparing programs written in different languages unless adjustment factors are applied to normalize languages, also skilled developers may be able to develop the same functionality with far less code, Disadvantages of SLOC

39. Line of Code Operation

40. This is a top-down method that was devised by Allan Albrecht when he worked for IBM. Albrecht was investigating programming productivity and needed some way to quantify the functional size of programs independently of the programming languages in which they had been coded. He developed the idea of function points  Function Point Analysis has been proven as a reliable method for measuring the size of computer software AIMS consistent measure meaningful to end user function points should be easier to understand than lines of code rules easy to apply Can estimate based on requirements specification independent of technology used Albrecht’s Function Point Analysis Method

41. count External user inputs External outputs Logical internal file External interface file types External inquiry types get points for every useful activity function points= information processing size x technical complexity adjustment Albrecht’s System

42. complexity tables data elements referenced 1-4 5-15 16 or more file types referenced 0 or 1 2 3 or more table of SIMPLE, AVERAGE, COMPLEX Albrecht’s System

43. Albrecht complexity

44. SIMPLE AVERAGE COMPLEX external input x 3 x 4 x 6 external output x 4 x 5 x 7 logical internal file x 7 x 10 x 15 ext interface file x 5 x 7 x 10 external inquiry x 3 x 4 x 6 add up, get total unadjusted function points Albrecht functional multipliers

45. 14 general application characteristics data communications on-line update distributed functions processing performance re-usability heavily used configuration installation ease transaction rate operational ease on-line data entry multiple sites end user efficiency facilitate change not present = 0 average influence = 3 insignificant influence = 1 significant influence = 4 moderate influence = 2 strong influence = 5 TCA = 0.65+(0.01x(total degree of influence)) Estimate effort = Total * TCA. Albrecht Technical Complexity Adjustment

46. Albrecht method alternative counting practices weights used are questionable large systems under-weighted (XEROX 1985: rapid drop in productivity with increasing system size) range of points too narrow but MUCH BETTER THAN SLOC Symons’ complaints

47. modification of Albrecht use same Technical Complexity Adjustment extend general application characteristics to 19 or more weights adjusted Information Processing Size changed the most Mk II Function Point Analysis

48. Most Entities in the system are going to have at least 5 transactions: Create, Read, Update, Delete, and List (CRUDL) logical transaction = unique input/process/output combination triggered by unique event of interest to the user or need to retrieve information create a customer read update an account delete List, produce monthly summary report logical transactions

49. UFPs = WI x # input data element types + WE x # entity types referenced + WO x # output data element types weights determined by calibration determine UFPs for system by adding UFPs for all system logical transactions assumes work directly proportional to # of data elements; size of process proportional to # data entries; weights meaningful, obtainable unadjusted function points

50. Albrecht’s method with 2 modifications: extend general application list to 19 interfaces to other applications special security features direct access requirement for third parties special user training facilities documentation requirements TCA = 0.65 + C x (total degree of influence) where C is obtained by calibration complexity adjustment