MrCo,

You make a great point! 

Many organizations do opt for the business analyst to be involved with the project until the end - and that can be a good thing! 

The problem arises when the BA is allocated 100% until the end of the project.  This is because it is a waste of valuable resource to have a business analyst dedicated to the project even if there is not business analysis related activities for them to work on.  Of course, this also depends on the size of the project.

What worked for me in the past project was dependent on the type of the project, the size of the project, and the number of business analysts available.

SMALL PROJECTS: On smaller projects, there might only be one business analyst and he/she might be full time during the duration of the analysis phase.  After that we usually allocate a smaller capacity % during development and QA for the analyst to be able to answer and clarify requirements and specs for the Dev/QA teams.  In that case the business analyst might also begin work on other projects working on the Inception phase where they might not yet be needed full time.

LARGER PROJECTS: On larger projects, where multiple business analysts are needed, we would allocate analysts as needed: start with one or two analysts, ramp up to a larger team during the analysis team, and then scale back down to one or two analysts during the development, coding, and deployment.  Once the bulk of the analysis has been completed, it is also a good practice to perhaps not keep any analyst full time in a support role or they will get tired of it and leave.  I like to allocate at most 50% with the remaining capacity having the BA work on other projects in parallel.  This keeps up the moral, allows more analysts to get involved in more projects, reduces risk, and provides a method of utilizing the business analyst on other projects when there is no work for them to do while their previous project winds down.  Of course, the manager must have the type of mentality needed to look out for the good of the analyst or the team of analysts.

AGILE PROJECTS: On agile project teams, it is feasible that the analyst would be involved until the end of the project because of the iterative nature of agile methods.  In this case there would not be one big analysis phase followed by one big dev/qa phase.  As soon as the agile business analyst completes their analysis tasks for one iteration they would move to the requirements/featured identified for the next iteration.

What do you guys think?

- Adrian

This is an insufficient answer. If a BA is hired on to write requirements and then sent away their job is completed at the handover of the artefact.  In realiity projects who release the BA once the requirements are signed off usually run into trouble (unless they are small/simple initiaitives.)

A BA should be on the project through to (and preferable past) implementation.  I'd love to quote research on the topic, but can't recall any off the top of my head.  I do believe the journal of project management or PMI have some info on dedicated teams versus shared teams - dedicated gets better results.