Modern PM

How we can survive upper management. This time with a conclusion right at the beginning.

Some time ago I shared my tips for good presentations with you. (Do not worry, they are timeless.) These tips are very general. On purpose. But we project people find ourselves often in situations where things are very specific. I am talking about those moments when we have to present the current project status to middle and/or senior management. Project Dashboards, Project Cockpits, Project-whatever-they-are-called-in-your-company. And one thing I have often been able to experience sitting on both sides of the table: a deliberate, planned and controlled procedure is the cornerstone in such situations. So much for the conclusion.

Talking turkey

What is the basis for a good review? Honesty. Unmerciful, if need be. And I do not mean to give it straight to one's own board of management, but to be honest about the project status. Not only when the sun is shining (usually at the beginning of the project), but also when clouds are rising (often seen at halftime).

One can experience often that such a just-not-so-great-presentation is then seen by all parties as a kind of a confession. That is not what it should be about in my eyes. Use this moment for you! You have so many people sitting around that table, who can help you. Make use of that power source.
And you can easily admit that you just do not know something. That is still a thousand times better than saying anything that later turns out to be wrong.

Of expectations

Imagine, you go to the opera and there is a Death Metal band at the scene. Or you go to a festival and they perform the Magic Flute on stage. (As a Salzburg native, I almost had to take Mozart as an example.) What I mean by that is: Think about who is going to take part in your presentation. I know, you already knew that. But I mean that on several levels.

• Which roles will participate?
• Are there tensions and conflicts within the group of participants?
• Who is my ally? Do I have to involve someone in advance?
• Are the right people listening to and watching me?
• Do I have a say in the cast?
• What do they expect from me?

And that brings us volée to our next point.

Priorities

That is the most important point for me. Ok, every point here is the most important. But this one in particular: What is really important? What do I want to communicate? What does my key message look like? Can I wrap the content of my entire presentation into one sentence? If not, I may have too much information (unnecessary information at the moment) with me. Of course, this goes hand in glove with our previous point. Who is there and what do they expect to hear from me?

And yes, I know. All that material we have for our presentation is important. But is this really the case? We are so good at prioritizing. This is something we really are capable of. We were able to do that even before Scrum. But with our status reports, we often fail with that. Where it is especially important. Maybe that is why. So we have to be twice as sensitive and prioritizing here.

About the less, which is often more

The great Sol Stein once gave me the following advice:

One plus one is one half.

Now we have tailored our presentation to our audience and found a message that we want to convey. And then we often feel the urge in us, especially when it comes to important presentations, to take it and pack every graphic and every measure that we can get hold of in it. I often felt the same way. The result is hopelessly overloaded PowerPoint orgies in which the statement drowns in massive ornaments. Of course, that is handy when things are not going so well. But we wanted to be ruthlessly honest. So what can one do about the dazzling accessory? Years ago, I found a simple rule for me: one message per slide, or one message per flipchart sheet.

Weapon of choice

Speaking of PowerPoint. Yes, that is a great tool indeed. But think back to the last review you sat in and where someone presented something via PowerPoint. Those present (pardon the pun!) looked briefly at the screen and then looked back into their unfolded laptops and unpacked smart phones. If we are standing in front of a flipchart and draw, everyone has to be attentive. They can not help it. We human beings are terrified of missing something. Use this weakness for you.

And I know what you are thinking now. My great transition effects. And I don't know how to draw. And certainly not while speaking. If you feel uncomfortable when seeing a bare flipchart and you are unsure without the buzzing sound of a beamer, go step by step. In any case, it does not always have to be PowerPoint. A flipchart and a pen are the tools of a true master. Says Yoda. I think.

"I'm late! I'm late! I'm late!"

Who knows whom I am quoting here? It is the white rabbit from Alice in Wonderland. And he says something important here for our presentations. Because such a presentation has one thing above all: a beginning and an end. Ok, that's two things. But you get the picture. A predetermined start time and a predetermined end time. So it is a timebox. This is often a company culture thing, but try being a good example here and be on time. And also have the courage to point out the remaining time. Kind of moderate your own presentation so to speak. And if the time is too short? Suggests follow-up appointments for the topics that still need clarification.

Now there are the contemporaries who come around a corner every now and then with detailed questions that no one else is interested in. We all know that, we all are experiencing it regularly. Again, be brave! Point out the timebox and the agenda. Stay polite and kind. And above all, understanding. Because such characters just want someone to listen to them and nod their head every now and then. So you are good here too with follow-up appointments. And if you want to take the wind out of the troublemaker's sails of, suggests that you like to forward detailed information via email. And that brings us to our grand finale.

Stay calm

Stay cool. Stay distanced. Stay souverain. There is this wonderful saying, based on a quote from George Bernard Shaw:

Arguing with a project manager is like wrestling a pig in mud: sooner or later you realize that they like it.

We all love to argue. That is why we are taking care of projects. And that is important and right. But not when we have to present a project status. In upper management levels we often can find people who are not used to argue. They are usually where they are because they do not like to argue. So better not even start with it.

Be honest (I know, we all are always and everywhere), think about expectations, prioritize and reduce, look at the clock, bite your tongue every now and then and rock your presentations!

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.

