Easy in theory, difficult in practice

I'll admit to being hyperbolic with the title of this article, but a question posed today in one of the project management LinkedIn discussion groups managed to sidetrack what I was intending to write about this week. The author asked what needs to be considered when planning risk responses. The majority of the answers offered focused on characteristics of the individual risks themselves such as their probability, impact, ability to be responded to and so on.

But what we should consider is not just the specifics of a risk but also the context in which that risk exists. Enterprise environmental factors will also affect not just the nature of risk responses but also their effectiveness, and one of the more significant ones is risk appetite.The PMBOK Guide®, Sixth Edition defines risk appetite as the "degree of uncertainty an organization or individual is willing to accept in anticipation of a reward". This definition acknowledges that appetite should be considered from the perspective of multiple stakeholders and not just that of the project team or sponsor.

Stakeholders with a low appetite for a particular type of risk might influence a stronger risk response than is warranted which can impact efficiency. Those with a higher appetite can reduce the effectiveness of the overall project risk management approach. As with so much else in project management, the Goldilocks principle applies to risk response.

Risks can be positive or negative, but risk appetite usually has a greater influence on how we handle threats rather than opportunities. The exception are cases where the realization of an opportunity generates secondary negative risks.

Companies operating in risk-driven industries such as financial services are more likely to have appetite statements defined organization-wide. Such statements can help governance staff to define policies and to provide practitioners with clear examples of the types of risk which might be passively accepted and which ones should be actively managed. However there remains a degree of subjectivity when it comes to risk based on one's own biases, and with ever increasing project complexity and uncertainty, such statements can only go so far in creating consistency.

One way to address this is for a project manager to facilitate a risk response guidelines workshop with key stakeholders early in the life of the project. Take each of the project's constraints and success criteria, define a range of outcomes for those based on the impact of a risk event and ask stakeholders which risk response (e.g. mitigate, transfer, avoid, accept, escalate) should be utilized for each potential outcome. Not only might this help to create some consistency in practice but it would also provide the project manager with insights about the relative biases of each stakeholder to different types of risk. This information can then be captured in the Risk Management Plan.

Finally when it comes to managing risks over the life of a project, it is important to remember that stakeholders' risk appetite will change.

“But doth not the appetite alter? A man loves the meat in his youth that he cannot endure in his age.” - Shakespeare, 'Much Ado About Nothing'

The original seven Disciplined Agile (DA) principles were recently refactored and as part of this refactoring, a principle was added: "Organize Around Products/Services".

While it is just one of the eight principles, this new one aligns very well with lean thinking. It also addresses many challenges which leadership teams experience with agile transformations. Such transformations require change to happen in not only the delivery teams within an enterprise, but also supporting functions such as finance, human resources, operations and procurement.

Some benefits of a product or service-centric organization include:

• A reduced likelihood of the "throw it over the wall" syndrome. When delivery teams are responsible for not just the enhancements to their products or services but also the resolution of escaped defects there is more skin in the game for them to build higher quality solutions. This also encourages teams to take a holistic view of a solution and not just its usability and functionality.
• Securing funding is less challenging when we organize around solutions rather than the individual projects to evolve those solutions. Based on the strategic value of the product or service, governance leaders should be able to allocate a tranche of funding for a time period such as a quarter or a fiscal year. That funding will determine how much value can be added into the solution over that time period.
• Better team cohesion and a reduction in the waste that comes with repeatedly going through the Forming-Storming-Norming (and Adjourning) phases of team development. When we organize around solutions, the delivery team remains together until that product or service is no longer needed by the organization. Prerequisites for high performing teams such as psychological safety and radical candor are more likely to develop and be strengthened within long-standing teams rather than short-lived ones. The team would also gain greater knowledge of the business domain which would increase the value they can provide to stakeholders while they are enhancing their assigned products or services.
• It addresses the inherent problem that how we structure an organization is not how the work on products or services is actually accomplished.

