Effort and Duration Estimation

This article is the third in a series of related articles with tips and tricks on producing a schedule for your project. The first two entitled "Creating the WBS" and "Scheduling Relationships” describe how to produce your Work Breakdown Structure (WBS) and scheduling networks. The ultimate objective of these two exercises is to produce the project schedule, but before you can schedule the project work you first need to estimate the effort required to perform the tasks and activities in your WBS, then estimate duration based on the number of resources assigned to the task or activity.

This article focuses on tips and tricks for effort estimation, load leveling, and working within budget and schedule restraints but the end goal is the production of the project schedule which requires the WBS and identification of relationships. If you haven’t already done so, I encourage you to read the first two articles in this series. This article also makes reference to MS Project because that is the scheduling tool that this author is familiar with. I’m not trying to endorse MS Project here, there are several excellent tools available for scheduling such as Primavera. If you happen to use a tool other than MS Project, you’ll have to translate the MS Project features and functions I refer to into the equivalent features and functions.

This article builds on the best practices espoused in the Project Management Body of Knowledge (PMBOK^®). For readers who have acquired their PMP^® certification, much of what I describe here will be familiar. For those of you who haven’t, there are many excellent PMP Courses available that provide you with PMP^® exam preparation training.

Effort Estimation

Estimation Methods

There are many estimation methods that can be used for estimating software development effort. Googling the keywords: "software development effort estimation” produced 534,000 results for me. An increasingly valuable reference source for this subject is Wikipedia. I’m going to restrict the methods I discuss to 3 for this article, and those 3 are:

• Analogous - uses historical information
• Parametric - uses estimation tools
• Top-down - uses project constraint information

There are different tools that support each of these different types and your choice of method will be determined by the tools available to you, to a large extent.

Analogous

Analogous estimation depends on the availability of historical information and is generally the most accurate of the methods. Even if you don’t have this information available to your project, you should consider starting your knowledge database to capture the information from your project so that it is available to future projects. The information you’ll need to capture will include: the number of lines of code per estimated package, the programming language used, the complexity of the package, the skill level of the programmer(s), and the effort in hours or days to develop the package. The analogous method will usually be the most accurate because it takes into account a number of variables that won’t change across projects such as: software tools, databases, source libraries, and the project team. The method that relies on industry information can’t take these factors into account.

Parametric

Parametric estimation is usually used for construction projects where there there is a plentiful supply of that information. Software projects don’t have that kind of information available to them and have to rely on tools to make up for this deficiency. Two of the tools most commonly used are Function Point Analysis and COCOMO (COnstructive COst MOdel).

Function point analysis (FPA) relies on the application being broken down into small components which are assigned to one of 5 catagories: External Input (EI), External Outputs (EO), Internal Queries (IQ), Internal Logical Files (ILF), and External Interface Files (EIF). These are then assigned a complexity value of high, medium, and low depending on the complexity of the component. Complexity is determined by the number of file types referenced, number of record element types, and number of data element types. The formulas used by function point analysis are quite complex and I would advise taking training in the method before attempting to use it. There are also IFPUGs (International Function Point User Group) that you can join to access the experience of other practitioners.

COCOMO also uses formulas to determine effort and cost. While Function Point Analysis uses a function point as a base, COCOMO uses the number of lines of code as a base. I would say that you should not attempt to use COCOMO if you are attempting to estimate a web site development project. The variances between the effort required for developing 1 line of HTML code when using a tool such as Dreamweaver and no tool is great. There is also a great degree of variance between the number of lines of HTML generated depending on the web development tool used. COCOMO uses modifiers such as required reliability, performance constraints, memory constraints, development tools, and programmer skill sets to weight the lines of code estimated. These modifiers are numerous and using them should not be attempted without some training.

Both FPA and COCOMO rely on a baseline to produce an estimate. FPA uses a baseline unit of effort for each function point score (e.g. if the baseline is 1 hour and the FPA score for the point is 10, the estimate is 10 hours). COCOMO requires an estimate of the number of lines of code and a baseline unit of effort for 1 line of code. COCOMO actually divides programmer skills into 5 different categories with an adjustment factor for each. Making effective use of each method will require some intensive information gathering.

