How do you estimate projects
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
How do you estimate projects
For ages I just sort of made a guess, based on previous experiences building similar systems, the nice thing about this approach is that takes minutes to determine and the client is happy. The bad thing with this approach is that is was rarely accurate and someone always lost (usually me) due to underestimating, not padding enough, etc.
The last two projects I have really strived for a micro-management approach, where I decompose a high system requirement(s) into smaller, more distinct functionalities, features, etc. This process continues until I have a low level understanding of what needs to be built, basically right down to the individual controllers, models, views.
The other advantage of this approach is that it makes TDD/BDD much easier, as you do not refactor tests nearly as frequently as you might otherwise.
This is not an easy process, it takes times to iteratively decompose high level features into more atomic/low level components. The end result is a simple specifications document, which complements BDD very well. As well it can easily be converted into a Gantt chart for project stakeholders to analyze, prioritze and have a clearer idea as to when certain deliverables are to be finished.
It can take upwards of two to three weeks (full time) for me to thouroughly decompose features into specs, but the investment is well worth the effort and, if nothing else, it provides the client with a standardized document of which they could send to any other developer to give them a clear idea as to the requirements.
This leads me to my 2 questions:
1. How do you estimate projectsÉ Are you a cowboy programmer who just guesses and wings it, saving you and client the additional investment in time, but accepting way more risk as a developerÉ
2. If you were to guesstimate the time it would take to implement a single controller:action and it`s required model method(s) and view, what would be your average estimate. I typically go with 5 hours as a nice *safe* value, which I can then easily multiply by the total number of controller:actions a system would consist of to give me and the client a good idea as to how long the project will take, once development starts.
Do you maybe use a more iterative approach, where you offer a time estimate that is very large and explain to your client that the number will probably decrease with each estimate iteration, thus allowing you to start development immediately.
Cheers,
Alex
The last two projects I have really strived for a micro-management approach, where I decompose a high system requirement(s) into smaller, more distinct functionalities, features, etc. This process continues until I have a low level understanding of what needs to be built, basically right down to the individual controllers, models, views.
The other advantage of this approach is that it makes TDD/BDD much easier, as you do not refactor tests nearly as frequently as you might otherwise.
This is not an easy process, it takes times to iteratively decompose high level features into more atomic/low level components. The end result is a simple specifications document, which complements BDD very well. As well it can easily be converted into a Gantt chart for project stakeholders to analyze, prioritze and have a clearer idea as to when certain deliverables are to be finished.
It can take upwards of two to three weeks (full time) for me to thouroughly decompose features into specs, but the investment is well worth the effort and, if nothing else, it provides the client with a standardized document of which they could send to any other developer to give them a clear idea as to the requirements.
This leads me to my 2 questions:
1. How do you estimate projectsÉ Are you a cowboy programmer who just guesses and wings it, saving you and client the additional investment in time, but accepting way more risk as a developerÉ
2. If you were to guesstimate the time it would take to implement a single controller:action and it`s required model method(s) and view, what would be your average estimate. I typically go with 5 hours as a nice *safe* value, which I can then easily multiply by the total number of controller:actions a system would consist of to give me and the client a good idea as to how long the project will take, once development starts.
Do you maybe use a more iterative approach, where you offer a time estimate that is very large and explain to your client that the number will probably decrease with each estimate iteration, thus allowing you to start development immediately.
Cheers,
Alex
Re: How do you estimate projects
Hi Alex,
That is a very interesting question. I've tried it both ways, and I've sort of settled into a middle ground, though I do have a slightly iterative approach. If there are very detailed requirements given (like what each button does, almost that level of detail) then I will do my best to summarize each major component in an itemized quote upfront. But in the vast majority of cases, I start by asking questions to try and uncover all the hidden assumptions about functionality, etc. and more importantly (at least with new clients) to develop a relationship. Then with each round of responses I can put more of the puzzle together and gain more mutual trust and confidence in the success of the project. When I do provide quotes, I do it in terms of weeks of effort, not hours. So for a certain feature or functionality, I'll put a dollar amount and a time amount on it, in half week increments (if something will take less than half a week I'll lump it with another requirement).
Regards,
Robert
That is a very interesting question. I've tried it both ways, and I've sort of settled into a middle ground, though I do have a slightly iterative approach. If there are very detailed requirements given (like what each button does, almost that level of detail) then I will do my best to summarize each major component in an itemized quote upfront. But in the vast majority of cases, I start by asking questions to try and uncover all the hidden assumptions about functionality, etc. and more importantly (at least with new clients) to develop a relationship. Then with each round of responses I can put more of the puzzle together and gain more mutual trust and confidence in the success of the project. When I do provide quotes, I do it in terms of weeks of effort, not hours. So for a certain feature or functionality, I'll put a dollar amount and a time amount on it, in half week increments (if something will take less than half a week I'll lump it with another requirement).
Regards,
Robert
Re: How do you estimate projects
I've never done this, but heard it quoted quite often. Take how long you think it will take and multiply it times 2 and that's closer to your real answer.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: How do you estimate projects
- Keep work logs as you do tasks, but also create a separate work log where you write down the technologies used, the task in terms of CRUD (Create, Read, Update, and Delete), and how long you spent doing the C, R, U, and D of it. The end goal is to start to average your CRUD time among several projects.
- Most projects I get have some quirk I don't know about yet. So, you have to pad a little for R&D time while you figure out unknowns.
- You need to not forget the time estimation on the visitor's view of a website, but also perhaps the authenticated roles. And then you have the backend admin view of the website. All require time estimations.
- I do estimation in two passes. I mean, if you don't do that, then you end up with clients occasionally who drag you on for 2 weeks of functional spec writing to gather all the requirements, and you might be doing that unpaid, which gets really expensive for you if you do enough of these. So, the first thing I do is count up features and roles, stick an estimate of anywhere from 4 to 12 hours on just by eyeballing it at the 500ft level, and pass that back and say, "Just a ballpark first guess at this, I'm looking at $10,000 USD with a +/- 30% variance here. Is that something you want me to commit to investigating further to see what the exact price would be?" It's how to eliminate a timewaster, or someone brand new to understanding the real costs of web development.
- Something recently I learned. If your first guess on the project looks like it might be over say $2000 USD, then you need to ask more questions with the client and see if you get sufficient responses in like 5 paragraphs with some detail. If all you're getting are 2 and 3 sentence responses, or 2 short paragraph responses, then you're likely dealing with a timewaster. I mean, a project of say $2000 USD or higher requires a project requestor (client) who is aware of what he wants and can specify it clearly.
- Something else I recently learned. You might find that your hourly rate should go down per hour as you are guaranteed more project hours. I mean, your standard rate is likely for the fact that you are making up for lost time here or there while doing sales and marketing, and for smaller projects. For larger projects, your rate likely needs to go down per hour because you are guaranteed more hours.
- Real time estimation, not the ballpark stuff, is only determined when you or a designer or client have wireframes drawn up, requirements gathered in emails, and you have written an outlined functional spec on what's going to be included down to some sufficient detail. Then, you compare tasks to your previous work logs on the CRUD items and estimate costs. Then, you go back and tweak if something just doesn't seem right. Some say then go back and double it, but you really need to look back over how you did on previous projects to judge that, such as padding a little and not a lot. This is where work logs are crucial. And remember, it's a balance game here. Estimate too high and the client walks. Estimate too low and you end up doing free work at the end of the project.
- Most projects I get have some quirk I don't know about yet. So, you have to pad a little for R&D time while you figure out unknowns.
- You need to not forget the time estimation on the visitor's view of a website, but also perhaps the authenticated roles. And then you have the backend admin view of the website. All require time estimations.
- I do estimation in two passes. I mean, if you don't do that, then you end up with clients occasionally who drag you on for 2 weeks of functional spec writing to gather all the requirements, and you might be doing that unpaid, which gets really expensive for you if you do enough of these. So, the first thing I do is count up features and roles, stick an estimate of anywhere from 4 to 12 hours on just by eyeballing it at the 500ft level, and pass that back and say, "Just a ballpark first guess at this, I'm looking at $10,000 USD with a +/- 30% variance here. Is that something you want me to commit to investigating further to see what the exact price would be?" It's how to eliminate a timewaster, or someone brand new to understanding the real costs of web development.
- Something recently I learned. If your first guess on the project looks like it might be over say $2000 USD, then you need to ask more questions with the client and see if you get sufficient responses in like 5 paragraphs with some detail. If all you're getting are 2 and 3 sentence responses, or 2 short paragraph responses, then you're likely dealing with a timewaster. I mean, a project of say $2000 USD or higher requires a project requestor (client) who is aware of what he wants and can specify it clearly.
- Something else I recently learned. You might find that your hourly rate should go down per hour as you are guaranteed more project hours. I mean, your standard rate is likely for the fact that you are making up for lost time here or there while doing sales and marketing, and for smaller projects. For larger projects, your rate likely needs to go down per hour because you are guaranteed more hours.
- Real time estimation, not the ballpark stuff, is only determined when you or a designer or client have wireframes drawn up, requirements gathered in emails, and you have written an outlined functional spec on what's going to be included down to some sufficient detail. Then, you compare tasks to your previous work logs on the CRUD items and estimate costs. Then, you go back and tweak if something just doesn't seem right. Some say then go back and double it, but you really need to look back over how you did on previous projects to judge that, such as padding a little and not a lot. This is where work logs are crucial. And remember, it's a balance game here. Estimate too high and the client walks. Estimate too low and you end up doing free work at the end of the project.
Last edited by volomike on Mon Dec 07, 2009 7:59 am, edited 1 time in total.
Re: How do you estimate projects
I use CRUDB - (Create, Read, Update, Delete and Bind (i.e. has-many, has-one relationships))volomike wrote:- Keep work logs as you do tasks, but also create a separate work log where you right down the technologies used, the task in terms of CRUD (Create, Read, Update, and Delete), and how long you spent doing the C, R, U, and D of it. The end goal is to start to average your CRUD time among several projects.
There are 10 types of people in this world, those who understand binary and those who don't
Re: How do you estimate projects
You have to adapt based on the client, IMO. If your client takes hours to get each idea out, you're not going to be able to cover any ground in one meeting, let alone in 1 month
[quote="VladSun"
I use CRUDB - (Create, Read, Update, Delete and Bind (i.e. has-many, has-one relationships))
[/quote]
In this case "bind" would still be editing, even if it is done via ajax, IMO (thats just a presentation detail)
[quote="VladSun"
I use CRUDB - (Create, Read, Update, Delete and Bind (i.e. has-many, has-one relationships))
In this case "bind" would still be editing, even if it is done via ajax, IMO (thats just a presentation detail)
Last edited by josh on Sun Dec 06, 2009 5:49 pm, edited 1 time in total.
Re: How do you estimate projects
+oojosh wrote:You have to adapt based on the client, IMO. If your client takes hours to get each idea out, you're not going to be able to cover any ground in one meeting, let alone in 1 month
There are 10 types of people in this world, those who understand binary and those who don't
Re: How do you estimate projects
Scrum estimation
Serious amounts of reading can be had on that. In a nutshell:
Write down the core requirements as Stories, I prefer the Story format of: So that ... As a ... I want ..., so for an example:
Once we have that, we can then identify the clusters of stories, and give them a gut-feel estimate of days to complete. Total it up, and you have an estimate for the entire project.
You can also do 60%/90% estimates to provide a range. E.g. I'm only 60% confident I'll have it finished in a week, but 90% confident it'll be done in a fortnight. Then you can say to the client "My estimate is between x and y" where x is the 60% total(s), and y is the 90% total(s).
Serious amounts of reading can be had on that. In a nutshell:
Write down the core requirements as Stories, I prefer the Story format of: So that ... As a ... I want ..., so for an example:
and on each Story, we have acceptance criteria, to continue the example:So that I can manage user accounts, as An Administrator, I want a user preference page.
Then, once everything is in that format on a Story card, lay them out on the table and use Affinity Estimation to lay the stories out in order of size (note: at this point we haven't set a scale, it is simply that the current story is bigger than the one to its left, but smaller to the one to its right, etc.)* Must allow creation, deletion and editing of every user account.
* Must only be available to Administrators.
* Must allow easy management of user permissions.
Once we have that, we can then identify the clusters of stories, and give them a gut-feel estimate of days to complete. Total it up, and you have an estimate for the entire project.
You can also do 60%/90% estimates to provide a range. E.g. I'm only 60% confident I'll have it finished in a week, but 90% confident it'll be done in a fortnight. Then you can say to the client "My estimate is between x and y" where x is the 60% total(s), and y is the 90% total(s).
Re: How do you estimate projects
Most often I have smaller projects, so I just estimate based on previous similar projects. Like, an information-focused website with about 30 pages, 2 different page templates and 2 web forms costs about $xxx.
I also take into account what kind of client it is. Corporate or small business or non-profit? The same kind of website might cost less for a smaller or non-profit client, while it might cost more for a bigger business. That's because the bigger client has more budget and also needs/expects the process of building the site to be more elaborate. (so to be truthful, they don't get exactly the same kind of website/building process).
I also take into account what kind of client it is. Corporate or small business or non-profit? The same kind of website might cost less for a smaller or non-profit client, while it might cost more for a bigger business. That's because the bigger client has more budget and also needs/expects the process of building the site to be more elaborate. (so to be truthful, they don't get exactly the same kind of website/building process).
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How do you estimate projects
And the math serves to confuse our clients into thinking we know what were talking about?You can also do 60%/90% estimates to provide a range. E.g. I'm only 60% confident I'll have it finished in a week, but 90% confident it'll be done in a fortnight. Then you can say to the client "My estimate is between x and y" where x is the 60% total(s), and y is the 90% total(s).
Thanks for the input, I've need a good excuse to read up on Scrum...this might be it.
Re: How do you estimate projects
No, it's merely a scale of confidence. Estimation is exactly that, an estimate. There is no way someone can ever produce a bang-on quote for work (except in the rare case of a fluke,) someone will lose out somewhere. Either the developer by under-estimating and thus doing some work effectively for free, or the client for over-estimates - paying more than what was required.
Providing a range reduces this risk. 
Re: How do you estimate projects
That depends, it reduces the risk should they accept the project, but I would also argue providing a range increases the risk of the client "inventing" reasons to go somewhere else for development (oh well their loss though)Jenk wrote:Providing a range reduces this risk.
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: How do you estimate projects
I think every project really has a sliver in it at the beginning called R&D. You either do it in the beginning, or at the end, or along the way. And what do you do in that phase? You figure out unknowns and minimize any risks. So, it's best to do this upfront. And it is the risks on a project that usually causes the most time slippage, in my experience. I mean, how often have you found yourself as a developer saying, "Well, I thought connecting X to Y was only going to take like a couple hours, but evidently it took me 15. I stuck with it, though, and I'm glad I did because I found some other things along the way that could help us in the long run." LOL.
So, you might be able to predict your CRUD time for the various web pages for each role, but it is the R&D part of any given project that is the hard thing to judge.
And every project I get usually has some level of unknown in it. For instance, I received a request today to put some links at the end of a JWPlayer Flash Control when the video finishes playing. We evaluated various ways to do this. We found one plugin that integrated into the Flash would perhaps resolve the problem if the client would accommodate how this plugin is coded, but we were not certain. Alternatively we found some code we can run that supposedly will intercept a finished JWPlayer video stream and then we can use jQuery and XHTML/CSS to throw up those links on top the video layer, but it requires testing to know if this will work. And last, we can outsource to a Flash developer to give us a remedy. But anyway -- this is the sort of thing where many of us regulars here are competent developers, but it's these nuances about technology, and new stuff, that throws us for a loop on every project and requires R&D time.
If we pulled out R&D stuff out of projects and estimated them purely on "knowns", then project estimation actually gets fairly accurate over time -- don't you think?
So, you might be able to predict your CRUD time for the various web pages for each role, but it is the R&D part of any given project that is the hard thing to judge.
And every project I get usually has some level of unknown in it. For instance, I received a request today to put some links at the end of a JWPlayer Flash Control when the video finishes playing. We evaluated various ways to do this. We found one plugin that integrated into the Flash would perhaps resolve the problem if the client would accommodate how this plugin is coded, but we were not certain. Alternatively we found some code we can run that supposedly will intercept a finished JWPlayer video stream and then we can use jQuery and XHTML/CSS to throw up those links on top the video layer, but it requires testing to know if this will work. And last, we can outsource to a Flash developer to give us a remedy. But anyway -- this is the sort of thing where many of us regulars here are competent developers, but it's these nuances about technology, and new stuff, that throws us for a loop on every project and requires R&D time.
If we pulled out R&D stuff out of projects and estimated them purely on "knowns", then project estimation actually gets fairly accurate over time -- don't you think?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: How do you estimate projects
That is pretty much what I do, but the planning I put forth on paper is probably significant compared to most developers. Nothing fancy really, just a waterfall approach to decomposing the requirements into smaller and smaller specs, until I feel I can accurately estimate the sub-totals, which bubble up into parent specs and so on.If we pulled out R&D stuff out of projects and estimated them purely on "knowns", then project estimation actually gets fairly accurate over time -- don't you think?
One downside, is the time take to paper plan (even sketches). A week to a month depending on the project complexity, most clients are left wondering WTF while they wait for some software. In times past I havelearned most people are content with seeing a interface, so I usually mock a UI and setup each controller:action which gives a client a feeling of work flow and allows them to make suggestions, etc.
I've often thought of building a tool to crank out basic templates/controllers from a low-level specsheet so the client would have instant gratification, depite most of the logic and application existing in the models.
Anyways, this approach works well for most scenarios, but really shines in a expert system, where CRUD-S panels are the impetus.
I find when building front-ends which typically rely on more complex business logic, or at least sophisticated SELECT queries, searches, etc...is where estimating gets more complex as you often have to solve issues which are specific to the problem domain, and are not easily understood from previous experiences.
For example, single keyword search on the last two sites I built were implemented wildly different, using different schemas, etc. How do you apply past experience in that case, IMO it's difficult if not impossible.
Cheers,
Alex
- volomike
- Forum Regular
- Posts: 633
- Joined: Wed Jan 16, 2008 9:04 am
- Location: Myrtle Beach, South Carolina, USA
Re: How do you estimate projects
Yeah, a good functional spec in its strictest form, I mean really, can take like 20 to 30 days to get 100% right. They're a beaut' when you see them. This poses two challenges. One, the client might not even use you on the project, so it could be all for nothing. Two, the client may be wondering where his code is. So really, I do my estimate on ballpark spec as best I can with like 30% variance, see if they're interested, and then come back again with a better estimate and a drawn out spec. But I now I don't just commit to spec writing unless I see the client is going to be iterative here. I mean, a project, say, worth $5000 USD or higher really needs interaction with the client. If he's just going to be vague, delay answering me every 3 days, or not have a lot of detail, then I really can't expect that this project is for real or that the client realizes the costs of web development. I had to learn that the hard way with another freelancer friend setting me straight the other day, and he's a regular here on DevNet. Anyway, even when I do spec writing, even though I try to do a great job, I have to kind of cut it short and apply the Pareto Principle here (80/20 rule) so that I can get an estimate out and get some cash in here.
And, yeah, just as soon as you land the project, spend 2 days getting your framework up, but then spend the rest of that week getting the basics online like admin login and main menu, user login and main profile dashboard, password reset, user registration and confirmation, and user control panel stuff. From there you can get a little breathing room to do some R&D on risks and unknowns, and get more questions answered on implementation choices with the client. But then you have to do 80/20 on that, wrap it up as fast as possible, and start delivering features one by one.
And, yeah, just as soon as you land the project, spend 2 days getting your framework up, but then spend the rest of that week getting the basics online like admin login and main menu, user login and main profile dashboard, password reset, user registration and confirmation, and user control panel stuff. From there you can get a little breathing room to do some R&D on risks and unknowns, and get more questions answered on implementation choices with the client. But then you have to do 80/20 on that, wrap it up as fast as possible, and start delivering features one by one.