This is not to say that organizations don't need project management as the hard and soft tools of the profession are still critical to implementing successful change. There will always be some changes which are "one and done" and those will remain fair game for project teams. Nothing would prevent product/service owners from organizing the allocation of funds within their annual allotment to projects if that makes the management of this funding easier for them.

But if we are looking to increase alignment, organizing around products or services is a good way to cut through the silo thinking which develops when we are organized by function or capability.

A few years back, I wrote an article in which I provided some gardening tips to developing good teams. I'm spending more time tending my garden these days so I decided to share a few more lessons for those wishing to cultivate a team building "green thumb".

Fertilization should be regular, but situational

Grass lawns need to be fertilized at regular intervals but the composition of the fertilizer (the proportions of nitrogen, phosphorus and potassium) varies by season and by the needs of the grass. Whereas you might use a 20-5-10 mix in the early Spring to give the dormant grass a boost of nitrogen to rebuild and to get ready for the heat of summer, a 13-25-12 mix is better in the late Fall to stimulate root growth in preparation for the following year.

When considering the professional development needs of team members, we need to regularly give them the time and resources for professional development, but the specific tactics used to develop should be dictated by their development objectives. Just like the three ingredients which go into fertilizer, there are three components for learning - formal training, relationship-based, and experiential. Depending on the development objective, the specific percentages of each should be varied.

Don't delay deadheading

Deadheading, the task of trimming faded flowers from plant stalks, is not just about maintaining the aesthetics of the garden, but is also about avoiding energy wastage by the plant. Gardeners don't relish this task but it is critical to developing stronger plants and getting more bloom cycles from your garden.

We may not look forward to the unpleasant task of removing someone from our team, but prolonged procrastination or wanting to be perceived as a "nice person" will hurt your overall team when there is a toxic, inefficient or ineffective team member who is clearly not improving in spite of support and coaching. Your best performers will be demotivated and may even leave and you will be sending the message that mediocrity is tolerated to the remainder.

Be thoughtful when adding a new plant into an established garden

When I have to replace one of the existing plants in my garden with a different variety, I always take the time to consider the impacts of the new arrival on the other plants in the garden. I learned this lesson the hard way. A few years back I replaced a large but unhealthy tree in my backyard with a small fruit tree. There were a few smaller stunted flowering shrubs under the old tree. When it was removed and the new tree was planted, the shrubs took this opportunity to spread like wildfire, risking the health of the fruit tree. I ended up having to transplant a number of those shrubs to a different spot in the yard to ensure the new tree remained healthy.

Even if you have a long-standing team with well defined ways of working, never underestimate the impacts on the team when a new team member is added. Involve the team in the selection of the new team member and make sure you build in sufficient ramp up time to help the newcomer understand and adapt to the culture and behaviors of the team.

Healthy, beautiful gardens do not develop by accident and the same can be said of good teams. As Rudyard Kipling wrote in "The Glory of the Garden": Gardens are not made by singing ‘Oh, how beautiful,’ and sitting in the shade.

Sabina Nawaz's article "In Times of Crisis, a Little Thanks Goes a Long Way", which was published this week on HBR.org, is a great reminder of the need we all have to be appreciated.

In a blog post from a few years back I'd written that team members need to possess sufficient Capacity, Capability and Commitment to contribute towards the success of the team. Daniel Pink's Autonomy, Mastery and Purpose can certainly help to kindle intrinsic motivation but we shouldn't stop there. Abraham Maslow touched on it with the fourth level of his hierarchy of needs, esteem, and Adrian Gostick and Chester Elton wrote the book on it in The Carrot Principle.

It doesn't need to be formal. Handing out financial rewards or trophies too frequently dilutes their value. Beyond that, you might have no budget for tangible rewards.

It should not feel forced. It is almost as bad to set a schedule for recognizing team members as it is to not do it all. Like feedback, appreciation is best when it is "in the moment" and close to the time when the action prompting the appreciation occurred.

