How to calculate times for developing software?


We have been developing pieces of code for small projects and everything went good until we started with large projects, we noticed that our way of calculating the developing time is not working at all, so we would like to implement a new strategy based on your suggestions and comments.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

crystal (strive4peace) - Microsoft MVP, AccessRemote Training and ProgrammingCommented:
multiply the time you think it will take by 4

With the database applications I build, I always have trouble estimating, with any accuracy, how long a project will take until the structure is known ... and that is often about 30% of the time for work.  With a large project, phase it out and estimate it a phase at a time.  

I connect and team-develop with clients.   This is especially helpful when the project is being designed to get better business intelligence and my contact also sees the effort.    Once the data structure and relationships are known, estimating is done on small pieces at a time is they must have a fixed number.  By then, they have seen how I work and are often happy with an hourly rate.

what kind of software projects are being developed?
dimensionavAuthor Commented:
Maybe we should start from scratch and "rethink" a new way of estimate time, any suggestion about it will be helpful. Please think as If we were amateurs on this.
We are now in a project of an ERP based on cloud, the technology involved is PHP and PostgreSQL DB.
dimensionavAuthor Commented:
Crystal, I forgot to mention that I would like to know if the strategy could be the same for internal or externals (freelancers) employees.
Your Guide to Achieving IT Business Success

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

crystal (strive4peace) - Microsoft MVP, AccessRemote Training and ProgrammingCommented:
For database development, I have a guideline of how long things will take such as:

structure and relationships -- couple days to a week

meetings -- frequent.  my preference is to team-develop so we are always meeting ~

initial forms: a few days
initial report menu: 2-4 hours to a couple days
initial reports: 1-2 days
queries: build as needed

general estimates:
simple form with no subforms: 1-2 hours
mainform with subforms and popups: 1-2 days
simple report: 1- 4 hours
complex report: 0.5 – 2 days

break down the work as best you can.  Use estimates for small pieces and multiply them to scope out a project.   You should be able to use this approach for internal and external work.

Even the most simple reports and forms take time to find out about and plan.
In a new project (2-1/2 years times 4 software developers - i.e., 10 man-years), we first wrote a detailed set of sequence diagrams describing the events and flow of data. (That effort took about 3 months with four of us handling the different pieces of the system.) From those software requirements, we had to come up with an estimate to come up with a detailed design, code, and implementation (to unit testing - integration testing was another estimate).

With small projects, often we had an intuitive idea of what the software requirements are, and a reasonable guess as to the detailed design (which sometimes is skipped in very small projects), and the remaining efforts up to unit testing.

With a large project, having at least a strawman set of software requirements is necessary in order to break the large system into more manageable sub-systems and the interactions between these sub-systems. Then it is easier to better estimate each sub-system as well as estimating the effort to handle the interactions between the sub-systems. Naturally, the closer you go away from a strawman document to an ironman set of requirements, the more likely that the estimates will be better.

For database having about 200 tables, we estimated 4 hours per table design and 4 hours per table implementation (code and test). For sets of tables where we knew complicated relationships existed, we added additional hours to handle triggers and foreign key design, implementation, and test.

Likewise, we broke the middle tier (consisting of C-code, sockets, GUI, third party libraries) into 4 hour chunks . At the end, the director said that when he saw the bottom line, he immediately started looking at the details in order to chop out a large part of the estimate. But when he saw that the chunks were mostly in 4 hours units of effort, he said he had to go with our plan.

Our estimates were pretty accurate in that we comfortably met all the intermediate milestones.

Having measurable and demonstrations of intermediate milestones is very valuable in that it allows you to revisit your estimates and adjust based on each milestone met.
Dave BaldwinFixer of ProblemsCommented:
I like phoffric's methods.  Some notes though.  You can't (easily) estimate something that you have never done before, especially if you didn't keep track of your time for doing similar things.  

And many estimates fail to account for the perfectly ordinary details.  Because one of my customers told me Not to estimate, just give him a quote !!!!, I made up spreadsheet that listed all the things that I have to do on every project.  In addition, to the main project, there were about 40 'little' administrative details that take time that needed to be accounted for on even the smallest of projects.
crystal (strive4peace) - Microsoft MVP, AccessRemote Training and ProgrammingCommented:
Agree whole-heartedly that it is hard to estimate the efforts for a new project .  Everyone has different procedures so if you have already done something similar, there will still be many differences.
It's pretty difficult to estimate anything without knowing more specifics. The above experts have given some generic approaches, but in my experience, a good estimate needs several pieces of information:

