Estimating time for a project

[RCurtin]

Hi everyone,
This post will probally turn into a rant about my workplace more than anything else.

I'm having lots of problems trying to estimate how long it will take to do parts of my project. The project has to do with payroll - there are about 450 employees all over the world - some being paid weekly, some biweekly, some monthly and in about 4 different currencies. Many change job alot - as they are on short term contracts. I've been creating a DB to track who is working where, on which project and their rates for their current assignment. The idea is to show the gross pay for each one by project. Oh and I was also supervising 3 temps putting in all the data - peoples contact details, pay rates, current jobs from various sources of data that were full of mistakes. I've just checked and I've been working on it since the 20 Aug. I don't think thats unreasonable for a database that lets them take care of all their operations?

Its very nearly there now but I've been having such problems estimating how long parts of it will change. The person I report (I'll call him Mike) to has very little involvement and has only really seen it twice. I'm not supposed to be dealing with the manager whose team will be the end users. That person is enthusiastic about it and interested in it. Only prob was he was on holidays for 3 weeks in the middle of it. So then I was dealing with Mike. Every time we have a meeting I feel that he is putting pressure on me to have it done soon and end up estimating things will take less time than they will. I'm bad at estimating the time it will take anyways. Also with IT projects I just think that its very difficult to estimate as unforseen problems come up or is that just because I son't have enough experience?

I have been working exclusively with Access for nearly a year now. Two of the projects I've developed are being used daily - one is the main system used by document control and they are quite dependant on it. The others is used by the Materials section to track goods delivered to them. Unfortunately there is no-one in the company with more experience than I have with Access so there is no-one I can ask for help when I need to. Thank God for this forum or I would have been completely lost.

On Monday for instance they want me to research the vacation side of it and have a list of all the questions to do with it complete by that evening! the employees are not regular employees at all - some work on rotations, some are contractors, most are on short term jobs..And my boss also wants me to have looked into the billing side for each person - their rates are billled to different customers. And I have to have a list of questions done. I'm supposed to do all this on Mon!

Maybe I need a new job where I have a boss that knows more about Access than I do and they can estimate how long it would take.. Think my chances of getting a pay rise are slim to none anyways, given that they think its taking too long to do everything.

So how do other people estimate how long projects will take??

 

[The_Doc_Man]

Look up the work of a gentleman named either Brian or Barry Boehm on the subject of project estimation. (I forget his first name.) Also, Edward Yourdon has published on this subject. Neither of these publications is recent. You can Google some papers on project estimation. The Harvard Business School has published some useful articles that might help, though you will have to do LOTS of filtering. (HBS is a prolific publisher, to say the least...)

The basic principle of project estimation is ALWAYS "Divide and Conquer." Break the problem down into pieces. Once you can "see the entire piece in your head" you have a chance of correctly estimating how long it will take. You might be able to guesstimate how many lines of code it will take, to perhaps within 10 lines. When you get that far, you can make an estimate.

Many places use the concept of "action points" in the code - places where you have something to do other than simple straight-line (in-line, if you prefer) code. Each branch of a decision is an action point. Each time you gather data from an external source is an action point. Each alternative on a case-selection is an action point. The higher the number of action points, the harder it will be to code. Our application here is a military personnel database that has literally hundreds of thousands of action points. This stems from the number of business rules we have to apply. We're on ORACLE because Access would NEVER be able to manage the amount of data we have to use. Also, we are on ORACLE because the agencies we talk to also use ORACLE. When both sides of a transaction use ORACLE, certain types of database-to-database transactions become easier. But I digress.

In all cases and in all methods of estimation, the sine qua non is the project break-down analysis. Without that, you are going nowhere.

 

[Bodisathva]

Ahh, yes... Boehm's Spiral Model of the Software Process, theres a blast from the past. Thanks for the refresher, Doc.

it's Barry W. Boehm, btw

 

[Ron_dK]

In all cases and in all methods of estimation, the sine qua non is the project break-down analysis. Without that, you are going nowhere.

I would say, define the critical path first and see where improvements can be made .

Just my 2ct.

 

[Bee]

Hi everyone,
This post will probally turn into a rant about my workplace more than anything else.

The book suggested by The Doc Man is excellent. I am reading some chapters of it at the moment. The author is called: Barry W. Boehm.

Planning and updating the plan regularly is the key I think.

 

[RCurtin]

Thanks for the suggestions everyone. I will have a look for that book. I did spend some time in the design phase planning it all right. However the project has evolved as I've gotten a better understanding of the current paper based system.

For instance I found out that a person can be moved between different job numbers very often. On one construction site there are 5 different job numbers or projects. The job numbers have to do with budgets also - that is why personnel are moved between them. Therefore I built checks into the system to check if the job number head office had the person on is the same job number as the site have him on in a particular week. These are the kind of issues that I think would have been hard to forsee.

Then later I found that a person can have a split salary i.e. one person can be paid a certain amount in one currency on a particular payroll and a different amount on another payroll in another currency!
I have sorted all of these issues now, but again they were all things I found out about as I developed it.

As regards having a list of questions about vacation for Monday evening - thats OK but Mike has said that as soon as I have the answers to my questions he wants to know how long it will take to do it. And that I won't know until I've had a chance to sit down and work out the rules. If the set-up with vacation is anything like the set-up with pay then I think it will be complicated. From what I've read about vacation on the forum it can be complicated anyways.

 

[The_Doc_Man]

Rak - you can't define a critical path without having all elements of the path fully defined. Given that MOST critical path analyses are based on time required for a given step, you can't do critical path analysis without complete time estimates AND resource (personnel) lists. Further, you must assign resources to tasks in order to assure that you don't have to linearize certain steps that might otherwise be capable of parallel activity.

"Critical path analysis first" is putting the cart before the horse.

 

[The_Doc_Man]

The big deal for ANY design process involves another step that I hadn't considered, but your last post brought it to mind.

You can't make Access do anything that you couldn't have done yourself. I.e. you can't design fully what you yourself don't understand fully.

 

[RCurtin]

I think a key part of what you said is also about resources. In this case, there is only me and we had a few temps to data entry for a time! I guess if I had spent more time in the design phase it would have been easier to estimate how long it would all take. The other resource that is restricted is time - I am under pressure to get this done as soon as possible.

My approach was to get an overall view of the design first e.g. on the one hand there were the employees and on the other side were the jobs. A new record is created in another table when a person is assigned to a job. This records when they started the job and when they finished. It is linked to another table with their rates. This means that we have a work history for every employee.

After that as I come to do each part of it I research that part e.g. the vacation part i.e. ask people questions about it. However if they don't think to tell me about something relevant then I generally don't find out till later and then have to change it. For instance I couldn't have thought to ask if one person could be paid more than one salary?! And nobody mentioned it. Fortunately it didn't turn out to be too big an issue but it could have.

 

[statsman]

When I worked in broadcasting, you estimated the time necessary to set up a remote, then doubled it. Some problem always popped up.