1.1 What is cost benefit analysis?

Cost benefit analysis (CBA) is a technique for assessing the monetary social costs and benefits of a capital investment project over a given time period. The principles of cost-benefit analysis (CBA) are simple:

• Appraisal of a project: It is an economic technique for project appraisal, widely used in business as well as government spending projects (for example should a business invest in a new information system)
• Incorporates externalities into the equation: It can, if required, include wider social/environmental impacts as well as ‘private’ economic costs and benefits so that externalities are incorporated into the decision process. In this way, CBA can be used to estimate the social welfare effects of an investment
• Time matters! CBA can take account of the economics of time– known as discounting. This is important when looking at environmental impacts of a project in the years ahead

1.2 Cost Benefit Analysis Components

1. General description of the project
2. List of alternative scenarios
3. Identify Benefits and Costs
4. Schedule Benefits and Costs
5. Comparison of alternatives
6. Sensitivity Analysis

A CBA application includes the following stages:

1. General description of the project:This part includes an explanation on the environment under which each analysis is done such as the objectives, the assumptions, the project/decision life etc.
2. List of alternative scenarios:In order to decide which is the best option in the CBA we have to consider the costs and the benefits for each of these options. This section lists the options considered during the analysis.
3. Identify Benefits and Costs:In this part, the application lists the exact benefits and costs met in each of the alternative scenarios. The application divides these into two kinds: The ones that are relatively straightforward to be measured and the ones that are not very easy to be measured. Many factors must be considered during the process of estimating the costs associated with competing alternatives in a CBA.

• All costs for the full system life cycle for each competing alternative must be included. The following factors must be addressed: Activities and Resources, Cost Categories, Personnel Costs, Direct and Indirect Costs (Overhead), Depreciation, and Annual Costs.
• Benefits are the services, capabilities, and qualities of each alternative system, and can be viewed as the return from an investment. To estimate benefits, first identify the benefits for both the customers and the organization that provides the service(s) to the customers. Benefits to customers are improvements to the current IT services and/or the addition of new services. Some possible benefits for the servicing organization are productivity gains, staffing reductions, or improved organizational effectiveness. After the benefits are identified, the user has to establish performance measures for each benefit. The final step is to estimate the value of the benefits. If a benefit cannot reasonably be assigned a monetary value, it should be valued using a more subjective, qualitative rating system (which assigns relative numerical values for the competing alternatives). All benefits for the full system life cycle for each competing alternative must be included.
  4. Schedule Benefits and Costs:For each of the alternatives defined in step 2, the user now identifies the value of each benefit and cost for each year through the life cycle of the decision beginning from Year 0, which is the start of the decision life. After the costs and benefits for each year of the system life cycle have been estimated, convert them to a common unit of measurement to properly compare competing alternatives. That is accomplished by discounting future Euro values, which transforms future benefits and costs to their “present value.” The present value (also referred to as the discounted value) of a future amount is calculated with the following formula = F (1/(1+I)n), where P = Present Value, F = Future Value, I = Interest Rate, and n = number of years.
  5. Comparison of alternatives:In this part the application compares the alternative solutions. The comparison is illustrated with tables and graphs so as to facilitate decision making. When the costs and benefits for each competing alternative have been discounted, compare and rank the discounted net value (discounted benefit minus discounted cost) of the competing alternatives. When the alternative with the lowest discounted cost provides the highest discounted benefits, it is clearly the best alternative.
  6. Sensitivity Analysis:In this part the application helps the user define how sensitive the results are to changes in the costs and benefits. This sensitivity involves costs and benefits whose definition is not straightforward or is not easy to be exactly defined. Sensitivity analysis tests the sensitivity and reliability of the results obtained from the cost-benefit analysis. Since the CBA is normally the key document in the investment review process, reviewers want assurance that the analysis is reliable. Sensitivity analysis identifies those input parameters that have the greatest influence on the outcome, repeats the analysis with different input parameter values, and evaluates the results to determine which, if any, input parameters are sensitive. If a relatively small change in the value of an input parameter changes the alternative selected, then the analysis is considered to be sensitive to that parameter. If the value of a parameter has to be doubled before there is a change in the selected alternative, the analysis is not considered to be sensitive to that parameter. The estimates for sensitive input parameters should be re-examined to ensure that they are as accurate as possible.

2.1 Why Estimate Time Accurately?

