Projects have been around forever. Since the beginning of history, people have organized themselves to turn ideas into reality. Challenging ideas as building a great pyramid, a great canal to connect oceans, a great wall, the first atomic bomb, a telescope to take pictures of big bang, a vaccine to save the world, etc. All these ideas came true thanks to projects.

Project management is a relatively young discipline. Over 50 years ago, experts agreed that operations management was not good at managing projects. New processes were needed to finish projects on time, on cost, delivering the value and meeting the business goals, and then to get the final product, service or result transitioned to day-to-day operations.

Regardless of the industry, all projects are expected to be initiated, planned, executed, controlled, and closed. World class expert professionals shared best practices to manage requirements, scope, time, cost, quality, resources, communications, risks, procurement, stakeholders, etc. Standardized process frameworks were released to manage projects. A discipline named project management began to differentiate and specialize.

Nowadays, ideas are more challenging and consequently, projects to turn them into reality are more and more complex. There are projects to make computers think better than us, to make computers extraordinarily fast, to drive without a driver, to fight climate emergency, to make fusion energy viable, to colonize Mars, etc. In these projects, hundreds of people are working simultaneously, in a coordinated manner, from distant places. Closer to us, in the companies we work for, projects are everywhere. Knowledge workers usually have several project meetings every day.

Today’s projects demand excellent management. Companies have to get projectified to beat the competition, expand into new markets, innovate, grow, etc. Poor project management can hurt companies (Bard case). Excellent project management can boost the stock market value (Microsoft).

Most of today’s projects require:

  • Rolling Wave Planning: Since requirements are not clear enough, the project scope has to be progressively elaborated, continuously interacting with stakeholders.
  • Beyond the Triple Constraint: Controlling changes, time and cost is less important than value delivery and meeting the business goals.
  • Real time Governance: Managers need to make informed real time decisions, anticipating issues while there are still options to correct project performance, and they don’t have time to read comprehensive documentation from dozens or hundreds of projects. PMOs are to be value driven.
  • Inclusive Project Management: Just one person to manage the whole project is not effective: collaboration is needed because the best solutions may come from one of many stakeholders. Nonprofessionals are to get involved in project management.

Now we can say that project management has changed from documents to outcomes, from processes to people. Clear evidence can be found in the newest edition of PMBOK, which is no longer based on processes but on principles and performance domains.

Professional project management is no longer effective if projects are managed in isolation—project team makes all—or managed by meetings or reporting. Stakeholders’ continuous collaboration is needed to achieve the project management goals, that is: delivering value on time, under budget, with the right quality, etc. In this digital hyper connected world, continuous collaboration in projects means online people collaboration to take informed decisions and propose actions proactively. Projects need this kind of distributed collaboration, especially.

Any tool aimed to unify professional project management for all projects should adapt features to different roles, so that people can only access the right information when needed. This has been the biggest challenge we have faced at PMPeople, being these kinds of functional requirements the source for most changes since we started development in 2015.

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 this article, professional project management roles can be defined as follows:

  • Stakeholder (SH): People who may affect, be affected by, or perceive themselves to be affected by decisions, activities, or outcomes of projects.
  • Requester (RQ): People who ask for new projects. They work hard to get projects approved, follow progress, and have great interest in completion.
  • Sponsor (SP): People who provide resources and support for the project and are accountable for enabling success.
  • Functional Manager (FM): 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): People who standardize the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques.
  • PM Assistant (PMA): People who provide a consultative role and assist project managers in their day to day activity.
  • Portfolio Manager (PfM): People assigned by the performing organization to establish, balance, monitor, and control portfolio components in order to achieve strategic business objectives.
  • Program Manager (PgM): People authorized by the performing organization to lead the team or teams responsible for achieving program objectives.
  • Team Members (TM): People who support the project manager in performing the work of the project to achieve its objectives.
  • Resource Manager (RM): People who manage resource pools, being responsible for recruiting, professional career planning, training, incentive policies, managing leaves, absences, etc.
  • Project Manager (PM): 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 some representative use cases in our tool PMPeople.

Functional Manager (FM) owns of one or more Business units (BUs):

  • FM can create a new BU.
  • FM can set BU data. This 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, PMA, PfM, PgM).

This screenshot shows some features accessible by FM on a given project:

Project Managers (PM) can manage their assigned projects, or those created by them:

  • 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 PMA (PM Assistant).
  • Assigned PMA 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 projects 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 (PMA 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 (anonymously) 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 in following.
  • 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 SHRQ and SP can evaluate project performance.
  • These feedback can be included into the project closure report, accessible by managing roles (PMO, PMA, 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 collaboration than projects?

PMPeople is the tool for the project economy. It is aimed to unify professional project management by these differential points:

  • Designed by and for professional project managers, following professional project management standards.
  • Online productivity –less meetings, less documents, less workflows– through distributed collaboration among 12 specialized roles: Organization Owner, 6 roles on demand management and 5 roles on supply management.
  • Freemium product –unlimited time, unlimited users– usable via web and mobile application.

Start using PMPeople for free, for unlimited time and for any number of users. In premium organizations, only managers have a cost. Several roles –stakeholders, team members, sponsors and resource managers– are always free. You can increase or decrease your premium seats according to the organization actual needs. Premium organizations have access to our interactive support through Slack. Our servers are located in EU. This software can also be hosted on customer premises.

Read this article in Spanish.