Modern PM

by
Modern PM is a blog about modern project management in all its facets: classic, agile and hybrid. I will share my thoughts about the developments, trends, problems and challenges we face in our daily routine as project workers — and hopefully some solutions.

About this Blog

RSS

Recent Posts

Perfectly presenting the project status

Half-life of knowledge

Two hats in one (or: what we can learn from a children's book)

Is the minimum viable product really the answer to everything?

Thoughts about having an icebox on your Kanban board

How an impediment backlog can help us to get our issues under control

Impediment Backlog

Of unpleasant surprises

Imagine yourself managing a project where not a single problem arises during progress. No issues, no uncovered risks, nothing. A nice idea, right? And now reality. Each and every one of us encounters problems and obstacles throughout every single project. Even with the best and most granulated Risk / Impact Probability Chart, we won't have all the risks on the radar. And even if we capture and reduce risks before the project's executing phase starts, over time all kinds of hurdles will be popping up.

Of course, you can handle it in a way that seems very prevalent to me. Just ignore the issues and hope that they will disappear. Funnily (or actually tragically) they never do that by themselves.

Let us have a look at Scrum

Old project stagers have to smile when Scrum Masters are proudly showing their impediment backlogs. Because, even if the average Scrum Coach is trying to tell us that collecting problems that are slowing down the team is an invention of Scrum, such lists have been there since project management exists: Issue Management is the magic word here. Such emerging problems have to be

  1. collected,
  2. clustered,
  3. prioritized.

And most importantly, they have to be managed. As always and everywhere in project management: it needs someone to take care for. Someone who is collecting and maintaining these issues. But which format is the right one for such an issue list?

Let's take a closer look at the Impediment Backlog format. Because we can find several takeaways there. But first things first, what is that? An Impediment Backlog is a document (analog or digital) in which a Scrum Master captures all the stones that are in the way of the team and that have to be cleared away. These are usually collected during the Daily - the brief meeting during mornings where everyone tells what was done yesterday, what's going to happen today, and what's stopping them from being productive (or even more productive).

Many small stones are cleared away easier than a big one

And here we can notice something. Such a Scrum Master does not (only) project work, but also a lot of operational work. Daily business. Of course inside a project environment. And, of course, the border is indistinct and depends a lot on people, phases and, above all, needs. But such an Impediment Backlog is mostly consisting of "small" problems. Issues at the daily business level. We won't find many huge - and huge means insoluble in that form - chunks there. In other words, in such an Impediment Backlog we have many issues that we can get rid of very quickly and easily. Many small stones are cleared away easier than a big one.

Project Risk Management

Prioritization is half the battle...

Another big advantage of such an Impediment Backlog is that it is not just a list, but a backlog - that is, a prioritized list. The most important - in our case the most serious - problem is always to be found at the top. This helps me to help my team. The issue that bothers them the most is the one I am going to tackle first.

..and clarified responsibilities are the second half

And such an Impediment Backlog is also a very elegant and easy solution for responsibilities: the Scrum Master is responsible for all the impediments that are on the backlog. No RACI matrix, no pushing around and no denying. There is one person and that one takes care. This does not mean we can not delegate topics that are on the list. But the responsibility should lie with the project management.

That may seem out of place at first glance. Why should we, as project managers, carry the can for other people? But we are talking about issues here. These are either risks that have become alive or even problems that have arisen unexpectedly. In my opinion, we are facing a roof that is on fire in that case. And the solving of such issues should be a particular concern for project leaders. But you all see it that way, right? And so it is only fair that we have the responsibility for resolving the impediments in our own backlog. My two cents.

Where there is light, there is also shadow

That sounds almost too good to be true. And in my experience, Impediment Backlogs also have some weaknesses. Or to be more precise, their handling has. I often see well-behaved Scrum Masters who are writing down all of the topics their team tells them about. In fine writing, with a box to tick it off. And then they grab all of their colorful marker pens and start drawing circles around and lines between those list items. In my opinion, impediments (or issues in our case) are tackled the moment we hear about them. They are far too important not to start immediately. Only when I have to wait for something - that is, a dependency - the issue becomes part of the backlog.

"Open your eyes, open your ears, Helmi is here"

Back in my childhood days (a long time ago) there was a television series in Austria called Helmi, which had the purpose to teach us careless children the responsible use of the traffic regulations. And in the show's title song, it said, "Open your eyes, open your ears, Helmi is here." And we should all take that to heart. Even if my team is holding a Standup Meeting where they are talking about any stones in their way every single day. Who says that they really are thinking of every single one? And who tells me that an issue does not show up two minutes after the meeting ends? So we should always keep at least one ear on the team.

And an important notice (a point that is discreetly concealed in the Scrum Guide). We should not ignore the distinction between issues and risks just because one is using an Impediment Backlog. Even if the two words are used quite synonymously. But a risk has no business on an issue list or in an Impediment Backlog! For risks we have our good old Risk Management, all with plan, identify, analyze, execute, and so on. Only when a risk becomes alive it becomes an issue.

So

Maybe we project managers should include the term Impediment Backlog in our vocabulary. Such a prioritized listing of all issues that are blocking our team - and thus jeopardizing our entire project - and that we can (gradually) work off is a valuable tool for our daily project work. Because even without such a list it is already complicated enough.

Posted on: May 27, 2019 09:23 AM | Permalink | Comments (5)

Presenting done right

Categories: Modern PM, Presentations

Four points, that make the difference between a good and a really good presentation. (And no, that's not me in the picture.)

Presenting projects

We project workers spend a lot of time communicating. According to the PMBOK Guide between 75 and 90 percent. Half of this time we spend with (hopefully) active listening. The other half we are presenting, lecturing, and telling different people different things. In short, we are transporting information. And in my opinion, it is incredibly important not to transport just some thing, but the right thing. I know, right now I am sounding like a motivational poster. Na no na ned, as we say in Austria - of course. Of course, we do not communicate just something somehow. Nevertheless, I can see exactly that pretty often. But what is the essence of a good presentation? 

Of course, a lot is depending on the frame of my presentation. Is it formal or informal? Am I about to give a brief status update to management, am I hosting a two days long scope finding workshop, or am I having a team meeting? But after nearly 20 years of holding and experiencing presentations, a few elements have emerged that are valid everywhere. And at this point it is the same as with every craft: if I know my 101 by heart, I can concentrate on the nitty-gritty. And the nitty-gritty, ...

Cheap Trick

..the nitty-gritty is less the way of presenting, but rather the content of the presentation. And yet, I am regularly seeing people standing on a stage and rattling off their NLP-Hocus Pocus. Cheap trick, so to speak. What is the talk about? Who cares. It is all right as long as the audience is mesmerized by all those sleight-of-hand tricks. Only, the audience does care. They want to hear some content.
And I do not mean that it is enough to be a geek who is mumbling a sermon to himself. It is about communicating relevant content. Not relevant for me, but relevant for my audience. Tailored to their particular level.

And please do not misunderstand, I do not mean that craftsmanship does not matter. Phrasing, timing, patterns of movement, all important things, no question. But not to call attention, but to communicate my content effectively to a larger group of people. Just as the Ri in Shuhari (and yes, I know, many of you guys are critical of Shuhari - and you are right; I am using the term as an analogy here).

Junior Woodchucks camp

It does not matter if someone is one of those people who are moving in with a stack of moderation cards, or - like me, I admit it - to those who prefer to conduct their presentations on the fly. In any case, there is one particular secret behind a good presentation: an incredibly intensive preparation. I'm not talking about the presentation itself, but about the topic. How can I tell others about a topic, if I am not having a good grasp of it? Not at all, in my eyes. It is necessary to know more than my listeners. Otherwise, such a lecture is a waste of time for all involved.

Walk like a duck, quack like a duck

The next duck-heading, I'm sorry, I can not help it. But it just fits too well. Let us switch the meaning of this witticism: if I wade like a duck, I will quack like one. That means, you should, and you have to pay attention to a proper posture in your presentations and moderation. Why. Two reasons:

  • When I am standing around like a potato bag, I will appear like a potato bag standing around. And let us be honest. When a bag of potatoes is telling us something, we will meet it with a solid amount of wariness. How does it know all these things about which it claims to be an expert? So we should use this bias for ourselves and stand straight and upright. Head up high, even if the neck is dirty. (And shoulders down.)
  • I do not know if anyone of you ever heard a potato bag speaking, I certainly did not. But I have heard many people speaking that have a posture like a potato bag (and that's enough potatoes for now, I promise!). And they are all mumbling, as if they are not getting enough air. And how should they get enough air, when their lungs do not get enough space. So again: head up high, shoulders down, back upright. Just like Mom told us.

"Here's looking at you, kid!"

Finally, our headlines are leaving Duckburg. My last point is a realization. When you are standing in front of a group of people and give a lecture, there are many faces. So virtually a 1 to n relationship. But turn the situation around. If you are one of those people in that group, technically it is still a 1 to n relationship, but for you, it feels like a 1 to 1 relationship at that moment.

Good presenters manage to give every person in the room the feeling that the presentation is less like a presentation but more like a personal conversation. And I'm not just talking about looking into eyes after eyes. (By the way, the German translation for the above film quote is literally "Look into my eyes, kiddo." - which brings us back to the cheap tricks from above.) Looking into eyes is only the beginning (not just when it comes to presentations, but that is a whole different story). Ask yourself. Would you be able to give that presentation to just that single person? Because from their view that is exactly what is happening right now.

So

Regarding that there are so few points that make the difference between a good and a bad presentation, I've already written way too much. So here is my crisp summary:

  • Content, content, content - they are not here, because you look so great and master so many cheap tricks.
  • Preparation - you also won't take part in the Olympic Games without training.
  • Posture - this is followed by good breathing, which is followed by a pleasant voice, which is followed by a good presentation.
  • Look a guest in the eye and imagine if you could deliver your presentation just to them. Because from their point of view you do just that.

And I know, those points alone do not make a good presentation. But for me, they are the basis for one. Because without these four points, it will definitely be a not-so-good presentation. And unfortunately, there are far too many of those. But that is another topic.

Posted on: May 23, 2019 01:57 PM | Permalink | Comments (9)

The dark side of agility

What agility has to do with (much) efficiency and (often not so much) customer value, and why cookies are not always the right choice.

The dark side of agility

“Come to the dark side. We have cookies.”

First things first: I am seeing today's topic through the eyes of project management. And through that lens agility is a great idea. But what exactly is the great thing about it? Why do many people and organizations embrace "agility"? Because it is different. Another approach to getting things done. A different approach than the way many organizations are using. Because let us be honest. Even today, there is still an incredible number of companies whose leadership firmly believes that C2 - Command, and Control - is the best way to have a productive and thriving business. And if you are part of such an encrusted, sedated structure, an agile approach sounds great. Of course, it does. Daring though, but very tempting. Faster decisions, faster work-done, less time-to-market. Different.
But is different better?

Arguments

I hate to be the naysayer again. But what is the dark side of an agile approach? And let us just ignore the arguments that I am hearing from a certain type of software developer over and over again ("Agility is bad because I've done well without agility for 20 years. That was a great time! We didn't bother about those customers and we spent every night fixing bugs.") - so, quotes, arguments, quotes. But I am sure you all have heard this a couple of times.
A few points that are - in my opinion - rather out of line when it comes to agility (sad to see what a buzzword this has become):

Not every company is manufacturing software

Agile methods have an insanely strong focus on software development. Yes, it is getting better. But whether if it is ASD, Scrum, DSDM, or - God forbid! - SAFe. In their origins, some of these methods were developed by programmers and most definitely had programmers in mind. And even the agile manifesto is still officially called Manifesto for Agile Software Development. And where do we see agile methods introduced in companies? In my observation, in the overwhelming majority of cases, it is the IT department or more specifically software development.

But what happens, when the IT is working and thinking agile, but the remaining 95% of my value chain is not? Chaos at the interfaces. And yes, Kanban can help a lot. But - and now I have to be careful - in my eyes (and the eyes of many others), Kanban is not part of the agile world. It is more Lean Management. Similar matter altogether, but another. Matter altogether. And yes, your magic-agility-coach told you otherwise, I know.

Pussyfooting

Kaizen and a steady improvement in small steps are fine and dandy. But every now and then it just takes a bit of Kaikaku. The big time. And I won't be able to achieve that if I am spending my time thinking in User Stories. Because that is contagious. And even if the strategy on the top level is good - the best strategy won't help me if the visions get shredded beyond recognition on their way to the implementation level. But that is what I am observing in many organizations that switch to agility: a rigid set of rules is replaced by another rigid set of rules. And then all are writing small User Stories and eventually everyone is thinking small. Good as gold. However, I will not experience any movement.

Standstill through prioritization

Agile methods live from constant prioritization. But, if only the currently most important things are implemented - who will take care of the right things? Those who may not be the most important at the current situation and time (and in my little world), but on a larger, more global scale. They fall by the wayside. And that is how I slow down my organization enormously in the long term. And at some point, I arrive back from where I started: Standstill. Standstill through prioritization.

Efficiency is not always the same as customer value

Agility creates teams that are maximally efficient. This pleases management and controlling. Agility thus also creates teams that have completely lost sight of the customer value. And that is also my main criticism of the way agile methods are often interpreted and lived.

But why is the customer value neglected? One word: velocity. At some point, teams only have this number in their heads. The average Story Points done per Sprint. The team's pace. And everything is subordinated to this team's pace. People will not rely on their own gut feeling. How much work I can accomplish as a team in the next few weeks. No, people are calculating. Because the Scrum Guide says so. (And here we are again with rigid systems.) So everyone is drawing down the line on their burn-down chart. How many Story Points have they done today? Rather than talking about what value has been generated for the customer. Instead of talking about how they have supported and advanced their own organization today. And many Scrum Masters participate in this madness, without even questioning it once. Because the Scrum Guide says so. (And yes, I'm just cynical and unfair now, I'm sorry!)

So what does that all mean?

What can I do better when talking about the above points? How can I avoid the negative and reinforce the positive?

The most important thing first. If I want to change my organization, I should consider whether agile project management methods are generally the right ones for the change part (ie the projects). If I am not better off looking from project to project - where am I on the complexity matrix? - and then deciding which approach to choose. Predictive, incremental, iterative, whatever.
And the second most important point for me: those who agilize organizational units are completely wrong in my eyes. What has to be agilized is products and services. Or their production. And here I am talking less about a set of rules, but more about a philosophy, a mental attitude. Since I have to convince people, not just send them. But to whom am I telling this.

All in all, agility is certainly a good thing - as long as I am using it for the right problems. And it's not outdated (even if agile project management methods are much older than the trend would have us believe). But maybe there is no one-size-fits-all when it comes to project management. And so maybe it is time for something new again. This time, not something different, but something better.

Posted on: May 18, 2019 10:14 AM | Permalink | Comments (14)

Jazz improvisation and teambuilding

 

What good teams have in common with good bands.

Jazz improvisation and teambuilding

As a trained guitar player I love some good jazz. Well, I love all kinds of music. But even those who are not much into jazz music at all, have to admit that they are astonished when musicians seemingly effortlessly deliver the wildest improvisations. But what is behind this genius? Dark arts? It is said that Jimi Hendrix never had a single music lesson in his life. So is it all talent? Or is there more than just pure musical sense? And what does all this have to do with teams?

First, let's clarify what jazz improvisation - or generally improvisation in music - actually is. Improvisation is when one or more people make music without previously written down fixation. That is, the played notes and melodies arise spontaneously.

Again, what does that have to do with teams?

In our daily project work, we are experiencing this every day. This interaction of people, which has not previously been fixed. And even if our planning is good and detailed and almost perfect - at the implementation level we are owing much to the spontaneous ideas and inspirations of individuals.

And here is our big 'but'. As in making music, this is only working when the people involved know exactly what they are doing, and are prepared well.

Learning from the best

Here we can learn a lot from musicians like Miles Davis, Chet Baker, or Judy Carmichael. Good improvisation has a rock solid basis. Because none of the above just went on a stage and started playing music. On the contrary, there is a lot of training and rehearsing and preparation behind it. So spontaneous improvisation is not so spontaneous at all. And it is not totally free either. There are chords and scales and a lot of formality. Does that ring a bell? Let me say it in other words: there are methods and processes and a lot of formality. Ha! Our daily business, right?

Of course, I can handle projects without these methods and processes. And there are certainly some Jimi Hendrixes of the project management world, who can do without formality and without their company going bankrupt. But personally, I have never experienced a haphazard project that did not go up in flames at some point. Did you?

Jazz and project management

So what are these good jazz bands doing and what lessons can we draw from them?

  • Formality
    Even free jazz is formal. And even completely self-organizing teams are operating within a framework or a ruleset. Be it Scrum, PMBOK, DSDM. But there is a formal basis for our teamwork. And we should pay particular attention to this basis.
  • Clear rules
    Well-playing musicians follow clear rules, such as key, scales, tempo, etc. And all good teams I’ve met have defined certain basic rules as the cornerstones of their cooperation. For freshly assembled teams, these are often the corner pillars and artifacts of the frameworks used. However, in teams that have already completed several Tuckman rounds, I often find very clear, concise rules that all members of that team are adhering to and which - most importantly - have been put together and accepted by everyone.
  • Agreement
    Functioning teams all have some things in common: their members listen to each other, the atmosphere is open and appreciative, decisions are made together. And also in the musical improvisation, it is about togetherness. Often there is one who - literally - sets the pace, but before entering the stage the band agrees on the most important basic rules.
  • And most important, mutual trust
    When I can rely on my colleagues, I am able to focus on delivering great work. And only then I will deliver top results. On stage as in the office or at a construction site or.. you name it.

Conclusion - how can I use that for myself

It does not matter if I am building a team for a big project from scratch, or if I am working with a veteran group. But I always try to create an atmosphere in which teams can live those above points.

I can not force formality and rules. This has to come from the team. I can only pave the way and make suggestions. And mutual consent and trust can also not be created on command. They come naturally when team members feel secure. And only when everyone has agreed on basic rules and everyone knows how things are going, valuable improvisation can arise.

Jimi

Oh, if anyone still wonders if it's true that Jimi Hendrix never had any music lessons: Jein, as we say in Austria. Yes and no. Billy Davis (https://en.m.wikipedia.org/wiki/Billy_Davis_(guitarist)) showed him a few things on the guitar. And Buddy Guy (https://en.m.wikipedia.org/wiki/Buddy_Guy) once claimed in an interview, that he had given Hendrix some lessons. So by and large, Jimi Hendrix is self-taught. But that is a different story.

Posted on: May 14, 2019 06:23 AM | Permalink | Comments (4)

A plea for change

Agility and why some organizations fail. A train of thought.

Some organizations are like a pond. And someday they are trying to install a circulation system into this pond with lots of effort and money. Because there has to be more movement in here. So they are asking external consultants to explain to them why this one circulation plant - and only this one - is the best and most awesome. And they are asking vendors to install the machine. And then they need those external consultants again to explain to them that the instructions should be followed exactly. Otherwise fire and sulfur. And we can't forget all those additional people that are hired to operate the machine. They have no experience whatsoever in running a circulating system, but they are young and dynamic and they know their stuff. Because they are millenials.

And then it is here, the big day. The circulation plant is put into operation. All the controls are turned on, the machine rumbles and spits smoke and is loud and eats loads of electricity. And the water in the pond is whirled and mixed up. And somehow the machine does not whirl as the organization has imagined. And somehow the machine coughs and sputters every now and then. Although they have followed the instructions so closely. So they call for more external consultants. And with those come the conversions on the machine. And then the circulation plant is thrown away and replaced by a new one - now really the best and most awesome one. At least that's what the external consultants are saying. And they have to know, they are building circulating systems in and out day in day out. So it's being rebuilt a bit more. And at some point, the circulation system is bigger than the pond and it is still coughing up smoke and is still eating electricity and millenials and is still making noise and is still whirling around the water in the pond wildly. And everyone is standing on the shore saying, "So much movement. Great!"

Only: if you come back a year later, the pond is still in the same place. And in five years. And in 30 years: the pond is still in the same place. And there, leaning on a tree on the shore, are a few shovels. And you just have to pick up those shovels and dig and then you would have a river. Without circulating system. Without a consultant. Without additional people. At no extra cost.

Then why do some organizations incorporate circulation equipment instead of shoveling? Why do they deceive themselves that the whirls in their pond are movement? Because these organizations are full of people who do not want to change a thing. People who have come to their positions because they do not change a thing. People who shape the culture of their organization with this attitude: Change is evil. These people are not stupid now. They notice that the carousel turns faster and faster. They feel the winds of change constantly changing directions. They know exactly what that means: disruption. And they know that only those who change are flourishing. That only those who live change are surviving. No big jumps planned for years. Small, constant steps. More kaizen, less kaikaku. More river, less pond.

But these people do not want change. Deep inside, everything is balking against it. Of course, they have been doing well for many years - often for decades - while avoiding change. That things would have gone even better with an open attitude? They know deep inside. That they do not exist because they deny change, but because coincidence meant well for them? They suspect deep inside. But still: better, we leave everything as it is. As it always has been. And so circulation systems are installed. And so external consultants live a fine life. And so people stand on the bank of a stagnant water and say, "Great! So much movement." Only they will not be getting anywhere.

Let us convert these people. Let's open their eyes. Let's take the shovels and dig. Let us be the river.

Posted on: May 11, 2019 12:11 PM | Permalink | Comments (1)
ADVERTISEMENTS

"One never needs their humor as much as when they argue with a fool."

- Chinese Proverb

ADVERTISEMENT

Sponsors