Voices on Project Management

By Sree Rao, PMP, PgMP, PMI-ACP

Atomic Habits has been on Amazon’s top 20 most read books of the week for 167+ weeks. In his book, James Clear proposes a four-step model of habits and the four laws of behavior change:

1. Cue – Make it obvious.
2. Craving – Make it attractive.
3. Response – Make it easy.
4. Reward— Make it satisfying.

Here are a few book excerpts that form the foundation for this blog entry:

“What is rewarded is repeated. What is punished is avoided. The first three laws of behavior change—make it obvious, make it attractive, and make it easy—increase the odds that a behavior will be performed this time. The fourth law of behavior change—make it satisfying—increases the odds that a behavior will be repeated next time. It completes the habit loop.”

“Success is the product of daily habits—not once-in-a-lifetime transformations. Habits are the compound interest of self-improvement. “

What can we take away from this? Here are three habits that I strongly recommend program managers implement. These are proven techniques that will help regardless of the type and size of the projects/programs:

Atomic Habit #1: Run regular retrospectives
Retrospectives are an excellent way to identify incremental improvements on a continual basis. Continuous improvement is also the foundational concept of Kaizen. Retrospectives are built into the Scrum methodology; however, you can use retrospectives irrespective of the methodology. Here are some steps to build this habit of running regular retrospectives:

1. Make it obvious by scheduling a recurring retrospective on your team’s calendars (biweekly, monthly or whatever cadence works for your project team).
2. Make it attractive by varying the format of the retrospectives regularly. Example: Use some fun templates for running retrospectives. There are several formats and templates that you can find on the internet.
3. Make it easy by allocating 10 minutes at the start of the retrospective to add everyone’s thoughts into the retrospective template. Identify only one improvement that is easy to implement.
4. Make it satisfying by starting off the retrospective by sharing the results of the improvement that you have implemented from the last session. Another way to make it rewarding is to add a “Thanks to…” section in the retrospective, where participants give thanks to the team members that helped them out

Atomic Habit #2: Templatize
“Templatize” as many artifacts like status reports, requirements documents, design documents and strategy documents as possible. While some leaders believe that templates limit creativity, I strongly believe that it is not the best use of our time to start everything from scratch when there are already well-established and researched templates. Creating an initial set of templates is a one-time cost with huge benefits in the long run. Get your project teams into the habit of using templates:

1. Make it obvious by creating a shared repository of all the templates and publicize the location of the templates widely. Make it part of a new project team member onboarding guide, project information resources page, etc.
2. Make it attractive by creating templates that are not only visually appealing, but also follow the accessibility guidelines. We don’t need to go overboard in terms of visual appeal, but ensure they meet the minimum standards for your team/company. Additionally, have an influential team member start using these templates. People form habits by imitating others, and having an influential team member using them would be a good way to get them motivated.
3. Make it easy to create the artifacts from the templates by providing as few instructions as possible. Also give them the freedom to make changes to the artifact based on the specific need without any approval process.
4. Make it satisfying by recognizing the team members that use the templates to create their artifacts. This is needed in the initial stages when the team members are getting into the habit of using the templates.

Another advice from the book is “standardize before you optimize” and this is perfectly applicable for templates. Standardize the use of templates first and based on the patterns that emerge, optimize the templates

Atomic Habit #3: Consolidate project tasks and action items
One of the challenges I have been facing has been that the action items from meetings are all over the place (Google docs, Words docs, Excel docs, etc.) and the project tasks are typically tracked in a tool (Jira, Asana, Monday.com, etc.).  Consolidating project tasks and action items would greatly simplify tracking both for the PM and the team. Here is a suggestion to get the team into the habit of adding action items to the task tracker:

1. Make it obvious by creating a specific section in the task tracking tool for tracking meeting agendas and action items. I have added a section called “weekly stand ups” in our regular project tracker and started adding agenda topics and action items there. You would have to figure out the best way to do this with the specific task-tracking tool that you use.
2. Make it attractive by using the features that the tracking tools already have for creating dashboards to show items in progress, completed, etc. Several contemporary task-tracking tools have the ability to create very attractive dashboards.
3. Make it easy by using existing tools and creating a section in the same task tracker so that the team has one place to check all their tasks and action items.
4. Make it satisfying by recognizing and acknowledging the completed action items and tasks. Send out weekly reports. Recognize team members that diligently use the tracker.

