This weeks tweets looked at tracking actuals, revising estimates during the project, and using estimates to complete to measure progress. There are 3 great reasons for tracking actual hours and costs on a project.
#1 is that actuals help track overall progress against the plan
#2 reason to track actuals is that they give you information you can use to make adjustments to the plan during the project.
#3 reason to track actuals is they give you data to plan future projects. The more actuals you have the better future estimates can be.

If you use a project scheduling tool such as MS Project or Workbench make sure to baseline the plan before you start entering actual hours. As you track and record actual work hours against tasks you can start to see trends and get info that can be used to revise the plan. Actual data lets you revise estimates for future tasks.E.G. If the 1st 3 web pages took 10% longer you can update the other page estimates.

Revising estimates is not a bad thing. Having this data can help you make decisions so the final delivery date can still be met. Another metric that can help you manage the plan is estimates to complete or ETCs. ETCs are the hours estimated to complete a started task.

Every week have resources with open tasks give you their ETC. This does 2 things. 1) It lets you determine if the task will be done on time. The second use of ETCs is to give you a heads up that a task needs more time. Getting this data early lets you make proactive adjustments. For example if a task is taking twice as long you can look to see if it is too complex or if you need to get other resources to do other tasks to keep the schedule on track.

This tip is a compilation of tweets that look at how to fine tune project estimates and turn them into a work plan.

After the first draft estimate is done, take a few days to have the team, stakeholders, IT, and business resources review and comment. Once the team and others have provided comments go ahead and make adjustments to the estimates. Make sure all deliverables have estimates.

After making adjustments now look at the estimate versus the budget. You wait till now to avoid building the estimate to fit the budget. If the estimate is within 10% of the budget, high or low, you are probably ok to create the workplan. Double check with mgmt to make sure.

The first step to build the workplan is to group the tasks you estimated into logical groupings, Start at a high level such as coding. The next step is to further group the tasks into functional or like groups. E.G.you can group web screen coding or new policy tasks. The next step is to identify the dependencies between tasks.

Once the dependencies are listed you can identify the critical path. This will be those tasks that are dependent that take the most time. The reason for the critical path is the CP will tell you if the project can meet the expected delivery date or to set a delivery date. If the CP date is ok then you can complete the plan and begin to communicate it to the team and stakeholders.

This week the tweets looked at at project estimation using the estimating by analogy method.

Estimating by analogy is done by comparing the effort for tasks / deliverables of the current project to past projects with similar traits.

So the first thing you need for estimating by analogy is data from past projects. Actual data is the best if you or others has tracked it. If you don't have a lot of past data you can still do the analogy method by using data from industry sources. Another way to get data for the is to estimate standard elements of the project such as web pages, interfaces etc. to develop base numbers

Once you have your baseline numbers you can now build the first draft estimate. Start by identifying elements to be built for the project. Then for each element identified categorize the complexity as high, the same, or low compared to the base element. Now you need to determine the time or effort change based on the complexity. E.G.the baseline web page takes 16 hrs to develop and unit test.

You can the say that a low complexity web page will take 12 hours and a high complexity will take 24 hours.

Do this for all the elements and then add up the numbers. Add in test, rework, and deployment time. This will give you your first draft estimate. It is best if the team helps with the estimates as the more expertise used the more accurate and complete the estimate will be. If you have multiple people estimating a particular element make sure to use the average numbers and not the best case or smallest. You want the estimates to be reasonable and doable.

Project Estimation Techniques - Function Point Analysis

Function point analysis has been around since 1979. It uses 5 types of functions to categorize the software. The 5 functional types of function points are outputs, inquiries, inputs, internal files, and external interfaces.

There are many artcles and books on Function points. Here is a link to a primer bit.ly/43KWT4 by Alvin J. Alexander

To estimate the size of a software project you identify the type and complexity of each FP. Using a FP model an unadjusted score is derived. The UFP is then adjusted using the results of looking at 14 factors
Function points give you the size of the software effort which you can then put a cost to. You also need to add in costs for testing etc.

There are lots of resources for learning about function points. One place to start is the IFPUG, International Function Point User Group. One of the advantages of function point analysis is that fps give you a measurable value that can be used to provide other project metrics. Function points give you a measurable method to determine the size of a software effort. Function points also give you a measure of complexity for each function. This can be used to better plan testing and debugging costs