Estimate of hours to be spent on a project

[Bob]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Thanks for help

Bob

 

[TJS]

google this

"help desk" asp.net

 

[TJS]

--break the job down into small tasks
--estimate the time to do each task

for help, contact the guy at http://www.ASPkey.net he's a project
management professional

 

[Randy Howard]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.
How do I estimate the number of hours I am going to spend on
programming in a project?

Have you ever worked on a similar project before?
If so, then you should have an idea of how long it took overall.
Where you part of a team or working on your own?
If you were on your own, then you should have a very good idea,
but as part of a team, you should also have a feel for time to complete.
How much will you have to learn new to complete it, or are you already
technically familiar with what is required?
If it's all new to you, try to imagine the worst case time it would
take you, then double it.

If it's your very first solo project, multiply by 3.

Unfortunately, there is no perfect way. If you have worked on a lot
of projects, particularly similar ones, you'll almost instinctively
know how long it will take. If you haven't, you'll be way off, no
matter what method you use. Better to overestimate it, and come in
early than vice versa.

You might also ask your management chain if similar projects have been
done before, and how much effort was required to complete them satisfactorily.

Even better, find a programmer more familiar with the goal and ask for an
opinion.

 

[Nick Landsberg]

Have you ever worked on a similar project before?
If so, then you should have an idea of how long it took overall.
Where you part of a team or working on your own?
If you were on your own, then you should have a very good idea,
but as part of a team, you should also have a feel for time to complete.
How much will you have to learn new to complete it, or are you already
technically familiar with what is required?
If it's all new to you, try to imagine the worst case time it would
take you, then double it.

If it's your very first solo project, multiply by 3.

Unfortunately, there is no perfect way. If you have worked on a lot
of projects, particularly similar ones, you'll almost instinctively
know how long it will take. If you haven't, you'll be way off, no
matter what method you use. Better to overestimate it, and come in
early than vice versa.

You might also ask your management chain if similar projects have been
done before, and how much effort was required to complete them satisfactorily.

Even better, find a programmer more familiar with the goal and ask for an
opinion.

Hmmm....

Randy provided some good advice, but I find the kicker in all of
this is "how well is the project defined in the first place?"

What your (non-technical) coworkers may feel is "well
defined" you will probably find is rather vague as you go
along. (I presume this is what Randy's comment about
multiply by 3 was based on.)

Second of all, given your situation, it sounds like your
only "testers" will be the end users. For certain you have
to plan for a debug cycle after it gets out, no matter how
much up front testing you do. So, I would change that
"multiply by 3 to multiply by 4 or 5" for the total effort.

Just opinion.,

NPL

 

[Chris R. Timmons]

(e-mail address removed) (Bob) wrote in

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am
going to spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Bob,

Read chapter 8 ("Estimation") in "Rapid Development" by Steve
McConnell.

 

[Programmer Dude]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Well, it seems to me, that if you're the solo programmer and you
have one (1) project, you'll be spending ALL your hours on programming.

So just tell them "All".

 

[TLOlczyk]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Break the project up into parts. Order the parts by importance ie
part 1 is the part where you know the project is failed if you fail
to finish this part. Make an estimate on each part. Keep that
list of estimates in a set of envelopes. Make sure that the envelopes
have been hermetically sealed in a mayonnaise jar and stored under
Funk & Wagnall's porch. Then multiply each estimate by 10, total
and hand them in.

After you finish the first part, write down how long you took to
finish it. Compare to the estimate of how long first part took,
and tweek accordingly. If the new estimate is lower then hand in a
revised estimate of course with the factor of ten. If higher say
nothing, unless it is more then ten times the estimate, in which
case hand in a new estimate.





The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

 

[Lloyd Dupont]

I think one good advice give previously was to cut the big project in small
task an evaluate the small task.

if you have no idea, you should say, it will be long I need to spend
sometime working on that

