Modern PM

What is the half-life of knowledge and how is it affecting us project people. Plus five tips on how to best handle it. And a huge plot twist at the very end.

The wild sixties

In my opinion, you have to start from the very beginning to understand something. In our case that means we have to go to the year 1962 Not only did cars look really good at the time, but this year Fritz Machlup also postulated the concept of "half-life of knowledge". Machlup - one of many Austrians chased away in the dark 1930s - was one of the first to understand knowledge as a resource. The term information society goes back to him. And just in 1962, based on the half-life that we know from physics, he defined a key figure: the time that passes until half of our acquired knowledge has become obsolete or wrong.

But...

At the risk of undermining myself in the second paragraph of this article. But it has to be said that the concept of half-life of knowledge is not free of criticism. Mainly, that the concept is simple and generalizing. And yes, that is partly true. Sure, such a knowledge obsolescence is highly dependent on the particular subject area. Knowing how to recognize rock formations will not be as fast-paced as expertise in IT. And often we also find huge differences within one subject area. The knowledge of a web developer will be outdated faster than that of a mainframe software developer.

But we have to be careful here: sometimes outdated knowledge will still help me to squeak through work. I can often observe this attitude with people who have huge comfort zones. And yes, there are environments, where the 50%, leftover from my initial knowledge acquisition is enough to get the job done. Is that great? Or rather sad? Everybody has to decide for themselves. But the fact is: even in these areas, there is still something like a half-life of knowledge. It only has a smaller effect than perhaps elsewhere.

In any case

In any case, one thing is true. And I know, I am mentioning this often and at any opportunity. The world is turning ever faster. So I hope that here and now no one contradicts me:

Our acquired technical knowledge will be usable for shorter periods of time.

The half-life of knowledge was already very short for technical professions in 1962. At that time, it was said to be about 10 years. (Compared to 35 years in the 1930s.) Today, just 60 years later, it has become even shorter. And I do not want to go into more detail here on possible causes. I want to encourage you to think about the subject. In other words:

What does that mean for me?

Two things. First, let us have a look at the obvious: in the worst case, my team is constantly losing knowledge. And yes, I know that my wording is incorrect. The knowledge itself does not become less, it is less applicable. But in the end, it comes down to a loss of knowledge, if you are asking me. And that means that even the best knowledge sharing concept can only be half the battle. My two cents. Before I can share it, I have to have the knowledge. And if it is constantly losing its topicality, I have to make sure that my team, my organization has the ability to constantly acquire new knowledge. A learning organization

So we have to create an atmosphere that encourages knowledge acquisition. I can do that quite well with easy access to learning platforms and a time quota available for continuing education. I have often experienced a value of 10% to 15% of the working hours here. That sounds like a lot at first glance. Especially when a project is about to be completed. At second glance, and considering the half-life of knowledge, that seems like a reasonable value to me. And now it is crucial to motivate team members to take advantage of this offer. After all, it is in both their interests. And in my experience, the best motivation is the role model here. If I want to do things for the better, I have to lead by example.

The look into the mirror

So hopefully we have found a good approach for our team. With that and thus we are finished. Aren't we? Hm. Because of all the focus on others, we completely forgot about ourselves. We project people are just as affected by the loss of knowledge of course. Even more so than others who often work within teams with similar subject areas and topics. And how can we keep our knowledge up to date? Ideally, we can access the same structures our teams have. And if we are lucky, we are part of a Project Management Office, which ensures a lively exchange of knowledge and knowledge acquisition for us. In any case, it needs our awareness that we have to constantly practice knowledge hygiene here. That we constantly develop and change. (Here we are again with my favorite subject Kaizen.) We must not overlook this in the stressful everyday project life. Otherwise, at some point, the dust settles and we realize that all the others have moved on and we are left behind.

And how do I deal with that half-life of knowledge?

