Need your advice on Project Estimation

[Vijay Jayabalan]

Hi all,

 

Background: We have been using LabVIEW for test automation for over a decade and we are a team of six people. There are two Certified LabVIEW Architects and three Certified LabVIEW Developers and a Certified Associate Developer. We have been using customized waterfall model for the project execution. Most of the time, individuals handle projects independently. Sometimes, we do have projects which demand few individuals working together to achieve the project goals/objectives.

 

Challenge/Issue: One of the key challenges we have at the moment is project size estimation. We do not have any standard method for project estimation and the estimation number goes purely on personal skill set and experience. Different people comes up with different estimation number (in mandays) for the same requirement. This technique does not work well always and fails many times.

 

Many times we found there is a huge difference between the initial estimate and actual time consumed.

 

1. Is there a standard estimation technique which best suits for LabVIEW based projects?

 

2. How do we factor technical project risks associated with the project in estimation? At present we simply add huge buffer for unknowns based on past relevant experience.

 

3. How to factor the level of expertise of the individual in project estimation? In general, project is estimated by an experienced individual and executed by a less experienced person.

 

Any comments suggestions are most welcome.

 

Highly appreciate your efforts.

 

Thank you.

[ShaunR]

This is a real issue with linear life cycles and whilst it can't be eliminated, it can be mitigated by not using them at all

 

The short answer is use an iterative/cyclic life cycle (I'm deliberately avoiding the use of the Agile word). Iterative cycles enable staged payments  since you have customer identifiable, feature milestones and it reduces your risk exposure to specification drift . There are also no surprises for the customer. The customer sees progress easily and, unlike linear cycles, timescales and billing can be adjusted during development.("sure we can add that feature-it'll cost this much and push delivery out by x weeks")

 

1. No. LabVIEW projects are no different to other software projects.
2. Short iterative cycles. Operate what I call the Bunnyman principle (ECCO). Early involvement, Constant Communication and Often (with the customer).
3. You factor it in by specification. If you have bums on seats programmers who'd rather be doing Python, then you will need to specify every VI, its behaviour, and its inputs and outputs(detailed design specs). If you have some neck-beard programmers, then you can create a systems design document and they can create the detailed design for you (that's what CLAs do in the exam).

Where many companies struggle is they don't have a dedicated, customer facing, project manager or systems engineer and rely on one of the programmers who are then also factored into the software development. It's a double spend since that person will be so busy making sure the wheels are oiled - site visits, meetings, purchasing, answering questions, hammering out specs, handling subcontractors - they won't be doing any programming. I would suggest that you promote one of your CLAs to Chief Systems Engineer and let him only do that for all the projects.

[Vijay Jayabalan]

This is a real issue with linear life cycles and whilst it can't be eliminated, it can be mitigated by not using them at all

 

The short answer is use an iterative/cyclic life cycle (I'm deliberately avoiding the use of the Agile word). Iterative cycles enable staged payments  since you have customer identifiable, feature milestones and it reduces your risk exposure to specification drift . There are also no surprises for the customer. The customer sees progress easily and, unlike linear cycles, timescales and billing can be adjusted during development.("sure we can add that feature-it'll cost this much and push delivery out by x weeks")

 

1. No. LabVIEW projects are no different to other software projects.
2. Short iterative cycles. Operate what I call the Bunnyman principle (ECCO). Early involvement, Constant Communication and Often (with the customer).
3. You factor it in by specification. If you have bums on seats programmers who'd rather be doing Python, then you will need to specify every VI, its behaviour, and its inputs and outputs(detailed design specs). If you have some neck-beard programmers, then you can create a systems design document and they can create the detailed design for you (that's what CLAs do in the exam).

Where many companies struggle is they don't have a dedicated, customer facing, project manager or systems engineer and rely on one of the programmers who are then also factored into the software development. It's a double spend since that person will be so busy making sure the wheels are oiled - site visits, meetings, purchasing, answering questions, hammering out specs, handling subcontractors - they won't be doing any programming. I would suggest that you promote one of your CLAs to Chief Systems Engineer and let him only do that for all the projects.

 

Hi ShaunR,

 

 

Thanks for your insight and comments.

 

I agree with you from the perspective view of the risk mitigation, we will give it a try in one of our future project.

 

Let me again come back to my initial question, How do we estimate a project size? we still need to estimate the size of a "project" or "features to be implemented in a next iteration" independent of the execution process.

 

I have read about Size Based Metrics, Effort-Based Estimations like Weighted Average, Planning Poker and Wideband Delphi methods....

 

Does any one able to apply any one of the above successfully in their projects? and how? or is there any custom approach

 

 

Thanks,

Vijay.

[ShaunR]

The project size is determined from the requirements. The risk assessment defines the variance due to mitigation (replaces your arbitrary fudge factor) and the effort required is derived from the tasks identified to achieve the requirements. This is all straight forward and exist in all formal methods but usually not the cause of over budget or project failure The biggest problem is generally not identifying all the tasks that are outside the purview of the person quoting. Software engineers know little about how to build machine frames from aluminum, for example and may under estimate hardware resource requirements or assume instruments are available instantly when required..

 

Breaking down the requirements into the effort required is time consuming. This is a problem since at quotation you do not have a budget, you only know the starting point for features and are not guaranteed an order. However. you can mitigate by operating a two step quoting process (lets not get into the project flow at this point) which enables a first guess (known as a budgetary quotation) which cannot be ordered against but aims to be within 5-10% of the final quotation assuming things don't change. This enables a quick response with small outlay of time and energy to ascertain the probability of an order. It also allows the customer to waive a figure in front of their colleagues and peers and does not commit you to delivery. If they are serious, then they can apply for a full quotation and you can commit resources to a full breakdown or decline to quote.

 

For small teams/businesses. It is a great advantage if you can split out the development from the requirements discovery especially if the customer doesn't have a detailed specification. This is a big bugbear in non corporate environments which tend to have minimal or undocumented, requirements definitions with vague references to other projects or driven by a guru that has "some thoughts". These customers need to be hand-held through the requirements discovery and sign off on a detailed requirements spec that you will formulate to their satisfaction. 90% of the time this is not factored in on Waterfall Projects since it falls between the hand-off from sales to engineering although it has to be achieved before any code is written but they already have a price so you are already at risk . If you are on good terms with the customer, then you can usually get a payment up front for the "Feasibility" phase which you can iron out the exact requirements over an agreed  period and iteratively define the requirements to their satisfaction with no expectation of delivery. This gives you your first flag in the ground to start development and you should have detailed requirements and implementation documents for the engineers.

Edited April 2, 2015 by ShaunR

[Jordan Kuehn]

This seems like an appropriate topic for a VI Shots episode.