Easy in theory, difficult in practice

The restrictions resulting from the COVID-19 pandemic have resulted in more project managers working remotely. While this keeps everyone safe, it also means that there is a larger supply of project managers available to lead a given project since location is less critical. So long as a project manager is temporally close to key stakeholders, in many situations they should be able to get the job done.

While this provides greater opportunity to gain experience outside your locale it also means you are facing much more competition for these roles. Your experience, education and "who you know" can certainly help to differentiate you relative to other candidates, but building a solid brand is equally important.

One of the definitions which Merriam-Webster provides is apropos to our purposes: "A public image, reputation, or identity conceived of as something to be marketed or promoted".

The first thing is to decide what you want your project manager brand to be. Perhaps it is a "Steady Eddie" who can be relied upon to get the job done or maybe you want to be the "Red Adair" of the profession who can always be counted on to extinguish the flames of a project which is on fire.

But once you have decide what your brand is, how do you go about proving that you live up to it?

A simple answer is to deliver expected project outcomes, but that's table stakes. If you don't have a track record for that, you may be in the wrong profession or, at the very least, working for the wrong company.

If successful delivery is the foundation of your brand, you still need some solid walls. These include:

• How good are you at leading a team? If you are getting the job done but it's at the expense of your team members' growth, engagement or job satisfaction, no one will want to work with you.
• How good are you at building bridges? When dealing with stakeholders with diverging interests, how successful have you been at creating alignment towards a common goal?
• How good are you at making tough decisions? Have you made a key decision on a complex project which resulted in its success? Have you been the voice of reason to convince senior leaders to reduce scope or to even cancel a project which you were leading when that was the right thing to do?
• How good are you at connecting the dots? We don't deliver projects in isolation. Our projects are all part of a larger complex adaptive system. Can you think of instances where your ability to connect the dots and to effectively communicate those relationships to key stakeholders has led to project success?

But these just relate to the projects you've managed.

What do you do to give back to others? Perhaps you mentor some practitioners who are new to project management. Or maybe you volunteer your time and skills to lead initiatives for not-for-profit organizations. Maybe you are a thought leader and have helped to evolve the profession through research or work developing standards or practice guides.

Your brand as a project manager is built across multiple dimensions. Neglecting those might result in you receiving a different type of brand as per Merriam-Webster: "A mark of disgrace"!

After daily coordination events (a.k.a. Scrums, standups or huddles), velocity might be the most misused tool by teams new to agile and the stakeholders supporting them. Used appropriately, it can help a team to understand how much work they can complete in a fixed amount of time and thus could be used to forecast when they might be done with a release. However, being able to do so requires that three critical prerequisites are met. If any of these are not, velocity is irrelevant.

The first requirement is that the team composition and capacity should be relatively stable. You might argue that if capacity has decreased, one could pro-rate velocity based on the decrease. This assumes that we have enough capability (skills and experience-wise) across the remaining team members to complete work items, albeit at a slower pace. In the real world, teams often rely on specialists and if any of those are missing, it might not be possible to complete certain work items.

The second prerequisite is that the team needs to be working on the same product. Change those and there is no guarantee that they can continue to complete work at the same pace unless the two products are very similar.

Finally, the relative uncertainty of upcoming work items should be less than or equal to that of recent previously completed work items. If complexity or uncertainty increases over time, velocity cannot be relied upon.

So assuming these three conditions are met, can we breathe a sigh of relief and freely use velocity?

Unfortunately there are still three ways in which velocity data can be abused by stakeholders.

1. Comparing velocity between teams. Regardless of whether you use story points, number of work items completed or some other method to calculate it, it is meaningless outside the context of a specific team working on a specific product. Using velocity as a performance measurement could encourage the wrong kind of behaviors such as neglecting quality, working an unsustainable pace or ignoring tangible business value delivered.
2. Calculating velocity at an individual team member level. Teams complete releases, individuals don't. Measuring velocity at the team member level provides no real value and will just create destructive competitive behaviors within a team.
3. Assuming that velocity will continue to increase indefinitely. It is reasonable to expect that velocity will increase temporarily as a team evolves their way of working. However, it is unrealistic to expect that they can continue to speed up their pace of completing work unless there is either a significant change in the product, their delivery process or the team composition. Any such change would represent a different context which means that you couldn't compare present to past velocity.

Just as with any tool, there is usually one right way and many wrong ways to use velocity.

It would be an understatement to say that project managers have had to deal with a lot of change this year. Projects have had their budgets vastly reduced or been cancelled outright, and remote work has become the norm rather than the exception. We are still far from the end of the pandemic, but in those areas where they have successfully flattened their first waves, some companies are starting to encourage their staff to return to the office. 

For PMs who now have to adjust to being in the office with their team members, things are not as simple as winding the clock back a half-year or so. They will face a number of challenges including:

• Planning for a combination of on site and remote team members
• Scheduling in person meetings with added complexities of safe physical distancing and people's working arrangements
• Helping their team members (and themselves!) cope with the stress and natural fears of returning to the office

So how can a PM prepare for the transition and what should they do once they get back?