Accurate time estimation is a crucial skill in project management. Without it, you won’t know how long your project will take, and you won’t be able to get commitment from the people who need to sign it off.

Even more importantly for your career, sponsors often judge whether a project has succeeded or failed depending on whether it has been delivered on time and on budget. To have a chance of being successful as a project manager, you need to be able to negotiate sensible budgets and achievable deadlines.

2.2 How to Estimate Time Accurately

Use these steps to make accurate time estimates:

Step 1: Understand What’s Required

Start by identifying all of the work that needs to be done within the project. Use tools such as Business Requirements Analysis  , Work Breakdown Structures  , Gap Analysis   and Drill-Down   to help you do this in sufficient detail.

As part of this, make sure that you allow time for meetings, reporting, communications, testing and other activities that are critical to the project’s success. Step 2: Order These Activities

Now, list all of the activities you identified in the order in which they need to happen.

At this stage, you don’t need to add in how long you think activities are going to take. However, you might want to note any important deadlines. For example, you might need to get work by the finance department finished before it starts work on “Year End.”

Step 3: Decide Who You Need to Involve

You can do the estimates yourself, brainstorm   them as a group, or ask others to contribute.

Where you can, get the help of the people who will actually do the work, as they are likely to have prior experience to draw upon. By involving them, they’ll also take on greater ownership of the time estimates they come up with, and they’ll work harder to meet them.

Tip:

If you involve others, this is a good time to confirm your assumptions with them.

Step 4: Make Your Estimates

You’re now ready to make your estimates. We’ve outlined a variety of methods below to help you do this. Whichever methods you choose, bear these basic rules in mind:

• To begin with, estimate the time needed for each task rather than for the project as a whole.
• The level of detail you need to go into depends on the circumstances. For example, you may only need a rough outline of time estimates for future project phases, but you’ll probably need detailed estimates for the phase ahead.
• List all of the assumptions, exclusions and constraints that are relevant; and note any data sources that you rely on. This will help you when your estimates are questioned, and will also help you identify any risk areas if circumstances change.
• Assume that your resources will only be productive for 80 percent of the time. Build in time for unexpected events such as sickness, supply problems, equipment failure, accidents and emergencies, problem solving, and meetings.
• If some people are only working “part-time” on your project, bear in mind that they may lose time as they switch between their various roles.
• Remember that people are often overly optimistic, and may significantly underestimate the amount of time that it will take for them to complete tasks.

Tip:

The most reliable estimates are those that you have arranged to be challenged. This helps you identify any assumptions and biases that aren’t valid.

You can ask team members, other managers, or co-workers to challenge your time estimates.

2.3 Methods for Estimating Time

We’ll now look at different approaches that you can use to estimate time. You’ll probably find it most useful to use a mixture of these techniques.

• Bottom-Up Estimating

Bottom-up estimating allows you to create an estimate for the project as a whole. To analyze from the “bottom up,” break larger tasks down into detailed tasks, and then estimate the time needed to complete each one.

Because you’re considering each task incrementally, your estimate of the time required for each task is likely to be more accurate. You can then add up the total amount of time needed to complete the plan.

Tip 1:

How much detail you go into depends on the situation. However, the more detail you go into, the more accurate you’ll be.

If you don’t know how far to go, consider breaking work down into chunks that one person can complete in half a day, for example. Sure, this is a bit circular, but it gives you an idea of the level of detail you should aim for.

Tip 2:

Yes, this does take a lot of work, however, this work will pay off later in the project. Just make sure that you leave plenty of time for it in the project’s Design Phase.

• Top-Down Estimating

In top-down analysis, you develop an overview of the expected timeline first, using past projects or previous experience as a guide.

It’s often helpful to compare top-down estimates against your bottom-up estimates, to ensure accuracy.

Note:

Don’t assume that the bottom-up estimates are wrong if they differ widely from the top-down ones. In fact, it’s more likely that the reverse is true.

Instead, use the top-down estimates to challenge the validity of the bottom-up estimates, and to refine them as appropriate.

• Comparative Estimating

With comparative estimating, you look at the time it took to do similar tasks, on other projects.

• Parametric Estimating

With this method, you estimate the time required for one deliverable; and then multiply it by the number of deliverables required.

For example, if you need to create pages for a website, you’d estimate how much time it would take to do one page, and you’d then multiply this time by the total number of pages to be produced.

• Three-Point Estimating

To build in a cushion for uncertainty, you can do three estimates – one for the best case, another for the worst case, and a final one for the most likely case.

