You’ve been asked to start a project, and it’s causing you major anxiety. The brief seems confusing, the expectations are unclear, and you’re not even sure where to begin. I get it. I’ve been there too.
When I started my first project, I was completely overwhelmed. I thought I had to do everything on my own. I was always rushing to tick off the next task, moving from one deliverable to another without ever taking a step back to look at the bigger picture. The project dragged on longer than expected, stakeholders kept appearing with different expectations, and I was constantly firefighting problems I didn’t see coming. Looking back now, those problems seemed avoidable.
Whether you’re developing a new product, creating a new policy, or taking on any project, there are three core things you need to understand before you do anything else. Master these, and you’ll set yourself up for success from day one.
First, understand what has already been done. Here’s the thing that nobody tells you: projects never start from zero. Something has always happened before you arrived. Maybe a proposal was submitted six months ago. Maybe budget discussions have been going on for a year. Maybe you’re joining a project that’s already been running, and you’re the third person to take the lead.
This isn’t just about reading old documents or catching up on emails. It’s about understanding the context, the decisions that were made, and why they were made. Whenever I ask a project lead about what their project is about, they often describe it as a completely novel concept, with the assumption that nothing similar has ever been attempted before. But when you dig deeper, you’ll find proposals that were submitted, feasibility studies that were done, or pilot programs that were tested. All of that context matters, and ignoring it means you’re reinventing the wheel—or worse, repeating mistakes that others already learned from.
This step helps you clarify what’s expected of you, understand what outputs you need to deliver, and know what’s required from you as the project manager. Don’t assume you’re starting with a blank slate. Build on what exists.
Next, map your stakeholders. All three types. There are people this project matters to—that’s why it exists in the first place. But here’s what most people get wrong: they think “stakeholders” means one group of people. It doesn’t. There are three distinct types, and if you ignore any of them, your project will struggle.
- The Decision Makers. These could be funders, clients, or executives. They need clear expectations, regular updates, and transparency about how the project is progressing. These are the people you report to, and they hold the purse strings or the authority to shut things down.
- Your Team. These are the people who help you deliver the work. You need to know who’s on your team, who can review your outputs, and who can assist you when things get complicated. I once worked on a project where the lead tried to do everything alone. When deadlines came, they were overwhelmed, the quality suffered, and the project fell apart. Remember—you can’t do it alone, and that’s exactly why you’re the project lead, not a solo contributor.
- The End Users. This is the most critical group, yet often the most ignored. These are the people you’re creating for. You must understand their pain points and what they actually need. When you deliver something that doesn’t work for them, it’s because you didn’t understand this stakeholder group well enough. I’ve seen products launched that checked every box for the executives but were completely useless to the people who were supposed to use them. That’s a failure, no matter how you frame it.
Finally, embrace your limitations. Limitations aren’t bad—they’re actually helpful. In fact, I’d argue they’re essential. Without limitations, you’d be paralysed by infinite options and possibilities. Constraints could include:
- Budget Constraints: Yes, you could deliver a million different things, but your budget forces you to prioritise. That’s actually a good thing because it creates focus. Once, I worked on a project with an almost unlimited budget, and it was chaos. Every meeting turned into a brainstorming session with no decisions. When we finally imposed artificial budget constraints, the team rallied, made decisions, and delivered.
- Reporting Requirements: Different projects have different reporting cycles—quarterly, every six months, or annually. Understand this upfront because reporting is essentially anti-work. You want to minimise it while maximising actual project delivery.
The Key Takeaway
Those are the three main things you need to nail down. Next time you start a project, take this framework with you. When you’re in that first meeting with your client or whoever you’re reporting to, make sure you’ve covered all three areas.
The options exist for success, and many project managers are already using these fundamentals in various spaces. A general shift is required, though, from thinking about project kickoffs as chaotic beginnings rather than strategic foundations. Because when you get the start right, everything else becomes easier.
Remember: successful projects start with clarity, not chaos.
Like what you see:
- Subscribe to my newsletter
- Follow me on Instagram for more coaching videos
Aliasgher Janmohammed 