Estimation Importance In Project Management Information Technology Essay
Objective of the report: The objective of this report is to investigate the use of “Estimation” of project parameters like project cost and time, in Project Management. The report starts with the definition of the estimation and its use for a successful project management. A brief description of project estimation process is explained in the report, along with the basic classification of the types of estimates that can be performed for a successful project management. The issues involved in estimating the project parameters in real-time are investigated in a detailed manner. Then critical evaluation of various estimation methods is performed. A complete analysis of the methods evaluated in the report is performed. Finally, the report is concluded with the suggestions on selecting a particular Project Estimation process for a successful Project Management.
Importance of Estimation in project management:
The four major parameters that control the software projects are time, requirements, resources (people, infrastructure/materials and money), and risks. This is one of the reasons why making good estimates of these variables like time and resources required for a project is very critical. But if the estimation is lower than the project needs it will affect the progress of the project due to the lack of enough time, money, infrastructure/materials, or people. At the same time even if the estimation is over estimated then the company will have to face losses due to the extra expenses or even if the project is sanctioned other projects don’t go on since there is less to go around.
For any successful project management, estimation is a vital part of project methodology. Estimation has numerous applications like justification of project which has to be applied in the initial stages of the project where in we need to anticipate the benefits which is compared with the costs incurred as well as to decipher comparisons and conclusions that has to be made with technical and functional teams involved in the project. The other additional applications of the estimation are to implement the disciplines required, to protect the resources required to deliver the project successfully, to ensure the support impact of the project is fully understood, to inform and improve the software development process. This document describes the techniques used to produce reliable estimates for the work required to complete projects and tasks.
Estimation process:
Definition: Project estimation is a process of forecasting or approximating the project parameters like cost, time, effort etc., for a successful completion of the project deliverables.
Overview of the Estimation Process:
The first point to be remembered about estimation is that it does not finish until the completion of project and is a process of a slow and gradual refinement. For many software projects a project manager can assist the team to create successful estimates by using sound techniques and understanding about what makes estimate more accurate. The team chosen to produce an estimate are typically drawn from IS, customers and/or service partners who have relevant experience of similar previous projects or tasks in the business area.
When we want to start a project we need to know basic parameters required in advance like how long it will take, how many people it will require, how much effort it will require. In such cases it is hard to estimate because in many cases projects overrun or project go over budget. Always a good estimation practices keep the project on track and even can earn some time for the tricky, interesting areas.
Our estimation process is based on three components:
Expert judgement, Consultation with qualified experts from within business and service partners. This is supplemented, where required, by expert input from software suppliers and consultants.
Experience, i.e. comparison of the proposed project or task with previously completed work.
Task Decomposition, i.e. decomposing the project into components, i.e. a Work Breakdown Structure, and estimating each component individually to produce an overall estimate. This will also reduce the chances of error occurrence.
When to estimate:
A rough estimate is needed at the initial stage of the project or probably even before the actual project starts. This is because, the final negotiations should be made with the customer, which needs the rough estimate of the cost, time and quality of the project.
Also, Estimation is a process of gradual refinement. It should be performed in parallel with the project development, in several phases. Each estimate will be refined to give a converged estimate towards the end of the project.
Estimation should be carried out until the completion of project deliverables.
There are basically two approaches for estimating project parameters. They are;
Top-down estimation approach
Bottom-up estimation approach
Top-down estimation approach:
Top-down estimation approach is usually used at the initial stages of the project. This estimation is usually carried out by the top managers who have little knowledge of the processes involved in the completion of the project. The input to this estimation is either information or the experience of the manager carrying out the estimation. These top-down estimation methods are often used to evaluate the project proposal. In most cases, the best results can be achieved in estimation only when one used both top-down and bottom-up estimation methods. However, it is practically not possible to carry out bottom-up methods until the Work Breakdown Structure (WBS) are clearly defined. In such cases, top-down estimates are used until the WBS becomes available.
There are many methods in top-down approach listed below:
Consensus methods: This estimation method uses experience of a group of people to estimate the project parameters. This method involves project meetings, a place where these people can discuss, argue and finally come to a conclusion from their best guess estimate. The Delphi method comes under this category.
Ratio methods: These estimation methods use ratios to estimate project times and costs. For example, in a construction work, the total cost of the project can be estimated by knowing the number of square feet. Likewise, a software project is estimated by its complexity and its features.
Approximation methods: This estimation method is very useful when the project to be estimated is closely related to any of the previous projects in terms of its features and costs. By using the historical data of the estimates, good estimates can be approximated with very little effort.
Function point methods: Many software projects are usually estimated using weighted macro variables called “function points”. Function points can be number of inputs, number of outputs, number of inquiries, number of data files, and number of interfaces. These function points are weighted again with a complexity level and summed up to get the total cost or duration estimates of the project.
Bottom-up estimation approach:
Top-down estimation approach can usually be put in practice once the project is defined or once there is some progress in the project. This means, this estimation is more into work package level, which are responsible for low-cost estimates and efficient methods. It is often recommended that this estimation is usually carried out by people most knowledgeable about the estimate needed. The cost, time, resource estimates from the work packages can be checked with the associated accounts to major deliverables. Also, these estimates in later stages can be consolidated into phased networks, resource schedules, and budgets that used for control. Additionally, customer will get an opportunity to compare the low-cost, efficient method with any imposed restrictions, using bottom-up approach.
There are many methods in top-down approach listed below:
Template methods: If the project to be estimated is similar to any of the past projects, then estimates of the past projects can be used as starting point estimates for the new project. This is similar to approximation estimation in top-down approach.
Parametric procedures: These parametric procedures are same like ratio methods in top-down approach. However, here the parametric procedures are applied on specific tasks.
Detailed estimates for WBS work packages: This is usually most reliable method of all estimation methods. The reason for this is that here the estimates are performed by people responsible for the work packages in Work Breakdown Structure. These people have prior knowledge or experience upon the tasks they perform specified in WBS, because of which the estimates are usually most reliable.
In addition to the top-down and bottom-up approaches, there is another kind of estimating which is a hybrid of the above two approaches. This is called as Phase Estimating. When there is unusual amount of uncertainty is surrounded by the project, people go for phase estimating. In this approach, two-estimate system is used over the life-cycle of the project. The whole project is initially divided into phases. Then a detailed estimate is developed for the immediate phase, and a macro-estimate is mode for the remaining phases of the project.
Difficulties in Estimation:
There are two major cases where Estimation problems almost always boil down to estimates that are either too high or too low.
Padded estimates, where the team members intentionally over estimates in order to give themselves extra time to work, are a chronic source of estimates that are too high.
Other case arises when senior managers give unrealistic deadlines that are a chronic source of estimates that are too low. Both the cases can lead to morale problems.
Estimation Tools:
Software tools are very important for estimation. Estimation tools are the software packages implemented using any of the estimation methods as its algorithm, to make project manager’s life easy. These estimation tools help from skipping important tasks in a method. These tools are useful to organise, update and store the results of the estimates. Also, Estimation Tools are useful to:
Estimate project size using Function Points or other metrics.
Derive effort and schedule from the project estimates using various algorithms and techniques.
Perform analysis with staffing, duration etc. and appreciate how realistic they are.
Produce and update results like Gantt charts and other tables easily.
Maintain and exploit a database of historic data.
Import data from other projects run in organisations with which you have no connection.
However, one should very carefully select the estimation tools for a particular project.
Principle: Required functional capabilities of estimation tools should match the needs and desired capabilities specific to the project.
In selecting an estimation tool, one should match the available tools with the overall requirements of the project. In general, estimation tools should:
Be very adaptive to any project’s development environment, so that one can customize the tool according to the project needs.
Be comparatively easy to understand, learn and use.
Be able to produce some early project estimates without waiting for the whole project to be completely defined & designed.
Be able to provide estimates for different phases and activities in the project, if it is classified so.
Understand and support wide range of languages and applications, as it is really important for a tool to provide estimates specific to the applications.
Be able to provide accurate schedule estimates, whose purpose is not only to predict task completion given task sequence and available resources, but also to establish starting and ending dates for the associated work packages and life-cycle phases.
Be able to provide maintenance estimates separately, which includes correcting errors, modifying the software to accommodate changes in requirements, and extending and enhancing software performance.
Critical evaluation of the estimation tools:
There are many tools in the market for project estimation. However, I am investigating a few and very efficient tools in the current market.
PROBE:
The name “PROBE” is derived from Proxy Based Estimating, introduced by Watts Humphrey (of the Software Engineering Institute at Carnegie Mellon University).
Principle: If a component being built is similar to one built previously, then the effort it takes would be about the same as it did in the past.
It mainly helps individual software engineers monitor, test, and improve their own work. Each component in the database is assigned a type (“calculation,” “data,” “logic,” etc.) and a size (from “very small” to “very large”). Also, a database is used to store history of size and effort details of these individual components. Later on, when a new project must be estimated, it is broken down into tasks that correspond to these types and sizes. A formula based on linear regression is used to calculate the estimate for each task.
Additional information on PROBE can be found in A Discipline for Software Engineering by Watts Humphrey (Addison Wesley, 1994).
COCOMO:
The COCOMO is the most used estimation tool in the market for cost and schedule estimating. The COCOMO is derived from Constructive Cost Model, developed by Barry Boehm in the early 1980s.
Principle: The model developed empirically by running a study of many software development projects and statistically analyzing their results. There by developing a database of the analysed details.
Boehm developed COCOMO empirically by running a study of 63 software development projects and statistically analyzing their results. COCOMO II was developed in the 1990s as an updated version for modern development life cycles, and it is based on a broader set of data. The COCOMO calculation incorporates 15 cost drivers, variables that must be provided as input for a model that is based on the results of those studied projects. These variables cover software, computer, personnel, and project attributes. The output of the model is a set of size and effort estimates that can be developed into a project schedule.
Additional information on COCOMO can be found in Software Cost Estimation with Cocomo II by Barry Boehm et al. (Prentice Hall PTR, 2000).
The Planning Game:
The Planning Game is the software project planning method from Extreme Programming (XP), a lightweight development methodology developed by Kent Beck in the 1990s at Chrysler. It is a method used to manage the negotiation between the engineering team (“Development”) and the stakeholders (“Business”). It gains some emotional distance from the planning process by treating it as a game, where the playing pieces are “user stories” written on index cards and the goal is to assign value to stories and put them into production over time.
Unlike PROBE, COCOMO and Delphi, the Planning Game does not require a documented description of the scope of the project to be estimated. Rather, it is a full planning process that combines estimation with identifying the scope of the project and the tasks required to complete the software. Like much of XP, the planning process is highly iterative. The scope is established by having Development and Business work together to interactively write the stories. Then, each story is given an estimate of 1, 2, or 3 weeks. Stories that are larger than that are split up into multiple iterations. Business is given an opportunity to steer the project between iterations. The estimates themselves are created by the programmers, based on the stories that are created. Finally, commitments are agreed upon. This is repeated until the next iteration of the project is planned.
Additional information on the Planning Game can be found in Extreme Programming Explained by Kent Beck (Addison Wesley, 2000).
Critical analysis:
In order to have the best estimates of a project, make some rough top-down estimates initially, develop the WBS, using which make bottom-up estimates, and develop schedules and estimates and finally, reconcile the differences between top-down and bottom-up approaches.
Also for ideal results, the project manager should allow some time to carry out top-down and bottom-up estimates, there by reliable estimates can be offered to the customer. This will in turn reduce the false expectations for stakeholders.
Phase estimation approach is much useful in the projects, whose final nature (shape, size, features) is highly uncertain.
COCOMO II can be used for the following major decision situations
Making investment or other financial decisions involving a software development effort
Setting project budgets and schedules as a basis for planning and control
Deciding on or negotiating tradeoffs among software cost, schedule, functionality, performance or quality factors
Making software cost and schedule risk management decisions
Deciding which parts of a software system to develop, reuse, lease, or purchase
Making legacy software inventory decisions: what parts to modify, phase out, outsource, etc
Setting mixed investment strategies to improve organization’s software capability, via reuse, tools, process maturity, outsourcing, etc
Deciding how to implement a process improvement strategy, such as that provided in the SEI CMM