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

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.