How to estimate a software project in man-hours?

In the beginning…

In the good old days, software development costs were purely based upon the number of man-hours that were put into it. This was good for many techies, as many didn’t have a clue of how to deliver the solution and a lot of trial and error was involved. Most software developers were usually put in a department called R&D :o). This was bad for the software industry as it meant that costs were ridiculously high for even medium sized projects, which meant that most investors kept away from such endeavors. None could question the situation, as nobody knew any better (least of all, the techies).

Then slowly, metrics was implemented into the development process and all that changed. Now, if most of the programmers could deliver 1000 lines of acceptable code in a day then that was considered a standard output. This was good with languages like COBOL as reusability of code was mostly not possible. One referred code that was already written, and reworked it (easier said than done).

Then, slowly the C language became popular, and soon, just churning out lines of code was not enough. The C language had in-built libraries which took away some of the joy of screwing around with lines of code. Furthermore, programmers could put lines of code into a function and then reuse that function in other functions. So then, the focus changed more towards how many functions were being developed. So if you could break down your code into many functions, it meant your output was higher. Real cool. Whenever a function appeared to be more than 20 lines, there was a possibility for splitting it and increasing your output.

Then came C++ and it really complicated the estimation work. Now we have components, objects, classes, libraries, and what not. Something called system design was critical in deciding how to reduce the number of man-hours involved. Good design meant that entire components/sub components having thousands of lines of code contained in hundreds of functions that were placed in a few hundred classes could be reused. And within the components too, several classes and functions were reused. Even this is acceptable provided you have a complete, detailed, and approved design in place. Such a design would help determine the number of functions and lines of code that would be required.

So, what really is the problem?

These days, the cost of the project is often fixed before the design is done, and sometimes even before design has begun. Estimation now becomes more of guesswork based upon experience that was gained by screwing up earlier estimates. Without the design, it was quite impossible to know how many lines of code/functions/components/objects would be required. The estimator should rely on data and documents available before one starts the design, such as the functional and non-functional requirements, workflows, and use-cases. Therefore, requirements gathering and analysis is very critical to the project's estimation (design, development, and testing).

Using these documents, the estimator may create an object hierarchy tree simultaneously. The object hierarchy tree can help identify different levels/types of objects to be created, what is expected from these objects, and even some attributes for the objects. Therefore, without having an application design in place, the scope of work to be done, in terms of functionality required, can be identified.

Next, we need to determine the output of a typical team member. Some companies prefer to segregate team members depending upon the role, position, and pay scale of the team member. A team member's output should be proportionate to the role, position, and salary. A team member's work includes ideas, suggestions, discussions, research, and coding. But their output involves design, documentation, test case designs, coding, debugging, and testing. Usually, an architect would not do any coding. Neither would a tester nor would the project manager. So, the deliverables of each of these is taken differently, as below:

There are other roles like deployment manager, SQAs, domain consultants, and what not? The problem here is that many estimates are done before one can determine how many man-hours are involved by each of the above roles. For this article, I assumed that all team members are equals in terms of efforts and salaries (extreme programming disciples would appreciate this).

How to estimate an application cost without a design in place?

Each company determines the output it expects from its team members. Let us call the average output of a team member per man-hour as the unit output (u.o.). Assume that one has to deliver an end-to-end login module's functionality for an application. The time spent on the login functionality should include the corresponding time required for gathering the requirements, doing a requirement analysis, architecture inputs, form design, object/class design, implementing the business rules, data validation and storage, framework (i.e., code for login module's constants, enumerations, utilities), testing, debugging, deployment up to user acceptance, etc. Now, the estimator has to figure out how many man-hours it would take to complete the login module, keeping all these factors in mind. The sequence of work and dependencies should be considered as they do cause delays in completion. For example, form design should be done first (all the way up to acceptance by the customer), then object design (up to acceptance by the architect), followed by coding (for business rules, calculations, and data validations), internal testing, and user acceptance testing. A wise estimator would always take support from other people to understand the scope of work to do a given task.

Map features of older projects to those in new projects

Login module is a common feature of most applications, so we could justify it if the total effort to complete all these activities is 20 man hours. Now, if it costs the company rupees 700/- per hour (for a programmer, and workstation including hardware and software), then the basic cost of developing the login screen is 20 (man hours) x 700 (Rupees) = 14000.00 (Rupees). Ouch! Did that hurt? Is it too much (time/money)? For too little? Better give it more thought to justify both. J

