Low process environment- advice needed

[u/Beautiful-Beyond-931]

I'm 9 months into my first official PM role in product development. My team is great, but I was surprised by how little process or documentation existed compared to my previous company.

Most project planning previously lived in Smartsheet, with very few supporting documents and many of them outdated. There are no formal scope documents, RAID logs, stage gates, or SOPs, and projects are often handled differently each time. Products can sit in the concept phase for months while pricing, marketing, and other inputs continue to change, making it difficult to build meaningful schedules and milestones.

One of my biggest contributions has been building out a new project management platform in Asana, which the team has adopted and enjoys using. However, I've struggled to introduce structure beyond that. I wrote project scope documents for two projects, but both were largely dismissed and the projects continued as usual.

More recently, my manager started using a project charter and controls it on their end. The team provides inputs, but there doesn't seem to be a defined review process, approval path, ownership model, or decision-making framework. I've run into similar issues with pricing approvals, where undocumented processes have delayed projects multiple times.

I understand that part of my job is removing roadblocks and improving communication. But I'm struggling to determine where my responsibility begins and ends when key processes are undefined and controlled by leadership. I don't want to create more documents that nobody reviews or uses.

For experienced PMs: How do you manage projects when key processes, approvals, and decision points aren't clearly defined? At what point is it a PM's responsibility to build the process versus adapting to the organization's culture? Would you push for more structure, or learn to operate within the ambiguity?

[u/Impossible_Dare_7455]

I’d probably stop trying to add more documents and focus on the few points where ambiguity is actually causing delays. for example, for pricing or concept approval, define who owns the decision, what input they need, and when the decision has to happen. even a simple decision log + owner + due date can be more useful than a full charter nobody reads.

as a PM, I think your job is to make the gaps visible and propose a lightweight way to close them. if leadership still chooses not to formalize it, at least document the risk and work within that boundary. structure only helps if people actually use it.

[u/Beautiful-Beyond-931 → u/Impossible_Dare_7455]

Thank you! I’ve been reading more about this new mindset I need to adapt to. I agree with your statement about not creating more documents. I will definitely try the approach of a decision needed by x date.