Acism's Offshore Outsourcing Guide > Challenges

This is the most common question asked to development teams, and is one of the most difficult ones. However, eluding the question is not a choice, because that's what the client wants to know before he starts a project.

Our mental picture while doing a project estimation is somewhat like the way it is shown in the accompanying diagram. We stack up different requirements on the project weighing scale, and it's supposed to tell us how much it weighs (in terms of efforts). Older software engineering books talk about a function point approach, where points are assigned to each functionality, and are later added up for an estimation. In other cases, work is broken down into smaller parts and they are estimated by experienced people to get a workable estimate. Both of these are minor variations to the same theme.

Let's see the unknowns:

1. Context switching kills. To understand this, imagine the simple activity of buying pens for your office. If you were asked to buy one pen at a time then it would take you N trips to the shop to buy N pens, which is far less efficient than knowing about the full need upfront and making only one trip to the shop. Exactly for the same reason, giving the requirements sporadically is a bad idea. Getting into the same thing again and again is inefficient. The waterfall model works great in this respect. But even in
   the iterative approach, clubbing related functionality together in an iteration is a good idea. It is a skill. If it is not done correctly, then the same functionality takes longer.
2. Detailing always takes a long time than the basic functionality. Those who build houses know this very well. When the brickwork is completed you can see the basic structure of the house and it looks nearly complete. But it's still a long way to go because of the tiny details in the interior design. Many times, especially when the client and the vendor are new to each other, the expectations about the detailing are not clear and that can cause serious mistakes in estimation. The waterfall model minimizes the risk in this respect too. In practice, if both parties strive for a clear communication and revisit the misunderstandings and continuously work towards resolving issues, then that keeps it easy.
3. Technology is a moving target. The programming interfaces that the modern programming languages offer are so vast that it's not possible for any single person to have used all of them. Then again, some times they change across different versions of the same language. Finally, all programming languages, operating systems, browsers or other tools have bugs and you won't know until you encounter. As a sum total, there are a lot of unknowns about a piece of code before it's actually written and tested. The best one can do in this situation is to use tools which are relatively mature, have a good user base, and have good support. This minimizes but does not completely eliminate the technology risk. Those working in software development know that it's a fairly common scene that a developer gets stuck in debugging some issue for hours together. There is no way to estimate these hours beforehand.
4. Developer productivity is another variable. Studies have shown that the emotional state of a developer can make a difference of as much as 10 times in his productivity. Many companies are not aware of the emotional needs of developers from their work. However, some things are obviously outside a company's perview. What if the developer's sister did not get admission to a college, or the traffic police towed his vehicle away?
5. It's theoretically proven that no amount of testing is ever complete. The absence of defects filed by a tester can not certify that a product is defect-free. (If you want to see how, just imagine that you are testing the simplest program that adds up two numbers. How many test cases will you need to write to conclude that the program is accurate for all possibilities?) The practical answer is again to do a “reasonable” amount of testing based on some norms.
6. Many requirements are crystallized only after the project has started (as long as you are not following waterfall model). Since they are not known upfront, a good estimation of them is out of question.
7. People attrition is another unknown and is the most dreaded nightmare. When someone on the team leaves, then she needs to be replaced. Some times the replacement takes time. Even after the replacement is on board, valuable project time is lost before this new resource becomes productive.

Another practical consideration comes from the fact that most of the times, project estimation is an unbilled activity, done before the project is signed off. The software vendor cannot afford to invest a lot of effort into project estimation, especially when the fate of the project is uncertain. If there is a 200 page document that the vendor needs to read for the estimation, then it makes sense to create a separate billable project estimation activity.

In the face of this uncertainty, the project estimations are never carved out into stone, and need to be revisited periodically. Acism typically offers two choices to its clients:

1. Time and Material: The project estimation is typically done to get a rough idea of the magnitude of the project. The client is charged proportional to the actual effort invested into project. Best attempt is always made to complete work as estimated, but the actual effort can be different.
2. Fixed Bid: The project estimation is done and a reasonable buffer is added to it to arrive at a Fixed Bid project cost. There is no impact of the project finishing earlier or later on the cost to the client. Of course, a fixed cost bidding is possible when the unknowns about the requirements or detailing are minimum at the time of estimation. If there is a change in the assumptions, then the bid needs to be revised.