Voices on Project Management

By Sree Rao, PMP, PgMP, PMI-ACP

From rookie mistakes to hard-won victories, my decade-plus journey as a program manager has been full of lessons. Here are the ones that stuck with me the most. As you ring in 2023, I hope these lessons will help you on your PM journey.

1. Don’t get too caught up in processes and labels. In my early career as a PM, I was stuck on implementing agile methodologies like scrum, Kanban etc. With experience, I have come to realize that it is important to figure out a process that works in the team-specific context rather than sticking to the labels of agile versus waterfall.

What is effective for one team might or might not work for another team. We get better engagement and buy-in if we involve the team in setting up processes and make the changes that the team recommends. It is important to rely on the collective wisdom of the team.

2. Don’t try to control the outcome of meetin­­gs. I place a high value on clear agendas and sticking to them in meetings. However, there have been occasions where my meetings did not go as planned. At first, this upset me, but I eventually came to understand that it is our responsibility to be prepared (and we cannot always control meeting outcomes). It is important to read the room and adapt meetings as needed.

3. Don’t overload yourself. During the early stages of my career, I was hesitant to decline additional work, even if my workload was already overwhelm­­ing. I was afraid of not meeting expectations.

However, it is important to be aware of your own limitations and feel empowered to say “no” when necessary. While we may not always have a choice, it is important to carefully consider how much work you can realistically handle. Is it better to do a good job with what you already have on your plate, or lower the quality of your work by taking on more?

Constantly being overburdened with work can prevent you from having the time and energy to identify opportunities for personal and team growth.

4. Don’t be a default meeting scheduler. There is a misconception that it is a PM’s job to schedule meetings, and as such I have often been asked to schedule meetings and take notes. However, this is not the primary focus of a PM role. To better manage my workload and prioritize, I have learned to say “no” to scheduling meetings unless I am driving the agenda or have a significant interest or stake in the meeting outcome.

While I may make exceptions in certain cases (such as when I need to expedite something), I have learned to be more selective about the meetings that I agree to schedule.

5. Identify single points of failure (SPOF) for projects and their mitigations. As a Technical Program Manager in the tech industry, I have often managed projects where only one engineer is assigned to a project. This is a big risk, as that engineer is now a SPOF for the project.

Whenever possible, it is advisable to request that at least two engineers share the workload of any deadline-sensitive, critical projects to reduce the risk of unanticipated personal emergencies or other risks. Apart from reducing the risk, this also helps with improving team morale as the engineers have someone else to bounce ideas off—and share the workload.

6. Put things in writing. It is important to document commitments or decisions made during your hallway or informal conversations in writing for future reference. Putting things in writing often leads to more careful consideration and follow-through from your team members.

Personally, I have learned the hard way to always get things in writing to avoid any misunderstandings or miscommunications later.

7. Encourage proof-of-concept development. If your team is stuck in analysis paralysis, or if you are trying out a new technology, get management buy-in to spend time creating a proof of concept or a prototype. This can help to quickly demonstrate the potential of the technology or approach and facilitate faster decision making.

8. Include key stakeholders in reviewing status reports before they are published. Early in my PM career, I gave more importance to adhering to timelines than to aligning with key stakeholders. One time, I marked a project as red (behind plan) in a report without first discussing it with the manager of the team that was running behind. That manager was unavailable, and I did not want to delay publishing the status report.

I went ahead and published the report without reviewing it with him. This had unexpected negative consequences, including the manager having to explain the red status to multiple members of the leadership team.

Since then, I have been more careful about how I report project statuses. Before turning a project status red, it is important to consider possible mitigation plans and to review the status with all relevant cross-functional team members and their management. This may slow down the process, but it ensures that all key stakeholders are aware and aligned on the status.

9. Identify projects/programs to cancel. Deciding to cancel a project or program can be challenging, especially if a lot of time and resources have been invested. However, it is important to consider whether the project is still delivering the value that was expected.

Don't let the sunk-cost fallacy (the tendency to continue investing in something simply because of the resources that have already been spent) influence your decision making. It's better to cancel a project and move on to higher-value projects rather than continuing to invest in something that is no longer worthwhile.

10. Be cautious about reporting program status as green/on track. In my experience, it is rare for all the projects in a program to be on track. If you do encounter a situation where all the projects seem to be progressing as per the plan, it’s important to carefully assess the situation and verify that thorough risk analysis has been done.

While there are several other valuable lessons I've learned, I've distilled my most valuable lessons into these top 10 nuggets of wisdom. Project management veterans, what valuable insights have you gained throughout your career? Share your nuggets of wisdom in the comments section below!

By Sree Rao, PMP, PgMP, PMI-ACP

Have you ever made a program or project decision that did not turn out to be the right one? As program managers, we not only need to make several decisions over the course of a project or program, but we also need to guide our teams with decision making.

Here is a framework to help you make decisions based on data and objective criteria. I heard about the RICIE model in a strategic management course, and found it to be really helpful to internalize the steps needed for rational decision making. Here I am proposing the RISCIE model, which is a minor modification to that model.

The RISCIE framework has six steps:

1. Recognize the problem/opportunity: In this phase, identify an opportunity or a problem that you want to solve. If it is a problem, identify the root cause of the problem. Do not mistake symptoms for problems. Example: Team members are consistently missing deadlines. This is a symptom that is a result of either bad planning, unclear requirements or team members’ lack of experience.

2. Identify solution criteria: Most of the time, we jump to solutions instead of identifying the solution criteria. To choose the best solution, come up with a list of criteria that the solution must meet. Example: The solution must be implemented in three months to meet the launch date, or should cost below a certain amount. Prioritize the criteria.

3. Solutions exploration: Analyze possible solutions that would fit the solution criteria. Do not stop with just one solution—explore multiple ones.

4. Choose a preferred course of action: In this step, evaluate all the solutions against each of the criteria that were identified in Step 2. Choose the solution that meets the most criteria. If there are multiple solutions that meet all the criteria, evaluate if there is a possibility to do a quick prototype or proof of concept of each of the solutions. This would uncover any pros/cons of the solutions that were missed in Step 3.

5. Implement the preferred course of action: The next step is to implement the chosen action. Ensure that any solution criteria that were defined upfront are indeed being met with this solution.

6. Evaluate the results and follow up as necessary: Lastly, evaluate the results. Ensure all the KPIs are being measured, and operationalize the solution. Do a lessons-learned or a retrospective session to use them for subsequent decisions.

Ensure everything is documented and that all the key stakeholders are involved in every step of this process. While this process does not guarantee successful outcomes, it does guarantee that your decisions are based on data and objective criteria. Do not measure the success of a decision based on the outcome (outcome bias). I plan to write my next post around this topic. Stay tuned!

What tips do you have for rational decision making in your projects and programs? What mistakes have you made, and what are your lessons learned?

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.