There are many ways to handle user authentication with the system. The authentication can take place at a per project, per company/client account or at a user account level. The pros and cons of each method will be discussed below.
One account per project
In this scenario, every time you want to create a project, you need to enter a new set of credentials. Although you may use the same combination of email/username and password for each one, you will also need a unique way to link these to the project, which means you need to remember the project ID or some vanity URL. The advantage of this is you can keep separate projects totally isolated from each other, so work and personal projects do not get in the way of each other.
Even if you had a nice, easy to remember vanity URL, as soon as you have more then one or two projects, keeping track of all the URLs would not be easy, so you’d have to bookmark them, which results in a loss of portability in most cases, which is one of the key benefits of a web app. On the plus side, as you can have a separate set of credentials for each project, you can have notifications from different projects going to different email addresses.
On the whole, this method seems to be more hassle then it’s worth, and it’s possible to get the same benefits to an extent with the following method.
One account per company/client
In this scenario, you will have one or more accounts, which can have the same set of credentials or different. So you may have an account for work which groups all your work related projects together, then you may have a personal account which groups all your personal projects together and so on. This greatly reduces the number of accounts in total, which makes it much more feasible to have vanity URLs. You still have the clear divide between work projects and personal projects. The one downside is if you end up with a large number of accounts, your resources get spread across multiple accounts, which makes finding what you need a little more effort.
One global account
In this scenario, you only have a single account which houses all your projects. This has the benefit of everything being in one place and only one set of login credentials to remember. It also removes the need to remember any special URLs. Even with this method, there is still the need to have company/client accounts, but it would be possible to select which one you want once you login to your master account. It would also make it much easier to switch between ‘accounts’ as they’re all in one place.
Conclusion
The benefits of the 3rd method exceed those of the first 2 and it still provides the separation of accounts within the master account. The master account is just an entry point into the system, as oppose to a replacement for multiple company/client accounts.
I personally would lean toward the single global account and then provide some form of tabbed navigation to swap between projects.
As mentioned this would require uses to only remember a single username/password. A lot of user’s do good to remember one, I don’t think it would be good to make them have multiple accounts.
The way to handle customer accounts and such would be to implement user roles and then throw in invitations. Anyone can create an account, be they are extremely limited to what they can do unless they create their own project, or are invited to participate in another. The customer could create their own account and then the PM send them an invite and set their role, or the PM could create a user for them. The user role/groups would perform the same way as users, moderators, and admins in a forum. You can have a group that is nothing but clients, they have access to certain aspects of the site, can pick around a little, but thats it (mainly just viewing, no editing and such). Then you have active members in the project which have access to what they are doing and their tasks. Finally you have the PM who has primary control of the project and all associated members.
Just my opinion on it.