How to estimate a software project?

At present here we view a simple, verified software project estimation method that generates exact results. It is used to guess significant unchanging value task. This process is supported on a quick but robust initial design on the premise that later versions of the design will reduce the amount of work as developers come up with smart ideas for reducing the task.

The System Designing

After collecting all the needed documents begin the system design. This design is meant for only estimation purpose. Typically it combines the team's current thoughts on technical design with what was learned from carefully reviewing the known requirements. Assign at least one technical person with significant design skills to read and understand the documents needed.

The design needs to be fleshed-out to the subsystem level, with each subsystem representing more than twenty days' work. Subsystems can be masses of code that needs to be written, products that need to be configured.

It is necessary to have a statement of project scope to attempt an initial design. In addition to setting out a boundary for the system, the statement helps focus the development team on the delivery of useful functionality, rather than technical wizardry - something that tends to happen when the goal is unclear. It is not necessary to have all the final requirements; although it is helpful to have the core requirements are distinctly proved.

The design from the beginning should be robust and complete - the team should have a high degree of confidence that the design will get the job done, even if it is not done in the smartest or neatest way. Later revisions of the design, with the luxuries of time and more complete requirements can add technical style. It is better to run a design workshop in order to get buy-in from team members. Have some work done on design prior to the workshop by a respected senior designer, who then presents the results to the workshop for review. The workshop should take just a few hours - a half day at most, and be focused on identifying subsystems and checking whether the initial design will meet the needs of the user.

The beginning design should be documented as a formal project file after the workshop. And this file has got the below peculiarities:

•a. A dependency list on external projects.

•b. An explanation of the role and responsibilities of each of the subsystems.

•c. Other risk lists.

•d. Assumptions made in arriving at this design - including interpretations of the requirements.

•e. An overview with a diagram showing subsystems and their interactions with each other and with the outside.

•f. The lists of assumptions, external dependencies and risks form the basis of the final lists of assumptions, dependencies and risks.

•g. Check the design manually to see that the design meets all requirements.

The Subsystem Estimation

Here we are prepared to run a workshop of estimation. This workshop involves the individuals who will be doing the work. At least invite the project's team leaders and/or other senior technical people. For larger projects, you may want to divide the estimation into several workshops. This estimation workshop should take one or two hours per subsystem. The workshop has a simple plan.

Check and examine elaborately this subsystem estimation:

Calculate the duration for each task

Have the workshop participants figure out how long a task will take, based on their experience implementing similar things. In the absence of experience, make a bold guess and assign the task a 'High' schedule risk.

If developers are having trouble with the concept of 'likely', try this analogy: If the boss were to ring you up and say "Come to my office as soon as you are free", you might say, "Sure I'll be there in ten minutes". Now you may only take five minutes if the thing you were working on finishes more quickly than you thought. On the other hand, you may take an hour if you were to twist your ankle in the corridor. Ten minutes is the likely time, assuming nothing goes particularly well or particularly badly.

Should you decide that a task is shorter than one day or more than ten days, consider combining or splitting tasks.

Assumptions should be documented

•a. Make the list of assumptions in explaining the requirements. This list should build on the list started in the design phase. Eg:It may not be clear what screen resolutions a system must support so the assumption will be made that "User workstations will have a screen resolution of at least 800x600".

•b. Sort the implementation of the subsystem into petty tasks.

•c. The each task is a logical unit of work that will be completed by one person. Breaking the subsystem implementation into tasks will require an amount of on-the-spot design. Tasks should be three to seven days long and they include both coding and unit testing. Each subsystem should have between four and twelve tasks.

•d. Consign each task a 'schedule risk' of High, Medium or Low. Some tasks are extremely straight forward, and have been done many times before, so it is possible to be very confident about the estimate given for the task. These tasks have a 'Low' schedule risk. Other tasks are almost completely unknown quantities, and these tasks have a 'High' schedule risk.

•e. Nobody would be surprised if a 'High' risk task estimated to likely take five days to complete actually took a two and a half weeks. A task with High risk can take one hundred and fifty percent longer than estimated.

•f. Similarly a three day 'Low' risk task should not take more than three point three days, and a four day 'Medium' risk task should not take more than six days.

Exterior projects document dependencies

List outputs from other projects or teams that this project will depend upon. Eg:If setting up a database schema will require the approval of the database admin team, write that down. This is a reminder to the project manager that they will need to secure the cooperation of that team.

It is also helpful for the workshop to estimate the chance that the dependency is not met and to document the effect of the dependency not being met. For instance, if that other project does not deliver the required component to a satisfactory standard, how must extra development will that cause?

Document any other risks identified

List any other factors that might affect the project. An example is the possibility that the test equipment may not be adequate. It is helpful for the workshop to estimate the chance that the risk event occurs and to document the effect on the project. Do not document the risks that have been already been included into schedule risk, as that would be double-estimation.

Other project activity estimation

The workshop has to estimate the below points too:

Expansion of background safeguarding: Configuration management and build system administration fall into this category. Typically allow 10% of the estimated implementation time.

Trial producing duration: Prototypes are often useful to reduce the total schedule risk for what would otherwise be long-running high-risk tasks.

Combination testing: System testing and User acceptance testing. Typically testing takes 20 to 30% of the estimated implementation time.

Consumption time: Each release to the client takes time. If unsure, estimate one week for the entire team prior to each release for a combined integration test, fix and build.

Set-up time: If new equipment or development software will be used make a time schedule. This covers installation and initial configuration.

