How do we calculate the man-month rates?

The cost estimation of a Software project involves estimating the effort required to develop the software using various estimation techniques and then extrapolating the development effort for the entire project by applying effort distributions applicable for various phases in Software Development Life Cycle and the activities like Project Management, Quality Assurance etc. After applying an Adjustment factor for various 'environmental' factors, the final effort is estimated.

Calculating the cost from the effort can be easily done by multiplying the effort (in man-months) by a man-month rate. Most of the organizations are keeping an organization level standard average man-month rate for ready reference. As a project manager, I always had the following concerns regarding how this average man-month rate is arrived.

1. Is this rate really arrived by considering all the costs of employees at various levels and then averaged? In many cases, the rates may be directly taken from the market figures.

2. Are we considering the salary increases year-on-year for changing this rate? Because I came to know that many organizations keep the rate unchanged for few years. This may be because of market demands, but we can't deny the truth that the cost is increasing every year irrespective of the pressure to maintain the rates same.

3. Do we have different rates for different types of projects i.e. a project which requires highly skilled, very experienced workforce may actually cost more than the organization's standard man-month rate.

4. Are the location specific information considered for calculating the average rate? Companies having offices in cities will incur more cost than who operate from non-urban areas/special economic zones.

5. Is the location of the customer is taken into account? The logistics and communication expenses to support a customer at long distances is more comparatively.


There may be much more points to be considered for arriving at man-month rates. A company can also consider to have different man-month rates for applying to different types of projects.

Points to Ponder: Fixed Bid Vs Cost Reimbursible contracts

In my experience, I have seen many Indian customers always prefer Fixed Price contracts against Cost Reimbursible contracts (e.g. Time & Material) for software projects. The reason may be because of the perceived risk of cost overrun in agreeing for a cost reimbursible contract.

Those who prefer Fixed Price contract should understand the following points:

1. Since the price is going to be fixed, the seller (software vendor) may become cautious and add more buffer in cost/effort estimation to take care of unforeseen risks. This will be actually much more than the effort required to develop the product.

2. Since the price is fixed, the seller will be under pressure for any delay during the execution of the project. If these delays are because of the buyer (delay in providing adeqaute information, support etc.), the seller will try to re-negotiate the timelines and cost. Such re-negotiations may include some more buffer due to the experience and it may cost the project much more than the actual cost of a Time & Material contract.

3. In a fixed bid contract, the buyer's project coordinators may act without diligence just because any delay due to non-cooperation, lack of clarity of requirements etc. are not going to cost them directly. But indirectly it will cost the buyer also in terms of poor product quality and extended timelines. In a schedule overrun project, not only the seller but buyer also spend more effort from his side.

4. In a fixed bid contract the buyer cannot expect 'sophistication' in the product since the seller may try to complete the product just to meet the requirements rather than to provide anything 'excellent'. Many sellers even try to smartly trim the requirements pointing to various reasons towards Technology, Best practices etc.

5. It is very difficult to hold the interest of the seller in a fixed price contract if the project extends beyond the planned timelines. This lack of interest will indirectly reflect in the product quality due to lower morale.

Generally the buyers should opt for Time & Material contratcs when their needs are not clear. Otherwise it may appear that the buyer saves money (mostly at the cost of sellers) but there are much more other ways as explained above, they too will loose.

We really need a clear picture...

In any business, the requirement for a software is identified from a business need/problem and the need is expanded to a list of associated requirements. These requirements are visualized only at a high level initially.

In many software projects, these high level requirements are detailed during the Requirements phase and generally an agreement is reached (Requirements Signoff) between the seller (customer) and buyer (software developer). From this point onwards, the seller starts the subsequent phases & activities towards developing the product. Though the customer and software developer agreed on the requirements, finally the customer comes with a list of additional requirements/changes during product acceptance stage (UAT).

Why typically many projects face this issue? Why the needs of the customer has not been identified clearly at early stages either by the customer himself or by the software developer?

In many cases, both customer and the software developer assumes that they both understand the communication exchanged between them through words. But behind those communications, there are some visions/pictures which are untold and not understood. These are called as 'implicit expectations' by the customer and 'scope changes/scope expansion' by the developer.

How can this communication gap be filled? To do that, we need a Projector to enlarge the high level requirements and display them on a screen for both the parties to 'see' and agree.

The following diagram depicts the point.




Like a film is projected on a screen through a projector, the business need is projected on a screen called 'line of Expectation'. For projects which are troubled due to scope related issues, the line of expectation may always be moving or this line is kept at a long distance from the requirements definition stage. When the line of expectation is moved beyond certain point, the focus is lost and the picture (of the software) gets blurred. This is the point where the customer's business focus is lost. At these stages, the customer may treat a critical business feature and a 'Nice-to-have' feature with same priority. The elaboration at this point (shown as red area in the picture) , becomes the area of dispute between the customer and the software developer.

The solution to this problem is to fix the line of expectation at some stage and bring it as close to Requirements Definition. At this point, the picture is clearly projected (as a detailed requirements doc/prototype) so that both customer and software developer see the same picture rather than having assumed something about other end's needs & understanding.

I hope you are getting my point.

Are we on the same page? Sorry.. Are we on the same picture?