It might be obvious, but I am not sure.

Should the analyst who interview the client, gather and analyse requirements then give an estimate, also specifies how many and with how much experience developers should be required to develop it?

Maybe I'am not so sure on how I go about this allocation thing, maybe this is just not my work.

closed as primarily opinion-based by durron597, user53019, user40980, user22815, Dan Pichelman Jul 6 '15 at 13:01


  • As a clarification, I won't necessarily will lead the project. But, I still must say that given project will need, for instance, a senior dev and two junior devs. The allocation is entirely done by management. – Tulio F. Dec 3 '12 at 13:27
  • It isn't clear from the description but it sounds like you are responsible for giving a price quote. If you are, then I don't see how you can't give your assumed team makeup. More senior team members get billed at higher rates than less experienced team members. That fact alone, means that the team makeup must at least be guesstimated. – Dunk Dec 3 '12 at 16:53
  • I just get the requirements and estimate the effort, then I need to allocate which roles(i.e. 1 senior dev and 2 juniors) that will work. Not who but which roles. The guys from the commercial gives the quotes. – Tulio F. Dec 3 '12 at 17:55

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.

  • I can only recommend some programmers, but in the end it goes to the unallocated devs. – Tulio F. Dec 3 '12 at 13:24
  • 1
    I'am giving the right answer as the second paragraph describes how it should work from now on. While talking with my manager a couple of hours ago, we agreed that the analyst won't tell how many people will work on the project, management along with program managers will do. – Tulio F. Dec 3 '12 at 18:01
  • Hah, that age has passed? Try telling that to some parts of the industry... please. No really, will you please tell them, we're dying here! – Jimmy Hoffa Dec 3 '12 at 23:13

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.
