Back to Blog
Management FrameworksProject EconomyTools

PMPeople: The tool for the Agile PMO

By  Jose Barato

June 25, 2020

11 minutes read

Digital transformation is affecting Project Management Offices. Project management organizations see how their projects grow exponentially, but their team doesn’t grow. Overnight, senior managers authorize projects with a high technological component, involve the organization as a whole, but requirements are not clear. Project steering committees ask for status reports, risk reports, cost forecasts, etc. Project managers ask for resources, methodological guidance, etc. Teams ask for agile courses, coaches, collaborative workspaces, tools, etc. Many business representatives still see agile as a passing fad , only applicable to software projects, etc.

At this point, the corporate PMO knows that the way to manage adaptive projects should not be predictive, but agile. Any Agile PMO will try to implement certain paradigms:

    • Projects should be value driven better than planned driven.

    • Business representatives should be engaged to provide continuous feedback.

    • Business analysis professionals need to focus on “what”. Development team need to focus on “how to”.

    • The PMO should not centralize project management because it would become a bottleneck. It should not introduce bureaucracy or approval workflows. The PMO must achieve more with less.

    • The PMO should encourage distributed project management models: project managers, program managers, portfolio managers, functional managers, resource managers, etc., should share project management from their respective knowledge areas, so that the PMO can focus their work better.

    • Coordination among multiple teams should be done following certain agile scaling frameworks like SAFe, DA, LeSS, etc.

PMPeople tool does not avoid the necessary agile face to face collaboration within teams, participation in the different ceremonies, the use of other tools to communicate, information radiation, virtual boards, etc. PMPeople facilitates all the collaboration among people involved in project management, accessing with the mobile application or via the Web, enhancing value orientation and eliminating waste. PMPeople also facilitates agile scaling when large teams need to collaborate.

Thanks to PMPeople, the PMO can go from being a bottleneck, to a facilitating unit that delivers more value projects successfully, faster and cheaper.

Agile Project Management

Agile frameworks do not mention the role of the project manager because they were designed for product management, not project management. However, the PM role is required when the organization approves a project that must be completed within a certain period of time and below a certain budget. Professional PMs are responsible, among other things, for the agile project to end on time and on budget, meeting stakeholders’ requirements. In predictive projects –those which follow a waterfall lifecycle– most requirements can be agreed beforehand. If requirements are set, we can set the scope to estimate cost, schedule, etc., and finally we can get a detailed project plan, which can be used as a baseline to compare actual performance so that we can take corrective actions to meet the project management goals. PMBOK® Guide divide project management into 5 process groups, which can overlap in time, although for simplicity they are presented in a sequential order:
    • Initiating Process Group: The organization debates whether the project must be done or not. If so, the sponsor approves it and signs a document called the project charter.
    • Planning Process Group: A project management plan is developed by the project management team develops, with the help of experts. The project plan will serve as a reference to execute and control the project. Some predictive projects practice progressive elaboration planning, that is, the plan is being versioned as better information is known, but normally the project plan is quite stable, as is usually the case in engineering or construction projects.
    • Executing and Controlling Process Groups: These two groups are connected. Executing group is designed to execute the plan. Controlling group aims to periodically monitor performance, taking corrective actions if needed to meet the project management goals.
    • Closing Process Group: Once all the deliverables have been accepted by the client, formal closing is followed, and product, service or result is transitioned to the requesting organization.
PMPeople uses the above states initiating, planning, executing and closing –executing includes controlling. In predictive projects, closing means that the final product is transitioned to the customer.
Agile projects do not distinguish a separate planning phase. Since requirements are not clear, continuous iteration with stakeholders is needed to progressively discover value. The execution phase is divided into time boxes called releases, which usually last about 3 months. At the end of each release, a product that will be used by the stakeholders is transferred.
Features included in a release are progressively elaborated. Each release is broken down into other time boxes called iterations, usually taking 2 weeks. At the end of each iteration, in a face to face meeting, the development team demonstrates the features to stakeholders, who provide immediate feedback. Agile follows an iterative-incremental lifecycle:
    • Iterative: meaning feedback is received at regular intervals.
    • Incremental: meaning that the product is elaborated like the layers of an onion, first the heart with the most important features and then the successive less important layers.
    • The product grows with new features while refining the ones already built. In each demonstration, a potentially shippable product is shown. If the release is cancelled any time, a working product could be delivered.
