Being the only project manager in a company comes with an unusual amount of freedom. There may be no PMO telling you which methodology to follow, no established templates to reuse, and no other project manager to ask how things are normally done. Basically, you get to decide what project management looks like.
Freedom, however, comes with some uncertainty: How do you know whether the processes you introduce are working? Without another PM or a playbook to compare against, it can be difficult to separate a useful practice from something that has simply become your routine.
You do not need to build an entire PMO to solve that problem. Instead, you need ways to test your approach, learn from each project, and gradually determine which practices deserve to become standard.
- 1. Solve the project problem first
- 2. Create a playbook you can build on
- 3. Look outside your company for reference points
- 4. Permit people to question your process
- 5. Use each project as evidence
- 6. Don’t measure maturity by the amount of process
- 7. Recognize when one PM is no longer enough
- Check your own PM practice
- Build your own reference point
1. Solve the project problem first
When nobody has established how projects should be managed, starting with a methodology can feel like the safest option. But before introducing templates, workflows, or recurring meetings, take a look at what is going wrong.
Consider what project problem the new process will solve. This helps you avoid importing practices from another organization simply because they worked there. A process designed for a large, highly regulated project may add unnecessary work to a small internal initiative.
| Try this: Before introducing a new process, complete the sentence: “We need this because…” If you cannot give a specific answer, reconsider whether the project needs it. |
2. Create a playbook you can build on
Think of your playbook as a living document. As the organization grows, priorities shift, or projects become larger and more complex, some practices may need to expand while others may no longer serve a purpose. What works for your projects today does not have to become a permanent rule.
Once something consistently helps, record it. You do not need to document every possible scenario from the start. Focus first on the practices you expect to repeat across projects.
This might include:
- How projects get approved and kicked off
- Where requirements are recorded
- How responsibilities are assigned
- How risks and issues are tracked
- Where project decisions are documented
- What stakeholders receive in a status update
- How lessons are captured after delivery
Start with these practices, then refine them as you learn what works. Which steps helped? Where did people need clarification? What did the team repeatedly have to work around? Finding patterns can show you which parts are worth keeping and which need another look. From there, use what you learn to update the playbook for the next project.
Your project management software can help turn those practices into something reusable. With monday.com, for example, you can save a board as a template and reuse its groups, columns, items, and other configured elements for future projects. Instead of rebuilding the same setup each time, you have a starting point you can keep adjusting as your playbook develops.
Visit monday3. Look outside your company for reference points
Being the only PM does not mean you have to make every decision from scratch. Before looking elsewhere, check whether your organization already has standard operating procedures, approval paths, reporting practices, or documentation rules that you can build from.
Using existing processes can make your project approach easier to adopt because the team already understands how the organization works. It can also reduce the amount of training required when you introduce a new process. If another team has already solved part of the problem, use that as a starting point rather than rebuilding it yourself.
Consider:
- What is this practice supposed to accomplish?
- Does this project need that level of control?
- What risk does it reduce?
- What happens if we do not use it?
- Could we accomplish the same thing more simply?
From there, external sources can help fill in what’s missing. Established project management standards, methodologies, professional communities, mentors, and former colleagues can give you additional reference points. The challenge is deciding which practices are worth adopting.
4. Permit people to question your process
One disadvantage of designing the process yourself is that your decisions can go unchallenged. The people using those processes, however, may have a different perspective. Asking for their feedback reveals whether your approach may need to change.
While feedback on a specific project is useful, you may also need someone who can challenge your broader project management decisions. A mentor, former colleague, professional community, or another PM outside your organization can provide that perspective when you have no internal peer to turn to.
| Tip: Workarounds are also useful cues. When several people keep bypassing the same process, it may indicate the process itself needs reconsideration rather than stricter enforcement. |
AI can also give you another way to pressure-test your thinking. ClickUp Brain, for example, works with information from your workspace, allowing you to summarize complex projects or use that context to examine a plan from another angle. For a solo PM, this lets you surface questions or issues before taking your approach to a stakeholder or outside peer.
Visit ClickUp5. Use each project as evidence
A successful project does not necessarily prove your process worked. The outcome tells you whether you delivered, but reviewing how you got there shows what is worth repeating. One example is capturing those patterns by conducting retrospectives.
After each project, ask:
Keep: What helped us deliver?
Change: What created unnecessary work or confusion?
Add: What did we realize we needed too late?
Those lessons can shape how you approach the next project, while each new experience gives you more evidence to draw from. Over time, your playbook will reflect the practices worth keeping and the ones that need to evolve.
6. Don’t measure maturity by the amount of process
As your playbook grows, another risk can creep in: processes may stay simply because they have become standard. More templates, reports, and approval workflows may create consistency, but they do not automatically lead to better project management.
The value of a process depends on what it contributes to the project. A decision log gives the team a reliable record of what was agreed, while documenting the same decision in several places creates extra work.
The same principle applies to escalation. Clear criteria help teams recognize when leadership needs to step in, but escalating minor issues can divert attention from problems that require more immediate action.
As your way of working evolves, revisit the processes in your playbook and ask: If I stopped doing this, what would happen? If removing one would increase confusion, introduce risk, or leave important decisions undocumented, keep it. If little would change, however, the process may no longer deserve a place in your workflow.
7. Recognize when one PM is no longer enough
Sometimes the problem is not how you manage projects. The volume of project work may have reached a point where one PM can no longer support it effectively. Reaching this point does not necessarily mean the organization needs a PMO. Depending on where the issues are, another project manager, a project coordinator, clearer portfolio priorities, or fewer simultaneous projects may provide the support you need.
Watch for recurring signs:
- Projects regularly compete for your attention.
- Teams depend on your availability before work can progress.
- Resource conflicts repeatedly require escalation.
- Project admin leaves less time for managing delivery.
- More projects need support than you can reasonably provide.
When you bring the issue to leadership, use your current workload to make the case. Show where projects compete for coverage, which activities are waiting for support, and how those constraints are affecting delivery.
Check your own PM practice
Without a PMO reviewing your approach, it helps to evaluate how you manage projects periodically.
| Ask yourself | If the answer is “no”… |
| Can I explain why each process exists? | Revisit the problem it is meant to solve. |
| Have I documented the practices worth repeating? | Start building a simple playbook. |
| Do I have outside reference points? | Compare your approach with established guidance and other PMs. |
| Does anyone challenge my approach? | Find people who will question your reasoning. |
| Do I know what has worked across projects? | Use retrospectives to identify patterns. |
| Can one PM still support the workload? | Document the gaps and discuss additional support. |
Build your own reference point
When you are the only project manager, you may never have someone sitting next to you who can confirm, “Yes, that’s how we do things here.” Over time, you become the person who establishes how projects are managed.
Even with that responsibility, you do not have to rely on instinct alone. By comparing your approach with established practices, gathering feedback from the people who use your processes, and carrying lessons from one project into the next, you can build a stronger reference point for your decisions.
Ultimately, no single approach will work for every project. What matters is understanding why you work the way you do, whether your approach is helping the project, and when the evidence tells you to change course.