Measuring Project Time

Measures in the eighteenth century not only varied from nation to nation but within nations as well. Today, the way time is recorded varies from software organization to software organization, and it even varies within a single software organization. This makes it difficult to share successes and avoid repeating failures. It becomes difficult to compare projects within a single organization, and it is extremely difficult to compare projects across organizations.

Just as most of the world uses the metric system, most of the world measures project effort in man-days, not in hours. There is no industry standard for the number of hours in a man-day. The number of hours in a man-day varies from organization to organization and typically varies from six to eight hours per day. When gathering data, I prefer to use hours instead of man-days because this allows me to convert the hours to man-days based upon the local organizational rules. I often compare multiple organizations and I need to make sure man-days were calculated the same for all the organizations in question.

Another problem with measuring project effort is who reports project time. The inconsistency of what time gets reported adds another dimension to comparing projects. Some organizations have everyone record time, and others record just programming time. Since programming typically represents less than half of total project time, this makes some organizations look very productive on paper. I typically calculate total cost of a software project using salary information. My source of data is payroll and time reporting. This helps me understand the gap between what gets reported and what gets spent. Often, gaps between what gets spent and what gets reported is large.

I was working for a company in Belgium, and they were interested in purchasing a software company located in Miami. The company in Miami had provide historical project information that looked very impressive. When I examined the data, it became evident the only cost information provided was for programming. In this case programming effort only represented about 20% of the total project cost. To make a long story short the company in Miami was understating project cost by about 80%. The company was not trying to be dishonest; they had always tracked project costs in this manner.