Project Management

Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Leading Through Crisis Means Leading Through Context

"It's the end. But the moment has been prepared for." - retirement lessons from the Doctor

Just because they are non-critical, doesn't mean they are not risky!

Just because they are non-critical, doesn't mean they are not risky!

How will YOU avoid these AI-related cognitive biases?

Categories

Agile, Artificial Intelligence, Career Development, Change Management, Communications Management, Decision Making, Governance, Hiring, Kanban, Lessons Learned, Personal Development, PMO, Portfolio Management, Project Management, Resource Management, Risk Management, Risk Management, Schedule Management, Scheduling, Tools

Date

Do your performance evaluation and recognition systems support cross-functional teamwork?

Categories: Agile, Project Management

linkedin twitter facebook Request to reuse this  

While it is usually Wally who openly expresses those thoughts which we normally keep to ourselves, Dilbert is letting his inner voice do the talking in today's strip. Let's imagine for a moment that Dilbert's co-worker is part of a cross-functional team which Dilbert is part of. Dilbert's response might seem unnecessarily blunt, but this behavior is not uncommon in those companies which place an undue emphasis on individual recognition or which don't require managers to actively solicit feedback from outside of their own teams.

While most of us would consider ourselves to be helpful, without some measurement and organizational encouragement our willingness to help someone is likely to be reduced by our need to finish our own work as we know the latter is what is measured.

In many organizations, functional managers are under no obligation to solicit feedback from others about their staff's performance. While these managers might ask for input from within their own team, they might be reluctant to contact those co-workers who report to other functional managers. If they evaluate their team members' performance purely on achieving functional objectives or on how they interacted with others from within their own team, they might not consider whether someone works well within a cross-functional team. While this type of feedback is certainly available from project or other functional managers in a matrix structure, the functional manager might not always be open to soliciting or acting on the feedback. When objective feedback from co-workers outside of a manager's team is a required component of formal performance evaluations, it encourages both managers and team members to look beyond the walls of their own silos.

It is also quite common to find generous enterprise-level budgets for individual recognition but not as frequently for team recognition. With strategic or large projects, a project manager might have sufficient influence to secure budgetary approval for team-level rewards but this is usually not the case on smaller initiatives. Without equal weighting given to both individual and team recognition, it is no wonder that team members will prioritize individual success over that of the team they are on.

We want team members to feel confident that if they ask for help from a co-worker who happens to report to a different manager that there is a strong likelihood that they will get it. We would like to encourage team members to be willing to slow down their own activities if it helps their team get ahead. But when environmental factors such as performance evaluation systems and recognition programs discourage such behaviors it can be difficult to build high performing cross-functional teams.

Posted on: November 17, 2019 07:00 AM | Permalink | Comments (11)

Don't be like a squirrel hiding nuts with project lessons!

linkedin twitter facebook Request to reuse this  

As weather gets colder, it is common to see squirrels digging holes to bury nuts and other food items to feed themselves when resources becomes scarce during winter time. But given the volume of nuts which are required to sustain squirrels through the long winter months and the large areas covered by an average squirrel, they often end up forgetting where they have buried all of their treats. While observing the little fellow I captured in the photo above, I was reminded that we are not so different from our furry friends.

Whether we capture lessons over the life of a project or wait till the end of a phase or the project as a whole, we frequently end up forgetting most of the lessons we have foraged.

Squirrels will eat a few nuts while they are in the process of gathering them. In the same manner, there will be certain lessons which we can implement right away.

But what of the remainder?

If we just store them in a repository or, worse yet, in standalone documents or distributed Wiki pages, we are no better than squirrels who have forgotten where they have buried their nuts.

Thankfully, unlike squirrels who are unable to invent and use GPS-based nut finders, we do have a few options:

  • Enhance our standards by incorporating identified lessons. This option works well as there is no need for practitioners to search for lessons but over time it could result in overly prescriptive, bloated standards.
  • Share lessons in community of practice meetings. One approach would be to leverage the oral traditions of storytelling from our ancestors by taking dry, theoretical lessons and make them come to life.
  • Develop playbooks or other types of practice-based learning offerings for practitioners. These would offer identified lessons as options but not as prescription.

