You are on page 1of 16

Effective Strategy To Estimate Time For Your Design Projects

How many times have you been completely confused at how that ’small’ project turned into such a big one costing double and taking three times the length you estimated? Many of you will say estimating time for web projects accurately is an oxymoron, but by applying a few effective techniques it’s possible to dramatically increase the accuracy of most web project estimates.

1. Why Underestimating Is So Common
There are several reasons, which are freely admitted amongst freelancers and web agencies, as to why web projects are so commonly underestimated - they include: • • • • The technologies required by the project have never been used before At the time of estimating, there are grey areas or complete unknowns The client operates in a specialized industry and the solution needs bespoke features that are not familiar to the supplier Splitting the project down into the detail would require as much as work as the requirements gathering phase that is chargeable

However, there are also some secret reasons why web projects are commonly underestimated: • • • The client needs an estimate for their project tomorrow or they will go elsewhere Revenue needs for cash flow now trump the effects of not winning the new work now No previous project ‘estimated vs. actual’ data analysis has been conducted to draw on Estimating time for a project is not fun

Despite being true, rarely do we admit these reasons to others or even ourselves! The fact is, when working as a web professional, as a one man band or as part of a small busy web team, the secret reasons are an everyday reality that shouldn’t be hidden away. By first identifying and admitting why underestimating is so common, can you then set about implementing changes to your estimating process that will reduce the barriers each reason creates and increase your accuracy.

Página 1

Technologies Not Used Before
There are three approaches you can take when confronted with a brief that requires a technology you have minimal experience with: 1. Negotiate a paid for functional specification phase as a first step 2. Consider hiring an expert 3. Research in your own time and make your best guess Try to negotiate with the client a mini-project where you are paid to conduct a research and functional planning stage before committing to the whole project. This way you can research the unfamiliar technology and deliver a functional specification to the client. Best case scenario You give the client confidence, have a much clearer understanding of the work required, reestimate and are hired for the rest of the project. Worst case You have completed foundation learning of a technology you previously didn’t know that you can sell to new clients, you generate revenue and the client has a comprehensive specification they can use in their tender process. Added bonus You, and the client, get to find out how you work together, giving both the opportunity to part company before being locked into a lengthy project. If you’re not able to convince the client to pay for this initial functional planning stage, and can’t find a suitable expert in the technology, but want the work and have confidence in your ability and passion to learn what needs to be learnt, then the best advice is to do some initial research in your own time and just take your best guess!

Estimating Takes Too Long
Thorough web project estimating takes time, but it tends to inherit all the same rules that apply to coding, the more thorough you are, the more accurate you’ll be. Is it possible you will spend time working out the features required only to learn you haven’t won the work? Will you have given the client a free and detailed breakdown of their project for free? Absolutely, but this is the just nature of sales, some you win, some you lose - don’t get disheartened, try to get feedback from the client on why you didn’t win and use the advice given to refine your next estimation.

Página 2

Estimate Is Needed Tomorrow
If a client is demanding an estimate tomorrow after briefing you on the project today you should immediately try to assess if the project is right for you by: 1. Determining if the response rate being demanded by the client, and any previous communication, is a sign of the type of client they will be to work with 2. Assessing if the potential gain to your business from the project (high profile client or long-term repeat business) is worth the risk of underestimating and going over budget 3. Trying to confirm a ball park budget range with the client so you can estimate realistically, or politely decline if far too low. The best kind of clients are experienced enough to know this is not someone looking to use up all their hard earned cash but someone looking to provide the best solution they can for the budget If the results of these quick steps are favorable, be positive and go for it! There will be another chance to decline if you later find out the project is not right for you, and then you may utter the words “Into the garbage chute, flyboy!” Cash Flow Dilemma Cash flow is the life blood of any freelancer or small web agency, without they don’t survive. Occasionally a situation may arise where work will be taken on with the knowledge it may not be profitable. As gut wrenching as this can be, and despite all the comments you will hear how you should never do this, the reality is the bills and wages have to be paid! When a freelancer or business owner is presented with the choice of committing to a project for a price they know is low, but by taking on the project means they live to fight another month, or risking not taking on the work on in the hope more profitable leads appear empathise with and respect them. It is a tough and gutsy decision that only they can make but rest assured they have their bills or your wages at the forefront of their mind when they make it and estimating low for a project isn’t always as naive a decision as it may appear to those not on the frontline.

