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.
Justin is a good friend of mine at work and a Six Sigma Black Belt. Over lunch the other day we were talking and he explained how sometimes people will tune past their optimum. While the conversation was casual the lesson in life seems to be worth sharing.
What this curve does is enable the ability to predict the outcome of a particular operation. In manufacturing that operation might be coating a particular widget. Not all widgets get coated equally and some will fall outside of the quality specifications. This curve would allow you to predict how much of those widgets have to get tossed due to poor quality. Used properly you can use it to help manage the process to reduce the number of wasted widgets. That’s a very basic description, but for this post it will need to suffice.
On the graph you can see the percentage of good output and the Greek letter Sigma symbolizing the deviation from the optimum output. Ideally if you can manage a process down to only 6 Sigma (three plus and three minus) then the process is considered to be stable. Stable processes can be improved. Unstable processes cannot consistently be improved.
An optimum output would look like the graph above, but the curve would be taller and skinnier in the middle.
The time period used to create this graph also matters. When Justin was using it for a particular part of the manufacturing process (bagging) he was taking a daily average. This meant both shifts were combined. He had a wide curve and wanted to make it skinnier. When he reworked the data for each shift he noticed that neither shift was working their optimum.
Each shift would tune this particular machine to where they knew the performance was good enough. In the process they would inadvertently tune past where the machine could work at its optimum performance.
Justin explained how the machine was complex and each shift had recorded different settings in their notebooks to know how to set it for good-enough performance. You could image that after fiddling with the machine for hours on a difficult shift that once you finally figured out settings that worked for you, you stuck with those settings. Think of the pressure. All the other parts of the manufacturing are stopped because the thing you’re working on isn’t performing right. Everyone on your team would know you (rather your machine–but sometimes it’s hard to separate people from the problem) were the one holding things up. Once you finally got it *working* you’d probably feel relieved and just want to move on.
While we don’t all work in manufacturing we’ve probably all had those experiences where others were waiting on us and the pressure that comes from that attention. Inevitably we do have those parts of our personality and how we perform that are based on experiences that were hard–experiences that we don’t want to live again. What if those experiences taught/encouraged us to tune our habits close to our optimum while still missing it entirely?
Six Sigma falls in the discipline of continuous improvement and while we may get some things right or right enough to succeed I’d like to believe that all of us in some ways have tuned our habits and processes past our optimum. As challenging as it was to get to your comfort zone, maybe it’s time to step out of it to see if good enough really is how you want to operate going forward.
I’ve been around software guys for years and have heard the phrase pull request long enough that I was embarrassed I didn’t exactly know what it meant. I had a general idea, but not one that was clear in my mind. I also knew that this was one of those technical questions where I would grok it better if I talked to someone in person. So, I found one of the smartest guys in the building when few people were around, drew out a kanban board (above) and asked him how a pull request was done.
I got my answer, but to my surprise when I searched for images none of them had anything to do with kanban boards. They viewed pull requests as off-track activities that needed to get pulled back into the main branch.
That’s interesting, I thought, because that understanding means that items on the main branch wouldn’t go through the review process that is a pull request. That doesn’t jive with the reality that I’ve heard pull requests being used on main branches and appendages of software development for some time. I think the definition needs to be updated, and the diagrams need some competition. So, here’s my contribution. It’s a kanban board view of a pull request.