JustMarie (11/5/2015)
One company I was at went to project level deployment in 2012. While the use of variables for data connections and parameters and such were really helpful there are some other considerations.If you have multiple packages in a project then you have to deploy all or none of the changes. So working on two packages at the same time means you can roadblock one while working on the other. It's a big thing to take into consideration.
The other thing (and this may have been resolved but I doubt it) is the permission needed to read the catalog reports. In the version of 2012 we were using you needed full permissions to the catalog database to read reports. You couldn't grant a read access at all. This was bad. The suggested resolution was to make SSRS reports into the catalog.
On the upside the DBAs made PowerShell scripts to do the 90 day data center cutovers a piece of cake. And the reuse of data sources was nice.
I have read that all of your concerns are addressed in 2016. That permissions thing is a bit 'all or nothing' and not very refined.
But regarding your 'working on two packages at the same time' comment, I don't agree. Packages should be deployed from a 'production' source control branch. Half-finished development work should not be checked into that branch.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.