Project Estimation Methods – WBS, 3-Point Estimation and PERT

Work Breakdown Structure (WBS) is used in three types of Estimation:

1.   Estimation using Work Breakdown Structure

2.   Three Point Estimation

3.   PERT

The Project Management Body of Knowledge (PMBOK) defines the Work Breakdown Structure as a "deliverable oriented Hierarchical Decomposition of the Work to be executed by the Project Team." WBS is usually derived with the participation of the entire team and is based on the team’s collective experience.

WBS can be used to arrive at the effort estimates for the project. WBS is also used in the estimation methods – Three Point Estimation and PERT. I have seen that some confusion exists regarding Three Point Estimation and PERT and they are used interchangeably. However, the two techniques are different.

Estimation using Work Breakdown Structure (WBS)

In this estimation method, the system is broken based on the activities in the system. The activities are further broken into tasks. Based on the tasks, effort and schedule are estimated.

Normally, Wideband Delphi method is used for arriving at the effort estimate of the tasks. One can use Three Point Estimation method also for the effort estimate.

Three Point Estimation and PERT

Three Point Estimation and PERT are based on three values for each task –

1.     a most optimistic estimate (O)
2.    a most likely estimate (M)
3.    a pessimistic estimate (Least likely estimate (L))

Three Point Estimation

Three Point Estimate (E) is based on the Simple Average and follows Triangular Distribution.

E = (O+M+L)/3

As you are aware, in a Triangular Distribution,

Mean = (O+M+L)/3

Three Point Estimation is typically used for small repetitive projects.

PERT (Project Evaluation and Review Technique)

In this method, the most-likely estimate (M) is weighted 4 times more than the other two estimates (optimistic (O) and pessimistic (L)). Thus, PERT Estimate (E) is a weighted average and follows Beta Distribution.

E = (O+4*M+L)/6

PERT is commonly used along with CPM (Critical Path Method). CPM highlights the tasks that are critical to the project. If there is a delay in these tasks, the project gets delayed.

PERT is classically used for large non-repetitive projects, usually R&D projects.

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.

Project Planning - Part 2

Friends, let’s focus on project planning activities. Keeping the project methodology aside, let us look at the core minimum things that are to be put in place before the project starts.

The first thing is estimates – effort, schedule and cost. Even if the estimation was done before it got handed over to you, it would be a wise decision to estimate again with the clarity on your current situation. The estimates should be based on the project objectives that are set. The effort estimate has to realize the available resources. The schedule and timelines for deliverables have to have a consensus from the team to avoid unforeseen delays. This might require negotiations – either with your marketing personnel or with the customer directly as the case may be. In case of disparities, the best approach is to have a compromise on the functionality – get into consensus with the core features that need to be delivered first and prioritizing the rest.

There are several estimation methods in use, and you can choose the one that best suits your project. We will discuss the estimation methods in a future blog.

Once you have the approved estimates at hand, your job is half done. The next important activity is assigning the tasks to the team members. It is a bit of an art – you need to get to know which team member can give the most to a particular activity. This helps you to maintain the team momentum.

At this juncture, you need to plan how the team members collaborate, communicate and contribute to the progress of the project. These can encompass informal meetings to formal project review meetings.

Identify a team member who has good hands-on experience on the configuration management tool such as Microsoft VSS, SVN, etc. that you choose to use (or your customer preference). Along with the identified team member, come up with that part of the plan to handle configuration management in the project. We will discuss configuration management in a future blog.

Obtain the risks identified by the customer facing personnel, add the risks that you have identified, have a meeting with the team to discuss on the risks that are identified and how you are planning to manage those risks. This is very crucial to the project as the team members are the ones who get to know the symptoms of any risk before it actually surfaces. Keep this as an agenda item in all your team meetings. We will discuss risk management in a future blog.

Planning and establishing the communication channels among all the people who are involved with the project is another significant step. This includes technical discussions, status reports, customer status calls, and reviews with the top management and so on.

The frequency and duration of these activities might differ from project to project and from one methodology to another. But, either explicitly or implicitly, these need to be taken care of.

Friends, you might have seen my earlier post on Project Planning.

I would like to share with you the significant topics of interest that would benefit the Project Management Communities. The topics range from traditional project management to the most recent agile project management. And of course, the trade-offs between the two. 

Look forward for the posts on various project management activities and discussions on how they fit into different project management environments.

Feedback and queries are welcome.

Project Planning - Part 1

As you all are aware, project planning is the heart of any activity. You know that you have to plan if you want to throw a party, if you want to go on a vacation, if you want to admit your child in a school, so on. You need to plan at the right time, revisit the plan when necessary and should be ready to accommodate any changes that creep up, without losing your goals.

So is the case of Project Planning. When you are asked to manage a project, the first thing that you would do is to plan the project that includes the requirements, timeline and budget. You will be mostly given the requirements and sometimes the timeline also as the input to your planning.

In the software development projects, this is tricky. As you are aware, the initial requirements may get changed during the course of the project. You may suddenly realize that the requirements that your team has completed development are obsolete now. You may also get new requirements at any point of time, which requires your team to redo certain activities such as design. All this amounts to schedule slippages and / or budget overrun.

There comes the need of having a holistic approach for project management including project planning. Points to remember and remind yourself from time to time are:

1. Project Planning is just not arriving at the deliverables based on       requirements, estimate the effort and come up with the schedule

2.  Yes, these are the activities that are part of project planning, but your job does not end with it

3. You need to concentrate on the following throughout the duration of the project –

   * Arrive at the initial project plan within a week of the inception of the project. 

  * Get it reviewed by the stakeholders. (You need to know who all the stakeholders for the given project are)

    * This is the right time to sort out any discrepancies that surface with the stakeholders

    * Share the plan with the team. Better make it available online with read access to everyone involved in the project

    * If the team has feedback on the plan, be open to receive it. After all, they are the executors of the plan. Discuss it out with the team if there are any project constraints

   * Focus on team collaboration. Have the schedule updated by the team. Discuss with the team on their progress periodically and also on need basis

   * Be a mediator among the cross-functional groups and also with the customer

   * Have intermediate working deliverables to get ratified by the customer, whether the customer asks for them or not

   * This makes a working product ready at any point of time and facilitates handling changed and / or new requirements

   * You be aware of the new trends in the technology and / or domain so that you can take the lead in discussing the possible changes in the upcoming product to suit the current time. Include the relevant stakeholders including customer in such discussions. Forget not mailing the meeting minutes to everyone involved with the project. This way you can avoid surprises from others that may topple you plan.

   * Last, but not the least, work towards team cohesion. You can choose the option right for you and your team – ranging among the team building activities

We have not discussed the core project planning activities yet. The above activities are required irrespective of the project management methodology you have chosen. You need to blend them with the core activities to achieve the results not losing focus on the objectives.