Estimating Is Not Fun
Ok, so it’s not as sexy as adding that beautiful grunge effect to your design, and it’s not as exciting as tweaking that jQuery plugin to work just the way you want, but estimating time for a web project more accurately is almost certainly more important than both when it comes to sustaining a freelance or small web agency business.

Página 3

However, while few will disagree as to its importance, many will continually find it difficult to muster up the passion and diligently estimate time for a web project, but why!? Here are more secret reasons: • • • • It’s hard work and takes many outside their comfort zone Estimating usually has to be completed alongside your plans for your already fully booked week It forces you to try and predict the future It makes you largely responsible for the business’s sales success, solution offered, project profitability and growth and survival of your business (scary stuff!)

Web agencies often have the edge here because they will have dedicated salespeople or project managers who are used to the rigors of estimating, but freelancers will generally be more inclined to find the whole process rather boring and just want to get on with the fun stuff. While we can all no doubt empathise with this, the harsh truth is that, when running a small business or operating as a one man band, one or two badly estimated projects in quick succession can ultimately lead to the demise of both! So what other techniques can be used to further increase the accuracy of your estimates?

2. Consistent Project Phases And Tasks
As previously mentioned, when being asked to provide an estimate for a project, it is invariably not something anyone has allocated time to do. As a result of this, estimates are often put together quickly and if compared to past estimates it’s not uncommon to see the same project phase or task classified in many different ways, and for similar sized projects the estimates for each to be completely different.

If you win the work you may think “so what?”, and to some extent you would be right, however, the first step in creating more accurate estimates on a long-term basis is to always break down the project phases and tasks in a consistent manner. Web projects can generally be broken down into the following phases: • Research and planning

Página 4

• • • • • • •

Solution design Design Front-end development Back-end development Content entry Testing Go-live

By always beginning to compile estimates using a consistent high-level breakdown means you can have a re-usable template eventually and track the time spent on each. But don’t stop there! Consistently breaking each phase down further will not only increase the accuracy of the estimate, but again, also result in valuable data over time.

3. Getting Granular

Now the project estimate is broken down into high-level phases, it’s time to get more granular and break each phase into tasks. This is where the estimate begins to become more tailored to the specific project, but also includes common tasks that you can add to your estimating template and use again and again. For example: • Research and planning o Requirements gathering o Project planning Solution design o Sitemap o Wireframes o User workflows o Functional specification Design o Initial homepage look and feel o Content page o Master content page template o News main page o News item

Página 5

Front-end development o 5x Templates build XHTML/CSS o JavaScript and AJAX o Cross-browser fixes Back-end development o CMS Setup and configuration o News feature o Contact us form Content entry o Homepage copy o Addition of 10x News items Testing o Internal functional testing o Client User Acceptance Testing (UAT) Go-live o Live server setup o 301 re-directs from old site URLs to new

The page templates and features specific to the client’s project can be listed at this stage, alongside the tasks required in all web projects. Once you get into the habit of compiling estimates in this way you will find yourself envisaging the phase and tasks lists during the pre-sales initial communication with the client and this invariably: 1. Refines your requirements gathering skills to quickly get the information you need in order to put together a thorough estimate 2. Forces you to think the project through in a step-by-step fashion and minimises the chances of missing a large, or several small, tasks that could end up putting you over budget because you didn’t factor them in So, you now have a pretty solid phase and task list for the project and all that’s left is to estimate hours for each and send it off to the client right? Maybe, but wait, what exactly does the News feature consist of? Is your interpretation of a News feature the same as the client’s? Now is the time to investigate and define it, as opposed to after the contracts have been signed.

Getting More Granular
While it’s tempting to estimate hours for the News feature and submit to the client, if possible, try to nail down exactly what the client wants from this feature at the estimating stage, after all, if you look around, you’ll be able to quickly find different variations of the same feature that have a huge differences in terms of size, features and complexity, and thus cost.

Página 6

Using the News feature as an example, talk to the client and determine what it needs to do so that you can again minimise the chances of missing something in your estimate that could, when added to the other ’small’ missed tasks, amount to a serious budget overrun situation. You may find out the News feature requirements are: • News feature o Add/edit/delete news item o Upload image o Attach PDF o Auto-archiving o RSS

Excellent, you have now defined the News feature and can confidentially estimate the time you think it will take to implement. But hidden in even the most basic and common of features lay more ’small’ things that if not captured, considered and quoted on, can add to the likelihood of overrun. For example, the client has specified they need to be able to upload images to news items, but do they need any of the following: • • • • Auto-resize capability? Auto-thumbnail generation? Full-screen viewing? Caption addition facility?

