Project Management: the definitions everyone should know

The project management area has many terms and concepts. PMBOK seems like an intimidating encyclopedia for those who read it for the first time, but over time I realized that some definitions are really fundamental in daily work.

Today I want to share these definitions in a more practical way, based on my experience dealing with real projects.

What are constraints (and why they’ll chase you)

Constraints are those limitations you can’t negotiate. They’re the famous “no way around it” of the project. I learned this the hard way when a client said it had to be ready by Friday for Black Friday. It didn’t matter if it was technically viable or not.

Constraints fall into 6 main groups. Time is non-negotiable deadline (like Black Friday). Costs is fixed budget that can’t be exceeded. Human Resources is available team (or lack thereof). Quality are minimum standards that can’t be compromised. Scope is what must be included mandatorily. Risks are exposure limitations to problems.

Real example: In an e-commerce project, we had R$ 650,000 budget, 3 months deadline and a 6-person team. Simple as that, there was no way to negotiate.

Assumptions are the bets we make every day

Assumptions are those suppositions we make to be able to plan. It’s like saying “let’s assume this will work” knowing it might not.

The rule I learned is that every assumption generates a risk. If I assume the client will deliver the layout on Tuesday, I need to have a plan B for when this doesn’t happen (and probably won’t).

Example I’ve lived: The client will provide the layout (PSD) by 10/10/2016 to start HTML. Spoiler: arrived on the 15th, with half the project delayed.

Programs vs Portfolios, the difference that confuses everyone

Program is a set of related projects working together. Think about renewing a company’s visual identity: website, graphic material, signage, uniforms. They’re different projects, but need to be aligned.

Portfolio is more strategic. It’s all projects and programs the company is running to achieve its objectives. It’s C-level vision about which projects will take us where we want to go.

The people behind projects

Stakeholders are everyone who can be affected by the project. From CEO to the doorman who will use the new access system. I learned that ignoring any of them can become a headache.

Sponsor is not necessarily who pays (although it can be). It’s your “political godfather” in the company. That person who will defend you in board meetings when things get tense.

Functional manager is the boss of functional areas (HR, IT, Finance). When you need someone from their team, it’s with them you negotiate. Fundamental relationship!

PMO, the 3 types you’ll find around

Support PMO is the “self-service” of PM. Gives you templates, training, best practices. You use if you want.

Control PMO besides support, demands you follow methodologies. “Where’s the updated schedule?” is a typical phrase.

Directive PMO they manage projects directly. You report to them, not to functional manager.

The environment that influences everything

Organizational culture, a startup vs a 50-year company have different speeds. Organizational structures in strong matrix (PM commands), weak matrix (PM “asks please”) and functional (each in their square). Environmental factors are regulations, available suppliers, existing technology.

The 5 process groups that rule your life

There will always be 5 phases every project will go through:

Initiation is “Should we do this project?” Here you get authorization, identify stakeholders and are officially named PM.

Planning is “How are we going to do it?” The most important phase in my opinion. Plan poorly, suffer later.

Execution is “Let’s get to work!” Where budget is spent and work actually happens.

Monitoring and Control is “Is everything on track?” Monitor, measure, adjust. Happens in parallel with execution.

Closure is “Mission accomplished!” Close contracts, document lessons learned, release team.

The structure behind everything

Every management process always has 3 components. Inputs are what you need to do the work. Tools and techniques are how you’re going to do it. Outputs are what you’re going to deliver.

It seems obvious, but this logic helped me a lot to understand PMBOK and pass the certification.

These definitions are not just theory, they’re tools I use every day. When you understand these concepts well, it becomes much easier to navigate the project world and communicate with stakeholders.

Do any of these definitions make more sense now? Or is there any term that always confuses you?