• Review the arrangements their employer has made to keep staff safe and raise any concerns they have before returning to the office. Don't assume team members are doing the same, so take the time to do a mini-onboarding with them upon their return to the office in the event that their employer's HR or health and safety departments are not already doing this. If team members are hesitant to communicate their concerns to those who can do something about it, advocate for your team members with these decision makers.
• Review working agreements with the team. Since some team members will now be working in person and others will continue to be remote, rules of engagement might need to evolve to ensure that remote workers don't feel like second-class citizens.
• Plan for unforeseen absences. While the risk of some team members being unavailable was present even while they were working from home, the likelihood of risk realization is increased due to the increased complexity of coming back to the office. Even something as simple as getting to one's cubicle could be delayed due to the lengthened time for commuting or for taking the elevator to one's floor. Timing for regularly scheduled meetings may need to be adjusted to allow for this.
• Enhance co-location benefits. While the entire team might not be able to be in the office at once due to capacity restrictions, determine which combinations of team members might give the best bang-for-the-buck from a collaboration perspective and structure team rotation based on that.
• Keep your second (or third or fourth) wave plan up-to-date. Just because in person work has resumed, doesn't mean things can't revert to the way it has been very quickly. Develop and regularly review contingency plans which could be implemented if some or all of the team is required to go back to working remotely.
• Frequently take the pulse of the team. Now more than ever, PMs will need to cultivate psychological safety within their teams so that team members feel comfortable sharing their fears and doubts with one another. 

When the pandemic hit, many project teams were caught off guard. Project managers should heed the adage "Fool me once, shame on you. Fool me twice, shame on me".

If a survey of teams was conducted to find out what they hated the most about working on projects, governance is likely to rank fairly high. Ask a group of project managers working for a large organization the same question and governance is likely to receive the most votes. This is because most governance approaches are or at least perceived as being onerous and viewed as barriers rather than enablers to getting work done.

Have a theoretical conversation with project managers about governance and they won't argue about its importance unless they are anarchists. Governance keeps both individuals and the organization safe and ensures that resources get used in a responsible manner. The issue lies not with governance itself but with its implementation.

An approach I've supported in the past has been for governance leaders to effectively educate delivery teams on the control objectives which need to be satisfied but then leave it to teams to figure out how to meet those objectives. The challenge with this approach is that if teams feel under pressure to deliver (and tell me the last time you were on a team which didn't feel such pressure!), without simultaneous emphasis on achieving control objectives, those might get ignored. The project manager can try to act as the conscience of the team, but by doing so they might lose the respect of their team, or worse, the full burden of satisfying governance requirements might fall on them.

A different approach might be to leverage nudge theory.

Wikipedia provides the following overview (I have highlighted in bold the two most common approaches for implementing project governance): "Nudge is a concept in behavioral economics, political theory, and behavioral sciences which proposes positive reinforcement and indirect suggestions as ways to influence the behavior and decision making of groups or individuals. Nudging contrasts with other ways to achieve compliance, such as education, legislation or enforcement.". Later in the same page the authors state "A nudge makes it more likely that an individual will make a particular choice, or behave in a particular way, by altering the environment so that automatic cognitive processes are triggered to favour the desired outcome."

One example which many travelers have probably experienced is how bed linens get changed in a multi-day hotel stay. A number of hotel chains have adopted the practice of using a card which the guest needs to place on the bed to signal the housekeeper to change the linens. In the absence of this card, the housekeeper's default behavior is to make the bed with the existing linens, thus reducing the environmental impacts of unnecessary washing.

When introducing nudges there are a few principles to think about:

1. Don't hide the nudges as we want to ensure that delivery teams are fully aware that they are being introduced
2. Involve delivery teams in the design, development and roll out of the nudges to avoid change resistance
3. Focus nudges on helping teams do the "right" thing as opposed to preventing them from doing the "wrong" thing as there is more likely to be buy-in when the outcome is a positive one.

So what nudges can YOU come up with which might satisfy the governance requirements faced by your team?

Scott Adams does a good job above of illustrating one of the many perils of low levels of psychological safety within a team. Dilbert is trying to raise reasonable doubts with his leader, the Pointy-Haired Boss, but his concerns are met with the threat of losing his job. How likely is it that Dilbert will raise such concerns in the future?

While this scenario has been dramatized for comedy purposes, it sometimes ends with tragic results. In those cases, lives are lost and the post-incident investigations often reveal systemic repression of raising any information which would refute established plans. The March 1977 collision of two Boeing 747 jumbo jets in the Canary Islands is a textbook case of what can happen when staff don't feel safe challenging assumptions.

But most of us don't find ourselves in situations where sticking with the wrong plan will result in loss of life or limb. However, there can still be negative impacts including:

• Reduced benefits realization
• Increased legal fees and other costs when we don't deliver what we had promised
• Reduced staff engagement and job satisfaction
• Increased attrition and costs of retention or replacement
• Reputational damage when former employees publish feedback about the toxic culture within their teams on job boards or on social media

Invalid assumptions are often a source of risk which is why assumptions analysis can be an effective method of identifying project risks.

If assumptions remain unstated because team members don't feel comfortable sharing them, the team loses the opportunity to challenge those assumptions. When they don't feel safe, team members will keep their concerns to themselves, valuing short-term security over long-term benefits. And if the risks are realized, they are likely to say something to the effect of "But they never listen to us" or "I was worried about losing my job".

On the other hand, when the members of a team feel safe, they are less likely to worry about the short-term negative impacts of having made a mistake and will be comfortable proactively speaking up when they are making an assumption about something. That provides an opportunity for the rest of the team to assess the assumption and identify any risks associated with that assumption being invalid. Then, if the severity of the risk is sufficiently grave, they can define when that assumption should be verified and even have a contingency plan to implement if that assumption is proven to be invalid.

But sometimes the assumptions being made are not ours.

In the Dilbert cartoon, the invalid planning assumptions are those of the Pointy-Haired Boss's. Another benefit of a team operating at a high level of psychological safety is that the team members are more likely to challenge their leaders when those leaders have made faulty assumptions. While that is helpful to the project, getting such feedback in an honest, timely fashion will also help the leaders' decision-making to improve.

Silence doesn't create project and organizational safety, it erodes it.