Putting the "learned" back in lessons learned begins with doing a better job of learning from the lessons we have previously identified.

Posted on: November 10, 2019 07:00 AM | Permalink | Comments (11)

I may be a "Crazy Fool" but I consider the A-Team to be agile!

Categories: Agile, Project Management

linkedin twitter facebook Request to reuse this  

When teaching agile classes, I'm occasionally asked if I could provide an example of an agile team from cinema or television. While the first Avengers movie does a good job of illustrating Bruce Tuckman's stages of team development (especially storming!), they are far from being agile.

The example I most frequently provide is that quintessential 1980's TV show, The A-Team. If your only exposure to The A-Team was the horrible 2010 movie starring Liam Neeson, you owe it to yourself to watch a few episodes of the original series. Keep in mind, this was the 80's so the show does glorify violence, isn't very politically correct and shows many tropes from that era, but it is still worth seeing!

Here are a few of the reasons for this:

  • The team is self-managing. True, they have been disavowed by their government and are being hunted by military police for a crime they didn't commit, but with each episode where they help a new client they figure out their way of working without being mired in bureaucracy or seeking guidance from outside the team.
  • Colonel John "Hannibal" Smith is the leader of the team, but acts as a servant-leader. While he leads planning efforts for their missions, he does this in an inclusive, collaborative manner and will defer to his other team members during the execution of their missions.
  • Plans are created, and Hannibal loves it when a plan comes together, but they are also willing to throw the plan away when it is no longer realistic.
  • They exploit the diversity of their team rather than being constrained by it. Bosco "B.A." Baracus might call H. M. "Howling Mad" Murdock a "crazy fool", but he respects Murdock's ability to fly almost any type of aircraft. Each team member brings a different, but complementary skill set to their missions. In this regard, they are a "whole team". Each is highly skilled at what they do which could have resulted in ego clashes, but they always put the team ahead of themselves.
  • They are comfortable with complex, uncertain situations. Every episode challenges them with a unique mission where their resources are constrained but they still manage to put together creative gadgets and weapons with common household items to help them succeed.
  • There is a high degree of psychological (if not physical!) safety within the team. They operate with true radical candor - while they care deeply about each other, they don't pull any punches when providing constructive feedback. They are also very supportive when a fellow team member takes a risk - they will always have that person's back!
  • They are working towards a shared, strategic vision. While most episodes focused on their helping clients through difficult situations, the team continued to work towards their overarching goal of clearing their names.

Finally, they are long-lived and stable, and as I wrote in my article from last week, this helps to overcome many of misinterpretations which can occur when we first work with someone. This is best illustrated in the following quote from "B.A." Baracus:

B.A. Baracus: You learn to love him, Mama. But it takes a long time. (Referring to Hannibal)
Amy: That's the same thing he said about you.

 

 

Posted on: November 03, 2019 07:00 AM | Permalink | Comments (10)

Understanding the mismatched is another benefit of long-lived, stable teams

Categories: Agile, Risk Management

linkedin twitter facebook Request to reuse this  

In his latest book, Talking to Strangers, Malcolm Gladwell writes about the problems which can result when we expect that there is alignment between how people act and how they really feel internally. Gladwell call this the transparency problem and provides multiple examples to illustrate the challenges we face when we assume that what we see is what we get.

He presents the assumptions which Neville Chamberlain made in the years leading up to World War II based on the meetings he had with Adolf Hitler. Chamberlain assumed that Hitler was being genuine when he indicated that he had no interest in starting a major conflict in Europe and yet his near term actions clearly showed that this was not the case. He talks about the difficulties which judges face when having to decide whether or not to grant bail based on not only case information available to them but how an accused behaves when they are in front of the judge. And he writes about the Amanda Knox case where Italian authorities assumed that she was guilty of murdering her roommate primarily because of her behavior when she was questioned after the incident.