Although this approach requires additional effort to create three separate estimates, it allows you to set more reasonable expectations, based on a more realistic estimate of outcomes.

Tip:

In the early stages of project planning, you often won’t know who will do each task – this can influence how long the task will take. For example, an experienced programmer should be able to develop a software module much more quickly than someone less experienced.

You can build this into your estimates by giving best, worst, and most likely estimates, stating the basis for each view.

2.4 Preparing Your Schedule

Once you’ve estimated the time needed for each task, you can prepare your project schedule  . Add your estimates to the draft activity list that you produced in the second step, above.

You can then create a Gantt Chart   to schedule activities and assign resources to your project; and to finalize milestones and deadlines.

Tip:

If your project is complex, you might find that identifying the critical path   on your plan is helpful. This will help you highlight the tasks that cannot be delayed if you’re going to hit your deadline.

Key Points

You need to estimate time accurately if you’re going to deliver your project on time and on budget. Without this skill, you won’t know how long your project will take, and you won’t be able to get commitment from the people required to help you achieve your objective.

More than this, you risk agreeing to impossibly short deadlines, with all of the stress, pain, and loss of credibility associated with this.

To estimate time effectively, follow this four-step process:

1. Understand what’s required.
2. Prioritize activities and tasks.
3. Decide who you need to involve.
4. Do your estimates.

Use a variety of estimating methods to get the most accurate time estimates.

3.1 Estimation involves answering the following questions:

1.    How much effort is required to complete each activity?
2.    How much calendar time is needed to complete each activity?
3.    What is the total cost of each activity?

Project cost estimation and project scheduling are normally carried out together. The costs of development are primarily the costs of the effort involved, so the effort computation is used in both the cost and the schedule estimate. However, you may have to do some cost estimation before detailed schedules are drawn up. These ini- tial estimates may be used to establish a budget for the project or to set a price for the software for a customer. There are three parameters involved in computing the total cost of a software development project:

•     Hardware and software costs including maintenance
•     Travel and training costs
•     Effort costs (the costs of paying software engineers).

For most projects, the dominant cost is the effort cost. Computers that are power- ful enough for software development are relatively cheap. Although extensive travel costs may be needed when a project is developed at different sites, the travel costs are usually a small fraction of the effort costs. Furthermore, using electronic communications systems such as e-mail, shared web sites and videoconferencing can significantly reduce the travel required. Electronic conferencing also means that travelling time is reduced and time can be used more productively in software development. Effort costs are not just the salaries of the software engineers who are involved in the project. Organisations compute effort costs in terms of overhead costs where they take the total cost of running the organisation and divide this by the number of productive staff. Therefore, the following costs are all part of the total effort cost:

1.    Costs of providing, heating and lighting office space
2. Costs of support staff such as accountants, administrators, system managers, cleaners and technicians
3.    Costs of networking and communications
4.    Costs of central facilities such as a library or recreational facilities
5. Costs of Social Security and employee benefits such as pensions and health insurance.

However, for any software problem, there are many different solutions, each of which has different attributes. One solution may execute more efficiently while another may be more readable and easier to maintain. When solutions with different attributes are produced, comparing their production rates is not really meaningful. Nevertheless, as a project manager, you may be faced with the problem of estimating the productivity of software engineers. You may need these productivity estimates to help define the project cost or schedule, to inform investment decisions or to assess whether process or technology improvements are effective. Productivity estimates are usually based on measuring attributes of the software and dividing this by the total effort required for development. There are two types of metric that have been used:

1. Size-related metrics. These are related to the size of some output from an activity. The most commonly used size-related metric is lines of delivered source code. Other metrics that may be used are the number of delivered object code instructions or the number of pages of system documentation.

2. Function-related metrics. These are related to the overall functionality of the delivered software. Productivity is expressed in terms of the amount of usefulfunctionality produced in some given time. Function points and object points are the best-known metrics of this type.

Estimation techniques

There is no simple way to make an accurate estimate of the effort required to develop a software system. You may have to make initial estimates on the basis of a high- level user requirements definition. The software may have to run on unfamiliar computers or use new development technology. The people involved in the project and their skills will probably not be known. All of these mean that it is impossible to estimate system development costs accurately at an early stage in a project. Furthermore, there is a fundamental difficulty in assessing the accuracy of different approaches to cost-estimation techniques. Project cost estimates are often self- fulfilling. The estimate is used to define the project budget, and the product is adjusted so that the budget figure is realised. A controlled experiment would not reveal the cost estimate to the project man- ager. The actual costs would then be compared with the estimated project costs. However, such an experiment is probably impossible because of the high costs involved and the number of variables that cannot be controlled.

