What Is Project Management
Project management is the work of turning an intention into a delivered thing, on a date somebody can rely on. Most of the discipline is about making that date honest rather than optimistic.
A working definition
Project management is the practice of organising people, work and time so that something specific gets finished by a date that can be trusted. Every part of that sentence carries weight: specific, because unbounded work is not a project; finished, because activity is not delivery; and trusted, because a date nobody believes is just a wish with a calendar entry.
What separates a project from ordinary ongoing work is that it has a defined outcome and an end. Running a support desk is not a project. Migrating that support desk to a new platform is.
Five things every project has to get right
Methods differ enormously. What they are all trying to solve does not.
What's being delivered, and, more usefully, what isn't. Most projects fail slowly through additions that each seemed small. Written scope is what makes an addition a visible decision rather than an invisible one.
What has to happen before what. Dependencies are where schedules actually break: the work was fine, but it waited three days for a review that nobody knew was the bottleneck.
Who is available, for how long, allowing for leave, holidays and the other projects they are on. Planning against headcount rather than availability is the single most common cause of a plan that was wrong on day one.
What is genuinely done, as distinct from what is nearly done. “Ninety percent complete” is the most expensive phrase in project management, because the last ten percent routinely takes as long as the first ninety.
Everyone who needs to know something knowing it, without the project manager becoming a human message bus. Where this fails, meetings fill the gap, which is why status meetings multiply in troubled projects.
A plan is only useful if bad news travels quickly. Cultures that punish a slipped date get told about slips later, which is precisely when the information is worthless.
The main methods, without the jargon
Waterfall
Plan the whole thing up front, then execute in sequence: requirements, design, build, test, release. It works when requirements genuinely are known in advance and change is expensive: construction, regulated hardware, some infrastructure. It fails when you learn something halfway that invalidates the plan, because there's no cheap way to respond.
Agile, Scrum and sprints
Work in short fixed cycles (typically one to three weeks), delivering something usable each time and re-planning based on what you learned. Scrum is the most common formalisation: a backlog of work, a sprint commitment, a review at the end. Its real advantage isn't speed but feedback: you find out you were wrong in two weeks instead of six months.
Kanban
No fixed cycles. Work flows across a board, and each column has a limit on how many items it may hold at once. Those work-in-progress limits are the whole point: they force a team to finish things before starting new ones, which is counter-intuitive and reliably increases throughput.
What most teams actually run
A hybrid, and that is fine. A common and sensible arrangement is Kanban with WIP limits for continuous work, sprints where a delivery commitment is needed, and a roadmap over the top for people who need to see months rather than weeks. The method matters far less than whether the board tells the truth.
How to tell whether yours is working
Certifications and ceremonies are poor indicators. These questions are better, because each has a factual answer:
- Can you find out the status of any project without asking a person?
- When something slips, do you learn weeks early or on the due date?
- Does the team know what it is meant to be doing today without a meeting to establish it?
- When someone is blocked, is there a route to unblock them that is faster than waiting?
- Do you know what a delivered project actually cost in hours?
- Does the board match reality closely enough that you would plan from it?
A "no" to the last one makes the others moot. A tracker that people update as an afterthought produces metrics that measure diligence at updating trackers.
Estimates, forecasts, and the difference
An estimate is a person's judgement about how long something will take. It's systematically optimistic, a well-documented and remarkably durable human trait, because people estimate the work they can imagine, not the interruptions, reviews and rework they can't.
A forecast is a projection from measured throughput: how much this team has actually completed per cycle, applied to what remains. It requires no optimism and no discipline from anyone, because it's arithmetic on history.
This is why teams that track how much they complete per sprint predict delivery far better than teams that re-estimate more carefully. If you change one thing about how your projects are run, measure your real completion rate and forecast from it.
The overhead problem
There's a trap worth naming, because it undoes a lot of well-intentioned process. Every mechanism above (status, capacity, progress, communication) can be implemented by asking people to report on their work. Do enough of that and the reporting becomes the job.
Four hours a week per person is a normal figure once you total up status meetings, "any update?" messages and chasing timesheets. On a fifteen-person team at ₹60,000 a month, that is on the order of ₹90,000 a month spent on the administration of work rather than the work.
The way out isn't less visibility. It's getting the same information as a by-product of the work itself: status from where a card sits rather than a field someone updates, hours from a five-second log next to the task, forecasts from measured velocity, and blockers raised in one tap instead of a meeting. That's the principle ShipSprint is built on, right down to that five-second log, and it's worth applying whatever tool you actually use.
Common questions
They need the outcomes, not the ceremony. Below about five people, a shared board and an honest weekly look at it is usually sufficient. The pressure arrives when no single person can hold the whole picture in their head, typically somewhere between ten and twenty people, and it arrives faster in a services business juggling several clients.
At its best: removing obstacles, protecting scope, and making sure the right people have the information they need. At its worst: manually collecting status and reformatting it for someone more senior. The second is the part that good tooling should eliminate.
No. The vocabulary differs (campaigns in marketing, candidate pipelines in HR, recurring processes in operations), but scope, sequence, capacity, progress and communication apply identically. Methods that came out of software, particularly Kanban, transfer to other departments with very little translation.
One board that reflects reality, with a limit on how many things may be in progress at once. Get that honest first. Estimation, reporting and forecasting all depend on it, and none of them work on a board people do not trust.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required