Before You Set the Project Plan… Adjust the Mindset You Will Manage the Project With

When a new project begins, the first question is often: What is the scope? What is the timeline? What is the budget? And who are the stakeholders? Then meetings begin, the project plan is built, responsibilities are assigned, and everyone feels the project is under control. But there is an element that precedes all of that, and it may be more impactful than the plan itself: the mindset with which the project will be managed.

For a project is not managed by tools alone. Tools do not make decisions, timelines do not solve problems, and risk reports do not decide when to escalate, adapt, or stop. Human beings do that, and humans always operate from a set of assumptions and convictions that shape their way of seeing the project before shaping their way of managing it.

This is why two project managers can possess the same methodology, the same tools, and the same technical expertise, yet achieve entirely different results.

One views the project as a plan to be protected, while the other views it as an outcome to be achieved. The first constantly asks: How do we maintain the Baseline? The second asks: Does the Baseline still serve the objective for which it was set? The difference seems simple, but in reality, it represents an entire mindset in project management.

The problem is that many practices we consider professional can become dangerous when turned into dogma. Adherence to the plan is an important value, but sticking to an expired plan is not discipline. Risk management is a necessity, but building the entire project around the fear of making mistakes can kill all space for initiative. Governance is required, but if it turns into ten layers of approvals, the project may become safer on paper and less able to move in reality.

Here lies the importance of what we can call Mindset Setting before managing the project.

Just as we document project assumptions, we must uncover our own assumptions as well. Do we believe the project manager must know the answer to everything? If yes, the project manager will hide ambiguity instead of managing it. Do we believe that changing the plan is a sign of poor planning? Then the team will resist change even when reality provides clear evidence of the need to adapt. Do we believe escalation is a sign of failure? Problems will likely remain beneath the surface until solving them becomes far more costly.

These are not theoretical ideas. They translate directly into time, cost, quality, and risks.

One of the most common situations in projects is when a small problem starts to surface, but the team hesitates to announce it because the internal culture views bad news as something to be avoided. Days pass, then weeks, until the problem becomes large enough for everyone to see. At that moment, the search for who is responsible for the delay begins, while the real problem started long before: the mindset that made the team believe hiding the problem was safer than revealing it early on.

That is why project culture is not formed solely by written procedures, but by how leaders deal with reality when things do not go as planned.

A project manager who tells their team: "I want to know about the problem while it is small, not when it becomes a disaster," sets a completely different mental posture for the project. They send a clear message that transparency is not a threat, that the emergence of risks is not a failure, and that the goal of project management is not to prove the plan was right, but to increase the likelihood of reaching the right outcome.

Here we reach an important point: Project management at its core is not the management of certainty, but the management of movement amid a degree of uncertainty.

Every project starts with a set of assumptions. We assume a certain resource will be available, that the client will approve the decision on a specific date, that the technology will work as expected, that the market will not change significantly, and that the team can execute work at the rate we planned. But the real project starts when these assumptions begin colliding with reality.

And at this precise moment, the project manager's true mindset emerges.

Do they defend the old assumption because changing it would make the plan look less accurate? Or do they acknowledge that reality has become the primary source of information? Do they view deviation from the plan as a problem to be hidden, or as a signal to be understood? And do they see a Change Request as an administrative burden, or as a formal tool to acknowledge that the project operates in a changing world?

A mature mindset in project management does not mean ignoring planning; quite the opposite. It means planning seriously, and then having enough courage to review the plan even more seriously when the data changes.

There is another, deeper dimension regarding the intention behind managing the project itself. Is the project manager's goal to appear in control? Is their goal to finish the project by any means? Do they want to protect their image before management? Or is their true intention to preserve the value of the project, the rights of stakeholders, and the resources entrusted to them, and to reach the best possible outcome within the available reality?

Intention here is not a concept distant from management. It is what sometimes determines the difference between a decision that protects the project and a decision that protects the person making it.

When an activity fails, one manager might ask: "Who is responsible?", while another asks: "What does the project need right now?" The first question may be required later for accountability and learning, but if it becomes the first reaction, project management can turn into blame management. The second question, however, brings everyone back to the goal.

And this is the essence of setting the mindset before managing a project: defining how we want to act before pressure begins testing us.

Before launching the project, it is not enough to agree on roles and plans. We also need a deeper agreement: How will we handle bad news? What will we do when data conflicts with our expectations? How will we discuss mistakes? When do we stick to the plan and when do we revisit it? Is our goal completing activities or delivering value?

These questions may not appear in the Project Charter, but they will show up in every important decision within the project.

In the end, you can have an excellent plan and a bad mindset, managing the project in the wrong direction with great efficiency. Or you can have an imperfect initial plan, but a right mindset that allows you to learn, adapt, and continuously improve your decisions.

Therefore, before you begin managing time, cost, scope, and risk, there is one more thing worth managing first.

The mindset you will use to manage all of that.