time you should spend writing a small draft/mockuyp application which cover
a little bit of everything (a prototype), then think clearly of how much
work you will need to complete each task.

the firsty answer you could give next day is "writting a prototype which
would help me giving a more accurate estimat would take: that much time"

then when he prototype is done spend 2 days thinking, estimate each part and
sum them up !

 

[Phlip]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Tell them you have a ball-park estimate - 60, 80, 240, whatever - but you
will know much more in just one week.

Before that week, write the name of each _small_ feature they request on a
card. Ask whoever owns these features to sort them by business priority (not
technical risk, or alphabetical order, or whatever). The feature with
highest business priority is the feature that will boost end-user
productivity the most.

Take the top 8 cards.

For a week, implement those cards. Write lots of Unit Tests as you go, and
run them between each 1~10 edits, the fewer the better. Always rapidly
return the code to a condition where you can predict the results of the next
test run.

After one week, compile everything into a deliverable, deliver it, and make
them use it. Watch them operating the features they just request. (Oh, and
all those tests made sure you implemented very fast, but with absolutely no
bugs. You will be surprised. A few short minutes writing tests, and simple
code, can prevent many long hours running a debugger.)

Count the number of cards you finished. It could be 6, or 8, or 10, or
whatever. Suppose it's 9.

Now tell them, "If we keep going like this, I can finish 9 of these cards
per week. What's the next 9 cards to do? And does running the program make
you think of new cards?"

They will add any new cards they think of, remove any cards that might no
longer make sense, and then sort the stack by business priority. You will
pull off the top 9 cards.

When you implement these, refactor your code to merge the new features into
the old code. The tests that constrained the old code will support this
activity. Bugs come when you add new features to old code, so adding tests
to all features defeats this risk.

After the second week, you may finish 5, or 9, or 11, or whatever, number of
cards. And you will not slow down, no matter how many features, because the
tests maintain your velocity.

By this time, your stakeholders will have such a clear picture of your
velocity that they will no longer ask to "estimate" any number of hours.
They will have a perfectly clear understanding of your throughput, and will
not consider your velocity - 9 or whatever - as an estimate. This process
makes them feel very in-control of your project, and very reassured. They
can easily select features in batches that steer the project towards its
business goals.

 

[Nick Malik]

very agile.
nice.

--- N

Tell them you have a ball-park estimate - 60, 80, 240, whatever - but you
will know much more in just one week.

Before that week, write the name of each _small_ feature they request on a
card. Ask whoever owns these features to sort them by business priority (not
technical risk, or alphabetical order, or whatever). The feature with
highest business priority is the feature that will boost end-user
productivity the most.

Take the top 8 cards.

For a week, implement those cards. Write lots of Unit Tests as you go, and
run them between each 1~10 edits, the fewer the better. Always rapidly
return the code to a condition where you can predict the results of the next
test run.

After one week, compile everything into a deliverable, deliver it, and make
them use it. Watch them operating the features they just request. (Oh, and
all those tests made sure you implemented very fast, but with absolutely no
bugs. You will be surprised. A few short minutes writing tests, and simple
code, can prevent many long hours running a debugger.)

Count the number of cards you finished. It could be 6, or 8, or 10, or
whatever. Suppose it's 9.

Now tell them, "If we keep going like this, I can finish 9 of these cards
per week. What's the next 9 cards to do? And does running the program make
you think of new cards?"

They will add any new cards they think of, remove any cards that might no
longer make sense, and then sort the stack by business priority. You will
pull off the top 9 cards.

When you implement these, refactor your code to merge the new features into
the old code. The tests that constrained the old code will support this
activity. Bugs come when you add new features to old code, so adding tests
to all features defeats this risk.

After the second week, you may finish 5, or 9, or 11, or whatever, number of
cards. And you will not slow down, no matter how many features, because the
tests maintain your velocity.