Nevertheless, organisations need to make software effort and cost estimates.

Some examples of the changes that may affect estimates based on experience include:

1.    Distributed object systems rather than mainframe-based systems
2.    Use of web services
3.    Use of ERP or database-centred systems
4.    Use of off-the-shelf software rather than original system development
5. Development for and with reuse rather than new development of all parts of a system

If project managers have not worked with these techniques, their previous experience may not help them estimate software project costs. This makes it more difficult for them to produce accurate costs and schedule estimates. A top-down approach starts at the sys- tem level. You start by examining the overall functionality of the product and how that functionality is provided by interacting sub-functions. The costs of system-level activities such as integration, configuration management and documentation are taken into account. The bottom-up approach, by contrast, starts at the component level. The system is decomposed into components, and you estimate the effort required to develop each of these components. You then add these component costs to compute the effort required for the whole system development.

The disadvantages of the top-down approach are the advantages of the bottom-up approach and vice versa. Top-down estimation can underestimate the costs of solving difficult technical problems associated with specific components such as inter- faces to nonstandard hardware. There is no detailed justification of the estimate that is produced. By contrast, bottom-up estimation produces such a justification and con- siders each component. However, this approach is more likely to underestimate the costs of system activities such as integration. Bottom-up estimation is also more expensive. There must be an initial system design to identify the components to be costed.

Each estimation technique has its own strengths and weaknesses. Each uses different information about the project and the development team, so if you use a single model and this information is not accurate, your final estimate will be wrong. For large projects, therefore, you should use several cost estimation techniques and compare their results. If these predict radically different costs, you probably do not have  enough  information  about  the  product  or  the  development  process.  You should look for more information about the product, process or team and repeat the costing process until the estimates converge.

These estimation techniques are applicable where a requirements document for the system has been produced. This should define all users and system requirements. You can therefore make a reasonable estimate of the system functionality that is to be developed. In general, large systems engineering projects will have such a requirements document. However, in many cases, the costs of many projects must be estimated using only incomplete user requirements for the system. This means that the estimators have very little information with which to work. Requirements analysis and specification is expensive, and the managers in a company may need an initial cost estimate for the system before they can have a budget approved to develop more detailed requirements or a system prototype.

Under these circumstances, “pricing to win” is a commonly used strategy. The notion of pricing to win may seem unethical and unbusinesslike. However, it does have some advantages. A project cost is agreed on the basis of an outline proposal. Negotiations then take place between client and customer to establish the detailed project  specification.  This  specification  is  constrained  by  the  agreed  cost.  The buyer and seller must agree on what is acceptable system functionality. The fixed factor in many projects is not the project requirements but the cost. The require- ments may be changed so that the cost is not exceeded.

Project duration  and  staffing

As well as estimating the effort required to develop a software system and the over- all project costs, project managers must also estimate how long the software will take to develop and when staff will be needed to work on the project. The development time for the project is called the project schedule. Increasingly, organisations are demanding shorter development schedules so that their products can be brought to market before their competitor’s. The relationship between the number of staff working on a project, the total effort required and the development time is not linear. As the number of staff increases, more effort may be needed. The reason for this is that people spend more time communicating and defining interfaces between the parts of the system developed by other people. Doubling the number of staff (for example) therefore does not mean that the duration of the project will be halved.

4.1 Does late delivery affect our standing in any way?

It depends on the situation. Late deliveries do factor into your eligibility and status for some features. How your buyer rates you has more weight than when you deliver. If you deliver late, but in the end your buyer is happy with your work and leaves you positive feedback that will count more than the fact that it was delivered late. In general it is important to coordinate with your buyer because once you’re late, the buyer is free to cancel or leave negative feedback which can negatively affect your status and ratings.

4.2 Delivery Performance

Monitoring Performance

Performance measures provide a management framework, facilitate communication, direct behaviours within the organisation, foster improvement and assess positioning and operational capacity. There are a great number of indicators for measuring the quality of services along the supply chain. These include time, scope, service and cost. No single indicator allows measuring all aspects of supply chain management. They should be interpreted and used in combination.