These two methods may be used for both bottom-up and top-down estimation, but will yield more accurate results when each piece of the application or web site is examined on its own. The one exception to this rule is when you use historical information to do your estimation and your project is very similar to the one you use as an estimation base.

Effort estimation will be at the individual work package level, or above so the effort must be divided among its components until the individual activities have an effort estimation. There may be a simple one to one relationship between activities and work packages, or one work package may have several activities. You will need to determine the ratio in which the effort will be split to accurately assign effort to each activity where a many to one relationship exists. If you encounter problems in determining the effort required for individual activities you may want to eliminate the activities from the WBS and manage the work at the work package level.

Top-down

A top down approach is most useful when you are given project constraints for budget and/or schedule. A budget only constraint means that you can only develop the features and functions that fit within that budget. A schedule only constraint means that you can develop as many features and functions as can be completed by the hard stop set for the project. This means that you must assign as many resources as necessary to a task so it will complete on time. I have never encountered a project without some form of budget cap, whether the cap was expressed in monetary terms or resource terms.

Most projects are scalable in that you can apportion your budget between design, build, and test (Quality Assurance) in a fixed proportion. The proportion is likely to change depending on the software system you’re building, the tools you use to build it, and the people who are building it. For most cases the build portion of the project will consume more resources than either the design or test portions. Try a default split of 25% design, 50% build, and 25% test if you have no other information to go by. Factors that will tend to drive design costs up are complex and intricate user interfaces, and unclear or ambiguous requirements. Factors that will drive build costs up are system complexity, component integration, lack of automated test tools, and lack of compile and system test tools. Factors that will drive up QA costs are the unavailability of test data, lack of automated test tools, and lack of adequate testing in the build phase. One way to reduce QA costs is rigorous User Acceptance Testing. Software development projects always have trouble eliciting users for testing so here’s a tip that may help: make user training contingent on, or part of, user acceptance testing.

Assigning effort to the child levels of each of design, build, and test is done the same way as described for Parametric methods. This requires you to determine the ratio which should be used for assigning effort to each of the individual deliverables in the WBS. From this point, you will determine a ratio for assigning the budget to each of the major work packages in the deliverable and so on, until you have assigned an effort value to the lowest level of your WBS.

Duration Estimation

Duration estimation occurs when resources are assigned to the activities in the schedule. An activity which requires 10 days of effort will last 10 days when one programmer is assigned to it, or 5 days if 2 are assigned to it. The resource assignments will be constrained by the resource pool available to the project, the skill sets of that pool, and any schedule or budget constraints placed on the project. You should attempt to assign resources to the project activities so that the resources are engaged and leave the project in an orderly fashion. This means that you don’t bring in 20 C++ programmers for 2 days, dismiss them for 3 and then re-engage them for 1 day.

MS Project has a feature which allows you to manage resource pools and even supports dividing the pool up into groups based on skill sets. Define your resources in MS Project, then assign resources from that pool to the various activities in your schedule. Software Development project managers frequently have to contend with resources who are "part time” on their project. You must be realistic and conservative when establishing the percentage of their time that will be devoted to your project when they are working two or more assignments in parallel. Use the MS Project resource calendar to block out the times that a resource is unavailable to the project when a resource will be devoting 100% of their time to your project for one period and 100% of their time to another assignment for another period.

Identify all the holidays the project will span and mark these in the project calendar. You’ll have to mark holidays in individual resource calendars where your team is geographically dispersed and enjoys different holidays. Mark any training that is planned as part of the project, or was planned outside the project in the individual resource calendars of the team members receiving the training.

Assign resources to activities so that the project completes as soon as possible. The project’s Critical Path will determine the date the project completes and MS Project will automatically reflect the length of the Critical Path once you’ve created your networks properly.

Budget and Schedule Reconciliation

It is common to encounter a clash between the budget cap set for a software development project and the requirements for the project. There are a finite number of ways which can be used to reconcile differences between the budget cap and the calculated effort/cost of the project. One method is to substitute automation tools for effort where these tools would achieve a reduction in effort. The advantage of the automated tool is that its benefit will live on long after your project is completed.