Any of the above News features could add a few hours to the overall project and thus need to be ideally catered for in your estimates - a few missed ‘couple of hours’ tasks and suddenly the project is two days over budget. Getting granular and mentally trying to build the solution means you are able to identify and address these issues early on, making sure to cater for them in your final estimate. “A Web Project Manager knows how to design and develop most of the project on his own, even if with poorer results compared to his team. This allows him to estimate projects with good approximation and to understand his team’s problems and difficulties” Introduction to Web Project Management, Antonio Volpon

Advantages Of Getting Granular, For You And The Client
By getting granular with project phases and tasks for estimates you are also able to tweak them very quickly if you discover the estimate you have submitted is above the client’s maximum budget. For example, how often have you been told by a client they want to go with you but your quote is ‘just a little too high’ and ‘if you could reduce it by five hours we can business’? Usually this means you have to do one of two things; drop the hours you estimated for the News

Página 7

feature and hope you can explain later down the line how the budget does not allow for image uploads and thumbnail generation etc., or remove the News feature altogether. But, if you have a granular estimate for the News feature, you can confidentially, and at this crucial expectation setting stage, simply remove a couple of sub-features of News and the News image upload functionality in order to align with the client’s budget. When communicating this to the client they will clearly see what you are proposing to drop and why and they will still get the News feature they need, but perhaps with a few less nice to haves. Using this approach is usually well received by clients as they have full and transparency on the reasoning behind the changes to your proposal. This kind of transparency during the sales process will invariably give the client confidence in you because it demonstrates to them you: 1. Are an expert in your field 2. Can envisage the project in its entirety 3. Adopt a diligent and methodical approach and more than likely will continue to work this way on their project Best of all, if you are successful with your estimate and you are hired you already have the foundations of: 1. 2. 3. 4. 5. An instant statement of work A defined project scope The timings you need to put together an accurate project schedule with milestones Client expectations settings very early Demonstrated your thoroughness and understanding of their business and requirements to the client

So what now? Well, now you have won the work, it’s time to start collecting the data that will enable you to create even more accurate estimates in the future.

4. Consistent Time Tracking And Analysis
Before starting the work, you should first replicate all of the phases and tasks, along with their time estimates, into your time tracking tool of choice. Once this is done, you can then begin work and make sure to be disciplined and track everything you do and log it under the right category. Of course many of you will do this by default as it allows you to: • • • Know how long you have to complete each phase View how long you have for each task and sub-task Reporting on how long everything actually took

Página 8

But the real value of keeping a consistent set of high-level phases, from estimate through to time tracking, is that after a few projects you can begin toanalyse the data and start to identify averages and trends that you can use to refine your next web project estimate.

Analyse Estimated vs. Actual Time
This is where the real magic happens! By breaking down and tracking your time for multiple projects into consistent phases and tasks, you will have valid comparable data to analyse, for example, after five projects, once you average out the numbers, you may well discover the following: • • • • • • • • Research and planning took around 5% of the total project time to complete Solution design: 5% Design: 25% Front-end development: 15% Back-end development: 30% Content entry: 8% Testing: 10% Go-live: 2%

The more projects completed that use a consistent estimating and time tracking structure, the more real your averages will become. With this valuable information you can then set about increasing the accuracy of your next estimate by being able to, assuming you can get a budget range from the client: • • Immediately allocate the estimated hours you need for each phase Determine the best solution you can offer the client for their budget

It even allows you to accommodate the client that ‘needs an estimate tomorrow’ when you don’t have time to break it down in detail.

Conclusion
Estimating time for a web project accurately is something many attempt everyday but few manage to succeed at. There is no one formula that will satisfy every situation and the chances of estimating what a project will cost exactly are almost zero. But it is possible to drastically increase the accuracy of your web project estimates by: 1. 2. 3. 4. 5. Identifying the reasons why underestimating is so common Understanding why it is so important Resisting the temptation to get granular Creating a consistent, methodical and re-usable estimating process Analysing the estimated versus actual data from multiple projects to identify trends

Página 9

“The Devil is in the detail: When people say that the devil is in the detail, they mean that small things in plans and schemes that are often overlooked can cause serious problems later on.”