By this time, your stakeholders will have such a clear picture of your
velocity that they will no longer ask to "estimate" any number of hours.
They will have a perfectly clear understanding of your throughput, and will
not consider your velocity - 9 or whatever - as an estimate. This process
makes them feel very in-control of your project, and very reassured. They
can easily select features in batches that steer the project towards its
business goals.

 

[Nick Malik]

I'm amazed at how many answers you got, and not one that takes a
quantitative approach to estimating.

So, I'll offer an alternative:

Take your requirements, perform a Function Point Analysis on them. Get a
count of your function points (a measurement of the SIZE of your application
based on a scientific method for measuring the size of the requirements).
Multiply the function point count by your estimated productivity per FP (you
can get an excellent starting point by using the national averages from
Capers Jones book on software cost estimation). A good number to start with
is 14.5 hours per function point. (Including project mgmt, analysis,
requirements, design, coding, unit test, functional test, integration test,
UAT, documentation, and deployment).

Of course, learning to perform an FPA is a career activity, not something
you do for one project. However, after teaching a session on FPA recently,
I had a project manager come up to me and tell me something I found quite
gratifying. He said that his group has been using FPA for estimation for
about a year, on about a half-dozen projects (mostly ASP.NET projects), and
FPA has been their most accurate estimation method in the history of the
organization.

So, for all the useful advice from ad-hoc specialists, especially those of
us who are old enough to actually assume that we'd be able to make a good
guess, realize that all that advice is a method of guessing. Using
measurements will produce a far more accurate number.

Consider it.

--- Nick Malik
Certified Scrum Master
Certified Function Point Specialist

For more information, see www.ifpug.org

 

[Brian Henry]

it's very hard to estimate until you are actually working on the project...
you have no sense of how hard the task is or how long it takes you to
complete it until you really start getting into it... our latest project we
estimated would take a half year... now it's virging on two years because
some of the pieces were way more complex then believed to be or were even
documented to be....

 

[Gabriele G. Ponti]

http://www.construx.com/resources/estimate/

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

The most common method is to break down the specs into individual tasks.
Estimate each task based on the time it took you to do similar things in the
past. Then, add a confidence factor to the estimate. If the project is very
similar to what you have done before, confidence is high. If you are getting
into deep water, confidence is low.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[rossum]

I have recently joined a healthcare company where I am the solo
programmer. I am going to be starting work on a project. The
management has asked me to provide an estimate of hours I am going to
spend on the project.

How do I estimate the number of hours I am going to spend on
programming in a project?

Thanks for help

Bob

Read all your other replies. This is another approach.

The basic phases of a project are:

Specify
Design
Build
Test
Implement
Run

If you can get away with it just estimate how long it will take to
specify the project, that is to get the scope of the whole project
*agreed in writing*. Without that you are in no position to be able
to say how long the other parts will take.

Whenever anyone subsequently asks for a change present then with a
written estimate of how much time and cost it will add to the project.
Ask them if they wish to proceed and get the time/cost change *agreed
in writing*. Without agreement the change does not go ahead.

As you get to the end of each phase give a detailed estimate for the
next phase only, and a rough estimate for the phase after.

Allow more time for testing than you think you will need, at least two
run throughs of the entire test suite as well as user acceptance
testing.

rossum

 

[Phlip]

The basic phases of a project are:

Specify
Design
Build
Test
Implement
Run

If you can get away with it just estimate how long it will take to
specify the project, that is to get the scope of the whole project
*agreed in writing*. Without that you are in no position to be able
to say how long the other parts will take.

Waterfall is a completely discredited methodology. No phase has any driver
except guesses and any exit criteria except boredom. There's no way to know
how to track or pace each phase, or estimate a percent completion. And each
phase has different durations.

Whenever anyone subsequently asks for a change present then with a
written estimate of how much time and cost it will add to the project.

This penalizes stakeholders for learning from the finished app how to make
it better. Teams who indulge in this kind of contract are usually just
trying to get paid to fix their own bugs.

