So much of this would depend on the budget, and size of the project. What works great for an enterprise site... is total overkill for a small project. Likewis

So much of this would depend on the budget, and size of the project. What works great for an enterprise site... is total overkill for a small project. Likewise... it's seldom one person, or even one team, that does everything end-to-end... so like... maybe your role is only to get to UAT, and their team will take over for security screening, performance testing, hardening, launch... Do we include what dev, design, devops, marketing, sales, legal teams all care about? I'm sure that's not even a complete list of teams... At an agency I worked for a few years back we had a sheet called "Getting to Done" -- looked something like this: * General Web Project Overview - Google Sheets || https://docs.google.com/spreadsheets/d/1rGSHT2kZQCahDqoQkryLJ1b3rEq_uVLEX2Qe10RCxB8/edit https://docs.google.com/spreadsheets/d/1rGSHT2kZQCahDqoQkryL... I've got a huge file on process, with sample documents... but every time I sit down to put it all together into something that can help new hires I hit a wall around who it needs to be written for. What size of company, what focus of the site, what department of the company, what role on the team...? I think the sample "technical alignment" document we used when taking over a web property was about 15 pages worth of questions... and we still had to verify all that stuff and look at the code and various metrics. Point being this stuff is all a learning process for everyone... best practices evolve, technology evolves, standards evolve... if you manage web projects it's more about ongoing learning rather than memorization / repetition.