Software Project Management
A dedicated project manager who owns scope, schedule, risk and communication — so your build stops running on hope
Software project management is the discipline that keeps a build on scope, on schedule and visible. It is not status meetings. It is a single accountable person who decides what gets built next, protects the team from thrash, escalates risk before it becomes a delay, and gives you a report you can act on. Projects rarely fail in one dramatic moment — they fail through many small decisions nobody was tracking.
In short
- A named project manager accountable for scope, schedule, budget and risk — one person you call, not a shared inbox.
- Fixed cadence: two-week sprints, a demo at the end of each, and a written status report you can forward to your board.
- Formal change control. Every scope change is priced and its schedule impact stated before it is accepted, so "just one more thing" stops being free.
- Risks tracked, not discovered. A live RAID log with owners and mitigation, reviewed every sprint.
- Works with your team or ours — including managing a third-party supplier on your behalf.
A Single Accountable Owner
One named manager responsible for delivery. When something slips, you know exactly who is answering for it and what they are doing about it.
Predictable Cadence
Two-week sprints with a planned scope, a working demo at the end, and velocity tracked over time so estimates get more accurate rather than more optimistic.
Change Control That Holds
Scope changes are documented, priced, and their effect on the deadline stated before approval. Scope creep is the single most common cause of software overruns.
Reporting You Can Use
A written status report each sprint: what shipped, what slipped and why, budget consumed, and the decisions we need from you this week.
What a Project Manager Actually Does on Your Project
Project management is often billed vaguely. This is the specific work, and how you can tell it is happening.
| Responsibility | The actual work | How you see it |
|---|---|---|
| Scope ownership | Maintaining the backlog, defining sprint scope, and refusing work that has not been through change control. | A prioritised backlog you can inspect at any time |
| Schedule management | Tracking velocity, forecasting completion from real throughput rather than wishful thinking, and flagging slippage early. | A burndown chart and a forecast completion date that updates every sprint |
| Risk management | Maintaining a RAID log — risks, assumptions, issues, dependencies — each with an owner and a mitigation. | A RAID log reviewed with you every sprint |
| Quality gates | Ensuring nothing is called "done" until it meets its acceptance criteria and has passed QA. | A definition of done applied consistently, not selectively |
| Stakeholder communication | Translating between business and engineering, running demos, and chasing the decisions that block the team. | A written sprint report and a live demo every two weeks |
| Dependency management | Coordinating third parties — payment gateways, hosting, ERP vendors, app store reviews — before they become the critical path. | External dependencies tracked with dates, not assumed |
| Budget tracking | Monitoring effort consumed against effort estimated, per module, with an early warning when a module is running hot. | Budget consumed vs remaining, reported each sprint |
If your project is small enough that this overhead outweighs the benefit, we will say so. Formal project management earns its cost on multi-month, multi-person, multi-stakeholder work — not on a two-week task.
Engagement Models
Managing Our Delivery Team
You commission a build from us and a dedicated PM runs it — the default on every project of meaningful size.
Embedded With Your Team
Your developers, our project manager. Useful when you have engineering capacity but no delivery discipline.
Managing a Third-Party Supplier
We hold your existing vendor to scope, schedule and quality on your behalf — with the technical depth to know when an excuse is not a reason.
Project Recovery
A short, intensive engagement on a project that has already gone wrong: establish real status, re-baseline, and get it back to predictable.
What You Receive Every Sprint
- Sprint plan — the committed scope for the next two weeks, agreed with you before work starts.
- Working demo — running software at the end of every sprint, not screenshots or a progress percentage.
- Written status report — shipped, slipped, why, budget consumed, and the decisions needed from you.
- Updated RAID log — risks, assumptions, issues and dependencies, each with an owner and a next action.
- Burndown and forecast — a completion date derived from actual velocity, updated honestly even when the news is bad.
- Change register — every approved scope change with its cost and schedule impact, so the final invoice never surprises anyone.
How We Start
- Project audit — for existing projects: real status, real remaining scope, and the gap between the two. For new projects: scope, constraints and success criteria.
- Baseline — an agreed backlog, an agreed definition of done, and a forecast schedule everyone has actually signed up to.
- Tooling setup — a shared board with real-time visibility, so you never have to ask "where are we" in an email.
- Cadence begins — sprint planning, daily coordination inside the team, demo and report at the end of each sprint.
- Continuous risk review — the RAID log reviewed every sprint, with escalation to you before an issue becomes a delay.
- Closure — handover documentation, a lessons-learned review, and a support transition plan rather than a silent end.
Frequently Asked Questions
Do I really need a project manager on a software build?
On anything short and single-developer, no. On a multi-month build with more than one engineer and more than one stakeholder, the absence of one is usually why it is late. The manager is not overhead on that kind of project — they are the reason the overhead stays visible and controllable.
Can you manage a development team we already have?
Yes. Embedded project management is a common engagement. Your engineers keep building; our PM owns backlog, cadence, risk and reporting. It is often the fastest way to fix a team that is productive but chaotic.
Can you manage another agency on our behalf?
Yes, and it is one of the more valuable things we do. We hold the supplier to scope, schedule and quality with enough technical depth to review what they deliver rather than accept it on trust. We are direct about it: this occasionally makes us unpopular with the supplier.
Which methodology do you use — Agile or Waterfall?
Primarily Scrum with two-week sprints, because it surfaces problems early. Where a client needs fixed-scope contracting or regulatory documentation, we use a hybrid: an up-front specification and phase gates, with Agile execution inside each phase. We fit the method to the contract, not the other way round.
How do you handle scope changes?
Through formal change control. The change is written down, its effort is estimated, its impact on the deadline and budget is stated, and you approve or decline it before any work happens. Nothing gets absorbed silently — that is how projects quietly overrun.
What tools will we be working in?
A shared board you can access at any time. We commonly use Jira or our ERPNext project module, and we can work inside your existing tooling if you already have a standard. The important thing is that status is visible to you without asking, not which product it lives in.
Our project is already late and over budget. Can you help?
That is exactly what a project recovery engagement is for. We start by establishing real status rather than reported status — those are usually different — then re-baseline scope and schedule and get the project back to predictable delivery. We will also tell you honestly if the right decision is to stop.
Put Someone Accountable on Your Project
Free project review call — including an honest read on projects already in trouble
