• Project failure usually begins with someone pretending you have authority.
• Without a mandate, you’re not a project manager – you’re project management-flavored wallpaper.
• Unclear authorization is how organizations say: “Take the chance!” when you don’t have one.
• Leading without authority is like arguing with HAL, the supercomputer—polite, futile, and fatal.
• No sponsor? That’s fine – you can always escalate directly into the void.
• No Project Charter? Perfect. You’re adrift in deep space with a Gantt chart and a Deadline.

Project failure often begins with unclear authorization and role definition: Clarify right at the beginning of your assignment:

• What am I authorized to decide and to do?
• What am I not authorized to decide and to do?
• Who will champion my project and support me as the project’s sponsor and direct escalation channel?
• When I run into capacity conflicts between my work for the project and other daily tasks, what has priority?
• Who will champion my project’s as a formal Project Sponsor and direct escalation channel?

The document to lay down the answers to these questions for later reference is the Project Charter.

Misunderstandings are among the top causes of trouble in projects.

A project glossary of terms is essential for establishing a shared language among all stakeholders, particularly in complex environments involving multiple departments, disciplines, or external partners.

Internal projects often suffer from communication breakdowns due to assumptions that everyone interprets terminology the same way—when in reality, even common terms can have wildly different meanings depending on role or function. A well-maintained glossary reduces ambiguity, aligns expectations, and shortens ramp-up time for new team members. It acts as a single source of truth that helps prevent costly misunderstandings and repeated clarification cycles.

In customer projects, especially those that are cross-corporate or span different cultures, industries, or technical domains, a glossary becomes even more critical. It supports contractual clarity, ensuring that everyone agrees on the definitions behind scope items, deliverables, and technical concepts. This is particularly important when dealing with performance obligations, acceptance criteria, or legal interpretations. Without a shared glossary, every meeting runs the risk of misalignment, and every document becomes a potential dispute waiting to happen. A project glossary isn’t just good practice. It’s cheap “quick-win” insurance against the chaos of poor communication.*

A glossary may be developed specifically for a project. It may also be provided by a Project Management Office (PMO) for the entire organization.

*: A template for a cross-corporate glossary can be found at https://project-business.org/tools/project-business-glossary.

When you step into a new project or take over an existing one, identifying the business intentions behind it should be your first strategic move.

This means going beyond the project charter to uncover why the organization or the customer want the project delivered in the first place. You should start by engaging with the project champion or sponsor, senior stakeholders, or account managers to ask pointed questions:

• What does success really look like?
• What business problem are we solving?
• What outcome are we betting on?

These conversations often reveal priorities not listed in official documents—like market timing, competitive pressure, customer satisfaction, or internal politics. The goal is to get a clear, executive-level understanding of the intended business impact.

Next, you should validate and contextualize these intentions with the operational realities. That includes understanding how the project ties into strategic goals, how value will be measured (cost savings, revenue generation, compliance, etc.), and what trade-offs are acceptable.

If it’s a customer project, this also means decoding the contract to understand not just the deliverables, but the performance expectations and pain points the customer is trying to resolve. You should document these business intentions and circulate them with key stakeholders for alignment, because if everyone isn’t working toward the same outcomes, it’s only a matter of time before the project veers off course.

Having a plan for your project is as important as having a plan for how to get from home to your vacation destination so you don’t get lost on the way. But here’s a surprising truth: Project management success has shockingly little to do with following the plan.

Your new project must succeed in a messy, high-stakes, cross-corporate environment? Despite all the charts, status reports, and process worshipping, the real-world success of projects hinges far more on your adaptability, trust, and communication than it does on perfect planning or rigid adherence to predictive or agile dogmas.

In fact, a project that sticks strictly to the plan is often either (a) fake, (b) driven by luck, or (c) headed for irrelevance. Plans are conjectures made early based on incomplete information. Reality is what smashes those guesses to pieces and demands improvisation.

That’s why risk management is so important. Developing a plan is based on the presumption that things will evolve as expected. Risk management asks instead: What if they don’t?

Want a genuine competitive edge as a project manager? Learn how to manage uncertainty, politics, and personalities. That’s the actual game, not just task lists and schedules.

Trust is the single biggest lever you have for improving cost, time, and even fun of running a project.

When you work with people you can rely on, everything moves faster and more smoothly:

• No endless double-checking
• No time wasted on covering your back
• No costly buffer-padding to account for unreliable partners.

Budgets hold better, deadlines get met, and the daily grind turns into something much closer to real teamwork. Frankly, projects with genuine trust feel lighter: People share information, step up to fix problems, and even enjoy the process. The work is hard, but the drama is low.

But here’s the catch: trust the wrong people, and all those benefits flip to liabilities.

Costs explode when you have to redo work or chase down missing deliverables. Schedules fall apart as mistakes pile up or partners drag their feet. Worst of all, “fun” vanishes, getting replaced by stress, blame games, and a creeping sense that the project is off the rails. In short, trust is a multiplier: it amplifies whatever is already there, for better or worse.

So be generous with trust, but never lazy about earning it, building it, and, when necessary, protecting yourself from those who’d abuse it.