Roles and permissions in project management
People with very different roles work on a project: whoever runs it, whoever directs it from above, whoever does the work and, sometimes, whoever only needs to see how it is going. Giving everyone the same screen is a mistake in both directions: either the consultant sees costs and communications that are not theirs, or management has to ask for an emailed report to know how the portfolio is doing. PjMan solves this with roles that decide what each person sees and what they can do, on every screen and in every action.
Two ideas: account role and team role
PjMan separates two things that are often mixed up:
- The account role decides what you can do in the application. PM: manages the organisation and creates and runs their projects. Consultant/Developer: works on the tasks and issues assigned to them. Whoever registers is a PM; whoever accepts an invitation is a Consultant/Developer.
- The team role is a person's part in a specific project (Director, Team Leader, PM, Consultant, Developer) and carries a level from 1 to 3. What really matters is level 1-2 versus level 3: levels 1 and 2 (management and leadership) see the whole project read-only; level 3 (execution) sees only what is assigned to them.
There are also team roles marked "whole organisation", such as the CEO: whoever has one sees all the projects in the organisation without having to be on each one's team. Team roles can be extended with your own. (Roles and access, Team roles)
What each one sees and can do
| Owning PM | Management (level 1-2) and CEO | Consultant/Developer | |
|---|---|---|---|
| Project | Creates, edits and deletes it | Sees all of it, read-only | Does not see all of it |
| Phases and tasks | Creates, edits, assigns | Sees them | Only their tasks |
| Task status and progress | Yes | No | Yes, on their own |
| Hours | Logs their own and anyone's on the team | Only if assigned | Only their own, on what is assigned |
| Risks, change requests, expenses, contacts | Manages them | Sees them | No access |
| Issues | Manages them | Sees and creates them | Sees their own and creates those tied to their work |
| Reports and Queries | Yes, of their projects | Only "whole organisation" management | No |
| My work | Yes | Yes | Yes: their home screen |
The full table, screen by screen, is in the help. (Roles and access)
The owning PM
Each project has one owning PM: the only person who can modify it (edit it, manage phases, tasks, risks, changes, expenses, team and assignments). It is the principle that a PM neither sees nor modifies another PM's projects, even if they share an organisation. If the project changes hands, the owner or a Team Leader on the project can reassign the PM. (Project team)
Management and organisation-wide visibility
Management needs to see without touching. A Director or Team Leader on the project sees all of it read-only, with the team and hourly rates, and can create issues to flag what they notice. A "whole organisation" member has an organisation panel with all the projects and their progress, plus Reports and Queries across the whole portfolio, always read-only. A CEO can read comments but not post them. (Organisation members, Reports and queries)
Consultants and developers: only what is theirs
A person with an execution role logs into PjMan and sees My work: their assigned tasks and issues, their hours on a calendar and the minutes they have created. They do not see the whole project, nor contacts, nor communications, nor costs. They can change the status and progress of their tasks, log hours in their own name, comment on the items they see and move their cards on the Kanban board. This protects the client and the PM, and leaves the consultant free of noise. (My work)
People with and without an account
Not everyone who works on a project has to have an account. A person without an account exists as a name: they can have tasks and hours, which the PM keeps, and they do not log in. When someone needs access, the PM invites them and the person accepts with their email. One account can belong to several organisations, with a selector in the header. (People, Invitations)
The assistant respects roles
The AI assistant does for you what your role allows, nothing more: it opens no new access. If a consultant asks it for something only a PM can do, it does not do it and explains why. Actions that change data go through the same rules as the screens. (AI voice assistant)
Permissions checked where it matters
Permissions are not just hidden buttons. They are checked on the server in every action: if a consultant tries to open another person's project address by hand, they see nothing and are told they have no access. Each organisation is isolated from the others.
Try it
Create your account, create a project, invite a person as a consultant and check what each one sees. Or explore the demo, with sample data.
Keep reading
- Reports and queries · Features
- Issues, risks and changes · Features
- AI voice assistant · Features
- ERP implementation · Project types
Updated 2026-10-26