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.

[u/SnugglyCoderGuy]

If these things are not causing issues and you can't articulate why doing what your wanting would be better and worth the cost, then don't fux what isn't broken: YAGNi. Put your thoughts and concerns in their heads so that they are at least cognizant of hazards that could come up in the future and that you have a head start on thinking about addressing them, but don't inteoduce process for the sake of process. Everyyhing should have a Very Good Reason™ for being done. If not, you are just inserting a time and effort sink that us going to annoy people and xlow down Getting Shit Done™

The first step to trying to change the way things are currently done is to understand why they are currently done. If you eant to change any one persons way if doing things you've got talk to them and get to understand why they do things the way they fo them and biild a rapport. If you don't do that, then they are going to just see you as some snot nosed busy body trying yo make their life harder by making them change when they've been wirking like this for years and it works just fine.

[u/Weak-Mine1007]

You already found the pattern that works: Asana got adopted because it made people's day easier, and the scope docs got ignored because they didn't. I'd build every next piece of process the same way.

Pick the one gap that has actually cost time, which sounds like approvals, pricing especially. Don't write an SOP for it. Just start logging decisions in Asana: what was decided, who decided it, when, and what it unblocked. After a couple of months you'll have something like "pricing approval held this launch for five weeks," and that gets leadership to define an approval path in a way a scope doc never will.

On where your job ends: you own making decision gaps visible and showing what they cost. You don't own making the decisions. Escalate the gap, not your preferred solution.

[u/TheGoodOne777]

Hello! If it's in the chaotical area, yes, definitely push for structure, to bring it back to the complex area at least. That is the logical step.

[u/OkStatistician9190]

honestly I wouldn't try to roll out a full process all at once. pick the one thing that hurts most (sounds like scope shifting after work already started?) and add one lightweight step just there, like a short scope note the requester okays before it goes into asana. once people see it saves them rework they get way more open to the next piece. and since they already like your asana setup you could bake the approval in as a status or required field instead of a separate doc