The Criticality of Scaffolding Out Documentation
You're a project manager, coordinator, QA or a lead. Whatever your role or title, you're helping to steer the ship and leading by example, with or without authority. You're just making it happen. One of the most important things you can do for the success of a longer-term project is Documentation. Yes. Where information goes to die. Or that's what they say. Don't believe them.
If you've got a codebase, it deserves a readme. If it's hosted on GitHub you get a fantastic Wiki alongside the repo for free. If you're using Jira, it integrates perfectly with Confluence. Whatever it is. You can also just spin up a folder in the code or design source and let it live alongside. It really doesn't matter, it just needs to exist.
Everyone thinks it's someone else's job or something we can do later. The problem with Just In Time documentation is you're only looking for it when it's needed and then it's too late. So build it in from day one. Before you even kick off the project with the team. Pick your tool and start stubbing out the topics. You know you will need a quick list of resources. You know that the team will need quick access to stakeholder contact info.
Have a culture of capture. If it's not in the project tracker or the documentation, it doesn't exist. You run meetings, use moments of ambiguities or questioning to remind people "Oh, yes, that's captured in the wiki", "sounds like something we should spin up a new page for", "you can do a wiki sweep if you're not sure where to start". Etc.
Plant the seeds and the team will water them. Just remember to pull weeds and tend to the garden.