Project Estimation

When to do the Project Estimation?

·         At the start of the project

·         At every project milestone

·         When requirements change

·         When there is a scope creep

·         If and when there are any changes in the team (If a team member leaves the organization / if a team member has to take unexpected leave, etc.)

·         When you notice that any of the assumptions you made are not holding good

Assumptions

You need to jot down all the assumptions that you are making while doing the estimation. This is because if any of the assumptions topple, your estimates also go haywire.

Basis for Estimation

·         Past Data/Past Experience

·         Available Documents/Knowledge

·         Assumptions

·         Identified Risks

Estimation Methods

There are several estimation methods in practice. You can choose the one that suits your project. Following table gives you an idea on how to choose an estimation method:

S. No.	Project Context	Estimation Method
1	When there is limited information about the current project. When estimates are used in deciding if an upcoming project is profitable to the organization.	Analogy
2	When clear requirement specifications are available with regard to the functionality of the software to be developed.	Function Points (FP)
3	When there are tasks that are critical in the project. If there is a delay in these tasks, the project gets delayed. Project is large and non-repetitive, such as an R&D project.	PERT
4	When the project is small.	Three Point Estimation
5	When the requirements are in Use Cases form.	Use Case Points
6	When the requirements in User Stories form, as is the case in agile projects, mostly Scrum.	Planning Poker
7	When the project is to be decomposed into small sized deliverables	Work Breakdown Structure (WBS)
8	When there is a panel of experts to do the estimation	Wideband Delphi

Next, let us look at each of these Estimation methods.

Analogy

Project Manager and Team need to collaborate in arriving at the estimates by Analogy. If there are past projects similar to the current project, the historical data is used to arrive at the estimates. Otherwise, from the historical data of the projects, data related to the similar modules and similar activities is collated and the estimates are drawn from them.

This method mostly relies on the past data. If there is reliable past data, the method is found to be accurate up to 60%.

Function Points

Function Points is a standard widely accepted estimation method for software sizing, though the method needs expertize in arriving at the required parameters for the computation.

International Function Point Users Group (IFPUG) defines the standard set of rules, processes and guidelines for Function Points (FP) Counting and publishes them in Counting Practices Manual (CPM). One needs to abide by CPM if Function Points (FP) is chosen as the estimation method.

Internal Logical File (ILF) is a user identifiable group of logically related data or control information is stored in a file within the application boundary. External Interface File (EIF) is a user identifiable group of logically related data or control information that is used by the application for reference purposes only.  The data resides entirely outside the application boundary and is maintained in an ILF by another Application.

External Input (EI) is how the application gets information from outside the boundary to inside.  The data can come from a data input screen or another application. The data can be either control information or business information. External Output (EO) is how data comes out of the application in the form of a report and/or an output file sent to other applications. Additionally, an EO may update an ILF.  External Inquiry (EQ) is for data retrieval.

Record Element Type (RET) is the largest user identifiable sub group of elements within an ILF or an EIF.  Data Element Types (DETs) are the different elements within each RET that are unique and user identifiable.

File Type Referenced (FTR) is the largest user identifiable subgroup within the EI, EO, or EQ that is referenced to. A Data Element Type (DET) is the user identifiable unique data subgroup within an FTR.

Use the counting rules for counting FTRs and DETs in ILFs and EIFs. (Refer to the IFPUG CPM). Determine the functional complexity (L=Low; A=Average; H=High) for each ILF and EIF from the counts of corresponding DETs and RETs, using the ILF/EIF complexity matrix:

RETS	Data Element Types (DETs)
	1-19	20-50	>50
1	L	L	A
2 to 5	L	A	H
>5	A	H	H

Obtain the FP Counts of each ILF and EIF from their functional complexities.

Functional Complexity	FP Count for ILF	FP Count for EIF
Low	7	5
Average	10	7
High	15	10

Similarly, use the counting rules for counting FTRs and DETs in EI, EO and EQ. Determine the functional complexity (L=Low; A=Average; H=High) for each EI using the EI complexity matrix from the counts of corresponding FTRs and RETs. Determine the functional complexity (L=Low; A=Average; H=High) for each EO and EQ using the EO/EQ complexity matrix from the counts of corresponding FTRs and RETs.

EI Complexity Matrix:

FTRs	Data Element Types (DETs)
	1-4	5-15	>=16
0-1	L	L	A
2	L	A	H
>=3	A	H	H

EO/EQ Complexity Matrix (EQ must have a minimum of 1 FTR):

FTRs	Data Element Types (DETs)
	1-4	5-15	>=16
0-1	L	L	A
2	L	A	H
>=3	A	H	H

Obtain the FP Counts of each EI, EO and EQ from their functional complexities.

Complexity	FP Count for EI / EQ	FP Count for EO
Low	3	4
Average	4	5
High	6	6

FP Count is obtained by summing up all the ILF, EIF, EI, EO and EQ counts.

Use Case Points

Counting Use Case Points is based on the Use Cases and Actors that are identified for the application to be developed. This estimation method also results in the software size.

To arrive at the Use Case Points of an application, perform the following steps:

** Find the number of transactions in each Use Case. If user goal levels are used to write the Use Cases, a transaction is equivalent to a step in the Use Case. So, you can find the number of transactions by counting the steps in the Use Case.

** Determine the complexity of each Use Case based on its number of transactions.

** Assign Use Case Weight for each Use Case based on its complexity.

Use Case Complexity	Number of Transactions	Use Case Weight
Simple	≤ 3	5
Average	4 to 7	10
Complex	> 7	15

** Sum up the Use Case Weights of all the Use Cases to obtain the Unadjusted Use Case Weight (UUCW).

** Similarly, determine the complexity of each Actor and the corresponding Actor weight.

Actor Complexity	Example	Actor Weight
Simple	A System with defined API	1
Average	A System interacting through a Protocol	2
Complex	A User interacting through GUI	3

** Sum up the Actor Weights of all the Actors to obtain the Unadjusted Actor Weight (UAW).

** Sum of Unadjusted Use Case Weight (UUCW) and Unadjusted Actor Weight (UAW) gives Unadjusted Use Case Points (UUCP).

** Adjust the Unadjusted Use Case Points (UUCP) for Technical Complexity and Environmental Complexity to obtain Use Case Points (UCP).

We will discuss the other Estimation methods in the upcoming blogs.