Setting Up Onplana for a Growing 10-50 Person PM Team

Here's the pattern every growing PM team hits. At five people, everyone knows the project naming convention because one person invented it last Tuesday. At fifteen, three naming conventions coexist and nobody notices. At thirty-five, a PM submits a project called "Q3 thing" while another calls the same customer engagement "Q3 Initiative - APAC (FINAL v2)." The tool didn't change. The team grew past the informal standards that were never written down.

The problem isn't team size. It's that the five configuration decisions that make a tool scale weren't made when the team was small enough for it to be easy. This walkthrough covers those five decisions, in order, for a PM team growing from 10 to 50 people.

TL;DR: A growing PM team needs five setup decisions made once and enforced in the tool: project templates (so every project starts from a consistent baseline), naming conventions (so any PM can find any project), role definitions (so permissions scale without manual exceptions), dashboard standards (so leadership sees a consistent view), and an onboarding playbook (so new PMs don't reinvent the standards). All five should be in place before the team reaches 15 people. After that threshold, retrofitting them is significantly more expensive than getting them right early.

The setup decisions that don't survive growth

There's a specific moment in every growing PM team's history where the informal arrangements that worked at five people stop working at fifteen. It usually shows up first in reporting: a leadership request for "the status of all active projects" produces ten different formatted responses, none using the same status vocabulary, some including tasks as milestones, others listing risks as blockers.

The configuration decisions below are not about turning Onplana into a bureaucracy. They're about encoding the decisions that the team is already making informally, so those decisions apply consistently across every new project and every new team member without anyone needing to explain them.

Make all five decisions before loading any projects. The cost of reconfiguring a 30-project portfolio after informal habits are established is much higher than making the decisions when the portfolio is still small.

Project templates: standardizing the starting point

A project template is the highest-leverage configuration decision for a growing PM team. A PM creating a project from a blank slate makes dozens of micro-decisions: which milestone types to include, which custom fields to populate, how to structure the task hierarchy, which resource roles to use as placeholders. Multiplied across every PM and every project, those micro-decisions produce a portfolio where no two projects look the same. ISO 21500, the international project management standard, emphasizes consistent process inputs and outputs across project types: templates are the practical implementation of that principle inside a project management tool.

A template collapses those decisions into a single choice made once: "What type of project is this?" Every project type that your team handles regularly should have a template. For a 10-50 person PM team, three to five templates is usually the right number:

• Infrastructure or IT project: Hardware and software milestones, IT-specific custom fields, technical and stakeholder resource roles.
• Business process project: Discovery, design, pilot, and rollout milestone structure, business-specific resource roles.
• External client delivery: Client-facing milestone structure, client stakeholder role placeholder, contract type field pre-set to "External."
• Compliance or audit project: Regulatory milestone types, mandatory documentation tasks, compliance officer resource role.
• Internal initiative: Lightweight milestone structure for projects that don't fit another category.

Each template should include the six required custom fields pre-configured (from the PMO configuration approach described in the 50-project PMO configuration walkthrough), the project naming convention with a prefix placeholder, and default resource role assignments. A PM should be able to create a new project from a template and have a usable starting point in under two minutes.

Naming conventions you can enforce inside the tool

A naming convention documented in a wiki page is a naming convention that will be followed by about 40% of the team, some of the time. A naming convention encoded as a required field prefix in the project creation template is a naming convention that will be followed by everyone, every time.

The pattern that scales from 10 to 50 people: [Type prefix]-[Area]-[Quarter]-[Sequence]

Examples:

• EXT-Finance-Q3-2026-003 (External client project, Finance area, Q3 2026, third project)
• INT-IT-Q4-2026-011 (Internal project, IT area, Q4 2026, eleventh)
• COM-Operations-Q1-2027-002 (Compliance project, Operations, Q1 2027, second)

The goal is that any stakeholder can read a project name and immediately know what type of project it is, which area it belongs to, and roughly when it closes. That eliminates the most common portfolio reporting confusion: projects with names that require a separate lookup to interpret.

Implement the convention in the project creation template as a text field with the prefix pre-populated and a placeholder instruction for the rest. Don't rely on team training alone. If the convention requires effort to apply, it will be inconsistently applied as soon as workload increases.

Role definitions that scale without manual exceptions

Role-based permissions are one of the most deferred configuration decisions for growing PM teams, usually because it doesn't feel urgent until the team reaches fifteen people and access requests start arriving faster than they can be processed.

Define four role levels before any team members join Onplana:

Viewer: Can see all project data in their assigned portfolios. Cannot edit tasks, resources, or schedules. Right for executives, sponsors, and stakeholders who need visibility but not edit access.

Contributor: Can update task status, log time, and add comments on assigned tasks. Cannot edit the schedule structure, resource assignments, or project-level fields. Right for individual contributors on project teams.

Project Manager: Can create and edit projects, manage schedules and resource assignments, update status, and advance governance gates. Right for named PMs responsible for delivery.

Portfolio Lead: Can configure custom fields, governance gate criteria, and portfolio settings. Can view and manage all projects within their portfolios. Right for PMO leads and senior PMs with portfolio accountability.

Assign roles to job functions, not individuals. When a new PM joins, they inherit the Project Manager role from their function, not a separate configuration request. When a contributor is promoted to PM, one role change updates all their permissions. Manual permission management per person doesn't scale past twenty people.

The diagram below shows the five setup decisions in sequence and the team-size threshold at which each becomes critical.

Dashboard standards your leadership can actually read

Dashboard standards matter more as the team grows because the audience for portfolio reporting expands. At five PMs, leadership might check in with the PMO lead directly. At thirty-five PMs, leadership needs a self-service view that doesn't require a conversation to interpret.

Three dashboard templates serve the full audience for a 10-50 person PM team:

Leadership portfolio view: Shows all active projects with RAG status, owning PM, portfolio, milestone health, and a days-since-last-update indicator. Executives use this to identify projects that need their attention without having to open any individual project. It should fit on one screen with no scrolling.

PM team operational view: Shows the same project list but adds resource loading, gate status, and open escalation flags. The PMO lead uses this as their working view to prepare for weekly PMO calls.

Individual project view: The schedule, open risks, milestone timeline, and resource loading for a single project. The PM works from this view daily and uses it as the basis for their weekly status update.

Don't let PMs build their own dashboards from scratch. A team of thirty-five people with thirty-five custom dashboards produces thirty-five different interpretations of what a healthy project looks like. Set the three templates as defaults, link them in the onboarding playbook, and permit custom personal views only after the standard templates are established.

For more on what PMO-level dashboards should show, and how the right dashboard architecture supports governance, see the PMO maturity tiers post, which covers the reporting structures that distinguish a Tier 2 from a Tier 3 or 4 PMO.

The onboarding playbook that makes setup stick

A configuration that exists in the tool but isn't documented in a discoverable onboarding resource will be partially overridden by every new PM who joins and can't find it. Within six months, you'll have half the team following the standard configuration and half following their own interpretation of it.

An onboarding playbook for a growing PM team needs five sections:

1. Project templates: Which template to use for which type of project, with one worked example per template type.
2. Naming convention: The pattern with three to five examples. The field in the tool pre-populates the prefix; the playbook explains how to fill in the rest.
3. Role assignment: Which Onplana role corresponds to which job function, and who to contact to request a role change.
4. Dashboard navigation: Which dashboard to use for which audience, where to find the three standard templates, and how to create a personal view if needed.
5. Questions and escalations: Who to ask when something isn't covered, and where to submit a configuration change request.

The playbook should live in Onplana's built-in wiki, linked from the organization settings page so it's discoverable without being told where to look. A playbook that requires someone to tell you it exists is a playbook that won't be found by new team members joining on their first day.

What to configure in week one versus month one

Not all five decisions carry equal urgency. Some gaps become visible within days; others don't matter until the team has grown further.

Week one (before the first new PM uses the tool):

• Portfolio structure: Create the top-level and second-level portfolios before anyone creates projects.
• Naming convention: Set the template prefix field and the naming pattern before the first project is created.
• Role definitions: Assign roles to every existing team member before adding new ones.

Week two to four:

• Project templates: Build one template per project type. Start with the two most common project types if you can't finish all five in week one.
• Dashboard standards: Set the three standard dashboard templates and make them visible to the full team.

Month one:

• Onboarding playbook: Write and publish the five-section playbook in the wiki.
• PMO maturity check: Run the PMO Maturity Assessment to identify governance gaps that template configuration alone won't address.

The temptation is to configure everything perfectly before letting anyone use the tool. Resist it. A partial configuration that gets used is better than a perfect configuration that's still being built when the team needs the tool today. Set the naming convention and portfolio structure in week one, and iterate on the rest.

The Onplana pricing page covers the plan tiers relevant to growing PM teams, including what's available on the Professional plan for teams of 10-50 and what unlocks at the Enterprise plan as portfolio scale and governance requirements increase.

Run the free PMO Maturity Assessment The 15-minute assessment identifies the governance and process gaps that tool configuration can fix and the ones that require a process change. Useful before and after initial setup. No signup required. Open the PMO Maturity Assessment