Quality Assurance test costs can be reduced by engaging the user community in testing and having them follow the test scenarios created by the QA team. User Acceptance Testers come from the user community and normally their cost will not be allocated to the project.

Increasing the money you spend on resources is another method of reducing the budget, believe it or not. The COCOMO tool assigns a factor of .71 to a senior programmer and a factor of 1.46 to a junior one. It is highly unlikely that the senior programmer will make over twice the wage of the junior one, and in my experience the difference in their effectiveness can be greater than 2 to 1.

The last resort is to trim work from the schedule. This may be done without having to drop any of the requirements, but that is highly unlikely. Beware of shortcuts such as eliminating testing, design reviews, code walkthroughs, etc. Eliminating effort spent in design and testing will inevitably lead to increased costs.

Look for less costly ways of delivering the same functionality first. Customers will always choose a Cadillac approach to building a log in screen, but may settle for a Chevy, or even a Volkswagen approach when confronted with the cost. Eliminating requirements will be your next step. Prioritizing the requirements in your Business Requirements Document will make discussions around which requirements to drop much simpler. Start by eliminating those requirements which have a high effort estimation and a low business impact.

Project managers who are performing the project for an external customer will not have the ability to eliminate any deliverables from the project. Project managers who are delivering a project for an internal client will have more leeway. Eliminating deliverables is the last resort and should be done based on the cost and business impact of the deliverable.

Scheduling is the next constraint to consider. Since schedule and budget are closely related in a software project, you should have a schedule that is close to the set delivery date once the budget cap has been met but may require some fine tuning. Your Critical Path is the first place to look for savings. Can you assign someone working on a task not on the critical path to one on the path for a period of time? Can you swap a senior programmer working on a non-Critical Path activity for a junior one who is working on the Critical Path? Shorten the Critical Path as much as possible using these techniques.

After you have assigned your resources in the most efficient manner possible, you still may not be able to meet the deadline. You will need to consider compressing the schedule in that case. Look for dependancies defined as "hard” which are not really hard. Typical of these will be the need of an approved Detail Design Document before beginning coding. "Crash” the schedule where this makes sense to do.

The next steps are the same as the ones for budget reduction: feature simplification, requirement elimination, and finally as a last resort, deliverable elimination. The good news here is that the budget will get reduced as a result!

Load Leveling

Most of us tend to be linear thinkers, that is we tend to concentrate on one task at a time and MS Project supports this approach very well. Unfortunately, in the process of shortening the timelines for the project we will probably overlook the definition of a reasonable work week for every resource on the project. MS Project provides a feature they call the resource histogram to check for this. Run this feature after your schedule has been updated to meet budget and schedule constraints.

You’ll have to work within the existing constraints to level the load. Do this by changing work assignments such that everyone on the team is working 40 hours a week (or whatever constitutes a standard work week for your project) for the course of their planned assignment to the project. Assign more than one person to a task which has a resource working on it 80 hours a week. Look for ways of shortening the Critical Path with resources who are idled for portions of the schedule.

Load leveling using the MS Project feature is a tricky and time consuming task requiring many iterations. Leveling each resource in isolation may work for you if you remember that the leveled resource cannot be assigned anything else in the plan. You should also explore the option of overtime if you budget allows this.

Conclusions

You should always strive for a schedule that delivers the project ahead of any dictated delivery dates. There are two ways to do this. One is to simply use an artificial final date which provides the buffer. Let’s say your mandated delivery date for the project is July 31^st, 2010. Add a buffer of one month to your schedule by using June 30^th as your completion date and schedule your project accordingly. The other way is to use the mandated date as the final date and to buffer each of the activities in the Critical Path. Let’s say an activity is scheduled to last 20 days in your original estimate and that activity is on the Critical Path. Add a 5 day (or 25%) buffer to that activity and do the same for each activity on the Critical Path. The advantage of doing this is that it allows you to manage the buffer at a much more granular level.

The schedule you derive from performing these exercises is a project baseline. You should have this schedule approved by your project sponsors along with your other plans. You probably don’t want to ask your sponsors to review the schedule item by item, but should at least have them review the major milestones and deliverables. Encourage them to review the schedule after approval and provide it in the form of an HTML file or Excel spreadsheet so that they can view it.