Further Resources
Here are further articles and related resources that may help you to increase the accuracy of your web project estimates: • Web Development Project Estimator A neat little online tool that allows designers and developers to quickly create cost estimates for web projects. Schedule and Cost Summary This Cost Estimate and Scheduling spreadsheet provides a lightweight method for learning to estimate time to complete a web design project, and calculating cost for completion. Tick Simple to use time tracking tool that makes it easy to keep track of project budgets. How to Estimate a Web Site Project Patty Ayers discusses a five-step process for estimating web projects. Simple process to estimate times and costs in a web project Antonio Lupetti describes his process for creating web project cost estimates. How to Accurately Estimate a Web Design Project John Reeve talks about catering for the usual missing elements in estimates; project management, contingency time and margin for error. Estimating Resource Time for Web Development Projects Bill Breen explains one way to approach estimating time for web projects, and how the size of the project should influence you estimate ranges. How To Estimate Time For A Project A Sitepoint article by Alyssa Gregory.

• • • •

Related posts
You may be interested in the following related posts: • • 15 Useful Project Management Tools 10 Harsh Truths About Corporate Websites

About the author
Sam Barnes is a Web Project Manager at Rawnet. Although a little short for a Stormtrooper, he can be found posting articles at thesambarnes.com, a blog dedicated to the subject of Web Project Management.

Página 10

How to Estimate a Web Site Project
By Patty Ayers, http://www.webdevbiz.com/article.cfm?VarArtID=5 There's no getting around it - almost every web site client you'll ever have will want a cost estimate before work begins. If the prospect makes you anxious, you're not alone. Estimating a web project is not easy to do, even for pros. In fact, some very skilled web developers I know use systems of estimating which have more in common with consulting a Magic 8-Ball than with detailing time and costs - basically, they make wild guesses. Although this may get the unpleasant task over with quickly, it's not helpful for keeping clients happy or for running a viable business. But with some preparation and organization, estimating can be done with reasonable accuracy, and without any permanent damage to your mental health.

A Few Thoughts on Free Estimates
Some web developers offer free estimates as a matter of policy. I believe that this can be problematic, especially for very small companies, and so recommend giving it due consideration before publishing that offer. The reasoning is simple: estimating well takes time, and not every estimate will net you a contract. Depending upon your market and the tone you set with your business, you may get a lot of "shoppers". Shoppers are looking to get estimates from several companies and compare them, and you may very well be only a pawn in their process of finding the supposedly "best deal" - or worse still, in driving the price down with someone who they've already decided to work with. If this turns out to be the case, it's not the end of the world, of course - but how many times a month do you want to spend several hours (or more) working for someone for no pay? Of course, that decision has to be up to you. In my business, we provide an estimate for free if we think that an accurate specification can be determined and written up within a couple of hours. If we feel that it's a complex enough project that it will take us 5-10 hours or more of meeting, talking, researching, and writing and re-writing the specifications, we charge for that time. We tell the client that we'll be spending valuable consulting time with them, determining their needs, and that we'll produce a detailed specification document and cost estimate. This information is obviously of value whether or not they decide to work with us. If they do decide to work with us, the cost of the specification-development phase is applied to the total cost of the project. Either way, their money is well-spent. After all, developing a web site is not the same as painting the living room or fixing a leaky faucet. Free estimates and convenient price-shopping may be commonplace in a lot of industries, but they aren't necessarily appropriate for complex creative and technical work. But whether or not you're being paid for your time, the process should be the same.

Página 11

A Five-Step Process
Estimating is essentially a five-step process: 1. 2. 3. 4. 5. Determine what the specifications are for the site Break these specifications down into as many smaller tasks as possible Figure as accurately as possible the amount of time each task will take Add up the total hours and multiply by your hourly rate Add a percentage for contingencies, add expenses, and total it all up

Determine what the specifications are for the site. This is usually the most difficult part of the process. Clients often don't have a clear idea of what they want; they need your help to clarify and articulate what kind of web site they have in mind. This can be done through in-person or telephone meetings and emails, but you have to take the wheel, and you often have to persevere through a certain amount of uncertainty, hesitance, and outright fogginess. It's helpful to have a list of the various aspects and features of web sites to help you and the client through this process. Your conversations need to cover every aspect of the proposed web site, including: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Total number of pages What kind of navigation bars or menus More than one page design? Number of custom graphics needed Number of graphics provided by the client How design-intensive a site do they want? What type of text content, provided in what form? Interactive forms? How many fields? Database-driven applications? (Detailed description of all functionality is needed) Administration areas? Domain registrations or changes? Hosting arrangements? How important is search engine positioning? Will any client training be necessary?

