Leaderboard

Hi Francois, Yes it did fix it! (I'm using 2014 right now, but still 2011 in general) I had to restart VPIM to get rid of the conflict icon though. But now everything looks good! Thanks

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.