Estimating and Costing

1. Estimating and Costing Rick Dewar (and Brian Palmer)

2. Aims of Topic • The group project did not have to take account of real costs, and estimates were probably “guestimates”. • This topic will address those missing components • estimating how long things will take • calculating how much things will cost

3. Learning Objectives • Discuss and apply COCOMO and Albrecht Function Point Analysis to software estimation. • Explain issues pertaining to project evaluation in terms of strategic, technical and economic criteria. • Appraise projects by applying cash flow, return on investment, payback and decision tree techniques, as well as evaluating risk.

4. PM Revision • You should now know about: • WBS (work breakdown structure) & CBS (cost breakdown structure) • Gantt Charts • PERT charts • Resource Planning • Slack/Float & Critical Path • These are just some tools that support management of the project lifecycle.

5. Big bits missing... • Initial Idea & Feasibility Study • Evaluating Risk • Estimating Task Durations • Justifying the Project • Executing the Project • Winding Up • Supporting the Deliverables Project Life-Cycle

6. Software Estimation It is difficult to estimate how long a programming task might take. Yet we need to estimate to give our customers a clue about TCQ (time cost quality). Programming is a creative act, not a repeatable manual skill. If programming were simply repetition then we’d probably just cut and paste, call a function, use an API, etc. Or we'd get computers to write our programs for us.

7. Quotes from Lord Kelvin (1824-1907) • To measure is to know. • If you can not measure it, you can not improve it.

8. More quotes from Lord Kelvin • X-rays will prove to be a hoax • Radio has no future • I can state flatly that heavier than air flying machines are impossible (1895) • There is nothing new to be discovered in physics now (1900)

9. Quote from Albert Einstein Not everything that can be counted counts, and not everything that counts can be counted

10. Software Estimation - Need for historical data Nearly all estimating methods need information about how projects have been implemented in the past Care needs to be taken in applying these data to the estimator's own circumstances, because of potential differences in environmental factors (e.g. programming languages used, standards enforced, experience of staff, organisational model)

11. Software Estimation: Measure of work It is not normally possible to calculate directly the actual cost or time required to implement a project. The time taken to write a program may vary according to the competence or experience of the programmer. Implementation time may also vary because of environmental factors such as the software tools available The usual practice is to express the work content of the system to be implemented independently of effort, using a measure such as source lines of code (SLOC) or thousands of lines of code (KLOC)

12. About lines of code as an indicator SLOC is very imprecise. Do you include comments or data declarations? It is also very difficult to use for modern 4th generation languages which often use tables or diagrams to record programming rules, or CASE tools/IDEs with code generation facilities. Different measures of size are needed, such as function points, which we will discuss later.

13. Code complexity Given that 2 programs have the same length, it does not follow that each would take the same amount of time to write, even if done by the same programmer in the same environment. One may be more complex. Because of this, SLOC estimates have to be modified to take complexity into account, but it is difficult to find objective measures of complexity and estimates often depend on the subjective view of the estimator. Objective, as we know, is good and reliable; subjective is bad and unreliable.

14. Estimation Methods Can generally be divided into bottom-up and top-down approaches. Bottom-Up estimation involves dividing the project into its constituent tasks (Work Breakdown Schedule/Structure) until you get to activities that can be executed by a single person in a week or two of effort, then calculating the effort for each of these activities and summing them to produce an overall estimate • better for use in the later stages of projects • use in early stages will involve assumptions about characteristics of finished system

15. Top-Down Estimating This is normally associated with parametric models, where the costs associated with the development of a project are determined by a standard formula, incorporating parameters describing variables associated with the characteristics of the final system model will normally be one or more formulae of the form effort = (parameter value) x constant once the overall effort is calculated, it is allocated to individual activities within the project quite often top-down and bottom-up models will be used in concert

16. COCOMO Parametric model Boehm’s COnstructive COst MOdel Originally based on a study of 63 projects Based around the formula : p = c(kdsi)k where p = person months, kdsi = thousands of delivered source instructions, and c and k are constants Looks mathematical and, as such, of course, reliable We first need to estimate the kdsi

17. Cocomo constants the constants c and k can be determined from the table below according to whether the project can be classified as: Organic - relatively small team developing software in a highly-familiar in-house environment, the system under development being small with flexible interface requirements Embedded - product being developed has to operate within very tight constraints, changes to the system are very costly Semi-detached - combines elements of the organic and embedded, or has characteristics which fall between the two

18. A Cocomo calculation A project requiring 20,000 lines of code, developed in Semi-detached mode will take p = 3.0(20)1.12 = 3.0 x 28.652 = 85.956 person months, precisely All these numbers look precise (and should please Lord Kelvin) but the kdsi is a guess, and the constants are empirical approximations.

