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.

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?

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.

“Ship often. Ship lousy stuff, but ship. Ship constantly.”
– Seth Godin

I’m obsessed about the create vs. consume ratio. I try to teach my kids they should ask themselves — “how much content do I consume?” I admonish them that by creating more we allow ourselves to make our lives seem more complete, more… valid. And yet, I fall victim to the same malady — it’s so much easier to sit in the back row and watch others take risks. Creation, however, doesn’t need to start with something big — this might be us writing a couple of words for future generations, this might be us spreading the word about an important cause. The premise is… that we increase value by multiplying – we share and thus make it available to more than us alone.

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.

You can clearly see a difference between two projects – the first one has a deadline two weeks ahead, the second – is months away from completion. The stakes are almost irrelevant. They might be high on both projects. From my perspective the only difference is… time. Time builds sense of urgency in practice. If the team perceives there is little time to spare, subjective priority increases. I’ve heard a VP of a large firm say “it’s a good thing there is little time, the guys will increase the pace so us to deliver on schedule”.

This is why we have the student syndrome (https://en.m.wikipedia.org/wiki/Student_syndrome) in the first place. Time creates urgency.

Lesson learned – one of the most important things I can do on my projects is to work on “sense of urgency” as a daily practice – if you are able to convince your team that there is precious little time, you might be able to create this sense of urgency even though your go-live is months away. On the other hand, if everyone believes there’s still plenty of time, you are likely to fail.

My friend told me a story recently…

From “me” to “we”

His son, a 13 year old boy, is involved in sailing as a sport. For the majority of his youth, he used to sail alone. There came a time, where the class he was in couldn’t contain him any longer and he faced a decision — to join a team or drop sailing altogether. He went for the former. Instead of being captain and crew member in one, he got himself a partner. Soon afterwards problems appeared — it seemed his new crew member wasn’t equally involved and results began to suffer. My friend’s son made attempts to distance himself from decreasing results – he did what he could himself, and the other guy… not as much. Needless to say, turning his back on the problem, didn’t make the problem disappear. At one moment, his father had a talk with him:

“Listen, I understand you are doing your best, and it’s frustrating to see results diminish, but separating yourself from your crew won’t get you anywhere. You are your crew, the world perceives you as one. The sooner you start working as a team, embracing both the good and the not-so-good, the sooner results will follow.”

Remote teams

We find ourselves in increasingly multicultural work environments. It’s good when there is a mix in the physical sense, where people benefit from the variety of perspectives in person. This makes it easier to learn about each other, not to mention — from each other.

With new communication tools, there is a temptation to look for ‘the best of both worlds’ by setting up remote teams scattered among countries or continents. While this allows companies to pursue cheaper work offshore or embrace the follow-the-sun principle, this approach allows for less space to create mutual understanding and build trust based on everyday situations. There is no physical connection.

When discussing multinational remote teams the expression “necessary evil” seems to hang in the air. One country requests work to be done, the other is supposed to provide results — when you spice such expectations with cultural differences, and stress, remote teams of this kind become everything but effective. But that’s not the main problem.

Stuck with each other

I love the notion of being stuck with each other. It’s a starting point, a fixed setting. This means there is no other choice, but to learn how to build using the available means. If you lock two enemies in one room, given space and time, they might just start learning — one about the other, and based on even the smallest resemblance of trust… they might start cooperating. Of course, it would be best if these weren’t enemies, as attitude plays a role. But this is an extreme situation chosen to make a point.

In practice, trust is the key ingredient. It’s difficult to build trust without a physical connection. How to make it happen? Here are several strategies:

1. Shared values — to have a common goal above all differences
2. Shared cellebrations — to show there are reasons to be happy together
3. Physical bridges — to respect face time for building trust by meeting in person or at least seeing each other as often as possible