Gladwell sorts people into those whose external behavior matches what is happening inside of them and those who don't. We are quite good at identifying matched people. In fact, Gladwell indicates that our ability to detect when a matched person is lying is almost as good as that of law enforcement experts. What's chilling is that when dealing with mismatched people these experts are no better than we are.

It is not that assuming transparency is a bad thing to do. As Gladwell states, Charles Darwin felt that transparent behavior was critical to creating trust between strangers which enabled our species to survive.

But what's the relevance of this to project delivery?

When interacting with those who we've never worked with before, most of us default to expecting transparency. When someone appears to be acting in a negative manner, this assumption might result in us becoming offended. Alternately, we might be getting warm, friendly vibes from a team member which causes us to assume that they are on our side only to be shocked when their subsequent actions prove they were not supporting us at all. In the latter situation, the individual may be purposefully deceiving us by providing false "tells" (to use the poker term) but in the former, it might simply be a case of someone who is mismatched.

This is illustrated in the movie Joker. Joaquin Phoenix's titular character is prone to burst out laughing hysterically at inopportune moments as a result of childhood head trauma. Strangers exposed to this behavior assume transparency and respond negatively. To attempt to compensate, he has cards which he hands to offended strangers providing the justification for his inappropriate laughter.

But once we get to know that these team members are mismatched, we begin to understand them for who they truly are, and the likelihood of misinterpreting their behavior is vastly reduced. When we are part of long-lived, stable teams, we are able to appreciate the diversity of those who work with us and are able to leverage these differences as strengths and not as sources of conflict.

Posted on: October 27, 2019 07:00 AM | Permalink | Comments (10)

Horror movie lessons for managing project issues

linkedin twitter facebook Request to reuse this  

My formative years were the 1980's which were the heyday for slasher film series such as Friday the 13th and A Nightmare on Elm Street. With Halloween rapidly approaching I felt it might be timely to draw three parallels between the villains of horror movies and dealing with project problems.

Never say "It won't happen to me!"

A common method of identifying which characters in a horror film are likely to be eliminated early is to look for the most arrogant or overly optimistic ones. One of the more humorous examples of this is Samuel L. Jackson's character in Deep Blue Sea who gets eaten by a shark right after he has made a wonderful, passionate speech expressing his certainty in being able to lead the survivors to safety.

Project managers and their team members should feel bullish that they can successfully deliver a project, but this confidence should come as a result of effective risk management rather than blind optimism.

Don't assume it's dead

In nearly every horror movie, just when the hero or heroine believes they have successfully eliminated the monster, it finds a way to come back to life. The first Halloween movie had one of the most unexpected comeback scenes. Whereas you knew that the villains in other slasher flicks (e.g. Freddy Krueger, Jason Vorhees) were supernatural entities and hence normal human limitations wouldn't apply, in the original Halloween movie Michael Myers appeared to be a run-of-the-mill psychopathic human being. It was only at the very end of the film after Dr. Loomis has shot Michael a few times at point blank range and he's fallen from the second story of a house and managed to get away that you finally realize he's going to come back.

While it can be very satisfying to resolve a tricky project issue, we need to remain vigilant to the possibility that it could recur. If it had been previous identified as a risk, we now have quantitative data regarding its impact which we could use to be better prepared in the future.

Never say "I will be right back!"

If there is one thing a character should never do in a slasher flick, it is to head off on their own. Just as carnivores in the wild prefer to hunt prey who have got separated from their herd, movie villains delight in dispatching foolhardy wanderers. While it can be tempting to try to tackle a problem on our own so that we are feted as heroes, for resolving really challenging ones, there is strength in numbers.

One, two, project issues haunt you

Three, four, you can't ignore

Five, Six, there's no quick fix

Seven, Eight, don't hesitate

Nine, Ten, they will come again!

Posted on: October 20, 2019 07:00 AM | Permalink | Comments (8)
ADVERTISEMENTS

"In three words I can sum up everything I've learned about life. It goes on."

- Robert Frost

ADVERTISEMENT

Sponsors