Additional design time: It is required for the whole system and for individual subsystems or components.

Make sure the target of the task producing an accurate estimation through the points below:

•1. Thorough design discussion should not be allowed unless it is quickly resolved and dramatically affects the accuracy of the final estimate.

•2. Whenever a design discussion begins, encourage the participants to make a note and take it up after the meeting.

•3. Make sure that high-risk work is isolated into its own tasks, separate from low-risk work.

•4. Document an assumption about the meaning if there is discussion about the meaning of a requirement and then go forward.

•5. Some developers may be wary of committing to any kind of estimate at all at the beginning. Other developers may be over-optimistic in their estimates.

•6. Guide the workshop through this initial phase, emphasizing either that these are only estimates, with risks, assumptions and dependencies to be taken into account or that the entire project will be run according to their estimates, as appropriate.

•7. Choose the option with the least total time to implement, including risk allowance, in the event of several valid design options being presented to the workshop.

•8. There will be genuine disagreement between participants always about how something should be done. In this case, get each of the warring parties to estimate their way, pick the estimate with the longest time to implement, including risk, and move on.

•9. Those that can stop the whole project will have to be dealt with separately in the project plan. Risks that are not independent - those that will probably occur together if they do occur should be aggregated into larger risks.

•10. Assemble the workshop output. Create a spreadsheet that contains one line for each task: the task name, 'likely' estimate, schedule risk assigned and total.

•11. Add an allowance for risks and external dependencies identified. Assuming the risks identified are relatively small and are independent of one another, calculate the allowance by multiplying the percentage chance of the risk occurring by the cost to fix it.

•12. Add an amount for project management. This will range anywhere from 10% of the estimated development time upwards, depending on the overall project risk. Include in this an allowance for change management and contract negotiation. If the time estimated to manage the project exceeds the amount of time the project manager will have available, consider asking for extra resources such as a project administration assistant or a full-time client manager.

Planning the task

You need to schedule the work before promising a particular delivery date. This also provides an excellent opportunity to get the whole development team involved in the project and committed to delivery dates.

However, do try to steer away from Gantt chart software, as the chart quickly becomes too large and complex for scheduling in a workshop.

Build a draft schedule before the workshop starts:

•a. Affix project milestones, including interim and final release dates.

•b. Add dummy tasks to represent known outages - public holidays, annual leave, training courses and so on.

•c. Include each of the tasks from Step 2 above. Make each task the length of the 'likely' estimate.

•d. Allot tasks as best you can without consulting individual team members. Distribute with blank space between to represent schedule risk.

•e. If you have not already, work out how many people will be needed on the team in order to complete it in the required time. Do this roughly be dividing the total person days by the available working days. Add these people to the program.

•f. It might be necessary to split the work amongst several teams on a larger project each with their own schedule. In this case, use milestones to co-ordinate the schedules.

•g. Ensure that at least some of the partipants from the estimation workshop are there as well, to explain and clarify as required. All team members whose work is being scheduled should participate in the scheduling workshop.

•h. If the participants are familiar with the task based estimates, and the draft schedule is reasonably complete, allow five minutes for each eight person weeks work to be scheduled. The workshop should be kept short and to the point. Allow more time for an overview and explanation of the estimate if necessary.

The format of the workshop:

•a. Move high risk tasks as near to the beginning of the schedule as possible so that there is as much time as possible to deal with problems.

•b. Make sure that tasks are assigned to people who have the skills needed to do the task.

•c. The person who will be doing each task should be given an opportunity to express an opinion about the task's estimate.

•d. Make certain that no-one is assigned too many tasks or too few. There should be some gaps between tasks to represent schedule risk.

•e. Demonstrate the relevant portion of the schedule to the workshop on a large monitor. The group looks at the schedule and makes suggestions. Make changes to the schedule on-the-spot.

•f. Guarantee that dependencies between tasks are respected - reorganize the schedule if necessary.

•g. You will have a schedule for your project that accurately reflects your estimates at the end of the workshop. Keep in mind however, that the schedule will change as the result of further design changes.

The Effects of this estimation

•a. The results of this method are listed below:

•b. We get a record of the project's external needs.

•c. We get a record of other risks to the project plan.

•d. We get a project schedule with allowances for schedule risk, internal dependencies and known work outs.

•e. We get a record of other assumptions made during the assessment.

Also we get some documents like:

•a. User prerequisites - use cases, functional speculations.

•b. Scientific prerequisites.

•c. The account of project possibility.

•d. When we get more information, the last outcome will be exact.

Conclusion

While it is suitable to be used as the primary method of estimation, do check the answers through other methods such as comparing it with similar projects or counting function points. This is just one method for obtaining an estimate.

Try to limit backwards jumps though, as they can be costly. While this method is presented as a series of steps, don't be totally limited by this sequence. For instance, it is valid to change the design while workshoping the estimate.

Keep in mind that a schedule is of most use when the project is tracked against the schedule. Keep the schedule up-to-date with latest design changes. Also, check-off progress against the schedule regularly, perhaps in a weekly team meeting.

Significant improvement in accuracy can be made over time by the collection and use of suitable metrics. However, do be aware that the working with unfamiliar technology or in new business areas necessarily makes estimates based on experience less accurate. Like many estimation methods, this one relies on experience. After several projects a team should be able to estimate projects to within 10%.

If possible, ensure that every developer at least attends the scheduling workshop. Schedules arrived at with group commitment tend to be self fulfilling.