You do not need a PMP certification to manage a project. You need clarity, boundaries, and follow-through. These three things are what separate projects that ship from projects that stall.
What Is a Project
A project is a temporary effort with a defined start, end, and deliverable -- distinct from the ongoing operations of a business. Any work that has a specific goal, a deadline, and requires coordination across people or time zones is a project, whether you call it that or not.
The skills of project management are not restricted to people with the title. Individual contributors lead projects constantly -- launching a product, planning an event, reorganizing a team's workflow. The difference between those who consistently deliver and those who consistently stall is rarely technical skill. It is project management discipline.
Defining Scope and Goals
The most common project failure is scope creep -- the gradual expansion of what the project is supposed to include, beyond what was agreed upon. The solution is ruthless clarity at the start: what is in scope, what is explicitly out of scope, and what does success look like?
Write these down and get agreement from stakeholders before starting. Not because change is bad -- requirements evolve -- but because scope changes without explicit agreement are how projects spiral out of control. When scope needs to change, make it a deliberate decision, not an accidental drift.
Timeline and Milestones
A project without a timeline is not really a project -- it is a vague intention. Break the work into milestones with specific dates, and track progress against them. Milestones serve two purposes: they create accountability and they surface problems early enough to correct them.
The most useful milestone cadence depends on project length. For a one-month project, weekly milestones make sense. For a six-month project, monthly milestones. When a milestone is missed, investigate immediately. Most delays can be recovered if caught early; they become catastrophic if ignored.
Common Pitfalls
Assuming that communication will happen naturally. In every project, specific communication mechanisms should be defined: how often status will be shared, through what channel, with what level of detail. Without explicit agreements, people default to communicating less than needed.
Not documenting decisions. Project amnesia is real -- people forget what was agreed, why certain choices were made, and what was promised. Brief notes capturing decisions and rationale prevent enormous amounts of future conflict.
Letting problems surface without escalation. The project managers who deliver consistently are the ones who surface problems early and loud. Waiting until a problem is solved before telling anyone is how projects die.
What if I have no formal authority?
Most project managers do not have direct authority over the people doing the work. Authority comes from clarity, credibility, and stakeholder management. Be clear about what you need, why you need it, and when. Build credibility by removing obstacles. Manage stakeholders by keeping them informed.
How do I handle scope creep?
Name it and make it explicit. "I would love to add that to the project. That would mean deprioritizing X or extending the deadline. Which would you prefer?" Force the trade-off to be made consciously rather than letting it happen by default.
What tools should I use?
Use whatever your team already uses. Spreadsheets work fine for small projects. Asana, Jira, Monday, and Notion work for larger ones. The tool matters far less than the discipline of using it consistently.