Blog
Cal's Blog
 |
Cal Evans Director of PCE |
| Cal Evans is the Director of the PHP Center for Expertise at Ibuildings. He has been involved in IT development and management for the past 26 years and for the past 9 has developed primarily in PHP and MySQL. Cal is the author of a book and many articles on PHP development and can regularly be seen speaking at PHP conferences around the world. Cal blogs regularly at http://blog.calevans.com |
Tuesday, June 23. 2009Best Practices in Estimating
Part of the mandate for the PHP Center for Expertise inside of Ibuildings is an ongoing series of Business Process Re-Engineering projects. The first of these projects, "Estimating Best Practices", was recently completed and released. It contains the collected best practices from estimators inside Ibuildings, as well as input from external experts and published works.
Our estimating team spent two months thinking and discussing how software companies create estimates; we discussed what works and what doesn't. While the final document itself, along with the accompanying workbook, are available internally only, some of what was learned about the meta process of estimating may be interesting to others. Here are four Best Practices that came out of the process that we want to share with everyone. Right size your estimating process to the projectThe process adopted by Ibuildings estimators is a very detailed one. It is designed on purpose to be useful in estimating very large projects. However, it can be easily scaled down as necessary. In large projects, where potentially large sums of money are at stake, we have adopted a policy of having two estimators independently estimate the project. The two estimates are reconciled in a meeting between the project manager and the two estimators so that a single estimate is presented to the client. For smaller projects we apply the same discipline but with a single developer estimating the project. The process is scalable both upwards and downwards. When estimating a smaller project, the pieces that are not applicable are immediately obvious. A qualified estimator knows what to skip and where to pay special attention. Use qualified peopleAt first blush, 'qualified people' are simply developers. However, upon reflection, that theory quickly falls apart. While it is true that non-developers have no frame of reference for estimating development projects and should therefore never be used, even among experienced developers, accuracy will vary depending on experience. This is not to say that the only good estimators are old developers. Some developers will be better than others. Find the ones in your organization that are good at estimating and then use them to help train others. Constantly monitor your estimates and estimatorsIn designing our new process at Ibuildings, we felt that to continually improve, we had to continually monitor. To that end, we are putting in place procedures that will bring transparency to the estimating process. One of the desirable outcomes of this transparency is that we can see which developers show a talent for creating accurate estimates. Even within an estimate though, some developers will have a better grasp of what it takes to build the backend and others will have a better grasp on the front end. It is an important best practice that your company's estimating procedure assists in the tracking of key metrics to help identify the strengths and weaknesses of each estimator. It is not enough to simply measure whether or not the estimate was accurate. You process needs to identify the 2-3 key metrics that are important to your company and track each estimator on those metrics. Identifying and tracking these metrics will help your company not only identify your best overall estimators but will help you identify experts in areas like UI design, database and middle tier. When not actively working on an estimate, your top people in each of your key metrics can be used as expert resources for your estimators to consult with. The estimate is what it isAs much as we would love to think otherwise, when the estimate is complete, and all internal policies have been followed, the output should be a valid estimate. Whether or not the account manager can 'sell' the estimate to the customer is not part of estimating the project and it is a travesty when an estimator is told "This is too high". The estimate is what it is; if the amount is too high for the customer to accept then the price per hour can be adjusted or the feature set can be reduced. The number of hours that the project will take, however, should never be arbitrarily adjusted simply to meet a client's budget. ConclusionThe goal of our Estimating Best Practices process internally was to find ways to learn from our successes as well as our failures. Our goal in estimating any project is not to create the lowest estimates possible but to create the most accurate estimates we can. By following our new internal guidelines, we can not only provide our clients with accurate estimates but show them how we arrived at the numbers. Share         Trackbacks
Software Development and Black Swans
In 2007, Nassim Nicholas Taleb wrote a very influential book called The Black Swan - the title referencing to the idea that no matter how many white swans you see, you can never infer from them the existence of a (much rarer) black swan. The book was conc
Weblog: Ibuildings Blog
Tracked: Jul 23, 08:26 Comments
Display comments as
(Linear | Threaded)
re: developers
It seems to me that the tech involved, as well as the type of project, would have a bearing much more than the experience level of a developer - after a certain point. In my experience, a dev with 15 years experience isn't much better at estimating than a dev of 7-8 years, working in the same tech sphere (php, .net, java, etc.). But a dev with, say, 3 years experience of CF will have better estimates for a CF project than will a PHP developer with 10 years experience. Again, this is just my experiences I've had with myself and colleagues, but seems rather straightforward as well. Have your experiences been any different? Also, how do you go about estimating a project when no one on the team has experience with a particular technology? Do you just pass on the project? Pad the estimate high?
Hi Michael!
Yes, you are correct, a developer with 3 years ColdFusion experience will be more relevant to a ColdFusion project than a 10 year PHP veteran. My corporate bias was showing when I wrote that piece as we only work on PHP projects. Your point can be applied to front end vs. back end though. A good front end developer may not be of much use when quoting a predominantly back end system. So starting with the right estimators is one of the keys to getting a solid estimate. We have yet to run across a situation where we were asked to quote a project that utilized technologies in which we had no experience. In those cases though, we would most likely tap one of our partners who does have the relevant experience and ask them for assistance in building the estimate since they would most likely be involved in the final project anyhow. Thanks for the comment! =C=
Yeah, I guess it was too obvious regarding the languages themselves. I think I was thinking more of a degree of problem domains - a search-heavy project vs an accounting-oriented project, etc. Also, yes, front end v back end is such a huge difference that back-end people should be allowed to estimate front-end work. Front end people don't often get enough respect in that regard
"Constantly monitor your estimates and estimators"
Actually, I think this is where most projects and groups completely fail. They come up with estimates, blow some of them - they can't always name which ones - and then estimate the same way the next time. If you don't learn from your mistakes and figure out where your problems are, you're guaranteed to make the mistakes again and hit the same problems again. And you nail one of the interesting aspects of tracking this properly. Certain team members will be especially good/poor at estimating certain aspects. Figuring that out and planning appropriate will save you time and headaches later on.
Keith!
You are correct, organizations that fail to learn from their mistakes will continue to make them over and over. Ibuildings recognizes this, that is why we reviewed out estimating procedures. not only do we have a guideline for our estimators to use so that everyone is doing it the same way but we have procedures in place to review this procedure to make sure that it is working. We not only have to monitor our estimators, we have to monitor the process. The payoff though is more realistic estimates, fewer blown projects and happier clients. Thanks for the comment! =C= |
