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

Depending on the organizational level from which you are looking at a project the tendency is to focus either on solving the problem directly or escalating the lack of a solution to that problem.

People directly involved in a project tend to focus on seeking solutions and resort to escalations when it’s late.

Those from middle or top management are more prone to escalate early — most likely because they lack details or specialist knowledge to understand the nature of the problem.

One way to invest in one’s future is by setting up hooks — future launching pads for career changes. This is particularly advisable when there are relatively few personal and professional obligations in our lives, i.e. one can stay up late investing in a community, leave home on a Socrates program, invest long-term in interesting, passionate relationships, or write articles in the night or early mornings without sacrificing family time, time you’d normally spend with your significant other, doing homework with the kids or teaching them something otherwise.

This pays back later on, when there is less space for a running start.

There is a saying “those who want look for means, those who do not — seek for reasons”. It’s easy to say “I have no time.” I do this myself far too often. With a growing family and new demands for my time — privately and professionally — explanations are readily at hand.

Time, however, is not a resource. Time does not wait. You cannot store time either. “Saving time” is a figure of speech. As anyone or anything on our planet we are submerged in time, and it is our decisions that define whether we use this time well or not.

Efficiency for its own sake is a recipe for disaster — something I’m becoming more aware of in nowadays corporations competing on the global market. “Efficiency” is just the means. The “why” is more important.

We can become extremely efficient at doing the wrong things. Or forgetting what is truly important.

… built a house from scratch, became a father for the 3rd time, finished my PRINCE2 Practitioner. Now it’s time to get back to work.

I was talking with my Colleague about Seth Godin and bam! the first article I see rings true like a church bell to me – A productivity gap:

You’d think that with all the iPad productivity apps, smartphone productivity apps, productivity blogs and techniques and discussions… that we’d be more productive as a result.

[…]

Isaac Asimov wrote more than 400 books, on a manual typewriter, with no access to modern productivity tools. I find it hard to imagine they would have helped him write 400 more.

Productivity has nothing to do with all of the fancy tools out there. Of course, that’s my opinion, and my opinion only. And believe me, I “invented” lots and lots of tool-related problems in order to waste time solving them later on. If anything, tools *might* draw us further from being creative as we begin to focus more on the process rather than the outcome itself – perfecting the *how* instead of shipping something worthwhile. We don’t need much in order to do good. The flip-side – the more we complicate our lives, the less space remains to fill it with value.

Reference: http://sethgodin.typepad.com/seths_blog/2013/12/a-productivity-gap.html

PRINCE2 distinguishes between management and technical, specialist products. The first are “value enablers,” the latter drive the real value for the customer. Both are needed — assuming the right balance, but it is technical products that build the project’s backbone.

There are companies where extensive control processes diminish the clarity of the value for the customer. The key aspect then is the organization’s project lifecycle — its phases determine the key dates for the project.

In such organizations milestone plans — the ones based on key technical deliverables (groups of deliverables) — are a rare thing to find.

Lesson learned
When developing the scope, building a WBS, and later on — continuing with a schedule, we should still create a milestone plan, presenting the completion of key technical products (not project lifecycle phase gates). Such a plan is particularly useful when reporting progress and when discussing the project with the organization’s management.