19. Basic Cocomo too simple Boehm found his Basic Cocomo to be a poor predictor of effort required. In other words, it didn't work. He still thought it was on the right lines, and went on to develop Intermediate Cocomo a nominal estimate for effort (pnom) is developed using Basic Cocomo the nominal estimate is then adjusted by a development effort multiplier (dem) : (pest) = (pnom) x (dem)

20. required software reliability data base size product complexity execution time constraints main storage constraints virtual machine volatility computer turnaround time analyst capability application experience programmer capability virtual machine experience programming language experience use of modern programming practices use of software tools required development schedule Factors in dem (more guessing)

21. Alternatives to Cocomo • Expert Judgement • ‘Price to win’ and ‘Design to Cost’ • Estimating by analogy • Albrecht Function Point Analysis, which we shall look at next

22. Albrecht Function Point Analysis • This is based on the argument that computer-based information systems comprise five major components (or external user types): • external input types • external output types • logical internal file types • external interface file types • external enquiry types

23. More guesswork The user calculates the number of each of these types in the system and weights them according to a table of values similar to the Cocomo model, to calculate the information processing size of the project This figure is adjusted by a technical complexity adjustment (TCA) based on 14 factors which can influence technical complexity It is suggested that 106 lines of Cobol, 150 lines of C or 64 lines of Basic are needed to implement a function point

24. OO Metrics Cocomo and function point analysis are not well suited to OO designs. Various metrics have been suggested, but little work has been carried out to validate them. At the moment, these metrics concentrate on assessing achieved systems.

25. OO Metrics Candidate metrics to measure size, complexity and quality: Numbers/ratios of classes and methods Depth of inheritance/number of children Coupling and cohesion Attribute/method hiding Polymorphism

26. Web Metrics Unusual in that there may be multiple languages JavaScript - client-side Perl/Java - server side Middleware - between legacy and Web applications. And multiple specialisms OO versus procedural programmers Graphic designers Architects looking at middleware, capacity planning, security, protocols Little formal consideration of all this yet.

27. Project Evaluation Once we have estimates of time, which might allow us to calculate some costs, we need to be able to assess the project against competing ideas, benchmarks and proposals. Let us consider a mini case study (caselet).

28. Widower Life Caselet One of the UK's largest life assurance, investment and pensions companies. Established in the early nineteenth century, it has £100 billion of funds under management and employs 3,000 people. Handles pensions for one million people and life assurance for further one million.

29. Widower Life Caselet Multi-channel sales capability, utilising independent financial advisers, a direct sales team and the branch network of a leading UK bank

30. Widower Life Caselet The company classifies development projects into one of three categories: Discretionary - lowest priority and can only proceed if they can produce a return on investment (typically within two years) and if the necessary resources are available Strategic - Strategic projects have a higher priority and are those that directly support the company's strategic goals - for instance entry into a new market or improving a brand image. Expected returns on such investments are often allowed to take longer (perhaps five or more years) than for discretionary projects. Essential - carry the highest priority and are those projects that must go ahead for the company to continue to trade. For instance, if the UK government changed tax rates, the company's systems must be amended to comply with this by a certain date. Another example has been Y2K.

31. Widower Life Caselet Within each category, projects can be small: costs less than £20k, medium: costs less than £250k large. Various factors (including size) determine whether a project rates high, medium or low in respect of risk and in respect of complexity. Payback and RoI (Return on Investment) also help the company assess competing projects.

32. Project Evaluation The appropriate selection of projects to undertake based on: strategic criteria technical criteria economic criteria Techniques used in Project Evaluation normally comprise : cost-benefit evaluation techniques to choose between competing project proposals risk evaluation techniques for cost minimisation We’ll see these later

33. Strategic Assessment : The development of the information system is assessed against the organisation’s strategic plan Objectives : does the system contribute to organisational objectives? improved productivity/market share Information System Plan : does the proposed system fit into an overall IS Plan? which existing systems does it replace/improve/affect? legacy issues? is it future-compatible with planned later developments? Organisational Structure : will the new system have impact on departmental or organisational structure? will new functionality overlap/replace/affect existing, especially management and control, structures?

34. Strategic Assessment Management Information System: what information will the system provide/need and at what levels in the organisation? will it complement or enhance existing management information systems? Personnel: how will the proposed system affect staffing levels and the existing employee skill-base? what implications are there for organisational policy on staff development? Image: how will the proposed system affect customer/supplier attitudes to the organisation?

35. Strategic Assessment Third party developers must also carry out strategic and operational assessments of project proposals, to determine whether taking on a project conflicts with their own strategic plans. Where a well-defined information systems strategy does not exist, system development and the assessment of project proposals are likely to be based on a more piecemeal approach. In such cases it is likely that economic assessment will have more bearing on the outcome of the proposal.