In summary, here are my top three atomic habits that you can cultivate amongst your project/program teams for success over the long term:

1. Run regular retrospectives
2. Templatize
3. Consolidate project tasks and action items

I would love to hear the habits that have helped you as a program manager. Share them in the comments below!

Customer satisfaction surveys are one of the most used feedback mechanisms. I have conducted several surveys for internal tools used by engineers within the companies that I worked at, and here I summarize my experience. While I talk about internal surveys, most of what I describe here is applicable for external surveys as well.

Before starting any survey, think through the three questions—why, what and how:

1. Why are we counting? It takes up valuable time creating a survey, administering it, analyzing the results, and acting on it. Respondents must spend time as well. Without a clear “why,” it’s a waste of time and effort. So always start with the “why.”

2. What are we counting? The next obvious question is the “what.” Determine what you are going to count. Ensure there is no ambiguity in the attributes you plan to count.

Also determine which metric you are going to use. There are several metrics: Net Promoter Score (NPS), Net Satisfaction Score (NSAT), Customer Satisfaction Score (CSAT), etc. Based on my experience, NPS is often used for external surveys, and it is often just one question followed by an optional open-ended question for feedback. This might not give you a good enough signal for internal tools. NSAT and CSAT are the most common ones that are measured for internal tools.

3. How are we counting? To eliminate any biases or fallacies, we need to determine how we are going to count. Here are some sub-questions to think about:

• How many people are we going to survey? This is to make sure we have a statistically significant sample size before we draw conclusions, and we are not prey to any base rate fallacy.
• Do we have a representative sample? We need to make sure the survey studies different personas that use the internal tools. Example: If the tool is a reporting tool, executives, engineers, researchers etc. might be some of the personas involved.
• Are the definitions clear? This is to ensure that people do not interpret definitions differently. If you use any abbreviations or acronyms, elaborate what they mean in the survey.
• Framing the questions will impact the survey responses. Keep the following in mind:
  • Pseudo opinions - People give an opinion even if they do not have any opinion. To prevent this, include options like “Don’t know enough to say” or “Don’t know.”
  • Answer sets - Open answer sets allow people to give their automatic perceptions. Closed answer sets provide options that the user might not have thought about. Closed answer sets will get higher completion rates and have the potential for more extreme answers. Ensure the surveys are a mix of both closed and open questions.
  • Response scales - Scales will skew the data. Example: If you are looking to determine how many times the users use the tool, the answer set could be daily, weekly, monthly, or once a week, twice a week, thrice a week. So, think through what makes more sense for the scales.

Here are some dos and don’ts to keep in mind when you think of a survey:

Do’s:

1. For every question you want to include in the survey, think about what you are going to do with the responses.
2. Keep the number of questions to the absolute minimum.
3. Anonymous surveys ensure that the respondents are candid; however, the drawback is that if you have any follow-up questions, you will not know who submitted the feedback. My recommendation is to go with non-anonymous surveys for internal tools.
4. Always follow up on the feedback coming out of a survey and publish the results. Let the respondents know how the survey results have been used. This encourages them to submit the survey the next time.
5. Be mindful of the number of times you send out a survey and carefully choose the cadence. I have seen quarterly, half-yearly and yearly cadences. Choose the one that gives you enough time to act on the feedback.

Don’ts:

1. Do not ignore survey fatigue. It is real, particularly for internal surveys.
2. Do not use a survey if there are other ways to get meaningful feedback.
3. If you are not going to use the responses to a survey question in any meaningful way, do not include that question in the survey.

Individual decision making is fraught with biases and fallacies. In one of my earlier blogs I talked about common fallacies and biases in program management. We can mitigate these biases by using group decision-making techniques, where you encourage participants in a group to brainstorm a solution/decision. Group decision making taps into the collective intelligence of the group and increases the acceptance of the decision by all the group members.