Thoughts on minimum viable products and riskiest assumption tests.

Always these misunderstandings

Some of you surely know this drawing by Henrik Kniberg on the subject of minimum viable products. (By the way, Henrik is a software developer for the best-selling video game of all time - Minecraft. Just to make sure we are collecting enough useless knowledge here too.) And in itself, and in theory this MVP is not such a bad idea. But as so often, when our beloved scrum-agility-buzzword-coaches are involved, it is turning into one big misunderstanding at the end. And as so often, there is an alternative that is actually more suitable to produce iterative and incremental products: riskiest assumption tests, short RAT. Those who mainly care about sounding competent should incorporate the term "RAT" as often as possible into their sentences in the near future before it is becoming the next big buzzword and can otherwise stop reading now. All others are going to learn more in the next paragraphs. You are still all aboard? Very nice!

Minimum Viable Product

Before we talk about beautiful shiny new things, we should ensure that we are all on the same level. What is an MVP? I don't want to be a smartass (pardon my French!) here, but I have seen teams dashing against exactly this question because no one has thought about the literal meaning of the phrase. The MVP is the "minimal survivable product". The idea behind it is quickly explained. The phrase was coined in 2001 by Frank Robinson, who, inspired by the bursting dot-com bubble shortly before and based on the Sharp Ratio - simplified, a return-on-risk analysis - has thought about how to give his customers a product which has just enough features to be viable. So maximum profit with minimum risk.

And what is the suboptimal part of such an MVP now?

The idea per se is, as I said, not bad - quite the contrary! But even its inventor says about the concept of the MVP:

"Too large or too small a product are big problems. The MVP is the difficult-to-determine sweet spot between them. Teams flounder tactically in trying to determine the MVP." - Frank Robinson

So as so often the implementation is the problem. The misconception that the MVP is the minimal variant of a product. Quite simply dashed off. And not enough, I often see organizations slipping into the Product Death Cycle attempting to work after the idea of an MVP.

And even if the implementation should work. Even if the mindset is recognized and lived as such, the MVP often does not really work. Because such a minimum viable product is poor in features by definition. This is not a big problem for new products. But in 99,999...% of cases we are in areas where there is competition. And in the long run, the product with the most sensible features and the highest quality prevails. And not the MVP.

The road to Riskiest Assumption Tests

Especially software developers have quickly come to the conclusion that the MVP is indeed a great concept, but just has its weaknesses. So they tried to develop the idea of an MVP further. Entrance Minimum Viable Experiment. The MVE takes an MVP to evaluate a product idea. True to the premise, "Nobody expects an experiment to be a complete success." That sounds complicated at first sight, and at second sight one notices that the MVE is nothing but the good old banana principle.  
And then the Minimum Awesome Product managed to catch some spotlight. Those who are suspecting a bunch of buzzwords, hot air, and marketing babble, are completely correct in my eyes. The basic idea behind the MAP is that the "minimum feasible" is not enough to survive in the market. Those of you who have been paying close attention to the previous paragraphs know that someone did not understand the concept behind the minimum viable product here. Not a good requirement to develop something further if you are asking me.  
Other ideas include the Minimum Valuable Product or the Minimum Lovable Product. All driven by the worry, the customer might think the MVP is not a full product, but a worthless prototype. These are solutions, but in my eyes in the completely and utter wrong direction.

I see RATs.

So, Riskiest Assumption Tests. RATs. I do not know if Rik Higham invented the concept, but he was the first I heard speaking about it. Rik is asking a simple question:

"What's the smallest experiment you can do to test your biggest assumption?"

When you are building a new product, you have to start with a whole bunch of assumptions. We project workers even have our own tool for that, the Assumptions Log. The big disadvantage of such assumptions is that you just do not know anything about it. Of course. So you take the assumption that carries the greatest risk for you and test it. Without much effort, just as easy as possible. Test early instead of Fail early so to speak. (That should be printed on t-shirts, I know.)

That is, I build a product that just tests my assumption. Quick, easy, and inexpensive. Need an example? Google Glass. Such smart glasses are an incredibly complicated and, above all, complex thing. Not just the technology, but also the whole surrounding environment. Legal, cultural, social. What do you think, how long did it take to get the first Google Glass prototype ready? I tell you: one day. 1 day. (By the way, Tom Chi is the courageous product developer in this case.) And yes, we are very close to rapid prototyping here and we should take rapid prototyping as a role model more often I think. If you have an idea, but you are not sure if it is going to work, just quickly tweak something together and test your assumptions.

Is MVP a bad approach now?

No. At least not if it is interpreted and lived correctly - as a mindset in product development. And, if you choose a strategic approach. I think a variant like this might be a good idea:

1. Analyze and understand the customer's need.
2. Write the epics and user stories based on this need.
3. Disassemble the mammoth (so, the product) into meaningful parts. (A story map is a great way here.)
4. Create an Incremental Release Roadmap.

When I do this and listen to my customers, I will have created my MVP in one of the first sprints. You notice, this is not a thing that you have done quickly in one refinement. This is hard (product development-)work.

And here riskiest assumption tests are a good alternative if I want to quickly and efficiently test my assumptions. Just dare it more often.

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.