You won't get all of this information worked out in a single conversation. For me, the process usually involves a series of conversations and email exchanges. After the first consultation, I go over my notes, usually typing them up so that they're easier to read. I then write out a "sketchy" specification, usually somewhat vague at this point. This makes obvious what information I still need. For instance, the client may have told me, "We want to display photos of the houses our firm has built", but I need to know more. How many photos? Displayed in what way? With thumbnails linking to larger photos? Will they need captions? In what form will he be providing the photos? These questions are jotted down for the next conversation. When I have a complete list of questions, I phone the client, making sure he has some time to spend, and I ask him the questions one by one. The discussion is usually far from linear, and may jump from one subject to the next, but I make sure that I'm in charge, and that I get the information I

Página 12

need. Remember, the client doesn't know how to write a specification for a web site - you do. The tangents and side-trips often provide valuable information too, so I try to be sure to listen well. A friend of mine recently took a sales seminar, and came back very excited about what he had learned. Basically, he said, he learned that he needed to really, really listen to his potential clients and customers. This is crucial during the specification-development phase. But again, be sure that your questions are answered, and that an unfocused or overly chatty client doesn't waste everybody's time. Always take notes when conversing with a client. Even if they are just scrawled notes, make sure you commit the crucial points of the conversation to writing, and be sure to date it. The information you have after this second meeting may be enough to write up a detailed specification. Add the information you've gained to your sketchy specification document, and see if you can flesh it out enough that you feel you are very clear on what's expected of you and that the client will be very clear on what he is getting for the estimated price. A note on pinning the client down on specifications: web site clients are notorious for figuring out what they really need and want only after a contract is signed and work has begun. This is so common that there's really no point in fighting it - it's almost guaranteed that the specifications will change. No problem - but make it clear to your client that when the specifications change, the cost estimate will change as well. Say this more than once during this phase: "This specification is only a snapshot, so that I can provide an estimate. If you add or subtract significant content or features, the cost estimate will definitely change. When that happens, I'll provide you with a written description of the change and the difference in cost." You may need more conversations, or a series of emails, to clarify the specifications. Don't rush it! Be sure that you have enough information before you commit to an estimated cost total. Break the specifications down. Now, take each part of the specification document and break it down into as many actual tasks as possible. For instance, "Gallery of 30 photos of 6 different houses" might involve: 1. 2. 3. 4. 5. 6. Receiving and sorting out client's photos Cropping, sizing, optimizing, and renaming photos Working with client to figure out how to present photos Creating thumbnails Building pages Receiving client's feedback, correcting and refining gallery page design

Figure how much time each task will take. This part of the process requires a little browfurrowing. For each task in your list, make your most honest estimate of the time it will require. Be realistic. You may want it to take one hour to build an entire page draft, but the reality is probably going to be closer to three or four hours. Give yourself enough time to do a good job! And remember - this type of time estimate is almost always short. Be generous!

Página 13

Add up the total hours and multiply by your hourly rate. Even if you don't plan to charge the client by the hour, but rather by the project, figuring by the hour is the only reasonable way to go, as it's the only real available objective measure of "how much work". The client doesn't need to know anything about the hours you're estimating it will take you, but you should know this. Figuring your hourly rate is beyond the scope of this article; we're assuming here that you have decided what you need and want to earn for each hour you work "on the clock". Add a percentage for contingencies, add expenses, and total it all up. The "contingency allowance" is something that experienced web and graphic designers don't even question. Underestimating is so universal that providing a cushion against your own probable inaccuracy is highly advisable. Between 10-20% is typical. Expenses, of course, are any out-of-pocket costs such as the price of graphics purchased, paying subcontractors, etc. Add it all up, and there's your total! Stand your ground. You may be tempted to shrink the total estimate down, fearing that your potential client will find it too high, but resist that urge. You came up with as accurate an estimate as possible, and it makes no sense to lower it. The client may or may not like your price, but if you offer to do the job for less than what is fair for you, no good can come of it. Stand your ground! You won't get every job, but the ones you do get will go much smoother if your estimate was accurate and fair.

