-
When everything is important, nothing really is
There’s a saying I keep coming back to in my work as a project manager: when everything is important, nothing really is. It sounds simple, almost obvious — and yet, in the day-to-day grind of managing complex initiatives, it’s astonishing how often we lose sight of it.I’ll admit it: I have a weakness for optimization. Some might even say I’m obsessed with finding the “silver bullet” — the most efficient, effective way to get things done. But for me, it’s not about constant customization. In fact, I’ve learned that sometimes, the better path lies in standardization — not as a rigid set of rules, but as a reliable foundation. A standardized core helps teams align more easily, reduces friction, and saves valuable time and mental energy.But as with many things in project management, there’s a danger of going too far in the other direction.It usually starts with good intentions. Someone wants to ensure compliance, minimize risk, or simply bring structure. Before long, the process becomes overgrown with artifacts: operating models, compliance logs, transition plans, detailed documentation of every conceivable scenario — all meant to demonstrate thoroughness and readiness.The result? Teams are asked to produce and maintain an overwhelming number of documents, each with its own structure and requirements. And soon, the focus shifts from delivering value to filling templates.I’ve seen this play out many times. Some people push back — often the more pragmatic ones, who would rather do the minimum necessary to keep the project on track and fit for purpose, rather than spending hours covering every possible angle “just in case.” Others simply can’t keep up — business stakeholders are stretched thin, and expecting them to contribute detailed inputs to a dozen different artifacts is neither realistic nor sustainable.And that brings us back to the core idea.If everything is treated as equally critical, we lose the ability to prioritize. We drown in noise, and the truly important elements get lost. The role of a project leader is not to create complexity, but to navigate it — to identify what’s essential, and to give teams the structure and clarity they need without overwhelming them.In practice, that means making conscious choices. Not everything needs to be documented in five places. Not every risk requires a mitigation plan. Not every deliverable needs its own workflow. Focus on what brings real value. Build just enough structure to provide stability and direction, and allow the rest to evolve.Because the world will keep changing. And projects, by definition, introduce change. The stability we seek doesn’t come from exhaustive control — it comes from clarity of purpose and well-placed priorities.Choose wisely. And don’t be afraid to let go of the rest.
-
Be Careful What You Wish For
In life, as we take on more responsibilities and the nature of these responsibilities evolves, we form an agreement with life itself. This agreement often involves sacrificing some of the lightness and freedom we once enjoyed in exchange for the greater burden of managing the affairs of others. This is frequently the natural order of things. We grow, demonstrate our reliability, and prove that we are responsible, stable, and trustworthy. Consequently, we take on more responsibilities. However, there is a price that we often have to pay.
The Hidden Costs of Responsibility
With added responsibilities come the gradual erosion of our smile and carefreeness. We often adopt a more serious demeanor, finding it harder to maintain a lighthearted approach to life. This doesn’t mean we should shy away from these obligations, but rather, we should be aware of the cost we might incur. We will inevitably become different people. This change might make us less like the individuals we once wanted to be or the ones our closest friends and family once knew.
Understanding the Transformation
Taking on new responsibilities can be a double-edged sword. On one hand, it allows us to grow and prove ourselves. On the other hand, it can strip away the joy and spontaneity that once defined us. This transformation is something to be mindful of, as it can have profound implications on our well-being and how we relate to others. In summary, while it is commendable to embrace new responsibilities and challenges, it's crucial to remain cognizant of the personal costs involved. Balancing these responsibilities with self-care and mindfulness can help mitigate some of the negative impacts, allowing us to maintain a sense of joy and fulfillment in our lives.
-
Action Cures Fear
Action Cures Fear: Embracing Delivery and Overcoming Uncertainty
In the journey of delivering work, whether it's a project, a product, or any kind of significant outcome, there is always an element of fear. This fear often stems from the potential mismatch between what is expected and what is actually delivered. This gap can manifest in terms of the quality of the end product or the time frame in which it is delivered. This is a challenge faced not only by project managers but by anyone who strives to make things happen.
The Nature of Delivery
To be proud of our workmanship, we must first accept that fear and uncertainty are inherent in the delivery process. These feelings are a natural part of our professional reality. Professionals are distinguished by their ability to deliver, despite these challenges. Embracing this mindset helps us move through our fears and uncertainties with a sense of purpose and confidence.
Action as a Remedy for Fear
Much like in our personal lives, the best way to deal with uncertainty in our professional endeavors is to take continuous action. This means making the first step and then persistently moving forward, step by step. Avoiding action only amplifies fear and uncertainty. When we engage in continuous activity, action itself starts to mitigate fear. With every step, we build confidence, gain satisfaction, and take pride in our workmanship. Action is not just a way to achieve results; it is a way to transform our mindset. As we progress, we begin to see that our fears are manageable, and our capabilities are greater than we initially believed.
Building Confidence Through Continuous Action
Confidence, satisfaction, and pride are the natural outcomes of committed and continual action. Each step forward reinforces our ability to overcome fears and uncertainties. By embracing action, we become more proficient and resilient. Delivery, then, is not just about the end result but about the journey we undertake and the growth we experience along the way.
In conclusion, action indeed cures fear. By understanding and accepting that fear and uncertainty are part of the delivery process, and by committing ourselves to continuous action, we transform these challenges into opportunities for growth and achievement. Through action, we build our confidence, satisfaction, and pride in our work, ultimately becoming more accomplished and self-assured professionals.
-
Trusting the people, trusting the process
You can look at Project Management processes in an organization from the perspective of two extremes - (1) pushing towards strengthening the process (process-centric) and (2) pushing towards strengthening the Project Managers themselves (PM-centric). While arguably this is a spectrum and one can envisage variants which are considering both the process and the PM, there is a tendency to continue putting weight on one or the other.
Process-centric aims to focus primarily on creating a standardized lifecycle of a project, providing standardized tools, and expecting the project managers to follow and use them meticulously. Usually the next step is to introduce controls, and build reporting, QA, and audits around them.
By contrast, a vanilla PM-centric approach focuses more on empowering the PM, providing him or her the tools he or she needs, providing access to resources, trainings, but still leaving plenty of space to adjust, taylor the approach, depending on circumstances, size, stakeholders and such.
The appetite for one approach or the other is a function of organization size and complexity, but also regulatory scrutiny, among others. It's not easy to leave the reigns to an imperfect human being, even with necessary oversight, when there are high stakes involved. In fact, it's not always possible, as regulators impose certain rules that later govern the said approach.
It is however important to recognize the difference and assess preference as a PM - an organization with little wiggle room to flex one's muscles as a leader, little appetite for adaptability, is not a place where everyone feels comfortable in.
-
You are what you make of it
We are all telling a story of ourselves. Feeding our inner wolf so to speak. And we can choose, if we focus on the good or the bad. The facts are almost secondary. They are like challenges, points of reference, testing our character and our perception of things -- mishaps, pain, health issues and the like. There are few circumstances, where we can be objectively miserable (e.g. serious pain or health issues). And even that is a matter of choice, or at least we have the freedom to choose our response, as Victor Frankl put it. The rest is our interpretation and our attitude. We can try to see meaning in pain, and we can choose to tell a positive story about all that's happening - showing up, doing baby steps, if that's all we can give, being aware that even a smile goes a long way.
-
Change
"Every time you're trying to change something in your life, you are exposing something that is really terrifying." -Ross Ellenhorn
Perhaps the most important facet of change, is change itself. What if we approached change as something valuable in itself? What if we consciously agreed that we are in it for the long run -- change being a constant state rather than a surprising, unwelcome experience? What if we learned how to "ride change", how to build tools around managing change and leveraging it to the biggest extent possible? Maybe instead of worrying about the next thing around the corner we would actually embrace it?
-
Do we need a bad plan?
In my work I often encounter stakeholders' reluctance to plan. I have the impression that fear of being held accountable for deadlines comes into play. It’s easier to refrain from making declarations about dates.
But is no plan better than even a poor plan? And what does a “poor plan” really mean? Should we insist on terms we are unsure of on the assumption that they might mislead someone? While this may seem controversial, in my opinion – yes.
Plan as a forecast
The plan is a risk-weighted forecast. We can make our plans more realistic, increase their precision and credibility using expert knowledge, references to other projects, using methods such as the Montecarlo analysis, but ultimately ... this is not the only task of these plans. Creating a plan is a process anyway – a pre-designed plan is not a final product. Therefore, it should be assumed that our plan will change, and this is the case (of course, after saving the “base” and meeting the change management requirements). By delaying (or refraining from) planning, we deprive the organization of the opportunity to improve the way to reach our goals.
Plan -- scope verification
When planning, we rely on a defined scope. We often start with the so-called WBS -- Work Breakdown Structure (or Product -- PBS). Although it happens in practice that we combine these steps and the WBS is omitted (by the way, in a tool such as MS Project, the task name column is often called “WBS”). The very act of detailing tasks (starting with “work packages”, which should be the lowest level of the Work Breakdown Structure) and defining dependencies forces us to double-check, if we missed something in the scope.
Plan as a reference point
A plan is more like a blueprint than a map. Thanks to plans, the involved participants can assess when their support will be indicatively needed, understand the dependencies between groups of tasks and the sequence of events.
An inaccurate map could mislead the traveler. However, if only the project manager and the team put a minimum of effort into preparing their project schedule, it should be updated on an ongoing basis, and such a plan will still turn out to be more useful than not having it at all.
The specificity of the plan assumes its adjustments in the course of work (progressive elaboration). The key is to save a version of the plan at agreed moments in the project (baseline). As a result we obtain a basis for assessing what and to what extent has been changed.
The plan as an analytical tool
When we work with our schedule, going down to the level of detailed tasks, we not only verify the completeness of the scope, but also the stakeholders involved in the analysis and estimates can submit their comments.
In addition, when talking about the duration of individual activities in the plan, we verify our assumptions and often consider risks - for example, when participants emphasize the discrepancy between the expected and pessimistic estimates for individual tasks. During my trainings, I often say that when planning, we should have a risk register at hand. Often in such a register, in addition to information such as proximity of a given risk, probability, weight or owner, there is a field to enter a reference to the task to which the risk relates.
Plan as a commitment
The plan is also a commitment for the participants. I would prefer to assume that this is a conscious declaration of the participation in the work, rather than a strong obligation to deliver the result within a certain period. Waiting for declarations on the completion date is almost destructive to the ultimate goal of our projects. Of course, these are needed – it’s hard to manage projects effectively without them, but it’s worth highlighting other benefits of having a schedule in the first place.
The aspects mentioned above are not exhaustive (enough to mention reporting), but I wanted to emphasize the importance of scheduling in general, going beyond the typical thinking about plans in projects. Perhaps this will encourage reflection and a more favorable view of the imperfect schedules in our projects.
-
Motivation
Motivation is a never-ending story. In the course of our work life there are periods, where we feel excited with our work, we feel pride of workmanship. What we do seems to click, we achieve a flow-like state easily. Other times we struggle as if walking through muddy ground -- every move seems to require effort. Ultimately, we feel guilty, we feel like impostors. We ask ourselves, whether we should be leading others, if we fail at leading ourselves.
As project managers we are responsible for motivating the team, but first and foremost -- ourselves. This may be challenging at times, as we are only people, and motivation levels vary. But since we become a point of reference, it is our responsibility to do whatever we can to stay motivated to the biggest extent possible.This means that we should actively search for sources of motivation. How can we do this?
- Engage in communities of practice,- Read books and articles on project management,- Build helpful routines to make our day run smoothly,- Work from a task list -- to see progress over uncompleted work,- Commit to a schedule and keep it updated on a regular basis,- Search for sources of inspiration,- Practice gratefulness -- our work is not a given,- Network more to feel engaged.
Ultimately, we might need to ask ourselves the big question -- are we attuned to our work indeed or is it perhaps a good moment for a switch? If we see that our work is leading us nowhere, if we struggle to build the motivation we desire on a regular basis, then we might need to move on -- create a space for others to take over and add value.
An option might be to start writing about our challenges -- putting these in words might have a cathartic effect, but it can also lead us to helpful discoveries, ultimately helping us understand the root cause better.
-
Constant Learners
One of the reasons, why I love project management so much, is because it requires one to learn constantly. Not only every project is different, but we get to do them in different organizational contexts – businesses, clients, internal / external, different settings and stakeholder types, different stakes involved. We rarely do projects alone – hence the need to know how to build teams and work with various types of people. This is learning too.
Change is a given
What’s given is change and the necessity to adapt and learn. Moving aside the entire domain of subject matter – to make change happen successfully we need to become experts at adaptation – our toolbox should be tested constantly and our approach reevaluated at all times. Could I have done better? Is it possible to be more effective and/or efficient? Was there too much structure or not enough?
A wake up call
Sometimes the best we can do is ask for feedback. Even a 15 min call at the end of a cooperation can wake you up or provide you with signals to adapt.
Some time ago I received feedback from someone more senior in the organization. More importantly, someone more experienced than me. He told me I should:
“develop stronger tolerance for ambiguity,”
and
“own the solution rather than the structure.”
The thought process
The thought process started. The learning too.
- Have I become inflexible in my pursuit to be morecompliant?- When do we engage in finding a solution putting aside structure?- Isn’t ambiguity something we should deal with first hand?
Questions like these started nagging me. I still haven’t reached a solid conclusion, but I’m certain the learning continues. The way it should.
-
Overcontrol
Project Quality Assurance is a tought necessity. While it would be better for an organization's project management processes to be sound enough to do without additional checks and challenges, for Project Managers to have a bullet-proof toolset to prevent quality-related issues, this doesn't seem to be the case at all times.
There is a flipside, however. It's easy to formulate standards and requirements, and expect PMs to abide by them. The PM herself is controlled - documentation reviewed, milestone timeliness checked, risk completeness assessed etc. These standards have the tendency to change often once QA teams start to operate. It's not enough to deliver - the "how" matters too. The caveat is that documentation is a secondary project management activity - producing docs does not equate the completion of a project and such "artefacts" are created by one PM sparringly throughout a given year. The PM is rarely an "expert" here. QA teams, on the other hand, specialize in the kinds of documents they review, plus they review them on a regular basis.
A Project Manager is tasked with making things happen, first and formost. A certain degree of formalization is often required to ensure standards are met, safeguarded by Quality Assurance. But it is well worth to consider supporting the PM rather than dinging him or her for non-compliance.