How can I calculate duration and price for the development of SW product?

Question

How can I calculate the duration and price for the development of the C# software? Does exist any pattern or tools for that? I think the duration of the project can be about the 6 months, for one developer (from my previous experiences).

Answer 1

Scheduling software development is somewhat of an art.

Why?

Because you're scheduling the unknown. If something identical was already coded then why are you redoing it? If something is slightly different, then there's no way to know how long it will take.

Besides, developing SW is more more than simply coding in C# (in your case). As I wrote on my blog here, the list of non-coding includes things like design, integration, testing, debugging and of course rewriting as the requirements change.

However, experience helps you make a good guestimate.

How to get a good guestimate:

• Define in detail what the end product will look like
• Define the components. E.g.: Front-end, graphics, database. etc.
• Figure out how many people you will need. (Does your front-end programmer do databases? Do they do graphics? Do you need a graphic artist? Will you need Dev Ops to set up servers?
• Talk to each of the people involved and get their estimates
• Add in time for meetings, integration, testing, vacations, sick leave
• Discover the team's availability; many programmers have to do maintenance work on previous projects and can't give you 100% of their time.
• Add 10% buffer

Now you can use a scheduling tool like MSProject, or a spreadsheet like Excel or pen & paper & calculator to figure out how long it will take, how many people you want/need and what it will cost.

Voila!

Answer 2

and welcome to the community!

I can tell you two or three pieces of advice from my own experience:

1. Involve in the estimation things that are time consuming and indirect part of the project: Meetings, planned unavailablity of the employees, quality feedback loops, potential integrations with products that are outside of your scope of action, etc.
2. Don't rely in your own estimates: The fact that you could do it in a certain amount of time, it's considering a lot of knowledge you have and possibly the person taking this will not. Estimates might change as you add more knowledge.
3. Aim for precision, not accuracy (And this goes for big and small projects): When we ask professionals an estimate we're looking to reduce to the feasible range dates. Narrowing it as much as possible. But what we often tend to forget is that it still is a range. We need not to get accurate estimates, if those have a high probability to be wrong. If you are looking to how much would it cost, it's likely that you are because you are defining if it's doable with a certain budget or not. And you don't need an accurate number but a range, ask the professionals for one on each feature.

Example:

• XS USD 10k to 25k
• S USD 25k to 50k
• M USD 50k to 125k
• L USD 125k to 350k
• XL < USD 350k

This should be easier to define than an exact number. (Prices here are just for the sake of explaining, feel free to fit this within the price bands you consider more aligned to your team structure).

You can then dive into those functionalities whose range is not acceptable due to either range or size, to see what would be needed to shorter or narrowed down.

Here I share you some additional info in my blog on Estimations, Agile Planning, and Agile Cost Accounting, part of which is what I learned by experience and by great minds like Kenneth Rubin.