Easy in theory, difficult in practice

This article represents the confluence of three separate concepts I read about this week.

The first came when I read Michael Küsters’s article Why WSJF is Nonsense which details the downside of blindly ranking work packages based on the Weighted Shortest Job First (WSJF) formula. WSJF uses the ratio of the cost of delay to the relative effort required to complete a work package. It has become a popular method for prioritization as it avoids some of the problems associated with using a single metric such as business value. Michael’s concern is:

“We turn haphazard guesswork into a science, and think we’re making sound business decisions because we “have done the numbers”, when in reality, we are the victim of an error that is explicitly built into our process. We make entirely pointless prioritization decisions, thinking them to be economically sound. WSJF is merely a process to start a conversation about what we think should be priority, when our main problem is indecision.“

The second came from my re-reading of the chapter on the affect heuristic and availability cascades in Daniel Kahneman’s book, Thinking, Fast and Slow.

The affect heuristic is the idea that people make unconscious judgments based on their emotions related to the focus of the decision. If you view an advertisement touting multiple benefits of a product with which you’ve had no previous personal experience and are later asked about the risks associated with its use, you are likely to state that it is less risky even though there is no connection between its benefits and risks.

An availability cascade refers to the snowball effect which occurs when a relatively minor or infrequent event is blown out of proportion based on the emotional reactions experienced by those who are informed of it. The infamous Summer of the Shark in 2001 is a good example. Increased media hype occurred in spite of the fact that there were 76 shark attacks that year which was lower than the 85 attacks the previous year, and similarly, fewer shark attack-related deaths in 2001 compared to 2000.

Finally, I read a discussion thread on projectmanagement.com related to quantifying risk information. In the thread, Expected Monetary Value (EMV) was discussed and the proverbial lightbulb went off.

While EMV can be a useful way to quantify the expected impacts of the realization of a risk, it as susceptible to the same flaws which Michael and Daniel had written about. Unless there is a high degree of similarity in the contexts between the current project and past projects, quantification of a risk’s probability and impact is likely to be skewed first by normal estimation errors and further by our emotional responses to the risk itself.

If we have recently been on a project which was delayed because of the loss of a key team member, we are likely to give a much higher weighting to the probability and/or impact of a similar risk on our next project, even though these are entirely independent events.

Does this mean that we can’t use quantitative risk analysis tools? Of course not, but we should ensure we have some checks and balances when we use them to reduce the risk (pun absolutely intended!) of making a poor decision.

The happy path for a project manager is shepherding their project's delivery from start to finish. Just like raising one's own child to the point where they have become an independent adult, there is a sense of accomplishment which you only get from having been there at the beginning and witnessing the successes at the end.

But as with all journeys, there are exceptions.

I've written articles in the past which provided guidance when taking over an active project from a departing project manager or when preparing to transition an active project to another project manager, but what about the situation where you are just a temporary custodian, assigned to keep a project going until it is time to "resume our regular scheduled programming"?

This happens more often than you might think resulting from personal absences such as sickness or jury duty or a business need such as the current project manager having to put out some fires with a client they had worked with before.

While this type of assignment possesses many of the same risks as permanently taking over a project, it generates some unique ones including:

• Resistance from your team members and other stakeholders resulting from the double whammy of feeling sad about losing the previous project manager combined with the natural reluctance to develop strong working relationships with someone who isn't going to be working with them for the full duration of the project.
• Knowledge gaps as there might be less motivation on the part of the departing project manager and supporting leadership to fully prepare you for taking over since they know you are just a temporary player.
• Reduced commitment or motivation on your part given the "damned if you do and damned if you don't" situation. If you do a better job than the assigned project manager, you might just make them look bad or they might just get the credit for your hard work. If the project fails on your watch, you will be an easy scapegoat for the assigned project manager.

So what are some ways to respond to these risks?

• If you have motivational concerns about taking on the role, acknowledge these, and seek guidance from a trusted peer or mentor if you feel they will affect your performance. Be prepared to suck it up, but also be honest with yourself. If you feel you can't give the role the commitment it will take, do the right thing and recuse yourself.
• Ensure that expectations for your role have been well defined, realistic and are clearly communicated to all key stakeholders.
• Push for a thorough transition of knowledge and if you don't feel comfortable with the knowledge you've gained, escalate the concern till it is addressed or at the very least document the risks of it and get senior leaders to accept the impacts of these risks in writing.
• Take the time to understand the working agreements which the assigned project manager had established with the team and with key stakeholders. Remember that your arrival will reset team dynamics back to the forming, storming an norming phases for a period of time. Seek first to understand, then to be understood.

Attitude is everything.

Being a substitute project manager might feel like a thankless assignment at first, but if you treat it as an opportunity to showcase your flexibility, versatility and resilience, it might be a catalyst which lands you a much better role in the future.

Accountability is a popular word in delivery.

It is one of the four classification categories in roles and responsibility tools such as R.A.C.I. charts. The underlying intent is sound. If multiple people are responsible for contributing to the completion of an activity or deliverable, we still want to have a single person who has overall responsibility for ensuring it was completed as promised.

Merriam-Webster defines accountability as "the quality or state of being accountable". This is an unhelpful operating definition for our needs but it is further qualified as "an obligation or willingness to accept responsibility or to account for one's actions".

I've highlighted two words from the previous quote which reflect how many managers think of accountability. When you hear an executive say "We need to hold our people accountable", they are rarely referring to rewarding staff for a job well done. More likely, they are indicating whose throat they will want to choke when something goes awry.