Estimators should also try to map older projects to new ones. This would give them an idea of the broader picture of the time spent, and they could then try to distribute the man hours across the application's modules and phases.

Convert complex stuff to simple stuff

The number of hours required to develop a simple registration feature (end-to-end) would be within the abilities of most estimators. The simple registration form would include a Username, Password, and Email ID. In my opinion, this is approximately the same as the login page, so let us put 20 hours again. A still more complex form having around 20 GUI elements with several business rules and data validation would probably take a lot more time. In such a case, try to separate out sets of GUI elements and functionality so that each part appears to be similar in scope to the simple registration form. Then, add up the number of simple registration forms that you have derived out of the complex form, multiply it by the number of man-hours per simple registration form, and presto, you've got the number of man-hours to develop the complex registration form.

The same concept can be applied to business objects whose functionality is complex. The objects should be simplified into simple objects for which effort can be more easily determined. When developing a common event-handling component for the application, try to first break it down into easier to understand 'pieces'. Assuming that event handling component would involve logging certain type of events and excludes event fired on the presentation tier and database tier. Logging should be a separate component to be developed as it may also involve exception logging, security logging, performance logging, disk usage logging, C.P.U. logging etc. So, take out the logging component development when estimating the event object (it only uses the logging component). Now, the event object would involve defining events to be handled, data if any to be passed by the event, and developing event handlers for those events. Slowly, you will find that it is easier to figure out the effort involved to develop this component.

Try using an object hierarchy tree

This is an easy to create, graphical view of the application and would make it easier to understand the scope of the application. Document all the details like the purpose, role, and location of objects in the object hierarchy tree. Other documents like use cases, activity diagrams, business requirements and workflows can be used to justify the objects in the tree. This tree is not a replacement for a full-fledged and approved design. It is just useful to get the ball rolling early in the project, and can be a forerunner to a complete design. Separate object hierarchy trees should be created to identify business objects, framework objects and presentation layer objects (form objects).

Do not forget the risks.

Another factor to consider in estimation is risk. Risk factors should be determined for the scope of the project, requirements, design & strategy, technology, processes (for development, payment, change mgmt, risk mgmt, and closing the project), and terms/conditions of the project. When all the stakeholders (at both client and development company) have understood and are comfortable with all the entire project, risk factors are low. Otherwise, the risk factors increase, and that too exponentially. Always try to determine and accept the risks including possible ones, at least within the core team. If everyone keeps portraying a rosy picture all the time just to look confident and positive then the project could end up badly. Identify the risks and identify how you are going to solve them, do not brush them aside. Each phase, stage, component should be classified based upon their risk factor. If the risk factor is too high, i.e., there are too many issues to resolve, you can be sure that the project will end up badly, and so best not get into it, unless maybe you need the (bitter) experience for whatever reasons.

Risks have to be classified by the development companies based upon their own experiences and priorities. Some ways to rate risks are suggested below:

Risk factors are rated high when most of the stakeholders have concerns. Even if one important feature of a project appears too difficult to execute, the risk is high. Issues like acceptable type of bugs and number of bugs for user acceptance, terms for closing the project, payments not being clear or misunderstood, make the project highly risky.

Risks are rated medium when a very small number of stakeholders have a few concerns. For example, the development team may not have very advanced knowledge of the technology but could provide some work around. Another could be that the customer's people cannot finalize a few unimportant workflows.

Risks are low when issues like the format of the forms are not finalized but the functionality is thoroughly understood and solutions approved.

Iterative development may always have a medium to high risk, as changes to existing modules are common feature here. Unless the stakeholders have clearly spelt out guidelines to solve change requirements and a good change management process, the risks here are often very high.

Waterfall methods are too rigid but have a lower risk factor. Here, feature changes usually mean extra costs to the customer, and inability to deliver features as per the contract spells higher penalties to the development company. But, the advantage here is that requirements are fixed upfront before making any commitments.

It's still weird machacha

Software estimation is too vague a subject to explain to the non-initiated. But then somebody's got to do it. Practice by estimating simple modules using the suggestions given in this article. Start with a login or simple registration form, and work your way into more complex forms. And record your reasons for the man-hours you estimate for a task. Sooner or later, you will cross the threshold and become a value for money estimator.

With suggestions from my readers, I may be able to add more value to this article.

A sample abstract for a software project

History

This is the second cut.