agreeing isn’t the last step

This was a big deal. Millions of dollars were spent to get to this point. On the call were resources in Hong Kong, S. Korea, and China. Not on the call were a team of other resources spanning from Florida to Hyderabad. The whole team would be waiting on the outcome of the discussion.

The topic, the first scheduled system outage. We needed to agree on a time and method for dealing with the interruption at a manufacturing facility. Mandarin was the primary language on the call. We let each section leader discuss the impact and their plans to overcome the disruptions of the outage.

I don’t speak Mandarin, but it was clear after about 20 minutes that we had an agreement that would work for everyone. Successful collaboration had occurred. We almost ended the call.

But agreeing wasn’t the last step.

Once we reached our consensus we needed to make sure that our plan to communicate and coordinate was smooth after all we just spent 20 minutes discussion what we’d do and when. How would we know when the when was happening?

How many times have you had a good plan go awry because we didn’t build in the communications plan?

Just as important as any agreement is the plan to execute that agreement. It may come across as tedious to talk about, but reminding your group that agreeing isn’t the last step should help them see the value in the effort.

The right thing to do isn’t always on the checklist

People often make checklists, and while they’re not bad tools they really aren’t the best tools ever. Most people who read English have their brain trained to read top to bottom left to right. What happens if the thing that’s the most important on your list isn’t what you remembered first and isn’t what you wrote first on the list?

Then there’s the question about who value to whom.

Don’t smirk. It’s real.

Different stakeholders will see different items on the list as having different values. At work, I measure each task I do based upon the value it has to the business (business value), project value (does it help us move the project forward), stakeholder value (something that improves the stakeholder experience). By measuring my tasks against their intended benefits I can easily adjust and pivot to doing the work that has the most value.

Often times though, the right thing to do never makes it to my checklist.

I saw Michele in the hallway the other day and she looked like she needed a friend. So I asked a question that allowed her to stop and take a breath and describe what was going on. As I listened she could see the value of her efforts. I could appreciate the challenges she was facing. The conversation was mutually beneficial.

Listening was the right thing to do.

But it wasn’t on the checklist…

100% accurate estimate

Kid you not I sit on a row at work with other project managers. One of the projects is over budget and sponsors are willing to increase the budget to get it over the finish line.

The project sponsor said that before she went to get the additional funds she needed a “100% accurate estimate.”

I’m not sure what reality she works in, but I’ve never seen a 100% accurate estimate.

If you have, please leave a note in the comments below.

Book Review: Project to Product

There are different vocabularies employed in the discipline of Project Management. This is one reason why PMI exists, to try and help the breadth of the discipline use a common language. In my library of project vocabulary I’m familiar with the following:

  • Army Vocabulary
  • PMI’s Project Vocabulary
  • Agile
  • DevOps

One thing different than PMI’s project vocabulary and that used in agile is the term used for the deliverable at the end of the project. In project management that deliverable is the project. In Agile, that deliverable is the product. The words sound similar enough but the distinction is significant. PMI’s focus is on the process that created the deliverable, while Agile is focused on the value of the deliverable to the product owner (stakeholder/business).

In Project to Product Mik Kersten drives home the important distinction between the two and how important it is to organizational survival to adopt a product focused mentality.

As tech giants and startups disrupt every market, those who master large-scale software delivery will define the economic landscape of the 21st century, just as the masters of mass production defined the landscape in the 20th. Unfortunately, business and technology leaders are woefully ill-equipped to solve the problems posed by digital transformation. At the current rate of disruption, half of S&P 500 companies will be replaced in the next ten years. A new approach is needed.

In Project to Product, Value Stream Network pioneer and technology business leader Dr. Mik Kersten introduces the Flow Framework—a new way of seeing, measuring, and managing software delivery. The Flow Framework will enable your company’s evolution from project-oriented dinosaur to product-centric innovator that thrives in the Age of Software. If you’re driving your organization’s transformation at any level, this is the book for you.

source

This was a way cool book to read!!!

In general it’s easy to see smaller deliverables as products, one of the messages this book is that it teaches you to see all your deliverables as products–even big ones. This book is about connecting it to business value at scale honoring lean, TOC, six sigma and showing how the understood foundation can be leveraged for the unknown future.

Photo by Pixabay on Pexels.com

On the fourth floor of our building sits a very large puzzle with the last piece outside of the boarder. It’s labeled with someone’s name on it waiting for them to return and finish the puzzle. This book is the missing piece in understanding the frustration with project management and why it’s processes can leave those who remain wanting even after the checklist is complete.

This book ranks high on professional application, but also has personal application as well in helping to see stuff as products capable of more than just satisfying their initial value point.

Intrinsics and Leadership

A few months ago I wrote about Project Management vs. Project Leadership.  The dichotomy wasn’t perfect, but it can be informative.  There’s also more to discuss.  One thing that wasn’t considered in that original post was the relationship between a supervisor and the employees as intrinsic or extrinsically motivated individuals.  In Daniel H. Pink’s Book, Drive he discusses how this difference impacts performance.

Extrinsically motivated individuals looks for external stimulus (positive or negative) in order to induce action. These are often seen as the carrot or the stick, and so much of our society is based on the idea that humans are sedentary and the only way to get them to do things is with either a promised reward or punishment.

Intrinsically motivated individuals are self-motivated. They like to solve the problems and puzzles in front of them for the sake of solving the puzzles. Daniel makes a compelling case for suggesting that we’re all naturally intrinsic beings who learn to be extrinsic based upon our experiences and in contrast to our nature.

An intrinsically motivated individual is going to respond to a project leader. An extrinsically motivated individual is going to respond to a project manager.

If it is in our nature to all be intrinsically motivated and we’ve only surprised this at some point then it would make sense that this intrinsic self of ours could be reinvigorated through the practice of project leadership.

The Chicken and the Egg

Tracking and understanding dependencies is a big part of project management. There’s been quite a few times when you map out a series of steps that are dependent on one another and you end up finding a situation where two things are codependent on one another. In English we call these chicken and the egg situations, based upon the quandary, which came first, the chicken or the egg?

In project management dissecting the chicken and egg situations requires some skill. This is because in real life the chicken and egg situations often means that one person will be asked to build something without having all the information. That person will move forward into new territory knowing that a significant portion of his work will have to be redone and result in rework. That’s never a pleasant feeling and I’ve also seen it lead to people feeling like their work didn’t add value–when in reality it adds a significant value.

food healthy dirty leaf

I’m generally not very funny. If it weren’t for the fact that I put my foot in my mouth people might get the impression I’m no fun at all. So I’ve been studying jokes–bad jokes–to help me be more funny. Why bad jokes? Because even a bad joke is so funny it sticks with you and brightens your day. One of my favorites: What did the green grape say to the purple grape? Breathe you idiot, BREATHE!

Recently, I’ve come across a bad joke about the chicken and the egg. It goes like this.

I ordered a chicken and an egg from Amazon. I’ll let you know.

Turns out you can answer the age old question by shopping online. Who knew?

The Amount of Work

I had someone try to tell me thank you for my work on a project recently.  I had earned the compliment, but felt awkward accepting it. I didn’t do all the work. I was just part of a good a good team.

I needed a good response and despite how witty I might appear on this blog I’m not always quick witted. This is one of those exceptions. I actually thought of something good to say.

I told him that the amount of work I did compared to the amount of work the team did was really small and that I was grateful to be counted as a member of that team.