If your organization isn’t very big, then you won’t have enough programmers to choose from and you should give the work to the programmer who is least busy. They can tell you if an assignment is beyond their technical abilities or their ability to meet the artificial deadline you have probably set for them.

If your organization is big enough that you have lots of programmers to choose from, then the programmers probably have a more or less formal management structure and you should leave the decision of who does what work to that management. The team leads and seniors know who can do what and who is busy and who isn’t.

As for giving estimates, I think the days of analysts sitting between users and programmers and making all of the design and project management decisions have passed. If you want the people doing the work and the people paying for the work to own the decisions you need to put them face to face and let them work together. This is what Agile is supposed to be about.

At best I would think the analyst can make recommendations on team makeup if there is no team currently, but whoever the Developer Manager/Lead is should be making the decision based on the velocity (or other metric of tracking) of the people he is working with. This assumes that there is already a working development organization in the company.

In the case of a company (that happens to have an analyst but no Software Organization?!) I should think the Analyst can at most suggest what the starting makeup of the team should be and I should think that very soon they hire senior level developer that can take a lead role and help the Analyst get back to their job rather than try to manage a bunch of developers.

At least in my 25 years of development I never saw a Business Analyst or Software Analyst leading the Software Development team. I have run into cases where they offered their opinion on team makeup but in this day and age of Agile Software Development Life-cycle being more or less normal, I haven’t seen this the case. I also don’t recall this being a part of the hefty ITIL process, but I would have to check to be sure.

This is something of a difficult problem that you face in consulting – you need to give a rough cost to get a contract signed before allocating resources. There just isn’t a great answer to a lot of these problems, but here’s a few tips:

1) You might want to first attack the problem by ‘breaking it down’ into smaller tasks that you can have a chance at estimating. Something like “I need to create a billing system, which will require that I have a database, a login feature, a list of current invoices, a way to edit a single invoice, a way to approve an invoice for payment, etc., etc.)

The smaller pieces you can define, the better chance you’ll have at producing a reliable estimate.

2) See if you can’t shoehorn a dev or two (buy her lunch!) into giving some advice – even at a high level you can define a “large” task, a “small” task, etc. Try to break the “large” tasks down even further if you can.

3) Now if you have a rough number in mind (think large chunks here – “this might be XXX days of work”), then you can think about resource assignment.

But to echo an earlier comment – I’ve never seen an ‘analyst’ ultimately responsible for estimation and resource assignment; to come up with a reliable estimate you do need someone with enough experience (and preferably a track record of actually tracking “estimates vs. results”) to know what amount of effort certain tasks might take. (Again, preferably the opinions of “more than one” of these people.)

The problem is similar to me planning a house building project: I can draft a bunch of back of the envelope projections, but at some point I’m going to have to get the opinion of a carpenter who actually builds houses.