Performance of the supply chain should be measured regularly, consistently and systematically rather than waiting until services have deteriorated below acceptable levels. Monitoring should be a key element of running a logistics service. Actual performance should be compared with the goals and objectives established for the program, which defines the level of service logistics tries to achieve.

Some aspects to monitor in logistics

Supply chain response/lead time

Lead time is the time between placing an order and receiving the goods or service. Delivery too early or too late may also incur unnecessary costs. Delivery too early can mean goods have to be stored until needed and will incur costs whilst being stored in warehouses. Delivery too late can mean the costs of setting up facilities, for example feeding stations and having people ready to distribute goods, is wasted because the goods have not been delivered. It can cause the organisation to incur additional transport costs, for example, aircraft/helicopters have to be used to move the goods more quickly along the next part of the supply chain. In disaster/emergency relief situations, timing of delivery can have a serious impact on the relief operation and on the beneficiaries.

Information on status of orders

The internal performance of the logistics function is dependent on the efficiency and effectiveness of each of the logistics components. For example, one performance indicator for procurement, would be its ability to disseminate information on the number of orders issued. This will enable the warehouse to provision for storage space. Unexpected deliveries can disrupt operations and put the stock at risk of being stolen when left in the open.

Efficiency

The measurement of efficiency is sometimes relative and dependant on what an entity defines as efficiency. In this context, efficiency is the satisfactory delivery of a logistics service that enables the end user to fulfil the intended purpose of the request. A good example is the request for malaria prevention medication ordered to be pre-positioned before a malaria season. A late delivery would mean higher incidents of malaria and an increase in the request for malaria treatment rather than malaria prevention drug.

Total supply chain costs

The total cost concept focuses on reducing the total cost of logistics rather than the cost of each activity. An organisation should monitor the cost reduction across the board and evaluate the impact on each of the logistics components. For example, purchasing in bulk may reduce the cost of the product but at the same time increase the stock holding costs.

Inventory costs

Inventory carrying costs include:

• inventory service costs – insurance and taxes;
• storage space costs – leasing costs or land rates;
• inventory risk costs – these are costs related to pilferage, the risk of goods being kept so long that they become obsolete, the risk of damage, etc; and
• carrying costs – the cost of storing – labour, depreciation and other overheads.

Inventory value

The concept of value has shifted. In recent years the concept of value has become accepted as the difference between the value a customer attributes to a product or service and the cost of acquiring value. Excessive stock holding is not only a risk in emergencies in the event of an evacuation but also not cost effective when millions are tied up in dormant stocks that may not all be utilised within reasonable time, or used at all due to rapidly changing needs. Monitoring and collaborating closely with programs on distribution rates would help in balancing the benefits.

Order management costs

Order management costs include those for issuing and closing orders, the related handling costs, and the associated communications costs. It would be prudent to benchmark these and keep them under close monitoring to ensure that service delivery is cost effective.

Cost of waste

The cost of waste covers the cost of disposing of packaging and damaged or unserviceable equipment. Waste disposal costs have sharply increased due to environmental impacts. .

Reporting performance

Customers provide feedback on the performance of procurement. This feedback should be both qualitative and quantitative. Qualitative – how they felt about the service they were given and how helpful people in logistics were. Quantitative – is objective and measurable. This can be achieved by setting and agreeing service standards with customers, for example the time it will take for a requisition to be processed. The customer can provide how well this was met. Information and data can be recorded and kept within logistics. The analysis of the information will provide feedback on performance. It is possible to measure performance in carrying out the logistics process particularly if there are standards set. 

For example:

• documents sent to accounts in time;
• goods delivered on the specified date or within the specified period of time;
• number of times a vendor has delivered the correct goods or how many times goods have been rejected; and
• number of requests rejected by procurement due to poor specifications.

In an emergency situation performance monitoring is a very important aspect and should be instantaneous with immediate remedial measures taken. The reporting back should be more structured and targeted to get immediate attention and action taken.

Some of the key indicators would be:

• on time delivery;
• delivery of exact specification requested;
• reliable transport services; and
• delivery of exact quantities requested.

Key Performance Indicators  management tools

Key Performance Indicators (KPIs) can be defined as specific metrics used to monitor performance on an on going basis. KPIs can only be useful if the metrics selected are targeted to achieving the organisations logistics objectives. Some examples of KPIs are:

• percentage of Items returned/rejected;
• total dollar value of damaged/lost goods;
• percentage of on-time deliveries;
• inventory levels vs. forecasted need; and
• field distribution performance.