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.
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:
PMI’s Project Vocabulary
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 ProductMik 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.
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.
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.
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.
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.
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?
I’d like to start off by pointing out this is not a true dichotomy. Project Management and Project Leadership are not exclusively on the same spectrum, but there are differences and placing them as opposites on the same spectrum can provide some insights into the discipline and our behavior.
Transactional vs Contextual
One of the ways I’ve seen the differences is in the way PMs conduct themselves at meetings. I’ve seen great people use meetings as control points where they’re focussed on accounting for the progress on a particular deliverable and only the progress. The dialogue usually includes something like “Tim, can you tell us the status of XYZ deliverable?” Moving around the room they’ll use a slightly different line with the next person “what’s the progress on EFG?” “When will this be ready to hand off?”
These are closed transactional questions that don’t lend themselves too much more information than could be achieved by a bar graph or spreadsheet. Why pull people into a meeting for a status you could get from a website?
In contrast I’ve worked with others who don’t directly focus on the progress of the deliverable, but instead will start with focusing on the person and their team. More than one time I’ve been a part of a meeting where a project leader will ask someone how it’s going and in the course of the response they’ll get a full status update as well as context that helps to understand the challenges that team faces. The style that only focuses on the status loses important context.
I’ve often said that Lean can be simplified into the sentence of “making work for the next person easier at the point of hand-off.” This is hard to do without a shared understanding among the team of the context the next person has to operate in. Shared context helps to make the work of the team visible it’s something leaders strive for and managers miss.
Our Reality’s History
Any time you see the word management written it’s probably referring to a definition widely influenced by Frederick Taylor. The industrial revolution moved work from disparate and disconnected environments and consolidated them in factories. Very quickly people who went from one generation working with a handful of others in agriculture found themselves working with hundreds of others.
This drastically changed the way the work force operated. It also mean that there was a large diversity in work ethics and work experiences. This was especially true in the United States when immigration meant not only a workforce new to the job, but new to the language and culture of their new country as well. Non standard processes and perspectives can lead to significant issues with production.
Frederick Taylor saw how these problems impacted the productivity of manufacturing and performed studies and wrote about the solutions he found. His book, The Principles of Scientific Management has been widely influential, but because of his generation it contains a few flaws that encourage transactional behavior.
Taylor’s model relies very heavily on class distinctions between Management and Workers. Managers get paid to think. Workers get paid to do. Ideas come from managers studying out the problems to improve progress along their measurements.
Can you see how this could lead to some issues? Firstly, the measurements of his era where the best they had, but are clearly wrong. Cost accounting’s flaws translate to a great deal of poor behavior and encourage waste in a system. If no good ideas could come from the employees then how valued do you think they will be and how will their sense of value improve their performance? One needs only read the story of the NUMMI Plant in Smarter, Faster, Better to see what a difference employee empowerment can make.
Taylor’s definition of management was highly influential during World War II when the term Project Management first appears in the literature. Today the heritage of Project Management is the transactional manager. PMI has made huge strides to address the issues this causes (there’s a whole section on resources now), but its literature isn’t quite divorced from the history of the transactional management style.
The history lesson and meeting observations are helpful to identify and understand the issue, but they’re not terribly prescriptive on how to move forward. Here’s some additional tips that can help improve the project’s performance and your stakeholder experience:
Change your vocabulary. Use the work Project Leader instead of Project Manager. It’s amazing how powerful a word change can be.
See the symptoms. If you’re frustrated then you’re managing, not leading. Leaders help the team through their trials.
Practice listening. Get to the point where you’re comfortable being quiet and asking follow up questions that show you heard the person and you care about the challenges as they see them. “What are the obstacles you’re facing?”
Help create the team. Leaders help members of a group feel like they’re part of a team. One of the best ways to encourage this is to provide positive reinforcement. Starting your team building by telling someone in a meeting they let the group down is not an ideal technique. Instead help the group see that the challenges of one person are group challenges and help that person with the challenges feel they’re not alone.
While it’s not true that Project Management and Project Leadership are opposites exaggerating the differences helps to illustrate that there are differences between the two. These differences are part of the heritage of the project management discipline being heavily influenced by Frederick Taylor’s scientific management. We’ve got some practical steps we can take now to change towards project leadership and to close the gap between the use of project management and project leadership in our actions and in our prose.
Of course, you could take another route and apply the techniques in The Art of Demotivation, or follow all the examples of Dilbert’s Pointy-Haired Boss.