Estimating Resource Time for Web Development Projects
http://www.effectivedevelopment.net/2009/06/estimating-resource-time-web-developmentprojects/ Coming up with accurate time and resource estimate is one of the toughest skills of a good tech manager. It is an under appreciated skill, but vital to a project’s success. In the ‘real world’ this one area requires many skills. It is necessary to have a deep knowledge of the project and technologies to be used, familiarity and confidence with your available resources as well as an intimate knowledge of the ‘outside’ forces. Outside forces on a project include other projects, vacation and resource availability, and finally all the stake-holders in the project. This could be your client, your boss, or perhaps another group in your company. This piece of the puzzle is usually the largest wild card when making an estimate. Hopefully, you are working on a small, manageable project or feature. As I mentioned in a previous post, no web project should take 9 months to a year of development. Delays are one thing, but if the project plan calls for over 6 months of specs, development, and QA, the project should be broken down to more digestible pieces immediately. I speak from experience here. In 2008, we completely redesigned our website. We looked to change both the front-end and back-end infrastructure and add every feature we could

Página 14

conjure up, but when the estimates rose into the 9-12 month range we scaled back the project. This reduced risk, and allowed us to provide an accurate estimate to the project’s stakeholders. After 8+ years of creating estimates for both internal and client based projects, I have a basic formula. This formula works for billable or developer hours. This is not a ‘Time to Completion’ estimate. Those estimates require knowledge of the company, other projects on the development queue, and resource availability. Here is the ’secret sauce’: When I have a project, I break it out into tangible subsections. Design, HTML/CSS front-end work, back-end work, middle tier, and database interaction. For each of these areas, there are questions that every manager must ask. These will be specific to your business and type of work. An example could be “will this project require third party data, or a registered user database? Do we need to put this particular feature behind a login? Or what technologies are we using or need to interact with?”. Knowing the right questions to ask comes with experience. At this point I take the resulting pieces, and come up with hourly estimates. Any feature or additional piece of functionality adds complexity to the whole project. They do not stand on their own. Let me explain. Say a particular widget takes 2-4 hours to develop on its own. And a poll or survey takes another 4 hours. Imagine a project comes across your plate that needs a poll, and also links to this ‘widget’. Simple addition would say this is 4-6 hours, but you know linking these 2 technologies will take more development, and add more complexities to maintain. Maybe it affects another poll or feature you deployed last week, and now that too has to be incorporated into this new poll+widget idea. So in reality, this new idea might take 810 hours to complete. You can easily see how the owner of this idea will not understand the additional hours needed if they are not technical or involved in the big picture. Selling these additional costs is another difficult part of the reality or practical development. Its very hard to explain the nuances of the development processes to the non-technical parties involved. Because of added and unforeseen complexities like these, I use the following hourly increments when creating estimates. All items take the following time (measured in developer-hours). • • • 2, 4, 6, 8, 12, 16: These increments work for 80% of feature additions. Anything over 16 hours proceeds in increments of 8 until 40 hours. (24, 32, 40) After 40 hours (1 week of one developers time), start to increase by 12. (This is because anything over a week now has a higher probability of being affected by outside sources now. I can easily shield any developer on my team from outside

Página 15

• •

distractions for 1 week, but its impossible to push off a person entirely after that. You may absolutely need them for something else with a higher priority or deadline.) After crossing 60 hours, I increase by 16 hours at a time. We usually stop at 120 hours. Very few projects get estimates past 80 hours anymore, but its not impossible. After 120 hours, we break the project into smaller, more digestible pieces of 80 hrs and under. I recently estimated a very large project at 300 developer hours, but it was really 3-4 smaller projects of 60-100 hours each. With practice you will find natural ‘breaks’ in a project for estimates. Maybe its database, back-end, and front-end. Etc…

I have spoken about realistically breaking down into 6 month turnarounds, which is usually a maximum of 120 hours of developer time. You will definitely have to tweak this for the way things work at your company, but the hourly incremental formula has worked for me for years, and always provides accurate billable estimates. Also don’t forget to add in a little padding for 3rd party projects, where you do not control all the project deliverables, and you shouldn’t get burned by a low ball estimate when it comes time to bill. You may also need to estimate design and project management into your estimates depending on where you work. This method concentrates on the area I have the most expertise in, Web Development. None of this is a science, rather it is an art, and there are no guarantees projects will come in under budget using these methods. This is particularly hard for us to come to grip with in the technology field. We like accuracy and concrete formulas by nature. However, I find these guidelines have provided fairly accurate estimates for me for years. Remember to keep records and compare your actual time with your estimates, and you will be able to achieve more accuracy over time. Does anyone else use a similar or perhaps a completely different process for estimating developer time? I’d love to hear about it and discuss.

Página 16