A BA should act as PM (sometimes)

In our environment, in order to maintain quality of the project and make sure communication is flowing to the right people, the BA needs to step forward and own the PM space. Doing the requirements piece is essential and is a first step; the information then needs to flow downstream to all the other parties in IT. The BA is at the forefront of this endeavor. If the BA stops there and expects the PM to take care of the flow of communication, the project more than likely will come to a grinding halt; either that or it will start to flounder. The BA should either work hand-in-hand with a PM who does take ownership and is vitally interested in delivery of the project OR the BA should own this piece as well and ensure that the right people are playing their parts & on time; thus the BA is acting as PM.

The benefit of having a BA act as PM on his/her own project is that since the BA is present at the inception of the project, s/he has interacted with end-users and felt their pain, needs, requirements, etc. from a first hand basis. This makes the BA a representative of the business and the BA can really strive for what is important. The BA playing a PM role can stress the right areas to focus on in the short-term and push off the less important items. A separate, detached PM may not take these things into account, especially if s/he is not as invested in the project. In fact, having a PM involved at the outset may be too much overhead.

The beginning of the project is very vital. A BA/PM can push for a working first iteration of the software that does the most important things first; the initial software will have limited functionality and the BA/PM can even act as an initial QA resource, vetting the design and construction of the software as it progresses by doing quick checks of functionality; and in order to make sure the software is aligned with the original vision. The BA in fact is in a most unique position, especially at the beginning of a software project, because s/he can play those 3 roles: BA/PM/QA and the reason should be blazingly clear; The BA is the one who feels the client's pain and will do his/her damnedest to make sure that the client is being given what they need (if you're a conscientious BA that is)

As the project progresses, matures and gets more intricate, there will have been some momentum built and other dedicated resources can be brought in to handle specific areas of the project: a dedicated PM, junior BAs, dedicated QA, etc.