Wow! As someone with a foot in the IT world and a foot in the user world, your alternative method is the most logical, common sense strategy I have heard in a long time. I have lost count of the times I have had to try to translate a programmer's question so that the user had even the vaguest idea of what the question was asking.

You missed the user's question - sort of. He wanted to know how many people he needed to do a project of a given complexity. You appeared to answer the follow-up question - how long it will take those people. Does Function Point Analysis give you both - along with the assumptions about technical skill? If not, it doesn't do much good because people required is related to time allocated and knowledge base. I can do a project of almost any magnitude myself - if you can wait for me to learn the requisite technology and do it. (And I live long enough to see it through to the end ;-).

Here's what I don't understand. The client hasn't made their business case, and yet a project exists anyway! Justification, budgeting, approvals, all have been bypassed. Business theory says this shouldn't even be possible.

My point is, why doesn't the client get tagged with the Function Point Analysis? It consistently falls to the IT folks to do the hard work, and when the answer is "no--that's too expensive/too difficult/outside our mandate/the payback isn't there/fails strategic analysis", then IT is painted as the bad guy.

This is all said when I've lived through this stuff too. Of course the answer is politics, but that doesn't give you a plan of action.

So here's what I suggest: use a political comeback. Say, "IT supports the business. We'll sign on when you have made your business case, received budget approval, and completed a Function Point Analysis."

That last point alone will have them running to Wikipedia to figure out what an FPA is!

That still doesn't answer the question! The user has already bypassed the normal procedures and in a small company, that's SOP (standard operating procedure).

Here's what I would suggest. Take a look at Steve McConnell's books, especially Rapid Development and Code Complete. There's a section on project estimation in one of them (I don't remember which one, so go down to the bookstore to browse through them). He has a few rules of thumb for how to go about estimating project length and manpower. You might also want to take a look at Agile Software Development. They have some fairly good estimation practices that are very similar to what was used in a group that I used to work in at Honeywell. Scott Ambler's web site is a good starting point: http://www.ambysoft.com/

In a small company, politics is everything. Telling someone that they have to do A, B and C before you will talk to them will not make friends or get the work done. Also, most users do not understand IT well enough to do the analysis. Do the work with them and you will make a new friend/ally and teach them how to work with IT. Sit down with the user and explain that you need several hours of his time to go over the requirements before you do anything. Once you have enough detail, go back to the user with a project breakdown that shows estimated completion dates. Make sure the user identifies which are requirements are essential and which are nice-to-have.

There are no shortcuts in project estimation. Experience is usually the best guide, so if you have no experience in the area, talk to someone who has handled something similar. That's one good way to get started. That way you can go to the user and say "I talked to a friend of mine who did a project just like this and it took X weeks/months with Y programmers and they had these problems."