Normally, a release has about 5 iterations. The last iteration, called iteration H –hardening- is not aimed to produce more features, it is aimed to formal closing procedures and technical deployment to production environments. In agile projects, project planning is usually done the other way around than in a predictive project. In a predictive project, requirements are elaborated first, in order to set the project scope. Later on, we plan schedule and cost, etc., producing finally the project plan. A management model based on planning is followed.
On the contrary, in an agile project, we can set the timeframe the business can wait to have the product done, let’s say 18 months, for instance. We can easily calculate the cost for a stable agile team of 8 people, for example. On the other hand, we need to estimate scope progressively, with the continuous engagements of stakeholders. We follow a value driven project management model. The agile project will fail if the stakeholders do not get along –they do not attend to demonstrations or refinements meetings, they do not resolve impediments, etc. The Agile PM must know in depth how you work on an agile project: roles, ceremonies, artifacts, etc. You must be a servant leader, promote value orientation, etc. Tools and techniques depend on the agile framework used. Scrum agile teams have the following roles:
    • Product Owner (PO) is responsible for maximizing the value of the product resulting from work of the DT. The PO is the sole person responsible for managing the Product Backlog, which is a prioritized list of requirements (user stories, features, epics, etc).
    • Development Team (DT) consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each iteration. DT shows a Product Increment at the iteration review. Only DT members create the Increment. DT members break features down into technical tasks and manage them in the Iteration Backlog. They self-organize to deliver value at the end of each iteration.
    • Agile Coach (CO): is responsible for promoting and supporting agile methods as defined, helping everyone understand theory, practices, rules, and values. The CO is a servant-leader for the DT, helping everyone understand which of their interactions with the DT are helpful and which aren’t, and helping change these interactions to maximize the value created by the DT.
    • Customers (CU): are the stakeholders that must provide directions to get the value. They are considered to be part of the agile team, but their level of commitment is lower.
SAFe agile teams have between 5-11 Team Members.

PMPeople for Agile Projects

In PMPeople, any PM can create a project inside a Business Unit (BU). Although the project has not yet been formally approved by the organization, PM can initiate the project entering the definition data, the summary of the business case, the project charter, the extended team and the stakeholder register:
Project team members are shown in INITIATION > Project Team:
PM can assign DT members in PLAN > Plan Resources > Assign Team Members:
PM can assign PO and CO as Team Members if needed. If PO and CO are to help project management, they can be assigned as PMO Supportive. Project Stakeholders can be assigned in INITIATION > Stakeholder Register:
PM can register all stakeholder data in stakeholder register, and also he can decide if he or she can enter the project using the tool. Stakeholders themselves can join proactively a project if they know the project private code:
PM and PO can plan different releases as work packages in PLAN > Plan Scope:
Each release typically includes 3–7 iterations. An iteration can last between 1–4 weeks. Iteration duration is fixed throughout the release. Project schedule for a team can be viewed as a succession of releases:
Releases can be modeled in PMPeople as the lowest level of the agile project schedule. PM and PO can model features as requirements or deliverables inside each release. Task management tools like Asana or Jira can be connected to PMPeople to manage agile artifacts such as Product Backlog, Release Backlog, Iteration Backlog, Parking Lot, Information Radiators, etc. If needed, PM can plan hourly rate and planned hours for each Team Member at each release, start and finish dates, etc. PM can calculate the estimate cost per iteration –burn rate- in order to plan the estimate cost for each release, to produce the cost baseline or S-curve. PM can control project cost following the EVM standard:
Regarding project monitoring and controlling, at each review date, the PM can record the Global Status Report of the Project so that it can be consulted by other Stakeholders:
The PM can manage project costs from a financial accountant perspective. Funding accounts can be managed as positive or negative cash flows:
In each review date, PM can control actual costs vs. planned, also the planned vs. actual dates for incomes and expenses:
In each review date, PM can produce a funding forecast to communicate his best estimate at the end of the project:
PM can register and control risks, assumptions and issues in the section LOGS:
PM can review the comments coming from the TMs –some of them anonymous– in the option Team Comments:
Agile Coaches can access with the role PMO Supportive to review the happiness index commented by the team members in a period of the project, which is extremely useful for retrospectives, in the option LOGS > Happiness Index:
If some lesson is learned regarding project management, the PM can register it in CLOSING > Lessons Learned Register:
In their day to day, DT members will mainly use low-tech tools or, if not co-located, task management tools like Asana, Jira, etc. PMPeople can save TMs a lot of time, though. Team Members can know how they are assigned to each release:
TMs can know who their teammates are:
Any TM can update the Team Charter:
Any TM can communicate comments to the PM, anonymously if needed:
Any TM can comment his or her happiness index, anonymously:
Last, but not least, if TMs need to report time sheets and expenses, typical waste, PMPeople allows them to do this very effectively via Web, or even better, using the mobile application.

PMPeople for Big Agile Teams

As proposed in SAFe to scale the work done by several agile teams when they need to build a product, a synchronization is needed among team increments at the end of each iteration, summing up in what is called a Program Increment (PI). Usually, each PI consists of 5 iterations, each iteration taking 2 weeks.
A program can deliver a product by coordinating several projects:
The resulting large team summing up the different agile teams, is called Agile Release Train (ART), including from 50 to 125 Team Members.
In PMPeople, a Program Manager can set a program to manage the development of a product. The easiest way to add projects to a program is using the private project code:
The different agile teams work as described above. In addition, they must coordinate with each other to deliver the PI. Scaling up we can have enterprise solutions involving several ARTs and also external suppliers. Portfolio Managers can include projects and programs in their portfolios. Outsourced projects can be managed via procurement management:
Key aspects in portfolio management are: prioritization, financial analysis, business cases, capacity management, etc. Team Members usually get organized in Communities of Practice (CoP), Centers of Excellence (CoE), etc. All these functions can be properly developed using PMPeople.

Related posts