36. Technical Assessment : evaluate the required functionality against the hardware and software available. Where an organisation has a strategic information systems plan this is likely to place limitations on the nature of the solutions that might be considered. The cost of the solution, incorporating any constraints imposed by strategic plans, will also influence the economic assessment.  if project re-scoped, what are technical consequences?

37. Economic Assessment : The most common way of carrying out an economic assessment of a proposed information system, or other development, is by comparing the expected costs of the development and the operation of the system with the benefits of having it in place. Assessment is based upon the question of whether the estimated costs are exceeded by the estimated income and other benefits.

38. Economic Assessment The standard way of evaluating the economic benefits of any project is to carry out a cost-benefit analysis, which consists of two steps ; (1) Identifying and estimating all of the costs and benefits of carrying out the project development costs operating costs new equipment costs technical costs training and back-fill cost of capital efficiency benefits increased sales/productivity benefits organisational benefits tangible and intangible benefits...

39. Economic Assessment (2) Expressing these costs and benefits in common units We must evaluate the net benefit, which is the difference between the total benefit and total cost. Development Costs - salaries and other employment costs of the staff involved in the development project and all associated costs. Setup Costs - costs of putting system in place, include new hardware, ancillary equipment, file conversion, recruitment, staff training, etc. Operational Costs - costs of operating the new system, to be offset against the costs of the existing system.

40. Economic Assessment Benefits are often quite difficult to quantify in monetary terms even once they have been identified. They can be categorised as : Direct Benefits - accrue directly from the operation of the new system, could include reduction in salary bill. Assessable indirect benefits - secondary benefits, could include increased accuracy of data input/error reduction resulting in cost reduction. Intangible Benefits - generally longer term, difficult to quantify, for example increased staff job interest and/or satisfaction may lead to reduced staff turnover and thereby lower recruitment costs. Or, improved customer perception and brand awareness. Or, preparedness for future projects.

41. Any project that shows an excess of benefits over costs is clearly worth considering for implementation. However, this is not the full picture. We may not be able to afford the costs; there may be better or less risky projects. Cash Flow Forecasting : As important as estimating the overall costs and benefits of a project is the forecasting of the cash flows that will take place and their timing. A cash flow forecast will indicate when expenditure and income will take place. Accurate cash flow forecasting is not easy as it generally needs to be done early in the project’s life-cycle and many items to be estimated may be some years in the future. When estimating future cash flows it is usual to ignore the effects of inflation.

42. Cost-Benefit Evaluation Techniques : Net Profit Difference between total costs and total profit over the life of a project. Payback Period The time taken for a project to break even or pay back the initial investment. Normally a project with a shorter payback period will be selected on the basis that an organisation wishes to minimise the period that it is “in debt”. Advantages - simple to calculate, not sensitive to small forecasting errors. Disadvantages - ignores overall profitability of project once it has broken even.

43. Cost-Benefit Evaluation Techniques : Return on Investment (ROI) Also known as the accounting rate of return (ARR) ROI = (average annual profit/total investment) *100 Advantages - simple, easy to calculate Disadvantages - takes no account of timing of cash flows, not directly comparable to bank interest rates, can be sensitive to errors in predictions.

44. Simple Cash Flow Forecast We can use this table to illustrate Payback and Return on Investment (RoI).

45. Return on Investment One measure of RoI is Net Present Value (NPV). This is a project evaluation technique that takes into account the profitability of a project and the timing of the cash flows that are produced based on the principal that £100 today is worth more than £100 in x years time the difference is calculated by discounting the value at an appropriate interest rate present value = value in year t/(1+discount rate)t NPV is obtained by discounting each cash flow, both negative and positive, and summing the discounted values.

46. The higher the NPV, the more viable the project. Allows comparison with other options and projects The main problem with using NPV for project selection is selecting an appropriate discount rate. This can be achieved by : organisational standard rate current interest rates and borrowing costs use discount rate as target rate of return

47. Payback Period Use the discounted accumulated cash flow to determine when the project breaks even (pays back). Calculate graphically or via linear interpolation. Answer: Payback 2.7 years after project start!

48. Internal Rate of Return (IRR) IRR = discount rate to give zero NPV. The higher the IRR, the more viable the project.

49. IRR a project showing an estimate IRR of 10% would be worthwhile if the capital could be borrowed for less than 10% or if the capital could not be invested elsewhere for a return of greater than 10% One deficiency of IRR is that it does not indicate the size of the return, thus a project with a NPV of £100,000 and an IRR of 15% may be more attractive than a project with a NPV of £10,000 and IRR of 38%. Therefore, mixed methods and thresholds are often used.

50. Decision Trees This cost-benefit analysis approach will result in a set of cash flow forecasts, each with an associated probability of occurring. The value of the project is then calculated by summing the cost or benefit for each possible outcome, weighted by its probability