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.

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.

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 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.

We live as long as we learn

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 more
  compliant?
• 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.

When preparing a Steering Committee meeting, consider agreeing the material with key stakeholders before the meeting.
Aligning a Steering Committee material with the Sponsor and key stakeholders prior to a SteerCo meeting should be a standard step — unless told otherwise. Of course, such processes may be adjusted once we get to know our stakeholders and their preferences better. The above becomes even more important, if there are conflicts of interest in the project — we definitely don’t want to antagonize participants further. Doing a SteerCo prep like that increases the likelihood of a successful outcome.

There is a constant push & pull between delivery and continuous improvement. Immediate value is palpable wherever there is shipping.

Work related to improving processes, tweaking tools, adapting communication or working on relations is often sacrificied on the time-to-market altar.

In this world delivery is king.

But once in a while we get reminded about black swans (like the dot-com bubble or disputedly – the current pandemic) or a new aproach to managing projects is born (like Agile). Things like that change our way of working, force us to shift our perspective.

So when “lost in delivery”, it is sometimes worthwhile considering a dinosaur’s dilemma – should I be interested more in finding a fresh new tree to feed on or… “what is that falling star on the sky?”