Ask them if they wish to proceed and get the time/cost change *agreed
in writing*. Without agreement the change does not go ahead.

Right. If you can't time and can't steer, then you need a written agreement
that you will get paid no matter what happens.

As you get to the end of each phase give a detailed estimate for the
next phase only, and a rough estimate for the phase after.

That burdens a project with a design created with the least possible
understanding of the implementation issues. Driving a process with
speculative paperwork is like driving a car at night without headlights. You
don't know where you are, and if you miss your goal you'l spend a lot of
time recovering.

Allow more time for testing than you think you will need, at least two
run throughs of the entire test suite as well as user acceptance
testing.

Manual testing, after debugging, after implementing without tests is a very
efficient way to burn an incredible amount of money.

If tests accompany implementation, the bug rate is much lower, and the
software is much easier to change. That technique permits change requests to
drive the system, not trail it.

 

[Nick Malik]

jeez, Phlip,

that's a little harsh, don't you think?

I find Agile methods to be more effective than predictive methods. I'm
guessing that we are on the same page on that.
I also find that it is difficult to teach, or pursuade, when you are on the
attack.

The method that rossum describes is very common in consulting models,
because of the business practices of the employers, not because of
intentional misconduct, or even ignorance, on the part of the consultants.
Think about it... if a company tells you, in no uncertain terms, that they
want you to deliver a dung-heap, and your company agrees to deliver a
dung-heap, is it your fault that the final product doesn't smell good?

Some of the most avid advocates of agile methods are consultants, who are
finding that they are spending more time educating their clients than they
are developing software! (Perhaps that's because you can develop your
software in half the time using agile methods . It takes time to change
an industry.

And, to be fair, until the majority of agilists can come up with a way to
answer the following fundamental business question with a straight face,
agile methods will be hampered. I outlined a method for doing this in my
previous response on this thread.

The question is: "I'm deciding between 10 different priorities for my budget
for next year. I have a one-page description of each problem. How much
will each one cost, and how many resources will each one take?"

This is the business question that the original requester is trying to
answer. This is the question that rossum completely ducked, and the answer
that you attacked.

If you answer the question, first, you will gain the credibility that you
need to instruct and pursuade.

--- Nick Malik
Certified Scrum Master

 

[Phlip]

The question is: "I'm deciding between 10 different priorities for my budget
for next year. I have a one-page description of each problem. How much
will each one cost, and how many resources will each one take?"

No prob. You request the difference between selecting a direction and
targetting a destination.

Directions are safe to select up-front, and to schedule and budget
proactively. Destinations (such as Features A thru N before the Trade Show
in September) cannot be scheduled and budgetted up front. The features
require tracking.

 

[rossum]

On Sat, 10 Jul 2004 14:57:21 GMT, "Nick Malik"

[snip]

The method that rossum describes is very common in consulting models,
because of the business practices of the employers, not because of
intentional misconduct, or even ignorance, on the part of the consultants.

Well spotted Nick. If I don't get what I am delivering agreed in
writing then the company doesn't get paid and I don't get paid.


Philip wrote

Manual testing, after debugging, after implementing without tests is a very
efficient way to burn an incredible amount of money.

Very true for small scale module testing which is done "in line".
However I am not going to deliver a whole system to the users until it
has been well tested as a whole and I am reasonably sure that it works
well. Just because each subsystem passes all its own tests does not
mean that the whole thing is going to work together. I have seen too
many cases where different parts of the system pass their own tests
but the system as a whole does not work:

Server: "Come in unit number 1"
Unit: "I am unit number 32."
Server: "Come in unit number 1"
Unit: "I am unit number 32."
etc. ad infitum.

Both the server and the unit had passed their own tests. The problem
was only found when the whole system was tested. One tesm had set up
the server and a different team had set up the unit. Whole system
testing can only be done at the end when the whole system is
available.

rossum