<br><div class="gmail_quote">On Sat, Feb 21, 2009 at 3:52 AM, Victor Kane <span dir="ltr"><<a href="mailto:victorkane@gmail.com">victorkane@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Interesting topic!<br><br>First of all, this is true of all software projects, not just Drupal!<br></blockquote></div><br>No doubt this is true, but I do think Drupal presents unique challenges that makes estimating almost impossible -- that it unless you build in lots of padding. <br>
<br>To start, if a client wants any non-core functionality, there's the issue of whether or not a module exists that can do this. And if there is, how close will it get. <br><br>It's often not possible or practical to do the research it would take to determine these things up front, so there's an enormous amount of guess work involved. <br>
<br>The other killer is the bugs that come up. I started a very complex site on Drupal 5 last summer that almost bankrupted me because I did it at a fixed rate. The client wanted very long content types with dozens of fields of all types and views will lots of exposed filters. I made the mistake of thinking cck and views would handle their needs, but discovered bug after bug which added dozens of hours to the project. I know longer offer fixed rates on anything. <br>
<br>I'm finally getting a little smarter in how I approach projects. I spend a lot more time educating the clients about the process and explaining why projecting costs is so difficult, and how, as we go, I can present options on various ways to do this (this way will take an hour, this way might take 2 days, it's your call) <br>
<br>The thing I'm also finding helpful is the working backwards approach, where we have a fixed budget up front, but I keep the specifics as vague as possible and do as much as I can within the time they have allocated. <br>
<br>Sam<br><br><br>