It shouldn't always be us as the leaders giving it. When you witness everyone on your team actively participating in informally appreciating other team members without being prompted to do so, you know that the team has baked it into its DNA.

It needs to go beyond accomplishments. Those are important but might be achieved at the cost of team health. We need to consider not only what people did but how they did it. Behavioral changes are hard, and if someone has made progress by acting on constructive feedback, that should be recognized even if they fell short of their target. Teams where appreciation is given only when things are going well are effectively saying that success is all that counts.

With a virtual team, it can be a little trickier to sow the seeds of appreciation, so here are some ways in which this could be done.

• Raise the topic of appreciation when the team is defining their values and working agreements. Solicit ideas from them about what they feel is worth appreciating and how they'd like to appreciate one another. This could include how appreciation can be expressed with the different virtual collaboration tools which the team uses. Likes or positive emojis can be used for chat-based tools whereas stars, hearts or other positive stickers can be used in whiteboards or virtual canvases.
• Suggest that team members share key personal events such as birthdays or anniversaries with each other in the team's online calendar to make it easier for team members to recognize these milestones.
• Build appreciation moments into your key team events. One approach might be to take the first ten minutes of each weekly team meeting to give team members a chance to publicly thank someone else on the team who helped them out over the past week. I have found that in events such as retrospectives, this results in better quality outcomes, especially if the team has experienced challenges leading up to the event.
• Create an appreciation board within your virtual space where team members can post thank you cards to one another.

The benefits of the recognition we receive are like the grains of sand in an hour glass. Creating a culture of appreciation within our teams is a way to ensure the sand never runs out.

Objective: Expressing or dealing with facts or conditions as perceived without distortion by personal feelings, prejudices, or interpretations (Merriam-Webster)

I responded to a discussion thread on ProjectManagement.com this week about categorizing risks and after doing so, I spent some time thinking about the impacts of bias on how we evaluate risks.

While subjectivity affects all aspects of delivery, when we evaluate risks, these impacts can get compounded through the combination of the intrinsic uncertainty of risks with our own biases. And if we think about a department or enterprise portfolio with each team perceiving risks through their own biased lenses, there will be very little precision to support a portfolio-level evaluation of risk.

Tailoring risk management to fit the context of a given project means that we may not always capture the same information, but at a bare minimum, we usually have a risk description, impact and probability.

How could we become more objective in stating or evaluating these?

There is no need for us to become template zombies by imposing "if-then" or other rigid format to how risks are described. What is important is to clearly articulate the uncertain event as well as the impact to the project. We should try to be as specific as possible with regards to the event and, ideally, time box it. This will help us both in getting the attention needed from risk owners, designing effective risk responses, and being efficient about use of buffers and contingency reserves. Whereas "If we lose a team member, our timelines will be impacted" is not particularly effective, "If we lose a business analyst during the first month of the project, it will delay the project on a day-for-day basis" provides greater clarity and focus.

While we will usually restrict quantitative analysis to higher criticality risks, if we provide thresholds for assigning qualitative impact values (e.g. high, medium, low), we can help teams to get more objective. For a frugal stakeholder, a $1,000 cost overrun might seem high. But if we have threshold guidance which states that negative cost variances under $5,000 and which are under 5% of a project's total budget should be considered to be low impact, they will be less likely to let their own biases skew their evaluations.

If the project in question is very similar to others we have done in the past, risk evaluators could ask the question "How frequently was this risk realized in the past?". But in many cases we don't have the benefit of good historical data to substantiate our evaluation and the current project may be sufficiently different to make it impossible for us to look in the rear view mirror. The only way in which we could get more objective is to involve a sufficiently diverse group of stakeholders utilizing Delphi or similar methods to reduce the impacts of external bias.

Increasing the objectivity of how we analyze risks could help us to become more precise, which might then help us over time to improve the effectiveness of our risk management practices.