1. You need to know the personalities of the people creating the business requirements. The "visionary" CEO-type person tends to have everything laid out in his/her head and simply needs help converting it into technical requirements. Creative types, on the other hand, tend to have broader ideas of what a project COULD be, but see the project as a porous type of blob that can be filled in with their ideas as it gets developed. You have to then decide IF and how you want to allow that to happen. The more ideas the person comes up with, the more rigorous you have to be about controlling that, because those ideas will impact your estimates in big ways.

While I don't recommend it, if you really need to allow a lot of change during the development, then you should almost certainly go with an Agile methodology and over-estimate your hours.

2. You need to know how many people can work concurrently on the project and whether or not one task will hold up another. Any good project management software will help you figure this out, but you need to have good communication with the people that will be doing the work. If you have a lot of distinct / specialized roles, then sometimes those people make bad assumptions about what the other people can do ("Sure, programmer X can develop the code for the login system before the DBA finishes the database...").

3. Once the business requirements are CLEARLY defined (with use cases), rank them in order of priority. The most critical requirements will need the most clarity upfront and they should be the requirements that experience almost no change from the beginning to the end. Think of the project as if you were building a house and imagine trying to put up walls while someone decided to change the entire foundation. It just doesn't work that way, and software development is no different - having critical, fixed areas will help everyone and everything.

4. Your project should begin with business requirements and proceed directly into technical requirements. The business requirements phase should be a minimal crowd of decision-makers, but EVERYONE should be there for the technical requirements phase. The last thing you want is a huge project delay because you assumed that your UI / graphic designer wasn't necessary for that meeting, and the resulting technical design leads into the most horrific user experience ever. EVERYONE should be talking in that meeting and contributing how long they think it will take for their various areas. Not only will it help you avoid unexpected delays later on in your estimates, but it will get people thinking AND get them more invested in the success of the project.

This is why the tech requirements phase will often take a pretty long time, but that's okay. You should come out with some pretty well-defined ideas of how it's all going to come together. As you get closer to the end of that meeting, the different roles should be writing down ON PAPER their high-level ideas of how it's all going to work. Don't just let them say, "Yeah, I know how I'm going to do it." I'm a programmer and I say that all the time and I'm almost always wrong, but I keep saying it. Every programmer seems to do it. Make them write out the details on paper. It'll also help when they need to collaborate later with other team members on a whiteboard.

5. You should know whether or not there are any pre-made components that you can buy to accelerate development. Yes, your programmer can write an accordion menu from scratch, but it'll take them an hour to get the working prototype and 5 hours to work out all the bugs. Let's say they are costing you $100 / hour. That's $600 that you could otherwise spend on a commercial, mostly-if-not-completely bug-free product that will likely also have more features and even come with more components (and maybe even $300 instead of $600). It might even cover scenarios that you didn't think about (508 compliance, for example). It'll also be less maintenance for you if there's a bug discovered because you can just get updates from the original author / company and release those updates without spending more time on that same accordion menu.

While everyone loves to show off, letting them do some shopping on your dime is also pretty fun for most people. Make sure they do their homework and can provide sufficient evidence that whatever they find is solid.

6. As someone else said, breaking up a project into phases is usually a good idea. Not every phase has to be some magical, working version of the product, either, but it should have some kind of testable deliverable from everyone involved.

So overall, your estimates shouldn't come from some generic equation that we provide, but it really should come from you and your team and it should come out of some really intense planning sessions which should last DAYS. If you come out of a session after a few hours, then you've probably missed something that will later tear your estimate to shreds. Everyone misses details, so give them enough time to work through everything so they can have their "Oh right" moments BEFORE the work actually begins - those moments often have domino effects.

Finally one last piece of advice - make sure you have distinct roles for security and for QA. A fantastic product will be the death of your company if it allows hackers to access everyone's credit card number or spew obscene messages to random grandmothers, so your security person should be able to supervise development and develop various tests as it progresses. A QA person should be non-technical and should irritate the hell out of just about everyone. QA people are often hated and berated, but for good reason. You don't want your perfect product to break because someone "shouldn't have been able to do that" (as said by your developer). A QA person will do stupid things on purpose and mash on the keyboard because someone else out there will do the same, unthinkable thing, and your developer will need to write code to anticipate it and fix it.

Take 10% of everyone's time and add it onto the project into a bucket for QA, and 10% of the developer's time and add it into a bucket for security, and make sure they are doing their checks and tests at the end of each phase or sprint.

And I need to run, so that concludes my 2 cents.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Project Management

From novice to tech pro — start learning today.