Estimating the Cost of a IT Project

There has been extensive research and development in estimation techniques for software development projects, resulting in a number of formal methods and toolsets.  These models suffer from a variety of weaknesses:

  • The most objective methods, such as Lines of Code, Function Points and Feature Points have the inherent disadvantage that a great deal of design effort is required to get to a point where the estimate can be made, raising the question of “How much is it going to cost to give me an estimate of how much it is going to cost?”
  • In trying to solve this problem by moving the estimate earlier in the project life-cycle, the solution becomes “less known”, and therefore the estimation error rises.  However, the better the estimators understand the business domain, the more reliable the estimate.  If the estimators don’t have a good understanding, the risk is sometimes not in the breadth of the scope, but in the intractability of one or two component – “Nobody told me that this project required curing world hunger!”
  • Team productivity can be highly variable.  If the estimators know who will do the work, they can produce better estimates.  But often the estimators have been given that job because they are very good developers, and they then estimate how long it would take them to do it, and not the mere mortals who will be actually be assigned to the project.
  • Simple estimator bias: optimistic estimators vs. pessimistic estimators.
  • Unstated assumptions, misunderstanding etc.

For the SMB, the relative cost of an IT project can be very significant, and so the necessity to get a good estimate as early as possible is essential, as is the need for a reliable estimate.  There are several things that can be done to achieve both of these, using a set of formal techniques, and taking advantage of the typical limited complexity of SMB projects.

The estimation activity is split into three distinct phases.  These phases should be ideally kept sequential, though some backtracking frequently occurs.  The phases are:

  • Assessment: understanding and sizing.
  • Estimation: turning the size into an estimate of effort
  • Adjustment: reviewing and adjusting the estimate and the risks

In the Assessment Phase estimators analyze the software solution to be estimated. Time pressure typically constrains the estimators’ ability to understand the scope of the task, so a focus on ramping up the estimators’ knowledge of the business problem is essential.  The general approach is to model the solution, to identify the components, and then estimate their size and complexity.  Finally, tasks that are not strictly mapped to components are added.  The essential point is that effort is not estimated at this point – just size and complexity.  Here we introduce the first bias reduction mechanism: the “sizing” should be performed independently by more than one person.  If the SMB has never developed a system like this before, analogical estimation will be a problem.  Looking at similar implemented solutions implemented by competitors can help with understanding the complexity (for example, there are many details in the shopping cart checkout process: change quantities, cancel item, shipping options, calculating shipping costs etc. etc.)

The Estimation Phase consists of turning the output from the assessment phase into effort.  Doing so requires analogical estimation.  For example, “How much time will it take to develop the detailed requirements for, and to design, construct and unit test this shopping checkout module?”  This is both a function of the size and complexity of each task, but also of the developers’ knowledge and experience.  For example, if it developed in house, the in-house team may have a better understanding of the business, but less experience of the technology.

The Adjustment Phase focuses on two aspects of the estimate.  First is the difference between the estimates of individual estimators; second is assessment of risks.  In comparing the estimates of individual estimators it is frequently found that estimates of experienced estimators for the same task can vary widely for any number of reasons, but chief among them are general optimistic/pessimistic bias, and differing assumptions.  So this part of the adjustment activity is a dialog, which is better if mediated by an independent third party to reduce the risk of one estimator dominating the result.  Finally, the “riskiest” activities should be identified, and potentially adjustments made to the estimates.  You can think about this as identifying the unknowns.  For example, does the solution require the purchase and integration of a software component that we have no experience of?  This activity can often uncover risks that need to be mitigated as early as possible in the project, and perhaps before the project is committed.  This could be done earlier in the estimation process, but these risks frequently only get uncovered when estimation differences are discussed and an unstated assumption is unearthed.

Pricing and laying out a timeline are typically the final activities.  At this stage, staffing options sometimes have to be evaluated.  For example, can this project be outsourced, and if it is, what are the assumed offshore rates and the additional project management oversight required.

Advertisements

4 Responses to Estimating the Cost of a IT Project

  1. Dear Subbu,

    Your thoughts are very insightful and I always take time to read and think through your ideas suggested or discussed. In the current article about IT project cost estimation, I can add two cents from my experience based on the specific domain and environment I am in.

    I have found that if the project is large and not all parts of the project can be estimated by a limited set of high level resources then there is a need to rely on the estimates of the many levels of estimators and managers. In order to drive confidence in this process and then to make it reality following two factors have helped.

    1. Estimator qualification: No one really thinks of setting a basic qualification criteria for estimators. Just like project resources estimator profile also needs to be recognized. One this is recognized, many of the team members can take the role and more than often they are the right people rather than the obvious ones who may be higher up in that consulting practice but not close to the domain and project. By setting a basic estimator qualification some level of higher predictability can be brought into the proecess.

    2. Estimator’s assumptions on resource qualification: Each estimator needs to put their assumption about profile of the resource they have in mind while making an estimate. This can then be brough to a single measurement acorss all estimators and estimate numbers can be adjusted based on higher or lower qualification of the resources assumed by each estimator.

    Since the only thing in control for the project leaders and services firms is the type of resources that they can bring in, so I feel that it should be made as the first driver in brining the reliability. If this parameter can be a control parameter then the project is likely to be more under control from estimation to reality.

    Then a milestone for assesment is always essential with the client with the focus on limiting the scope to fit within the budget and timeline. Since its a function of setting management expectations, proejct goals and defining the solution, project managers’ ability to lead all these parameters in relation to the parameters in control is the best predictability of the accurate project estimates and reality meeting the estimates.

    Just my thoughts from recent experiences of work that was actually out of control but our PMs brought it back in control despite all odds against it.

    Regards,

    Shrini
    (949) 235 7091

  2. Thank you for writing this, I can not find an information which is so clear and through up to now. Erp, customer relationship management are my favourites, please check.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: