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.

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.

Count me as well...