However, group decision making has its own drawbacks. A couple of key drawbacks are:

• Groupthink – A psychological phenomenon that occurs within a group of people in which the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome.
• Possible domination by the most vocal or senior person.

We can avoid these drawbacks by using some facilitating techniques that bring out dissenting opinions and give everyone in the group a chance to present their thoughts/ideas.

Here are three facilitating techniques that we can use to bring out dissenting opinions:

1. Devil’s advocate method – As the name indicates, in this technique we identify one person or a subgroup to act as “devil’s advocate.” One subgroup iden=tifies the solution or decision and corresponding assumptions. This subgroup then presents the decision to the “devil’s advocate” subgroup/person. Responsibility of the devil's advocate subgroup/person is to present a contrarian view and poke holes into the assumptions and the decision/solution. Intent of this facilitating technique is to think through alternate scenarios.
2. Dialectical inquiry method – This is very similar to the devil’s advocate method. The main difference is that in this method, one subgroup is assigned to think through one option and the other subgroup is assigned to think through the opposite option. Both the subgroups then come back and talk about both the options. The team then comes to a final option based on the group discussion. One key thing to remember when using this technique is to ensure there is diversity in terms of gender, experience, personality types etc. when creating the two subgroups.
3. Step-ladder method – In this technique…

• In the first round we ask everyone in the group to come up with their own ideas. 
• In the second round we bring in two people, have them present each others’ ideas and agree on a temporary decision/solution.
• In the third step, the third person presents his/her idea to the first two and the three of them come to a temporary decision/solution.

This continues until everyone has a chance to present their ideas in an unbiased way and their feedback is incorporated into the final decision. This is a time-consuming process, so use this cautiously.

In situations where we end up with more than one decision/solution, we can use objective criteria to converge into a single solution/decision. Here are a couple of frameworks we can use to make rational decisions:

1. Mediating assessment protocol: Daniel Kahneman, a Nobel Prize-winning psychologist, suggested this approach for making important strategic decisions. In this method, we identify assessments or criteria that are important for analyzing a decision. We then assign individuals to conduct the assessments. Once all the assessments are done independently, the group then makes a collective decision based on individual assessments. Interviews conducted by major tech companies like Google, Amazon and Facebook follow this protocol, wherein there are multiple interview loops like system design, coding and behavioral assessments that are conducted by individual interviewers. A group decision is made on the interview candidate based on these individual assessments.
2. Relative weighting: In this method, we identify a set of criteria that are important in making the decision and assign relative weight for each of those criteria. We evaluate the decisions based on the relative weights of the criteria and pick the one that has the maximum weight. As an example, when we must finalize a list of features to implement, we can assign complexity, feasibility and impact as the criteria—and each of these have relative weights. We then evaluate the features against these criteria.

What are some of the ways in which you have debiased group decisions? Let me know in the comments.

By Sree Rao, PMP, PgMP, PMI-ACP

The ability to influence is one of the most valuable—and
underrated—leadership traits. It’s particularly important for program
managers, since we must influence cross-functional team members over
whom we may have some positional authority—but not enough to get things
done.

Here are 7 ways to influence:

1. Identify your style

We all have our own ways of trying to impact other people’s thinking and
actions. Chris Musselwhite and Tammie Plouffe identified five different
styles:
Rationalizing: Using logic and reason to advocate for a solution
Asserting: Stating ideas confidently to directly drive action
Negotiating: Finding favorable compromises without sacrificing the long-
term goal
Inspiring: Drawing on passion to open people’s eyes to new possibilities
Bridging: Resonating with others by listening and building coalitions

We often try to influence the way we like to be influenced—but that doesn’t
always work. Instead, try to match the style of the person you’re trying to
influence.

2. Establish trust

Influence is based on a foundation of trust and credibility that’s been
solidified over time. We cannot build trust overnight. The best way is to
continually deliver on your promises and be transparent when there are
roadblocks. Encourage others to express their honest opinions, concerns and
doubts, and give open, honest and constructive feedback.

