What metrics to use and how to make calculations if writing specification for a new programming project is worth doing it and spending time (and money)?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
What metrics to use and how to make calculations if writing specification for a new programming project is worth doing it and spending time (and money)?
I think you’ll find yourself backed into an uncomfortable corner if you try to use any metric to definitively predict or control the outcome of your project. Ultimately, your project sponsor/owner will ask the questions ‘how long/how much’ ? The best you can do is a forecast that is based on your current knowledge of the project at this point in time – and this just comes from experience and literally guess-timating.
And here’s the catch: Your estimates will likely be off by several orders of magnitude. They only become more accurate as your team understands the problem domain and they estimate no more than 2-4 weeks ahead, max. Barry Boehm (and Steve McConnell) illustrated this effect with the ‘cone of uncertainty’ principle:
The further you are from implementation of a system or feature (left side), the greater the innacuracy of your estimates (-0.25x – 4x). As you get closer, and understand the problem domain more, estimates begin to take on greater accuracy (0.8x – 1.0x). This is why, in software projects where there is a lot of ‘noise’, or ‘complexity’ (ie. almost every project) we want to leave concrete estimation until the last responsible moment – no more than 2-4 weeks out.
You can also expect one thing with absolute certainty: The specifications WILL change over time. How you plan to adapt and manage that change will measure your success.
So, the best judgement that can be made to scope your work would be to assemble the team who will work on the project and the ‘customer’ to collaboratively work out the big brush strokes – the major features of the project. Write these as user stories that the team estimates using relative weight points (see Mike Cohn’s book on Agile Estimating and Planning) and devise a release plan that will give the customer a ‘draft’ forecast on what to expect – they can then decide if the investment will generate the return they are looking for.
Of course, I’m assuming that you’ll be releasing early/often so that your customer is always in possession of some functional increment of the final product – vital for their continued valuation of the project.