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.

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.

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?”

Alain de Botton on Emotional Education @The School of Life
Source: https://youtu.be/W9X7u-MeJz0

“Whenever you are talking about your project, you seem to be sad,” my friend’s words struck me like lightening. Sadness was clearly not the emotion I wanted to stir up with relation to the initiative I felt responsible for. Sadness brings us dangerously close to doubt. Ideally, change should be linked with hope rather than fear, and doubt. Granted, some longer projects seem to run forever and project participants might become anxious – concerned about the end result, tired of the pressure of time, the constant stream of challenges. But this is something we, as project managers, should find ways to counter. Even when circumstances are tough. After all, we are supposed to manage the change. Of course, a sense of urgency by itself isn’t necessarily a bad thing. But we should deal with any negative emotions arising from or exacerbated by that change. Best – before they even appear. The worst thing we can do is allow them to rule us.

Personally, I link maturity with the ability to manage one’s emotions. Consider this for a moment – what’s typical in a child’s behavior? Emotions control the child rather than the other way round. Tantrums are one noticeable example. By contrast, a responsible leader seems to roam the sea of organizational challenges steadily, seemingly emotion-less, wielding emotions like a weapon or tool, drawing upon them only when required. The leader’s stability, predictability with respect to her emotions provides a solid ground for all the leaps the team has to make. Instability fosters doubt and mistrust. A positive outlook will be shared, so will a negative one.

See also
I Made A Mistake – https://progressblog.com/2012/04/07/i-made-a-mistake/
The Stage is for the Child – https://progressblog.com/2008/08/07/the-stage-is-for-the-child/

Whenever a client wants us to start a new venture with them, to initiate a project together, we work on defining business requirements (apart from making sure there is a business case in the first place). Traditionally, Business requirements form the “what” of the project. They provide an explanation on what should be built to achieve the expected return on investment. It is uncommon to find a detailed, technical description there. From a technical perspective, finding a flowchart or field definitions in a BRD (Business Requirements Document) is rare. As the document is owned by the client and often prepared by her, as professionals on the supplier’s side, we often expect from our customers not to cross the thin line between the “what” and the “how”. Figuring out the “how” is the supplier’s job. It’s the space where he can analyze the work at hand, translate the more general, business perspective into functions, data structures and flows, paired with interfaces required to interact with the future solution. Among others. This is how functional requirements are born. They form a pair – business “reqs” and functional “reqs,” they should directly relate to one another, where business requirements are the “what” and the functional requirements – the “how.” In a way, the BRD is part of a mandate to start a project, whereas the FRD (Functional Requirements Document) – a contract describing how the project result is to be built.

Here’s the challenge. Agile is founded on the premise that suppliers and customers are able to work out requirements collaboratively in the form of user stories, maintained in a backlog of remaining work, detailed iteratively as needed – based on priority / proximity, aligning in tight iterations and frequent feedback. In theory this is faster as there is no dichotomy . In practice… I have yet to see this work well.

Granted, agile requires sufficient organizational maturity with the new artifacts, events, and roles – Product Owners able to own the backlog, empowered and knowledgeable enough to detail requirements and decide on priorities.

But I haven’t seen many Product Owners like that. Plus, with increasing complexity of the business landscape and progressing specialization, they simply cannot be know-it-alls, right? Even having sufficient business acumen, they won’t be able to drill down to technical levels detailed enough to provide a sound basis for development work.

How do we deal with this? From my perspective this is Agile’s uncharted land, that’s where “there be dragons.” Pre-sprints, parallel analytical sprints are just means to patch this up. The issue possibly requires several “whys” before we reach the root cause. My bet is that complete functional requirements are a necessity that cannot be neglected, and that they should form a response to whatever the business requests. Having agreed functional requirements we can expect viable “work packages” which can be decomposed, estimated, and developed with a higher degree of accuracy.

“The schedule model simulates distinct scenarios and situations that predict milestones and completion dates according to the project’s actual and future data input by the project team. It is an important tool used for communication and managing stakeholder expectations.”

From Practice Standard For Scheduling, third edition, PMI

What do you find better? An ordered stack (a backlog) or a sequence of actives of varied length (a schedule)? Agile advocates the former, with waterfall we got used to the latter.

It’s easier to move items up and down in a stack. Rescheduling takes more time as you have to maintain logic (dependencies). On the other hand, a schedule allows us to see how activities relate to each other. Based on estimates – which are part of any schedule by definition – one can easily tell when to expect what. Of course, with relation to time a schedule is only a prognosis. The sequence in a schedule, however, provides value by itself – allowing the involved to see how tasks refer to one another. A work organization tool. And a useful one at that.

Lists focus on work in progress.
Schedules focus on relations and dependencies.

Lists draw attention to the work at hand.
Schedules show us how late we are, in addition to the above.

For a one-man band a list is fine. That’s my view. Where there’s teamwork involved, I prefer a schedule. And so do my customers – when asked, I can instantly tell them not only how much work remains (same goes for backlogs), but what the estimated duration is, and what the key milestone dates are.

I am in favour of new approaches. Sometimes a new approach is just a stepping stone towards something better. Better than schedules.