3. Build social capital

Look beyond your role and offer help: Volunteer to pitch in on mentoring or
other company initiatives that you’re passionate about. You’ll get to network
with people across various departments and build social capital. Give help—
and then ask for help.

4. Think like a hotshot

Consider this as a variation of what former Focus Brands COO Kat Cole calls
the hotshot rule: Think of a colleague that you admire for their influencing
skills—aka, a hotshot. Now imagine if that colleague took over your role.
What would they immediately change? How would they interact with the
person you’re trying to influence? This might not be feasible in all situations
because of personality differences, but you can gain some insights from the
hotshot’s style.

5. Influence the influencer

If you’re trying to influence a team, identify the person on that team with
the most sway and influence them. And they will in turn influence the team.

6. Unlearn what you know

Keep an open mind and don’t write anyone off. There might be ways to win
over even the biggest skeptics. Initiate a conversation, acknowledging that
your view is different from the other person’s and have them help you
understand their perspective.

7. Know your value

The Cohen-Bradford influence model recommends that you think of what you
can offer in exchange for what you’re asking for. That can be your technical,
organizational or process knowledge, a tool, an expression of gratitude or
recognition, or help with tasks you have expertise in. Be mindful to do
something the other person values, which may not be what you value. As an
example, some people don’t like public recognition. Knowing that and
respecting that will go a long way.

Let me know your favorite influencing technique in the comments.

I’ve been trying to learn more about good decision-making and recently read Daniel Kahneman’s famous Thinking Fast and Slow. It’s very surprising to see the number of fallacies and biases that cloud our decision-making, with some impacting us more than others. Here are three of the most common fallacies that we encounter in project and program management, along with a few “smartcuts” (smarter way of doing things) to mitigate them. 

1. Planning fallacy: the tendency to underestimate the time, costs and risks of future actions, while overestimating the benefits of the same actions
Smartcuts:
•    Conduct a pre-mortem: Think of what could go wrong, work backwards and plan for those scenarios.
•    Use chunking: Break down the project into as small tasks as you and the team can.
•    Try consensus-based estimation: This method uses conversation and convergence to reduce individual cognitive biases—but it’s time-consuming. To strike a balance, I’d recommend using it only for complex features or projects in which there’s not much leeway in delivery time.
•    Add buffer: This decision depends on a lot of factors: type of project, whether there’s a need to have a definite deadline, complexity, dependencies etc. At a basic level, if you’ve been working with the team and have a history of how much the estimates are off by, you can plan to add that much buffer. If it’s a new team, and you don’t have any idea, look for similar projects use that data to gauge the buffer.

2. Sunk cost fallacy: an increased propensity to continue an endeavor once an investment in money, effort or time has been made 
Smartcuts:
•    Don’t just think about the time/money already spent. Instead, think of how much additional time/money is needed and if continuing the project will be a worthwhile investment.
•    Companies can help employees overcome loss aversion by putting greater values on gains and less penalties for losses. While this is something that happens at the enterprise level and might not be in our sphere of influence, you can influence it at a program and project level when framing wins and losses. For example, instead of saying, “We were over budget by 10 percent,” try framing it as, “We were within +10 percent of our initial estimates.”
•    Avoid perpetuating the stigma that stopping a project is a failure. Instead frame it as a lesson learned and incentivize people to make such decisions in the projects and programs they manage.
•    Consider opportunity costs. By sticking to the original plan, think of all the projects you’re giving up.

3. Status quo bias: sticking with the option you’re given even though the alternatives might be better
Smartcuts:
•    When you propose any change, be very clear and intentional about why you’re proposing it. Explain the problem statement you’re trying to solve and then detail the pros and cons of status quo versus the change.
•    Evaluate the opportunity cost of making the change versus sticking with the status quo.

While it’s not possible to eliminate all biases and fallacies, being cognizant of them and recognizing them will guide us in making better decisions.

What are some of the fallacies and biases you’ve held onto and how have you overcome them?

Here is a link to the unabridged version of this post.