Estimating Projects Time & Cost

What is estimating?

Estimating is the process of forecasting, predicting or approximating the cost and time of completing project deliverables. It is the task and responsibility of balancing the expectations of stakeholders and the need for control while the project is implemented. 

There are two types of estimates:

1. Top-down (macro) estimates: analogy, group consensus, or mathematical relationships.
2. Bottom-up (micro) estimates: estimates of elements of the work breakdown structure.

Accurate estimates:

How project managers ensure that estimates are accurate:

Below are a number of points for boosting and achieving the accuracy of estimates:

• Use several people who are familiar and experienced with the tasks to make the estimate e.g. goal is to launch new colour laser printer - depts such as production, design and marketing should estimate.
• Create and use planning documents e.g. specifications and project plans.
• Perform a detailed task analysis of the work to be performed and ensure to treat each task as independent i.e. don’t aggregate.
• Use more than one method to arrive at an estimate and look for a midpoint among all of them.
• Base estimates on normal conditions, efficient methods, and a normal level of resources.
• Use consistent time units in estimating task times by maintain an ongoing “actual hours” database of the recorded time spent one each aspect of the project. This data can then be used to help estimate future projects and to identify the historically accurate buffer time needed to realistically perform the work.
• Use a “complexity factor” as a multiplier to determine whether a pending project is more or less complex than a previous one.
• Identify a set of limitations, constraints and assumptions to accompany your calculations, which would bound the conditions under which your estimates would be meaningful.
• Don’t make allowances for contingencies.
• Add risk assessment to help avoid surprises to stakeholders.

Conditions for preferring Top-Down or Bottom-Up estimates are illustrated in the figure below.

Bad estimates:

How bad estimates can lead to good projects failing:

• False analogies - When project estimates are developed using methods such as expert judgement, one rarely knows what is relevant and what isn’t. 
• False precision - Project estimates are often quoted as single numbers rather than ranges and these estimates are incorrect because they ignore the fact that uncertain quantities should be quantified by a range of numbers.
• Estimation by decree - The people actually performing the work are excluded from the estimating process.
• Subjectivity - Estimates are based on insufficient information or analysis and are “justified” based on gut-feel and other subjective notions.
• Coordination neglect - Projects consist of complex tasks that need to be coordinated and integrated carefully. Unfortunately, the time and effort needed for coordination and integration is often underestimated or even completely overlooked.
• Estimates are cut in order to secure a contract or to make a project more attractive.
• Estimates are provided without a corresponding statement of scope.
• The assumptions used for estimating are never documented, discussed or validated.

Work Breakdown Structure (WBS)

What is a WBS?

A WBS defines the objectives of a project at all levels of detail (hierarchical) and is essentially a map of the project i.e. visual representation of all parts. It can only be formed once the scope and deliverables have been identified.

How is a WBS constructed?

The WBS begins with the project as the final deliverable. The higher elements are used to identify deliverables at different phases in the project and to develop status reports during the execution stage of the project life cycle. Major project work deliverables are identified first; then the subdeliverables necessary to accomplish the larger deliverables are defined. The process is repeated until the subdeliverable detail is small enough to be manageable (top management deals primarily with major deliverables while first-line supervisors deal with smaller subdeliverables and work packages). This subdeliverable is further divided into work packages which is the lowest level of a WBS. Work packages are basic units used for planning, scheduling, and controlling the project (Figure 1). Since the lowest subdeliverable usually includes several work packages, the work packages are grouped by type of work e.g. hardware, programming, testing. 

Why is a WBS constructed?

• Helps to assure project managers that all work elements are identified therefore they can be easily monitored & tracked
• Determines a project timeline and develops a schedule
• Assigns responsibilities and clarifies roles
• Integrates the project with the current organisation - offers an ongoing view for management and team members into how the entire project is progressing
• Establishes a basis for control - accurate estimation of effort, duration, resources and cost
• Offers an ongoing view for management and team members into how the entire project is progressing
• Minimizes the chance of adding something outside the scope of work or forgetting a critical deliverable
• Helps make planning consistent and provides for effective project execution

How can it be used to identify risks?

• WBS helps controls scope creep and prevents work from slipping through cracks. Unnecessary work or anything not seen in the WBS can be eliminated thus it helps the team to focus on the project scope only.
• WBS enables project managers distribute the project budget into defined packages linked to the tasks and check to make sure that the task costs in total don't exceed the total project cost
• WBS ensures no overlap and no gaps in responsibility or resources

Figure 1

WBS example - Structure for building a house (w= work)

Project Definition Phase

