Wherever cost is involved and price is not published or well known (as you may see in case of commodity), often you need to take help of estimation. In other industry – for example acoustics, trading, and constructions you take help of quotation to indicate the price of your service and products to your customer. Depending on product attributes and type of service you can define your pricing strategy, which allows you to provide quotes relatively easily. However, in case of IT, the estimation becomes relatively tricky. People across the industry have been doing this for over 50 years and still there is always questions raised on estimates. The question is why estimation is tricky in software development?
Let’s consider few situations where you are working in fixed cost model:
- You go for bidding a project in a new area (technical or functional) – which talks at extremely high level – of course you have to give a cost and time estimate. Often in such cases you don’t even get a chance to ask too many questions. Since there is lack of clarity – of course estimate will be risky. Worst, many times you may not be even involved in giving such estimates. It may be your higher management who gives these estimates.
- There is a slow down in the market. Your customer has invited few vendors to provide estimate even though customer may have slight preference for you. Most likely you need to close the deal in your favor. Even though you know that you are quoting less, the customer negotiates further and you end up closing the deal at much lower cost.
- You are doing a project where customer is asking you to give an estimate regarding their existing product enhancement. They talk to you about the functional requirement at very high level and you have to come up with a proposal and estimate. You come up with estimate by adding the variance that your company recommends. However, when the actual project starts you see that there is no one at the client side with complete clarity about the project. Worst, there are multiple people with their own thought process and customer is assuming that things will evolve.
Well, there will be number of scenarios that we can come up with. However the bottom line is that customer will be interested in getting commitment from you or your management as early as possible. This may sound logical as well because they may have some time and budget in their mind and before they spend any money, they would like to evaluate who can serve them the best at the lowest possible cost. Even if you communicate time and cost estimates through proposal or some other means they do get stuck up with the numbers which look suitable for them. Hence, you must make sure that you have strong basis before you come up with any number. Now, if you look at the scenario that we have discussed above, everyone knows that it is unfair to expect accurate estimate or fixed cost in all those situation. However, due to whatever business situation – your company needs to do that work. This is where it is helpful to share the basis of estimation with the customer. Whenever that basis changes, the customer may not push you to stick to the same numbers. Remember one thing, customer who wants to grow, will often want you to win as well so that you can serve them better and longer.
Alright, so far we have been talking in terms of cost and time estimates. As we all know that time commitment can be met by involving more resources, specifically if project activities can be performed by more resources, which are available for work on this project. Hence the cost given to customer is not necessarily the exact effort estimate. In fact, we must differentiate between overall cost and overall time required to complete the project. Many times your customer knows the hourly or daily rate that you may be charging. The moment you say that this project will take X-$$ or N-days they start doing their mathematics. Well, if the mathematics is not straightforward (i.e. as per the general understanding) then make sure that you explain both the things and if you have charged any additional amount or less amount then it is appropriately explained. Question is – what is advantage of doing this?
Well, if a project takes 800-hours of effort for an average resource then the bottom line is it will take that much time. It doesn’t really matter whether the cost of 4000$ or 16000$. Now assume that everything is not explicit to the customer. Due to whatever reason you could charge only 4000$ and customer knows that you charge 20$ / hour. Unfortunately, customer will expect that you will be able to complete the work within 200 hours. This is where shying will not help and transparency will be helpful. Of course, I am not recommending you to be transparent to a level where your business is not comfortable and customer need not know about those things.
Now, I am confident that you will have enough context to understand the things that you should know before you come up with estimates. Try to respect following principles:
- Base the estimate on the performance of average resource
- Ignore any external influence / constraints – these constraints must be factored later; if they exist
- Assume that whoever will work on the project will be available full time
- Get the estimates from those who are qualified to do the work on the project
- Get the estimate reviewed by someone else as well (preferably more knowledgeable) – specifically useful when the person giving estimate is also relatively new or you think that he / she might have overestimated or underestimated
- If feasible, try to think about the estimate at the granularity of hours
Never expect that all the senior staffs or super stars will be available for work. If you are lucky to get them on your project – explain them that this is an estimate based on average resources and they are supposed to outperform. Similarly, if you get less than average resource then make sure that you accommodate more time for them or ask them to put additional effort.
Another aspect is asking for estimate from someone who is qualified to work on the project. Well, this may happen when you are lucky to reach to that level where you know what all different skills will be needed and you also get hold of people with that kind of skills. Don’t forget that you may need to explain them about the whole project before they can come up with estimates. Here the fear is that you may end up spending significant time before you get the suitable estimate. Also, different people may think in isolation. Hence, often you will have to decide the size of the project and take a decision whether you can estimate on your own or you must involve someone who is more hands-on.
Now that we are aware of basic guiding principle, let’s also try to understand some of the challenges that we face while providing estimates. Well, if you want to use one liner then the main problem is lack of clarity. Now lack of clarity could be due to any of the following reasons:
- Lack of complete knowledge about the technology (new technology)
- Lack of functional knowledge in the related area
- Integration effort – specially with 3rd party software
- External dependency – where project depends on someone’s performance
- Methodologies – specially when the expectation is to follow a methodology which is new to you
This is where estimation tools are really helpful. Specially when your estimation tool is able to take care of following aspects
- Functional aspects – example working on ERP for the first time
- Technical aspects – example new technology or new version of a given technology
- Environmental aspects – example motivation level, possible change in scope
- The project activities – specifically when you are able to categorize them as Complex, Average and Simple tasks
then you can add certain weight factors and use some of your historical data in similar projects to come up with closer estimates.
Following is the sample guideline we recommend at Walking Tree for the rich internet application that we develop using Sencha / ExtJS:
- The exact requirement (BRS)
- If anything is not clear then that should be marked as risk and we must seek complete clarity
- If clarity cannot be achieved and estimate must be provided then we need to add variance upfront. The variance may be from 20% to 100% depending on what kind of clarity we have. If we still have confusion then take help from someone who can provide better clarity.
- The estimate must explicitly mention any assumptions and constraints
- Design, Coding and Unit Testing
- The environment in which we need to test
- Operating Systems
- We must consider following
- We must consider following
- Combination of OS and Browser
- Requirement discussion and project related meeting
- Requirement sheet
- Design and UIS documentation and update
- Unit Integration Testing
- Integration Testing and Integration Test Support (in case we are not developing application end-to-end)
- Any other testing – which will be project specific
- Estimates to be given by Project Manager
- Test Support
- Pre-Acceptance Test
- User Acceptance Testing
- Pre-Acceptance Test
- Project Management and Administrative tasks
- Inter-dependent parellel development
- Status reporting
- Test Support
- Data Migration Needs
- <<Anything else>>
While above guideline is still evolving, the bottom line is that we have to do all these activities to be able to successfully deliver the project. If you are able to think about estimate at the activity level and then you are able to visualize each and everything that you will be doing as part of that activity then I believe you will be almost there with accurate estimate. There may be variance of +/- 10%, which is most often acceptable in IT industry.
Let me give you an example of what do I mean when I say – you should be able to think at activity level and visualize each and every action within that activity. Say, my customer is saying that the application should work on all the browsers.
- First of all you need to quantify the word all. Get exact browser list from the customer and also make sure that you have got the right version.
- Remember that some of the browsers may not be supported in the technology that you are using and some of the browsers may have implemented something which is not part of the standard. Hence, there may be a situation that even though technology claim to be browser independent, you still need to make sure that you test the application on all the browser and if any issue arises, fix that issue. This will take time.
- If you don’t include testing the application on all the browser in your estimate, most likely you will not test the functionality on all the browser. When client tests the application, you will be on the back foot, because client already said it should work on all the browsers.
- Suppose if some of the browser in client’s list is hard to support, and if you could not visualize the possible issues then it may eat a lot of effort and your overall estimate will go for a toss. Hence, it is again important to be able to visualize clearly.
Overall, we need to understand that estimation is not a process which will give you precise number. However, as a professional we need to use scientific tools, historical information, our own experience and help from knowledgeable person to make sure that we come up with an estimate which is close to the actual numbers. Once the estimates are given on certain basis, we must be able to defend it and whenever any change occur, we must go back and review it. Remember, you don’t want to overestimate and lose the project and at the same time you must not underestimate and put your company in loss. Hence, estimation is a key area where you must keep on improving and try to reduce the variance as much as you can.