I think you need to be more specific in what you're asking.

Once a project has been selected (depending on who holds the purse strings), management will usually select some sort of broad resource plan for the whole project, deciding how many programmers/designers/artists/etc will work on the project, and at which stages in the project lifetime.

The project is often divided up into milestones, which act as checkpoints to verify that the project is being delivered as expected and on time. Less formal projects might have a handful of milestones, whereas big publisher-funded projects often have a formal milestone delivery process where the build is explicitly handed over every so often (monthly, or six-weekly, or quarterly, etc) to be assessed.

Each milestone typically has a bunch of intended 'deliverables' - they are ideally working features, but can also be assets that may or may not yet be integrated into a feature. And there can be different expectations for the state of a deliverable (e.g. "prototype", "working", "finished", etc). The actual state of those deliverables, relative to what was promised, dictates whether the milestone is 'passed' or 'failed'. In the latter case the team is usually expected to fix up those failed deliverables before the next milestone is handed over. If you keep failing milestones, the publisher may terminate the project, as they lose confidence in your ability to complete it.

Scheduling within a milestone is usually done via some sort of agile planning process. With a given set of deliverables in mind, the heads of each department and the project management team ("producers") come up with a list of prioritised tasks and decide who to allocate them to. Those people receive the task descriptions and implement them.

The day-to-day work of each person depends entirely on their job and their task. There may be a 'daily standup' meeting or Scrum where people briefly discuss what they're working on and ask for help if they're stuck. Beyond that, they communicate via conversation/meetings/email/Slack to resolve ambiguities and discuss details. The rest of the time, they're probably at their computer, executing their current task by creating code, art, whatever.

Also note that you are talking about massive projects.  AAA games these days are hitting 9-figure costs. "Big" games are hitting $50M and more. It is sometimes easier to forget about that. Today's AAA project's total cost is becoming more easily measured as a fraction of billions rather than millions of dollars.

While there are many steps that are common, there is much that is unique and different about each project.  Much like other enormous projects there are similarities between projects but none are identical.  Creating enormous skyscrapers or airports or major buildings have many steps in common, but each has unique building schedules and procedures.  Building a large road network or rail infrastructure has many steps in common with similar projects, but each is quite unique. 

Individual teams have common elements that they do every day, as described.  Many of those are common between everything; teams who create code, teams who create models, teams who create animations, teams who create object designs. But the questions regarding broad schedules and executive tasks over the entire projects, those elements are quite unique to each.  The biggest publishers have somewhat refined their processes, but they mostly only bear superficial similarities at that level.

On 1/15/2018 at 8:32 PM, Matthew Birdzell said:

Is there a standard practice to how AAA production works?

In my experience, no. Every studio has its 'way' and many studios even have more than one process, and these processes may change over time.

There are some common concepts, but most of them you'd acquire running your way up through other lower-entry positions.

I'm afraid there's just no dumbing down the work a studio of 200-500 heads working for years does. Some work agile, others don't, and in both ends of the spectrum, there are quite a few different ways to make things work, starting with spreadsheet lists of tasks in cubicles to cardboard boards on the wall (and everything in-between and more!)

Edit: And I believe 'knowing how a studio operates' may be much less relevant to landing a job there than having an open mind about how to operate, and being able to adapt to change on a whim.

Exactly, every team is different, and the person who runs the team might want it done a certain way, and that's how many games have been made.

While I do agree that every team is different, at a high level you can find enough similarities to be able to describe production cycles and functions.

I explained the production cycle on a post in my blog, check it out http://leonardperez.net/game-production-cycle/

If you are interested, I also desbcribe the producer role in detail in this post: http://leonardperez.net/what-exactly-is-a-producer/

Hope it helps!

Leonard