Acism's Offshore Outsourcing Guide > Effort and Scope

Person-days (or person-hours, person-months etc) is a unit of measure for efforts. If N persons work for X days, then N*X person-days is the effort that's been put in. Theoretically, the same amount of work should be possible by N*2 persons in X/2 days, or N/2 persons in 2*X days, or with any other combination where the product comes to N*X.

Many times, clients pay for the effort of the development team that would be utilized to develop the scope of the work. It is therefore a good idea to understand the relationship between the two.

Limitation of the Calculations

However, it's a good idea to bear in mind that this simple-minded theory starts breaking down as you move away from the original number of people. For example, if you have a project that a team of 3 people will be able to deliver in 6 months, then the calculations say that a team of 18 people should be able to deliver it in just 1 month. It does not work this way. This is because:

1. There is a difference in productivities of different people (even with the same experience level) in different things.
2. Communication needs (within the team) go up as the number of team members increase. Thus, the amount of work to be achieved (which includes communication) actually goes up.

Stretching (Working Hard)

Some times, clients try to push more work to be accommodated within the same resources and time. Often these are small changes or enhancements. Most development teams would try to accommodate these changes by working harder. However, it should not be stretched beyond a limit, because:

• The productivity of people starts going down. They may spend more time in office, but the returns on the extra hours spent are diminishing.
• Worse-- people start making mistakes and the quality of the software being built starts suffering.

The figure shows the result of stretching the resource-time fabric to cover more area (scope) beyond its stretchability.

It is therefore wise to remember the strong relation between scope and effort. The required effort increases when the scope increases and vice versa.

Rework

Rework needs effort. It always takes effort to break something that is built and then to build it again. Rework can be seen as effort wastage which could be avoided if the right thing were built in the first place. It is in everybody's interest to minimize rework on a project. Let's understand why rework is caused:

1. Understanding of requirements is not good enough. It could be a problem on the client side, on the development side or both. Irrespective of whose fault it is, the project suffers. It is therefore a good idea to invest enough effort to make the requirements quite clear.
2. The requirements change and it is not communicated to all the relevant people.
3. The requirements keep changing even after that part of the software is designed or already built.

Although undesirable, some amount of rework is inevitable on many projects. However, it starts wasting any non-trivial amount of effort, it's time to raise an issue and resolve it together.