The project manager is the person accountable for getting a software project from inception to delivery -- on time, within budget, and to the agreed scope. It sounds straightforward. In practice, it requires juggling competing priorities, managing human dynamics, navigating uncertainty, and making dozens of decisions daily with incomplete information. At Pepla, project managers work across our Orange, Green, and Blue development teams, coordinating complex multi-team deliveries for clients ranging from startups to enterprises.
The PM in Agile vs Waterfall
The project manager's role looks fundamentally different depending on the delivery methodology, and most real-world projects use a hybrid approach that borrows from both.
In waterfall, the PM is the central control point. They create a detailed plan upfront, define milestones, manage a sequential flow through phases (requirements, design, development, testing, deployment), and measure progress against the original plan. Change is managed through formal change control processes. The PM's authority is clear, and the plan is the primary coordination mechanism.
In agile, the PM's role is less prescriptive but no less important. The team self-organises around sprint goals, the Product Owner sets priorities, and the Scrum Master facilitates ceremonies. So what does the PM do? They manage the project-level concerns that exist above individual sprints: budget tracking, vendor coordination, cross-team dependencies, stakeholder communication, risk management, and programme-level planning. They ensure the agile team has the resources, environment, and organisational support they need to deliver.
In many organisations, particularly those running multiple agile teams on a single programme, the PM role is essential for coordination that no individual team can handle. They manage the big picture while the teams manage the sprints. At Pepla, our PMs coordinate across development teams, manage client relationships, and handle the commercial and operational dimensions of delivery that sit outside the development team's scope.
Project Planning: WBS, Gantt, and Critical Path
Planning is where the PM earns their keep. Not because plans survive contact with reality unchanged -- they never do -- but because the act of planning forces the team to think through dependencies, identify risks, and establish a shared understanding of what needs to happen.
The Work Breakdown Structure (WBS) decomposes the project into manageable pieces. It is a hierarchical tree that starts with the project's major deliverables and breaks them down into progressively smaller work packages. A well-structured WBS ensures nothing is forgotten, provides a basis for estimation, and creates clear accountability -- every work package has an owner.
The Gantt chart maps the WBS against time. Each work package becomes a bar on a timeline, showing when it starts, when it finishes, and how it relates to other tasks. Dependencies between tasks are shown as links -- task B cannot start until task A is complete. Resource assignments show who is responsible for each task and reveal overallocation (when someone is assigned to more work than they can handle in a given period).
The WBS, Gantt chart, and critical path analysis force the team to think through dependencies before they become surprises mid-project.
The critical path is the longest sequence of dependent tasks through the project. It determines the earliest possible completion date. Any delay to a task on the critical path delays the entire project by the same amount. Understanding the critical path tells the PM where to focus attention and where buffer exists. Tasks not on the critical path have "float" -- they can slip without affecting the end date, up to a point.
Even in agile projects, these tools have value. A high-level Gantt chart showing epic-level timelines, major milestones, and external dependencies helps stakeholders understand the project's trajectory without requiring them to understand sprint mechanics.
Plans never survive contact with reality unchanged -- but the act of planning forces you to think through dependencies, risks, and accountability.
Risk Management
Risk management is not a one-time exercise completed during project initiation and filed away. It is an ongoing discipline that the PM practices throughout the project lifecycle.
The process starts with risk identification: systematically listing things that could go wrong. Technical risks (the chosen technology might not perform at scale), resource risks (a key developer might leave), external risks (a third-party API might change), scope risks (requirements might be more complex than estimated), and commercial risks (the client's budget might be reduced). The PM facilitates risk identification sessions with the team, because the people doing the work often see risks that management cannot.
Risk assessment evaluates each risk on two dimensions: probability (how likely is it to occur?) and impact (how bad would it be if it did?). The combination produces a risk priority. High-probability, high-impact risks demand immediate attention. Low-probability, low-impact risks are monitored but not actively managed.
For each significant risk, the PM defines a response strategy. Avoid the risk by changing the plan to eliminate it. Mitigate the risk by taking action to reduce its probability or impact. Transfer the risk to another party (insurance, contractual terms, third-party services). Accept the risk when the cost of mitigation exceeds the expected impact.
The best project managers are not the ones who avoid all risks. They are the ones who identify risks early, communicate them clearly, and have a plan ready when they materialise.
At Pepla, every project maintains a risk register that is reviewed weekly. Risks are added, reassessed, and closed as the project evolves. This discipline prevents the common failure of being blindsided by risks that were foreseeable.
Budget Tracking
Software projects are expensive, and one of the PM's most important accountability areas is financial management. This goes beyond simply tracking how much has been spent. It involves forecasting, variance analysis, and proactive intervention when the budget is under pressure.
Earned Value Management (EVM) provides a structured approach. It compares the planned value (what should have been done by now), the earned value (what has actually been done), and the actual cost (what was spent to do it). The Schedule Performance Index (SPI) reveals whether the project is ahead of or behind schedule. The Cost Performance Index (CPI) reveals whether the project is under or over budget. An SPI or CPI below 1.0 is a warning signal that requires investigation.
In agile projects, budget tracking often operates at the team level rather than the task level. If the team costs a certain amount per sprint and you know the number of sprints remaining, you have a rolling budget forecast. When scope changes, the PM translates the impact into budget terms so stakeholders can make informed trade-off decisions: "Adding this feature will require approximately two additional sprints, which is an additional cost of X."
The PM also manages contingency. A well-planned project includes a budget reserve -- typically 10-20% depending on the level of uncertainty. The PM controls access to this reserve and uses it judiciously when risks materialise or scope changes are unavoidable.
Delivering bad news early with analysis and options is always better than delivering it late with excuses. No surprises is the PM's golden rule.
Vendor Management
Few software projects exist in isolation. Most involve third-party vendors -- cloud providers, SaaS platforms, integration partners, subcontractors, licensing providers. The PM manages these relationships, which involves procurement, contract management, performance monitoring, and issue resolution.
Effective vendor management starts with clear contracts. Scope of work, deliverables, timelines, acceptance criteria, payment terms, and penalties for non-performance should all be documented before work begins. The PM ensures these contracts protect the client's interests without being so adversarial that they poison the working relationship.
During the project, the PM monitors vendor performance against commitments, escalates issues that are not being resolved at the working level, and manages the commercial implications of vendor delays or failures. When a critical API vendor misses their delivery date, the PM assesses the impact on the project timeline, activates contingency plans, and communicates the situation to stakeholders with options rather than problems.
Status Reporting and Stakeholder Communication
Stakeholder communication is where many PMs spend the largest portion of their time, and rightly so. A project that is executing perfectly but failing to communicate its progress will be perceived as failing. A project that is struggling but communicating transparently will receive the support it needs.
Effective status reporting follows several principles. Frequency should match the stakeholder's needs -- weekly for active sponsors, fortnightly for steering committees, monthly for executive portfolios. Format should be consistent, enabling stakeholders to compare reports across periods and projects. Content should lead with status (green/amber/red), summarise achievements, flag risks and issues, and state what is needed from the audience.
The most important communication skill for a PM is managing expectations proactively. Delivering bad news early, with analysis and options, is always better than delivering it late with excuses. At Pepla, our PMs follow the principle of "no surprises" -- if a project is trending towards a deadline miss or budget overrun, stakeholders hear about it as soon as the trend is identified, not when the deadline arrives.
PM Certifications
Two certifications dominate the project management profession, and they represent different philosophies.
The Project Management Professional (PMP) from the Project Management Institute is the global standard. It covers predictive (waterfall), agile, and hybrid approaches. The PMP requires documented project management experience, a 35-hour education programme, and a rigorous exam. It signals comprehensive knowledge of project management principles and is widely recognised across industries.
The PRINCE2 (Projects IN Controlled Environments) certification, managed by Axelos, is process-based and particularly popular in the UK, Europe, and South Africa. PRINCE2 defines a structured project lifecycle with clear roles, processes, and themes. It comes in Foundation (knowledge) and Practitioner (application) levels. PRINCE2 is prescriptive about process but agnostic about delivery approach, making it compatible with agile methods.
Other relevant certifications include PMI-ACP (Agile Certified Practitioner) for PMs working primarily in agile environments, CAPM (Certified Associate in Project Management) as an entry-level credential, and SAFe Program Consultant (SPC) for PMs working in scaled agile environments.
Effective vendor management starts with clear contracts. Scope, deliverables, timelines, and acceptance criteria must be documented before work begins.
Certifications provide a common language and demonstrate commitment to the profession. But they are a foundation, not a substitute for experience. The best project managers we work with at Pepla combine certified knowledge with the practical wisdom that comes from navigating real projects with real constraints and real stakeholders.
