Not the TV show, though there are times I feel like I'm living in an episode of it.

I'm curious about what the rest of you have experienced when it comes to managing the number of users performing configuration, table uploads, and developing reports and what controls/best practices you have established to minimize them adversely impacting each other.

How many is too many ?  We have three people involved in a large scale configuration effort.  Three people creating a lot of ad hoc type reporting.  Two people actively uploading files during the month, and two others generally floating in/out of all of the above activities.   

Logic and the powers of observation tell me that's too many.   We have too many active workspaces, too many documents checked out, too many branches, too many calculations competing for horsepower. etc.  All of which lead to new headaches every day.

Let's hear from other large shop veterans.   How do you keep order from turning into chaos ?

WOW! that is a lot of brainpower working on admin tasks. This is a topic I have ask about many times, so happy to have a dialog here.

Based on your comments I assume you're in R12. I'm in R11 which is more restricted but the principles are still the same regardless of the platform you're in. This is fairly new for us too. We went form one TBMA to three in a short time, and we're working on R12 migration as we speak.

We have three people doing configuration work and the same three people loading data.

1. Data loading takes precedent over configuration work every month during business days 6-8. During those three days no one does configuration work unless it is critical. All resources are focused on loading data and meeting our SLA
2. Every day we hold a standup 15 minutes meeting to share what each TBMA plan to work on that day, priorities, questions on approach, . . .
3. We strive towards constant, frequent, detailed dialog between the three TBMAs so that they all have intimate knowledge of the model, how things are build, and are capable to jump in as needed to respond to questions, and resolve incidents
4. We maintain a manual queue of enhancements requests with priorities assigned to each. We re-visit it once per week. This document is published to our corporate web page
5. Recently we have documented a test script that is completed (by another analyst) when we load data and every time we promote code to production. The results are published to our corporate web page

This is obviously work in progress, and I can't wait to hear suggestions and questions from people to keep improving this.

On the question of how many is too many. Because of the effort required for people to know what others are doing, I can not see how having more than three people would still be productive. It's all about finding an effective way to share, and absorb knowledge.