1. Awareness. First, that there is something like the half-life of knowledge. Second, that this half-life of knowledge concerns our technical, not our "social" knowledge.
2. Evaluation (environment, existing training, current knowledge, etc.), followed by a suitable strategy.
3. Focusing on important knowledge. Unimportant one may erode. (Liechtenstein, for example, is the only country in the world where every football club has played at least once in the cup finals. Fascinating, isn't it? But completely unimportant. Except, if you are a professor at the chair of Liechtenstein Football History. And in case you have the urge to google "Liechtenstein" now: you propably have googled "Austria" already after reading where I come from. Liechtenstein is the tiny dot right left of it. And no, I am not talking about Switzerland.)
4. Onwards, onwards, onwards. (I'm just writing this so I can mention Kaizen again. No, seriously: that is the single most important thing in our professional life.)
5. And finally, a realization: "innate" skills are perhaps and more important than we are thinking. So we should have a special eye on that when it comes to employee selection.

As I said, the concept of half-life of knowledge also has critics. But maybe what was state-of-the-art in 1962 is not that up to date anymore. And so maybe the whole thing is proof in itself. Have fun thinking about this!

Life as a project manager is not easy. On first sight, we may only have one single role. But we are much more than what the doorplate in front of our office is saying. We are planners, facilitators, controllers, handlers, organizers, mentors, presenters, helpers, impediment-scavengers, carers, managers, servant leaders, humans and often even friends.

But out of the many hats we are carrying on our PM-head, two stand out in particular: one says "Project Manager", the other one says "Team Member".  
And these two hats have a very special relationship to and with each other. Not only do they mark our most important roles, but also they often stand in each other's way.

Let's take a closer look at these two different roles

On the one hand, we are part of management. We administrate, we control, we are emissaries of evil. On the other hand, we are members of the project team. We are celebrating successes together, we dive through depths together, we are part of the family.

Project manager...

As a project manager, we are responsible for the successful completion of projects. We prepare, we plan, we manage. We are responsible for controlling the projects. And it doesn't matter if we are part of a functional, project or matrix organization: to our co-workers, we are one of those "up there". Even and especially when our desk is located in the middle of the team room.
And the fact, that project managers are often either the first or the last to become part of a team won't make things easier for us. Either the group is just right in the process of forming, or it has already formed. So we are often the fifth wheel on the car.

..and team member

If we do everything right, we are in the middle of our teams. At least we have that feeling. And with distributed teams, that's no different. There is the spatial separation, but we are the fat spider in the middle of the network, where all information converges. And we are the maven, who distributes this information to others. So we are clearly a team member, a part of the group. Especially when talking about longer projects, or teams that have existed for a long time, there is a special bond between the project manager (or Scrum Master) and the team members. Of course, it is: you have been through a lot together and you are going to experience a lot more together. That is the material that welds a group of people together.

So far so good, but where are we now?

So these are our two main roles in my eyes. And none of us is just one or the other. When we are organizing a meeting or demanding metrics, we are part of the management. When we are having coffee together in the office kitchen and talk about our weekends or we are working out a plan together, we are part of the team.  
And that often is creating conflicts, because the borders are blurred, not clearly defined. I have experienced those situations pretty often. You are having fun together and the next moment you ask for the progress of a work package to be able to document it. In everyday life, this is going without friction most of the time (at least as long as you are asking nice and polite). But in stressful situations or formal moments, this often leads to misunderstanding and conflict. Of course, it is. It has to - the rules are not clear. Both for you, and for the people around you. So you never know exactly, if a sloppy formulation is understood as inappropriate. Or if a correction seems far too bossy.

In between

And this issue won't get easier if we are not only in charge of project management-related tasks but work as part-time project managers. I have seen this several times in agile software development: a Scrum Master that is part time-developer. Or the developer is part time-Scrum Master. And there are the smaller companies that simply don't have the resources to have a full-time project manager. So projects are often led and managed _en passant_. In these scenarios, the team has even more difficulties to determine _who_ is communicating with them right now.

But what does the solution look like?

There is a book that I loved when I was a child. Herbie's Magical Hat by Otfried Preußler. There, in this children's book, I found a solution to our problem. Herbie (or Hörbe as he is called in German) is a Hutzelman (a kind of a Brownie) from the Siebengiebelwald (the Seven-gables-forest) - one of thirteen. And those thirteen Hutzelmen have something very special: Doppelhüte - double hats. A hat on top, which protects from sun and rain (and at night from evil dreams). And a hat below that keeps you warm. And for us, it is essential to realize that we all are wearing such a double hat. We have to be constantly aware of that. And in some situations, we should aim to wear only one of those two hats. This makes it clear to everyone involved who is in front of them.

Communication is everything

In this situation - as everywhere else - communication is everything. When changing roles, we have to communicate this to our teams clearly. If, as a project manager, I want to raise an objection during the Planning Meeting that has nothing to do with Scrumstuff, I have to preface an "I'll say that as a team member". Or, "I'll take off my project manager-hat now."

And vice versa. When I'm playing table soccer with team members and want to communicate some organizational matters, it must be clear to everyone that I am now speaking as a project manager and not as a team member.

The hard slog always pays off

Yes, that is difficult. But clear communication and role separation not only has the one clear advantage that your team members always know which hat is talking to them. It also helps us tremendously in our daily work. If we make ourselves aware, what role we are currently taking, we can structure and document our work much more clearly.

So when our current role is clear to us - especially in those stressful situations - we are not only facilitating the people around us but also are greatly empowering our lives. And I know, this takes some time to get used to speaking out loud, what role I am currently in. But trust me, it pays off a lot.

Why I take the view that putting tasks into an icebox is a dangerous business - in summer as during winter. And what can be done about it.

What is an icebox?

A couple of years ago I overheard some developers, I had the chance to work with at that time, talking about an icebox. It was summer and it was hot and I was like: “Yay, ice cream. Yummy!” The look they gave me made me feel like a little boy again. A stupid little boy. So let us talk about some theory first and then see how that correlates with reality. Now, what is an icebox? (Besides the one where you can find ice cream and cold drinks.)

When starting with Kanban or an agile methodology like Scrum, things are mostly and hopefully new and exciting. Requirements are cut into user stories and tasks. And those tasks are now starting to wander across that new and shiny whiteboard. From the To Do column / row / pipeline / step / whatever-fancy-name-your-scrum-coach-gave-it, to Work in Progress and finally to Done. After a while, most teams figure out, that some sort of testing state makes sense. Fewer teams then realize that the journey of a task won't stop after it is done and add a column named Released. So good, so far.

Die hard

Sorry for starting with movie references. Again. I promise this was the last for this article. So we have our Kanban board and our tasks. And everything runs great. But then old habits begin to sneak into our new agile world. Customer value sometimes tends to come in disguise. Priorities are not always that easy to decide. And so requirements start to add up. And at some point, somebody had the <zynism>great</zynism> idea to add a place on that whiteboard where all those tasks could find a new temporary home: the icebox.

So, a long story short: an icebox is a list of requests and issues that nobody is going to work on. Low priority tasks, minor bugs. Things, that are requested every now and then but that represent a low value. So, in theory, it is a kind of a parking space for tasks.

There is always that reality

And in theory, this sounds like a good idea. But here comes reality kicking in theory's door. Because let us be honest: in real life that home is not temporary but forever. It is not a parking space, it is a cemetery. Task Sematary. (Remember, when I promised to stop with movie references? Well... sorry!) Those tasks never ever get done. Why? In my experience there are two reasons for that:

1. Their priority is too low. This is one of my issues with agility. Standstill through a constant prioritization. When only the currently most important things are worked on - who will take care of the right things?
2. Because the world around that requirement is changing. Fast. And back then, when somebody wrote it down, it surely had its reason to exist, its customer value, its raison d'être. Now, after hanging on that whiteboard for some time, the basic conditions likely have changed. And with them, the necessity of that requirement has changed.

So after a while, we have requirements that don't represent that importance anymore they once had. And some years ago it was common for tasks to grow old. Think of all that councils and task groups and management layers such a requirement had to go through. Still has to go through in many companies. Those companies that actually don't feel the pressure to change that hard. And in that case, it is not exactly good, but also not bad to take some time. But in fast moving environments (and these days we see a lot of environments changing) it is deadly. So let me formulate it differently: after a while, we have requirements that don't represent that value anymore that they once had.

An icebox inside an icebox

I guess we all agree that we don't want to have these requirements around our board. But for me, there is a situation that is kind of the same: user stories or tasks inside a backlog. Well, not the same. Even worse. At least an icebox is a sign. Inside a product backlog, those "parked" tasks just add to obscurity. It reduces the maintainability and - more even worse - the transparency of that backlog. (Well, maybe sometimes that is intended. And if it is intended, then an icebox should not be our number one priority.) So we should scan a backlog we have to work with for exactly that user stories. And it does not matter if our role is project manager, or Scrum Master, or Product Owner, or whatever here. Because that user stories represent an icebox inside an icebox. And double pain usually is not a good thing.

How to handle these requirements

I guess it depends a lot on the environment and the team and the culture how such "parked" tasks are handled. A thing that I have made positive experiences with are mold points. Every morning you place a dot sticker on every requirement on your board that has not been pulled during that sprint. You can also mark them with a felt pen. As those points will grow (like mold), you will reach a point (pun intended) where you won't be able to figure out what this task originally was about. And in that very moment, you can remove it from the board.

If you are using a digital equivalent of a Kanban or Scrum board, those mold points obviously won't work. Here you need to make those scruffy tasks transparent. And I know, this is hard work. And it is not easy to be that annoying person who is crashing every daily meeting with "Any news on that requirement?". But in my eyes, it is worth the pain. Because a clean backlog or board will push the effectiveness of a team.

The best for last

So for me, there are two ways to deal with a requirement: either it generates enough (customer) value to have a high enough priority to be done: do it. Else: throw it away.

And here is the only good thing about such an icebox: the "parked" requirements have already been identified and clustered. So you can grab the whole thing and throw it away. Time for an ice cream.

Kanban, Kaizen, Kaikaku, Gemba, Muda, Heijunka, Jidoka, Genchi Gembutsu. Why are so many recent project management buzzwords of Southeast Asian origin? A trend? Of course, yes. But there is more to it than just that.

It used to be that way before. In the 1980s. The older ones can (hopefully) remember. Those who feel old, like me, have experienced the aftereffects of it during their early years. And the millennials among us may know one or the other story. In those years Japanese culture was a huge trend. Why? Japanese producers suddenly were far superior to the western ones in terms of throughput, time-to-market and just-in-time. So much so that at some point even Michael Crichton wrote a book about it. Rising Sun, 1992. (And no, it's not really good.)

And what do throughput, time-to-market, and just-in-time have to do with philosophy?

Let us talk about the mother of all this success. And the mother was two fathers: Eiji Toyoda and Taiichi Ohno. The two have devised and developed the Toyota Production System. Lean Manufacturing has grown from this, which brings us to Kanban via Lean Management. And this Toyota Production System is not a framework, as PMBOK is, for example, but a so-called socio-technical system. So much more than just a guide. After all, the main work of Ohno has the subtitle Beyond Large-Scale Production.

By the way, if any of you get their hands on "Toyota Production System: Beyond Large-Scale Production": be sure to read it! In contrast to Rising Sun, it is really good in my eyes.

Let us take a closer look at a few of those buzzwords

Behind the Toyota Production System, we can find a pretty simple philosophy and mindset. The most famous aspect of it is certainly Muda: the pointless activity, the waste. It is important to avoid it. And as so often: yes, of course, it is. Logically. Unfortunately, it is happening far too rare.
I often experience that much attention is paid to the introduction of processes that should prevent Muda. This is usually not necessary if I pay attention to avoiding the other two points:

1. Muri, the unreasonableness, and
2. Mura, the inconsistency.

This means that I constantly observe my processes, my entire system and adapt if necessary. And not just me, but all members of an organization, all employees of a company. So this includes flexibility into the system at all levels and - above all - in all places.

And how about "western" culture?

Here it is always the one big hero who saves the day (or the project). Even from the beginning of Western culture: Homer.
A competitor (Troy) goes through changes (robbery of the beautiful Helena) and threatens our own organization (the Greek city-states). A big change project is planned (soldiers are recruited, warships are built) and carried out (years of the siege of Troy). However, the competitor is steadfast and your own company is heading towards a solid crisis. Appearance of the great hero (Odysseus), who can turn things around with a heroic hero-deed (the Trojan Horse). The own organization is saved, the project team is disbanded, the hero pilgrimages a bit through the departments (Odysseus' Odyssey), but on the whole, everything is peaceful and quiet again. The good, old daily business.

And in the 1970s and 1980s, the corporate world looked exactly like this. For most of the time, everything went its usual course of events. Every few years, change was necessary. A big step. And most of the time this one step was a single achievement of legendary project managers. And in those times that was more than enough. Today the world looks different (I know, you all know this). Because some organizations have come to the conclusion that the ones who change fast and more consistently have a competitive advantage. And the tools that have been added to our tool case since the 1990s (keyword digitization) also support this faster and more constant change.

Back to the East

In Far Eastern cultures, things are seen differently. There is this famous study by Richard E. Nisbett and Takahiko Masuda, in which they showed Japanese and Americans short sequences of an underwater film and asked them what they had seen. The Americans described primarily larger, foreground objects, while the Japanese had mostly the big picture in view.
The same Nisbett also has studied with Hannah Faye Chua, whereupon Americans and Chinese turn their eyes when they are shown a picture. I know you guessed it already: the former immediately focused on the primary object, the second let their eyes wander over the whole picture.
And then there is the study with the picture taking. The participants should take a picture of a person. Westerners zoomed in on the face, Southeast Asians photographed the whole person in their environment.

By the way, you can find the article by Richard E. Nisbett on those studies mentioned above here: https://www.pnas.org/content/100/19/11163 - Copyright 2003 National Academy of Sciences.

And I do not want to philosophize about what that says, but I am driving at a very simple fact here: seen from the perspective of project management, in a world where things are changing ever faster and more profoundly - that is, in our world today - such an approach is a huge competitive advantage.

And what now?

Does that mean Far Eastern philosophies and approaches are better suited to project management than our Western ones? No. Yes. Yes and no. (Jein, as we say in Austria - a frankenword of Ja and Nein.) What does "better" mean from a project management perspective? A better framework is a more successful framework. And in our case, philosophies, attitudes, thinking is nothing more than frameworks. My two cents. And in our times when things are changing constantly and, most importantly, fast, frameworks that have that change inside their DNA and so can use that change for leveraging, are certainly the right thing for project management. Or what do you think?

Pictures from Giammarco Boscaro on Unsplash resp. The National Academy of Sciences / Richard E. Nisbett.

Looking over the rim of our project tea cup.

Lately, one is hearing more and more often about Flight Levels. Especially in combination with Kanban. But what is meant by that? And more importantly, how can I use these flight levels for myself? And where do they come from? The latter question is the easiest to answer, so I start with that. There is a gentleman by the name of Klaus Leopold. He is a crazy good (Lean Kanban-)coach. (And no, I do not get any money from him for that statement, but honor to whom credit is due.) And he wrote a book called "Kanban in Practice". And there he formulated the idea of Flight Levels.

And what are these Flight Levels now?

The Flight Levels are the levels on which an organization is working and thinking. And yes, there are thousands and thousands of them. But for the sake of simplicity we are distinguishing three:

• Flight Level 1
  The daily business, as the saying goes.
• Flight Level 2
  Spoiler Alert: The interface between daily business and strategy.
• Flight Level 3
  The strategy level. Where the visions arise.

And I can hear you, project managers, all shouting, "We've had that for a long time! Project, Program, Portfolio." And at first, I felt the same way. But the Flight Levels are about more than just change. (And yet I think there are a lot of parallels between project-program-portfolio and the three Flight Levels, no question.)

For me, the Flight Levels are meant differently, wider in some parts. Or more precisely in others. I know that contradicts itself. So let us take a closer look at the three.

Just under the clouds - Portfolio Management

Of course, the top Flight Level can also be called portfolio management. But there is also a lot of strategy inside, which I do not necessarily have with Portfolio Management. (OKR - Objectives and Key Results would be the right and hip buzzword here, but I bite it back.)

Klaus Leopold is using the term Strategic Portfolio Management and to me that is actually a pretty good description of what is happening at this level. Here we can find the levels on which strategies are developed and broken down into initiatives (the next upcoming buzzword). So management work, then. In which direction are we evolving? Where are our priorities right now? In which areas do I put my resources?

By the way, all these questions, topics, initiatives are in good hands when we are using a Kanban board. Talking about "visualization of my work". Sure, that seems funny at first glance. Writing the big mammoths on task sheets and move them across a whiteboard. But especially here visualization is actually an incredibly powerful tool.

About busy bees

The first ("lowest") Flight Level can certainly be seen parallel to the term "project". And I deliberately put the word "lowest" in quotation marks, because at this level the actual implementation takes place. But I can not think of a more appropriate word. After all, we are talking about altitudes here.

So projects, but also in a broader context. The headline here, we can not forget that, is Kanban. More run than change, if you like.
(And please forgive the many comments in brackets. Today is probably a parenthesis day.)

Klaus Leopold has a wonderful analogy that I would not want to withhold from you. If every team is responsible for one line of the keyboard and I want them to write a letter, there is nothing in it for me, if a team can press the "S" key really quickly. I need an efficient and effective interaction of the teams. Of course. Unfortunately, this is working far too rarely.

The Golden Mean

The strategy and the daily business (Flight Levels one and three) are pretty well received by most of the organizations I know. We have that under control. Only in between, something is missing pretty often. The level that translates the strategies into tasks. The big, abstract chunks divided into small, concrete work instructions. ("The mediator between the head and the hands must be the heart!", to quote Metropolis). Small companies often find this easier to achieve because a single role can often fill this level. However, this also greatly increases the risk. And at least beyond a certain size of the organization, I have to institutionalize this level.

We know that quite well from project management. There we have our PMO and the program managers who slip into the clothes of this mediator between brain and hands. And that works quite well in most cases. But outside the project world, we can often find a void here. Since the unifying bracket is missing. The second Flight Level precisely. The coordination and interaction between the teams and above all the coordination of the teams to ensure that the right things are being worked on at the right time. And what is often overlooked here: that also means to make sure that new initiatives are not constantly sloshing from top to bottom, but that the first Flight Level can finish work. Here we are talking about Customer Value. And that should be our noble goal.

How can I use this for myself?

In my eyes, Flight Levels are a good analogy, alone because of their name. Altitudes. This pretty well reflects how and where individual organizational units are currently moving. And they come from Kanban county, but for me, the basic idea of the Flight Levels is universally applicable. Or, like Kanban, I can combine them well with other philosophies, methodologies, ideas, approaches. Neither, as PMBOK as big picture and Scrum as a daily business tool exclude themselves (on the contrary, that works really well!), nor do Flight Levels and - again - Scrum. Here we are facing the same situation as everywhere else: some things you just have to try.