Professional project management is no longer effective if projects are managed in isolation –project team makes all– or by managed by meetings or by reporting. Stakeholders need continuous collaboration to achieve the project management goals –on quality, scope, time, cost, etc. In this hyper connected world, continuous collaboration in projects means online collaboration to take informed decisions and propose actions proactively.
Our previous article All Projects in the world managed in one tool introduced the need for professional project management in the cloud, multi-role, multi-organization, etc. This article describes the different roles needed in professional project management, and how these roles can collaborate to manage projects, programs and portfolios.
Any tool aimed to unify professional project management for all projects should adapt features to different roles, so that peoplel can only access the right information when needed. This has been the biggest challenge we have faced at PMPeople, being these kind of functional requirements the source for most changes during this 3 years development project.
Professional project management roles can be separated in 2 sides:
- Demand Management: People who propose projects and monitor performance.
- Supply Management: People who use human and material resources to execute projects.
As explained in the article 10 Roles in Project Management, professional project management roles can be defined as follows:
- Stakeholder (SH): The people who may affect, be affected by, or perceive themselves to be affected by decisions, activities, or outcomes of projects.
- Requester (RQ): The people who ask for new projects. They work hard to get projects approved, follow progress and have great interest in completion.
- Sponsor (SP): The people who provide resources and support for the project, and are accountable for enabling success.
- Functional Manager (FM): The people with management authority over a Business Unit (BU). Any project should belong to one BU. Even when a project shares resources from different BUs, good practice is that one of them is identified as accountable.
- Project Management Office (PMO): The people who standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques.
- PMO Supportive (PMOS): The people who provide a consultative role and assist project managers in their day to day activity.
- Portfolio Manager (PfM): The people assigned by the performing organization to establish, balance, monitor, and control portfolio components in order to achieve strategic business objectives.
- Program Manager (PgM): The people authorized by the performing organization to lead the team or teams responsible for achieving program objectives.
- Team Members (TM): The people who support the project manager in performing the work of the project to achieve its objectives.
- Resource Manager (RM): The people who manage resource pools, being responsible for recruiting, professional career planning, training, incentive policies, managing leaves, absences, etc.
- Project Manager (PM): The people assigned by the performing organization to lead the team that is responsible for achieving the project objectives.
Let’s describe now how these different roles can collaborate in a projectized organization. In PMPeople we use the following table to summarize the main objects, and who can create, update or delete them.
For instance, the object project can be Created/Updated/Deleted (CUD) by a Functional Manager. However, a Portfolio Manager cannot create or delete, only update project information (Update = U). Project Managers can create and update but not delete (Create/Update = CU).
Let’s describe now some representative use cases.
Functional Manager (FM) owns of one or more Business units (BUs):
- FM can create a new BU.
- FM can set BU data. These data will be used from any project inside the BU, including: calendars, clients, phases, tags, cost categories and payment methods, project goals, etc.
- FM can create projects inside the BU.
- FM can assign the project Sponsor (SP) and the Project Manager (PM).
- FM can control a project by reading the information updated by PM (also by PMO, PMOS, PfM, PgM).
This screenshot shows some features accessible by FM on a given project:
Project Manager (PM) can manage his assigned projects, or those created by himself:
- PM can initiate the project: He can complete the project definition data, include the project into a program and/or portfolios, set the parameters to integrate the PPM tool with another tools, edit the business case, the project charter, the stakeholder register, etc.
- PM can assign the RQ (Requester), the SP (Sponsor), and one or more PMOS (PMO Supportive).
- Assigned PMOS can help PM manage the project.
- PM can plan the project: scope, deliverables, requirements, dates, reviews, milestones, costs, funding requirements, tasks, resource assignation, etc.
- PM can invite some stakeholders. Stakeholder Register may include some stakeholders who need online access using the tool. These people can oversight project just reading planning and control information.
- PM can set the project in execution state. Team Members can see their assignments, submit timesheets and expenses. At certain review dates, planned or not, PM controls project status by measuring deviations against baselines, writing explanations for stakeholders to read, managing changes, etc.
- PM can control resources, approving/rejecting timesheets and expenses, replanning tasks, effort hours, etc.
- Finally, PM can set the project to closing state. TMs are not able to incur effort nor expenses anymore.
- When closing is finished, PM can set the project to archived state. From then on, PM won’t be able to change project data (PMOS and PMO can set the project back to closing state if some change is needed).
This screenshot shows some features accessible by PM on a given project:
Resource Manager (RM) owns of one or more Resource Pools:
- RM can create a new Resource Pool to include Team Members (TM).
- Besides, a TM can join a Resource Pool proactively on his own.
- TMs need to belong to a Resource Pool to be assigned to a project by a PM.
- TM can join a project proactively on his own, he only needs a private project code.
- TM can see his work assignments on project in execution state. They can know who else is working in the same assignment, submit timesheets and expenses. They also can submit comments on the project to the PM, be it anonymously or not. They can submit data about their mood (anonymous) very useful for retrospectives.
- PM can control work hours and expenses coming from TMs, their progress on tasks, etc.
This screenshot shows some features accessible by RM on a given TM belonging to one of his pools:
This screenshot shows some features accessible by TM on a given project assignation:
Stakeholders (SH) can see the projects they have been invited to:
- SH can also join a project proactively if he knows the project private code. In the reverse, he can quit a project if no longer interested to follow.
- SH oversights projects reading some planning data and control updates.
- SH can submit comments on the project to the PM, anonymously or not.
- SH can request project changes to the PM.
This screenshot shows some features accessible by SH on a given project:
Requester (RQ) can create requests –internally managed as projects not yet approved, in initiation state:
- RQ can assign the PM, who could start managing the project initiation along with the RQ. Project state “initiating” is equivalent to request state “proposed”.
- RQ can also assign the project sponsor (SP).
- Once the project is approved, RQ can move request state from “proposed” to “in progress” or PM can move project state from “initiating” to “planning”. When planning is over, PM can move project state to “executing” –request state keeps “in progress”.
- RQ can read project control data.
- When the project is finished, RQ can move the request to “closed”. PM can do so moving the project to “closed/archived”.
This screenshot shows some features accessible by RQ on a given request/project:
Program Manager (PgM) can create programs:
- PgM can include projects to a program.
- PgM can help PM manage the project belonging to the program.
- PgM can submit comments and change requests to PM.
This screenshot shows some features accessible by PgM on a given program:
Portfolio Manager (PfM) can create portfolios:
- PfM can include projects to a portfolio.
- PfM can help PM manage the project belonging to the portfolio.
- PfM can submit comments and change requests to PM.
- PfM can include programs to a portfolio.
- PfM can help PgM manage the program belonging to the portfolio.
This screenshot shows some features accessible by PfM on a given portfolio:
Resource Manager (RM) can read feedback on Team Member performance for those TMs inside his pool:
- RM can set the evaluation criteria for TMs inside his pool.
- Using these criteria, the other roles can evaluate TM project performance.
- TM can read the feedback aimed to him or her.
- RM can read the feedback aimed to TM and also the feedback aimed to the management team.
Functional Manager (FM) can read feedback on project performance for those projects inside his Business Unit:
- FM can set the evaluation criteria for the projects inside his BU.
- Using these criteria, roles SH, RQ and SP can evaluate project performance.
- These feedback can be included into the project closure report, accessible by managing roles (PMO, PMOS, FM, PfM, PgM and PM).
There are many more interesting uses cases related to collaboration in professional project management. Just think about procurement relationships, status reporting, governance workflows, etc. Could there be any other subject more prone to professional collaborationthan projects?
