Posts Tagged With: communications

In defense of the Digraph

I’ve found project risk management to be one of the weakest performed PMBOK knowledge areas in most organizations, even for those companies whose operational risk management practices are very mature. A part of this challenge is that we tend to identify obvious risks but miss key ones when we don’t engage sufficient stakeholders in the identification process or when we ignore lessons identified in past projects. But another major source of issues is the lack of meaningful response to identified, analyzed risks.

An article from the October 2017 issue of PM Journal reminded me that HOW we communicate risk information is as important as WHAT we communicate.

I’m sure many of you recognize the futility in only sharing risk information via risk registers. While those are a valid place to consolidate risk information for project management purposes, it is unlikely that most stakeholders will know where to locate a risk register for a project, let alone review it periodically. A better approach would be to use existing information radiators, reports or meetings to secure ownership of actions and responses for key risks.

But how do we present the information itself?

Extracting key fields from the risk register into a management-ready table is one way to do this. You might also be creating some colorful heat maps to provide stakeholders with a higher level view of overall risk probability and impacts.

But what about the relationships between risks?

You might have communicated some information regarding the secondary risks generated by responding to other risks, but what about the relationships between the risks in your register?

Creating a visual representation of the relationship between risks can help us focus further analysis and response efforts on those risks where we will get the greatest overall project benefits. An interrelationship digraph which was one of the quality management tools covered in the Fifth Edition of the PMBOK Guide and excised from the Sixth Edition provides one way to do this. Such a view might also help key stakeholders to connect the dots for themselves. They can visualize how their response to a specific risk might help to prevent impacts resulting from the realization of other risks triggered by the first one.

Our project risk management practices are only effective if there is a tangible difference in outcomes compared with our doing nothing. 

Advertisements
Categories: Project Management | Tags: , , | 2 Comments

How are you resolving your agile transformation blockers?

Teams leading agile transformations can encounter multiple challenges along their journey including changing the mindsets of senior and mid-level managers, transitioning from a focus on specialists to developing generalizing specialists, educating and effectively engaging delivery or control partners and reducing the time and effort required to deploy deliverables once they’ve been deemed production ready. Worse yet, it can sometimes feel like a game of Whac-a-Mole – as soon as your team resolves one hurdle then another two surface.

How about being agile with your transformation!

Treat each of these blockers as a work item in a backlog. Collaborate with stakeholders to identify appropriate acceptance criteria to help you know when you’ve successfully resolved the issue. Size the work items with your team. As with all preliminary estimates in agile don’t aim for precision but rather for consistency. T-shirt size them or if you feel creative use an alternative fun sizing taxonomy (Decepticon-sizing?).

Prioritization will be a challenge. Just like managing a backlog of product requirements, it’s rarely as simple as letting business value be the sole determinant of priority. Many of these hurdles will be interdependent. You might also want to incorporate relative uncertainty into the ranking process by tackling higher risk and impact hurdles first.

Once you’ve prioritized these blockers at a high-level your team should decide whether it is worth disaggregating them into smaller hurdles. Techniques such as story mapping could then be utilized to help you create a release plan for resolving the issues.

Now comes the tricky part – socializing the plan with your senior stakeholders. Assuming they accept the list of blockers and their relative priority you will want to share it with delivery teams and control partners across the organization. This will increase their confidence in the transformation as well as helping to manage their expectations regarding the resolution timeframes for specific blockers.

A critical step is to adapt and evolve the plan as your transformation progresses but don’t obsess over creating the ideal plan. As new blockers get identified by delivery teams, size them, prioritize them and add them to the backlog. Use information radiators to share status. For example, you could post a list of which hurdles are being actively worked on, which ones are “on deck”, and a burn-up chart with an up-to-date forecasts of when the backlog will be cleared. Your team should also decide whether a sprint-based or lean lifecycle makes sense given their capacity and maturity.

Resolving a backlog of organization blockers can seem an insurmountable task but take the opportunity to increase buy-in and provide a showcase for the benefits of being agile.

 

 

 

 

Categories: Agile, Facilitating Organization Change | Tags: , | 2 Comments

Avoiding groupthink on long-lived teams

Long-lived teams are often presented as being superior to their temporary counterparts. The benefits of longevity include the avoidance of wasteful forming-storming-norming cycles, higher levels of trust and psychological safety within the team and a more accurate understanding of what someone means when they communicate with us.

But there is a potential downside to persistent teams which can erode many of these benefits: groupthink.

Groupthink usually refers to a situation where team members prioritize consensus over the quality of a given decision or outcome. We might all disagree with Bob’s recommendation on how to address a project issue, but we value the harmony of the group over the mediocrity of his approach and hence we don’t challenge it. According to Irving Janis, the social psychologist who is credited with introducing the term, groupthink tends to occur most often where there are high degrees of cohesiveness, external threats, difficult decisions or isolation of the team from others. These factors are often found on long-lived teams.

So how can we avoid groupthink on long-lived teams?

One countermeasure might be to use Delphi or a similar method of anonymously or simultaneously gathering input from the team. This will reduce the likelihood of any one team member winning a “first to speak” advantage and will provide a structured approach to surface and discuss differing viewpoints.

Another option is to have the group nominate one team member to act as a devil’s advocate. This selection should be made on a per decision basis. Since everyone knows that this team member is responsible for finding weaknesses within a decision it eliminates their fear of being perceived as disruptive. Care needs to be taken in selecting the right team member to play this role. Someone who is likely to have significant interest in the outcomes of a decision might not be the best candidate as they might consciously or unconsciously disqualify the group’s approach to further their own path of action.

Have the foresight to bring someone in from the outside who has no stake in the outcome. This approach can replace the previous suggestion if team members feel that none of them can impartially play the role of devil’s advocate. This method has its own challenges as it might take some effort for the outsider to gain sufficient context to be an effective contributor to the decision.

Finally, breaking the team into two independent groups and having each group develop a recommendation is a very explicit method of eliminating groupthink. Of course, this requires a team which is large enough that such a sub-division is possible. If this approach is used more than once, it is a good idea to have different people in each group for each distinct decision.

When all think alike, the no one is thinking – Walter Lippman

 

 

Categories: Agile, Project Management | Tags: , , , | 2 Comments

Blog at WordPress.com.

%d bloggers like this: