Erik Eckel makes the case for why consultants should assign group rights to server shares, and then assign users to groups.
How it happens
I'm guessing a novice consultant, pressed for time or potentially overwhelmed with other client responsibilities, works quickly to create a new folder. Maybe the client is requesting a new file share to enable collaboration among accountants or marketing staff.
Based on complex, undocumented, and massively failed file share structures my consulting office occasionally inherits, I know what ends up happening. Rather than taking time to properly configure file shares and architect the appropriate group and corresponding user memberships, the consultant just adds Jane Smith and John Doe (the users the client requested have access to the new folder) to the new server share.
That'd be all fine and good if life stopped there, but it doesn't.
The real world
Two months later a new subsidiary is launched, and only Jane is supposed to have access to the subsidiary folder. So, while likely remotely addressing another server issue, the consultant might remotely connect to this client's server, quickly add a new folder, and extend Jane permissions to that folder.
A few weeks go by and a similar task occurs for John. Then a few more months pass, and a few more shares are added in like fashion for Jane, a new user named Jill, and a volunteer named David. Maybe a few service calls arise to switch a few permissions around. Typically these tasks are completed on the fly to enable quickly closing a trouble ticket queue that's getting out of hand.
At one point the client wants some users in the marketing department to access accounting files, but to be safe, the client doesn't want that department to be able to change accounting's files. The marketing employees are given read-only access.
Jane ends up transferring from the accounting organization to the sales team. She stays a few months and then leaves the organization. Her replacement, Donna, only hangs around for a few weeks. The short-lived Donna is replaced by Robert.
And then the real trouble arises. It's discovered that David, the volunteer, can see sensitive donor information only Jill is supposed to see. Robert, meanwhile, can't access new files Donna created. Oh, and Mike, a user who has been logging in as Donna because he couldn't access files he needed, and Donna was the only person who could, can access some files but can't edit them. Then John leaves the organization. That's when you're called in as the new consultant to sort out the mess.
"Just give Dan, John's replacement, the same permission John had," the client says.
Fun stuff. And what permissions does John have? No one knows. You'll lose quite a bit of time reverse-engineering just which server shares John can access and which permissions he actually possesses to each share. By the time you're done, you'll be cursing the previous consultant.
Avoid becoming an offender
Consultants -- because they frequently work within incredibly demanding and rapidly changing environments in which clients routinely pelt them with extraneous requests and sometimes don't take time to document through dedicated internal HR and IT teams user access rights -- must take particular care to follow best business practices. By assigning users to groups and assigning groups permissions to server shares, it becomes much easier to administer, configure, and troubleshoot permissions issues.
If the original consultant in the above example had followed such practices, it would be simple to know to which folders Dan should receive permissions. It's easy -- just look at John's group memberships and mimic those for Dan.
But when individual users are given permissions -- particularly varying permissions -- directly to server shares, unless meticulous records are kept (and they never are, and even if they were the client would misplace them), access rights nightmares are inevitable. Consultants should assign group rights to server shares, and then assign users to groups.