The Art of Project Management
A realistic framework for leading projects in chaotic tech environments.
Every company I’ve worked at defines “project manager” differently. In fact, it’s the one role title that seems to mean everything—and nothing—at the same time. Some want glorified note-takers. Others want mini-CEOs who somehow don’t manage people. I’ve even seen companies use “program manager” for people who’ve never run a program in their lives; it is like the fallback title.
In my 15+ years as a project/program/portfolio manager, I’ve seen endless confusion—and a lot of misalignment—about what these roles actually mean. Since this discussion keeps following me around, I decided to write down my point of view. This is how I personally think about project management in tech, and the mental models that guide me. It is not the only mental model to do project management but it is one that I relied on a lot.
Disclaimer: This post focuses on project management in tech—especially in highly dynamic companies where requirements, teams, and budgets shift constantly. The framework mainly covers product companies (teams building products for their own company) but applies to service companies too (teams building products for clients). There are plenty of great books on traditional project management for pharmaceutical, construction, defense, or regulated industries. This is not that.
Some Definitions
Let’s start with definitions. At least we can build some common ground before the debates begin.
What is a Project? The textbook answer: “A project is a unique, temporary endeavor to create a specific product, service, or result, with a defined start and end date, and distinct objectives, time, cost, and resource constraints.”
That’s fine, but I prefer a more pragmatic version:
A project is a unique, temporary group of activities to create specific customer value while managing constraints—the iron triangle of scope, cost, and time.
I removed the “start and end date” because most tech projects don’t stick to specific dates. You sometimes find yourself in the middle of a project without knowing when it officially started. You deliver multiple milestones but rarely “complete” the project at a specific time—things are more fluid. For example, a customer comes with an idea and asks for the cost. Your team evaluates requirements, creates a POC, and offers it to the customer. They accept or reject. What’s the start time? When you got the request? When the customer signed? It really doesn’t matter unless you’re chasing certifications. Most projects start without a PM assigned—kicked off by sales, product management, or some engineering work—and often end with a list of open items that might never be addressed. You know, those 20 bugs you agreed to fix “after launch.”
What is Project Management? Again, the textbook: “Project management is the discipline of planning, organizing, and overseeing resources and activities to achieve a specific goal within defined constraints of scope, time, cost, and quality.”
My version:
Project management is the art of continuously planning, organizing, monitoring, and adjusting activities and resources to achieve defined objectives within the changing constraints of scope, time, cost, and quality.
Why “art”? Because in tech, almost nothing is stable. Plans change the moment you finish them. Scope shifts. Stakeholders rotate. Budgets tighten. The PM’s job isn’t following a static plan—it’s creative problem-solving and judgment in the middle of chaos. A good project manager adapts to changes as long as they serve customer value, and stops new changes when they don’t make sense. They know when to charge customers for changes and when those changes actually help the company. I know project managers who charge customers every time they change a button color, and others who never charge them. A good one finds the balance and does change assessment when it makes sense—or at least consolidates multiple changes together to save themselves and the team time.
What Project Management Is NOT
It’s worth clearing up some misconceptions. Project managers are not:
Note-takers or meeting schedulers
Chiefs of staff for executives
Scrum masters (though we sometimes borrow agile practices)
Technical advisors or architects
Product managers (Note: at Microsoft, many of the project managers are actually product managers)
If that’s all your company expects from a PM, you don’t have a project manager—you have organizational confusion.
Another important note: In my conversations, a lot of people consider project management an easy job (or even a fallback job when they cannot find the right one for themselves). In practice, everyone should learn how to manage projects, but managing big or challenging projects is not for everyone. It requires experience, learning, and a lot of art. I am sure it is all learnable, but it is not like a developer or a manager decides all of a sudden to be a project manager and succeeds in complex ones.
So What About Product Managers?
Since everyone confuses these roles, here’s the distinction: Product managers own the WHAT and WHY. They define what we’re building and why it matters to customers and the business. Project managers own the HOW and WHEN. We figure out how to build it and when it’ll be ready, given our constraints.
Product says “we need this feature because customers are churning.” Project says “okay, given our team and timeline, here are three ways we can deliver it, with different tradeoffs.”
Sometimes these roles overlap, especially in smaller companies. That’s fine. Just know which hat you’re wearing.
What the Hell is a Program?
A Program is a multi-year, strategic effort tied directly to a company’s financial or market goals. It’s the engine driving the business transformation. A Project is the specific component—the gear—that the Program Manager needs to deliver that engine’s power.
If projects deliver outputs (a feature, a prototype, a product), programs deliver outcomes (a market entry, a transformation, a competitive advantage). Many tech companies call their Project Managers “Program Managers” even though they’ve never run a program in their lives.
Honestly, naming doesn’t matter as long as you know what you’re doing. But it’s much better to know you’re doing project management even if your title says “program manager.”
Project Lifecycle
Let’s tackle the first debate: what is a project lifecycle, and how does this work with all the Agile craziness?
In traditional project management, projects have 5 phases: Initiation, Planning, Execution, Monitoring & Control, and Closure. In practice, these usually overlap. Depending on the project’s progress, you’ll be doing some or all of them simultaneously.
When you compress timelines, you overlap activities. In most projects I’ve run, we started execution before closing on scope (or even initiation). Sometimes without a signature from the customer or stakeholders. Not because we’re reckless, but because the market won’t let you work sequentially. Same with planning—we usually start the plan early and finish it during execution.
Tech projects are so iterative that I see them as a group of sequential projects, each going through full phases until the end. Part of the output of the first project is delivering requirements and plans for the second project.
In other words, a project consists of smaller sub-projects (also known as work streams, verticals, components), each with its own complete cycle. The art is managing them together. This isn’t really a program because the focus is on delivery, not business outcomes.
This matches the agile approach in general, but since it’s too consuming to do a complete project every sprint, I think of it hierarchically:
Project = set of sub-projects
Sub-project = set of sprints
You have a high-level project plan, then smaller, quick plans for each sub-project
Easy? Not really. I honestly think it’s confusing. Let me use a hypothetical project to illustrate: inviting friends for a party at your house.
Initiation: The goal is: Having fun with friends (the goal isn’t to feed them—it’s to have a pleasant time. This is the difference between having a task “make food and drinks” and an objective “have a good time”). Note: this is different if the host is your mother or grandmother, it is usually about the food :).
Planning: What should we cook? How to decorate? What drinks? What day? Are we watching a game or just chatting? Should we get games? Does the group fit together? Do we have enough chairs? Since we’ve done this before, we don’t need to calculate every penny to know the budget—we know it’ll be around X euros. We’re already making assumptions and starting execution.
Execution: You don’t have to answer all these questions to start. In my house, once we know the people, we start executing immediately by inviting them—to eliminate the risk of people not coming. We check the number of chairs much earlier than defining the menu. Buy drinks early because they’re always required. Keep the food planning for the end.
Monitor and Control: Once we send invitations, we monitor the weather to decide if we’re sitting in the backyard or inside, to decide timing, and sometimes even change the food based on availability. We might invite more people if someone cancels. This is usually done intuitively, but it’s really like managing “change” and handling “risks.”
Closure: When everyone leaves, we clean up, throw away the trash, and sometimes assess if we could have done things better or cheaper (retrospective). Again, these aren’t elaborate activities, just intuitive ones.
The Art of Balance (The Iron Triangle)
Every project is a balancing act between three constraints: scope, time, and cost. This is called the iron triangle—change one, and the others must adjust.
(A quick note: Some models add quality as a fourth dimension, calling it the “Project Constraint Quadruple” or “Project Management Diamond.” I personally prefer to see quality as part of the scope, not a separate dimension. This emphasizes that defining the required level of quality—whether it’s “minimum viable” or “gold-plated”—is inherent to defining whatyou’re building.)
What are we building? (customer value)
“We are doing A to help customers do B, so our company benefits C.”
What’s the minimum “valuable” or “lovable” product I can deliver to make customers happy sooner?
How will we measure success? (users, revenue, speed, cost, reliability?)
How are we going to build it? (technology, resources, process)
How much will it cost?
When is the right time to deliver?
You rarely answer these in order. Instead, you iterate, negotiating scope, cost, and time until you find the sweet spot.
Planning Is Guessing
Planning is not predicting the future—it’s making the best educated guess you can. Rule of thumb: don’t overdo it. It’s needed because otherwise you don’t know what you’re doing or where you’re going. But changes will always happen. Once you feel around 70% confident, consider the plan done and write down your assumptions and risks to validate later. There’s no 100% accurate plan (unless you wrote it at the end of the project).
Here’s my model:
Start with a rough baseline (”Plan 1”). Assume you’re asked to get a plan in one day—what would you do?
Review with engineers and product. Challenge assumptions.
Iterate and refine.
Set milestones and baselines, but expect to update them.
Revisit at 25%, 50%, and 75% of the project.
The magic isn’t the plan itself—it’s understanding what really matters and have a laser focus on it.
When I first started in project management, I was obsessed with creating the perfect plan. I would spend weeks trying to cover every scenario and lock down every detail. For a project with just one team, the plan could easily reach over 30 pages (yes, it was insane).
And of course, those plans would change—always within the first two weeks, without exception. We used multiple estimation models, reviewed everything with several stakeholders, and still, in reality, none of it held up.
A plan is meant to help us execute. It’s not a deliverable and it’s not customer value on its own.
Risks, Assumptions, Issues, and Opportunities
Assumptions → accepted as true until proven. Always track and validate.
Risks → uncertain events that could help or hurt your project. Dependencies count.
Issues → risks that materialized.
Opportunities → positive risks. A new tool, early delivery, or regulatory change could accelerate success.
A good PM doesn’t need a fancy risk register—but they need to keep these close to their heart and update stakeholders transparently.
Depending on your business, location, and geopolitical context, these items might be simple or incredibly complex. For example, during the Arab Spring, we had a risk about Internet going out and a clear mitigation plan. During winter, I calculate lower productivity due to sick leaves; during summer, I assume fewer working days due to vacations. The strongest risks are ones generated by dependencies. If you rely on another organization or team to deliver something and they’re late, your project might be late. Track all critical dependencies as risks.
Change Management
Change is not failure—it’s learning. The PM’s job isn’t to block change, but to:
Make it transparent
Assess its impact on scope, cost, and time
Facilitate the decision with stakeholders
Adjust the plan accordingly
Stakeholders and Communication
If you remember nothing else from this post, remember this: Project management is 80% communication.
Stakeholders often have conflicting goals. Product wants more scope. Engineering wants more time. Finance wants lower cost. Executives want it yesterday. Your job is to be the translator, negotiator, and diplomat who keeps everyone aligned on reality.
I know project managers who keep mediocre plans and documentation but write excellent status reports—and they deliver like stars. I cannot repeat it enough: communication is the most important skill for a project manager.
This means:
Transparency: Your team and stakeholders must always have access to consistent, up-to-date information. A PM who hoards or forgets updates is often the root cause of project failure.
Bad news early: Surface problems when they’re small, not when they’re catastrophic.
Call out the elephant: Someone needs to say what everyone’s thinking. That’s you.
Regular touchpoints: Kick-offs (always), periodic check-ins (formal or informal), extra kick-offs when scope shifts significantly, and celebrations at the end.
Leadership Without Authority
Project managers lead without authority. You don’t own the product definition, you don’t write the code, you don’t control the budget. But you own the alignment and momentum.
To lead, you have to gain people’s trust. This doesn’t mean being biased toward one side or another—it means representing everyone’s interests fairly and ensuring everyone stays updated. A good leader makes sure everyone understands the what and why, and surfaces bad news early. They’re the one who calls out the elephant in the room while maintaining respectful relationships with everyone.
Don’t get lost in politics. Focus on facts, deliveries, and customer benefits.
This is where the art is. You have to understand that project management is not the product or the objective—it’s actually a tool to help you deliver the objective. In pure technical terms, it’s overhead. If it’s not adding value by reducing overall time or cost, then it’s not needed. That’s why project managers need to know where and how to spend their time instead of creating plans and reports all the time.
My Style
There’s no single right style. Tools and frameworks are just amplifiers—they either amplify clarity or amplify confusion.
For short, high-speed projects (6 weeks or less), I like sticky notes, whiteboards, or even a simple Google Doc list. The point is to move fast, not to over-document.
For longer projects, I build a structured plan, track with Jira/Asana/Excel (whatever works), and send periodic updates.
The only non-negotiable: transparency and communication. Everything else is negotiable based on what serves the project and team best.
TL;DR
Here’s what matters:
Project management in tech is about judgment, balance, and transparency in uncertainty—process is to help you but not to define all the work
Plans are guesses—stop at 70% confidence, document assumptions, and adapt
Communication is 80% of the job—status reports and frequent check-ins beat perfect plans
The iron triangle is real—scope, time, and cost are always in tension
Lead without authority—build trust by representing everyone fairly and surfacing bad news early
If you’re just taking notes, you’re not a PM—you’re organizational confusion
Tools don’t matter—trust and clarity do
My thoughts above don’t reflect all the details, of course (don’t shout at me saying I missed this or that yet). Each section requires a lot more discussion, and I really encourage you to read more about all of this.
That’s my way of doing it—not the only way, but one I’ve seen work across messy, high-speed, high-stakes projects.