For those who are held accountable, rarely do they perceive the upside of accountability if things were to go well. And, going back to the first word I highlighted in the definition, rarely is it full willingness to accept only accountability. More often than not, it is an offer that you can't refuse.

Continuing our grammatical journey we find that the top synonyms for accountability in a Google search are responsibility, liability, answerability, reporting, and obedience. Again, the majority of the connotations of the word are negative.

Accountability which inspires fear erodes psychological safety.

But is this what we really mean when we ask someone to be accountable?

I'd argue that we want to create a sense of ownership. Search for the synonyms for that word and the majority will arouse positive feelings.

Ownership implies rights. It implies opportunities for benefit. It also implies a degree of autonomy which is not always present when we are being held accountable. And as autonomy is one of the levers for unleashing intrinsic motivation, true ownership might lead to greater engagement in the work being done.

You might complain that I'm arguing over semantics, but words matter.

Just as we shouldn't refer to people as "resources" why not use ownership in place of accountability? After all, if we define roles such as Business Owners, Solution Owners and Product Owners, is it not reasonable to have Activity or Deliverable Owners?

"Ownership and control is important, because if you don't own what you do, all sorts of stupid stuff happens to it, and people spend good money on garbage." - Kevin Shields

In 2014 I wrote an article about the benefits which diversity in team composition can bring to risk identification. With different backgrounds and experiences, team members will usually identify a richer set of risks than might be defined by a group with limited diversity. It is also recognized that diverse teams are usually more creative and can be more innovative.

But while attending an Agile20Reflect event yesterday where a fair amount of time was spent by the participants discussing the lack of diversity in the boards of some agile associations and in the hiring of agile roles within certain companies, it reminded me that just because we conceptually accept something doesn't mean we are great at putting it into action.

Inertia often trumps diversity when it comes to staffing teams.

In matrix contexts, PMs will be providing their skill requirements to people managers and while the PM might be considering the overall team makeup in the back of their minds, priority is often too heavily placed on getting someone with the best skills to complete the expected work. Functional managers are faced with fielding multiple parallel and often competing requests for talent, so adding diversity into search criteria might be seen as a nice-to-have requirement. Even if the PM is at a higher level of power or influence, they might be reluctant to push back on the staffing recommendations made by the functional managers purely on a lack of diversity.

In projectized situations, the PM has much greater control over who will be part of their team, but if they are facing pressure to meet aggressive dates, they might be inclined to build the team as quickly as possible which means that diversity again takes a back seat.

Diversity quotas are not an answer as such strategies are divisive by intent. Oversight helps, but nothing will replace the real commitment of a PM to building their team with diversity in mind.

Staffing is just the first step.

Opportunities provided by having greater team diversity are squandered if we don't incorporate inclusiveness into team culture. For example, a PM's attitude towards conflict will affect how successful they are with inclusiveness. If they are concerned about intellectual friction, a conflict-averse PM might prefer to let the louder voices within the team drown out the rest.

We need to start by baking inclusiveness into team working agreements and we need to model inclusive behavior in our interactions with the team. It could also be a topic of discussion during reflection events by having team members identify behaviors and actions which were inclusive and those which weren't.

It is not by accident that embracing diversity has been paired with psychological safety within the first promise of the Disciplined Agile mindset as the two go hand-in-hand. The more inclusive we are with the diversity in our teams, the safer our team members will feel. And the safer our team members feel, the more they will be inclined to respect and encourage opinions which are different than their own.

A recent Harvard Business Review article warned of the challenges with using the "feedback sandwich" method. The authors wrote that such feedback might irritate the recipient, cause them to ignore the feedback or confuse them. The authors also stated that positive reinforcement should be given independently so that its impacts on morale or performance are not lost. They go on to advocate a more direct approach of describing the behavior which needs to be corrected, explaining the impacts of the current behavior and either telling them or asking them what should be done different in the future.

We are still missing one step.

Telling or asking someone what you'd like to see changed is task-oriented. For behaviors which are easy to change such as remembering to wear safety boots before going to a job site, such an approach is likely to work well. The recipient could remember to do this for themselves by putting their safety boots in front of the door before going to bed or by leaving themselves a Post-it® note reminder on their steering wheel.

But when it comes to behaviors which are subtle or deeply ingrained, just telling someone what they should change rarely helps them figure out how to do it regardless of how direct we were in providing the feedback.

Think about public speaking. Most of us have at least one chronic flaw when giving presentations such as saying "you know" or "um" unnecessarily, keeping our arms crossed or avoiding eye contact with audience members. It is quite possible that someone may have informed you about this behavior in the past, but that doesn't help you to correct it. When preparing to give a presentation, you might remind yourself explicitly of the feedback but you may be unable to act on it in the moment.

If you agree with Daniel Kahneman's categorization from Thinking, Fast and Slow, such behaviors fall under System 1 processing as they are performed unconsciously. To change, you might need to shift into System 2 thinking until the new behavior becomes second nature.

If the person who provides feedback also offers to help the recipient implement the change, it is more likely to stick. Not only does this external support move into System 2 thinking by directing more attention to the behavior, but it also shifts the nature of the feedback from task-oriented to relationship-oriented which will reduce the likelihood of a defensive response.

So how might this be applied in our public speaking example? The feedback provider might offer to sit in the front row of the audience at a few presentations given by the recipient and perform a mutually agreed upon subtle action such as rubbing their nose every time the behavior occurs. This external stimulus should help the recipient become more aware of the behavior and, over time, they are more likely to avoid it.

If you want someone to change, be committed to helping them change.