The Project definition phase provides groundwork for project planning. The key activities and outputs from this phase are described below, as well as, the risks that this activity minimises. 

Defining a project consists of a number of key steps: 

                                                                               

Step 1:  The project scope is a definition of the end result or mission of the project i.e. a product or service for the client/customer - in specific, tangible, and measurable terms. For example, as a result of extensive market research a computer software company decides to develop a program that automatically translates verbal sentences in English to Indian. A project scopes primary purpose is to define the deliverables for the end user and to focus project plans. Many projects suffer from scope creep, which is the tendency for the project scope to expand over time and in most cases means added costs and possible project delays. By carefully writing the scope statement, scope creep can be reduced.

Step 2: Quality and the ultimate success of a project are defined as meeting and/or exceeding the expectations of the customer and/or upper management in terms of cost, time and performance of the project. It is interesting to note that the interrelationship among these criteria varies.  For example, sometimes it is necessary to compromise the performance and scope of the project to get the project done quickly or less expensively. A project priority matrix is used to identify which criterion is constrained, which should be enhanced and which can be accepted. This is essential when managing trade-offs among the triple constraints and is useful for approaching a problem that must be solved.

Step 3: Once the scope and deliverables have been identified, the work of the project can be subdivided into smaller manageable work elements for the team. The outcome of this hierarchical process is called the work breakdown structure (WBS). The visual representation defines all the elements of the project and establishes their relationships to the project end items. The WBS can be used to define communication channels in many parts of 
the project. The structure shows the work and organizational units responsible and suggests where written communication should be directed. This means that problems can be quickly addressed and coordinated because the structure integrates work and responsibility. This diagram illustrates the major groupings commonly used in the field to develop a hierarchical WBS.

Step 4: The WBS is used to link the organizational units responsible for performing the work. In practice, the outcome of this process is the organization breakdown structure (OBS). The OBS depicts how the firm has organized to discharge work responsibility. The purposes of the OBS are to provide a framework to summarize organization unit work performance, identify organization units responsible for work packages and tie the organizational unit to cost control accounts.

Step 5: Gaining the maximum usefulness of a breakdown structure depends on a coding system. The codes are used to define levels and elements in the WBS, organization elements, work packages, and budget/cost information. The codes allow reports to be consolidated at any level in the structure. The most commonly used scheme in practice is numeric indention. In practice most organizations are creative in combining letters and numbers to minimize the length of WBS codes.

“We can control only what we have planned”

Gartner Survey Shows Why Projects Fail - Lars Mieritz

In the 2012 article, “Gartner Survey Shows Why Projects Fail” Analyst, Lars Mieritz, classified IT projects by size and revealed the reasons behind project failures.

The three classifications:

1.    Small

2.    Medium

3.    Large

The six causes behind IT application project failure:

1.    Functionality issues

2.    Substantially late

3.    Quality issues

4.    High cost variance

5.    Cancelled after launch

6.    Rejected or not implemented for other reasons

Small:

A small project was defined as one with a budget of less than $350,000. These sized projects are easier to maintain, oversee and execute. In order to achieve a lower failure rate, it is essential that projects remain small and do not exceed 6 months in duration. A fascinating pattern emerged when comparing the most recent survey results with previous data gathered. It indicated that small IT projects encounter a one-third lower failure rate than large projects- there was a 20% failure rate observed for small IT projects. (Figure 1) It is interesting that “poor quality” was ranked 3^rd highest as the reason for small IT project failure with 17% of respondents, whereas it was the 2^nd lowest in medium (12%) and large (11%) IT projects. (Figure 2)

Medium:

A medium project was defined as one with a budget of $350,000 to $1 million. Runaway budget costs are behind one-quarter of project failures for projects with budgets greater than $350,000. There was a 25% failure rate noted for medium sized IT projects which was slightly lower but similar to the failure rate of large IT projects which stands at 28%. (Figure 1) In both cases, nearly one-third higher than the failure rate observed for small IT projects. “Functionality issues” and “high cost variance” were both positioned in the top 3 causes for project failure in medium and large sized IT projects. (Figure 2)

Large:

A large project was defined as one with a budget that exceeded $1 million. The failure rate of large IT projects with budgets exceeding $1 million was found to be almost 50% higher than for projects with budgets below $350,000. It is intriguing that as the projects became greater in size, the failure rate increased accordingly. (Figure 1) Across all project sizes, it was evident that “substantially late” was the main reason for project failures, which is not a surprise considering the ongoing nature of projects. (Figure 2)

FIGURE 1

FIGURE 2