Easy in theory, difficult in practice

Steve Kay, a Program Manager interviewed in the Closing Credit article of the August 2012 issue of PM Network made an interesting change on his mega-project – he altered the typical 5×5 risk matrix (e.g. very high – very low) to a 4×4 one to remove the “sitting on the fence” option for those participating in the qualitative risk analysis process.

This prompted me to check the risk registers for a few of the historical projects I’d been involved with and I noticed that when there is a three or five rating scale for probability and impact, the medium selection is picked much more often than one of the other choices.  This should not be a surprise since we can draw a reasonable conclusion that probability and impact values follow a normal distribution for projects with an average level of risk.

My concern is that the frequent selection of this rating relates more to indecisiveness or lethargy than to statistics.

The former cause might be tied to the common behavior in some organizations of people being unwilling to take a stand.  With a three point rating scale, providing a low severity for a risk which you had previously identified might incur the wrath of those minimalists who want the focus purely to be on critical threats or opportunities.  Doing the same for someone else’s risk event might put you at loggerheads with them as they might perceive a very different severity for their risk.  On the other end of the scale, assessing a risk event as high might brand you as a “Chicken Little”.

Such behavior might occur if risk analysis participants are lacking knowledge on what the different ratings imply and how to score risks, but more likely it is caused by participants that are uninterested in the process.  I believe that most staff are so focused on their day-to-day operational and project work and the “real” issues that plague them that they wish to minimize their effort spent on risk management which they perceive as being at best, an academic practice.

The recommendation in the PM Network article is a simple way to address the inappropriate use of medium ratings as it forces participants to pick ratings that will be either above or below the point of indecision.  This method could be enhanced by one or more of the following practices:

• Take the time before qualitative risk analysis begins to clearly explain risk rating scales and illustrate their usage with examples.
• Make sure that you effectively communicate the linkage between risk scoring and the responses that would be based on the scores as well as the implications of scores on risk reporting.
• As of a follow up to the analysis session and only if you have sufficient risks to support this, you may wish to construct a graph of the distribution of impacts and probabilities to see if the overall shape of the curve “fits” the team’s perception of the overall project’s risk profile.  If it doesn’t, this could point to inconsistent scoring.

Yoda said “Do or do not, there is no try” – medium might just be the “try” of risk management!

(Note: this high value article was originally published in August 2012 on kbondale.wordpress.com)

After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.

The Scrum Guide doesn't specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.

Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.

Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?

Just as with providing constructive feedback, we shouldn't wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.

A recent Washington Post article described how kindness can be contagious.

Anyone who has participated in or initiated a "pay it forward" chain would likely agree with the article's author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.

Change requests are similar to many project management artifacts in that significant effort is spent over the lifetime of a project in creating them and getting them approved, but they are rarely looked at once a project is over.

This is a shame, since while the primary purpose of a change request is to formalize changes to one or more of a project’s approved constraints or baselines,  they can also be a valuable source of knowledge beyond the lifetime of the project.

Some examples of these benefits include:

• During the final harvest of lessons to be learned at project closeout, change requests could be reviewed to identify change triggers that could have been avoided due to better planning, requirements gathering or stakeholder participation.
• They provide a source of knowledge for the impact analysis or effort estimation on risks, issues and changes for future projects.  While their usage cannot be a substitute for knowledgeable subject matter experts, they can act as a reasonable substitute if these SMEs are not available in a timely fashion.
• When change requests are reviewed across a portfolio of projects at regular intervals, they can help to identify chronic or systemic issues.  For example, if the majority of change requests are not scope related, but are instead being used to formally approve delays to project end dates, analysis could be done to determine whether there is a common cause for these delays such as poor resource capacity planning, ineffective work intake or prioritization, or overly optimistic effort estimation.
• They can be used by project managers who are new to the organization to understand how projects are “really” managed as well as to help gain insights into the attitudes or personalities of specific sponsors.

Change requests are the rats of the project management world – we usually go out of our way to avoid them, but just as rats are a critical input into development of future lifesaving drugs, change requests can be used to improve the delivery of future projects!

(Note: No change requests were harmed in the original publication of this article in January 2013 on kbondale.wordpress.com)

The Scrum Guide indicates "The Scrum Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint."

During a class which I was teaching this week, one of the learners asked: "Won't the ideas from a retrospective use up some of the team's capacity in the next sprint?".

As usual, it depends.

Here are a few scenarios and I'm sure there are many others.

If an improvement idea requires the team to learn a new skill or to perform a task which they wouldn't have done otherwise, then yes, it will consume capacity in the next sprint. Teams which aspire to be as transparent as possible will make these types of ideas visible to all stakeholders by explicitly adding them into the sprint backlog. When deciding on whether to implement these ideas, the team should balance the capacity costs against the potential delivery, quality or happiness benefits.

For those ideas which relate to improving behavior or interactions within the team or with the stakeholders supporting the team, there might be no capacity impacts beyond the team figuring out how they will remember to behave in a different manner. If the team was used to working virtually but saw some benefits in face-to-face interactions at least once a week, they could do so without reducing available capacity.

Some suggestions might require work effort from those outside of the team. For example, a dedicated testing environment might be desirable to reduce the impacts of limited access to a shared environment. An external person might provision the environment hence there would be no capacity impacts for the team beyond confirming that the new dedicated environment was setup correctly.

Finally, other suggestions might change the effort required to complete work items. If the team enhances their Definition of Done to include more criteria to improve product quality, this might increase their effort per work item.

Regardless of the nature of the improvements, there is a critical difference between retrospectives and traditional lessons learned practices. With the latter, only a small fraction of what was identified is immediately applicable, whereas with the former, the majority of the vital few ideas identified should get implemented before attention shifts and memories fade.

Thanks, Deepak, for inspiring this week's article!

There is a remarkable similarity between organizations trying to improve their project management capabilities and someone who is attempting to lose weight.

As personal trainers will attest, significant weight loss improvements are usually made early on but having reached a plateau with the potential of being able to achieve further reduction with continued effort, many clients will stall and some may even rebound and gain back some of the weight they had lost.  Although there is significant empirical evidence of the health benefits of weight loss, the ongoing effort required to lose more than a nominal amount of weight increases in a non-linear fashion, hence many people are unable to reach their original goals.

The same is witnessed with project management – while there has been much research supporting the premise that improvements in project management increases competitive advantage and operating efficiency, few companies capitalize on this and some even end up sliding back to their pre-project management levels of mediocre performance.

Don’t get me wrong – I’m the last person to advocate that all companies should strive to achieve world-class levels of maturity.  Those heady altitudes are best reserved for a very small set of organizations as the significant costs required to achieve world-class maturity must be justified financially.  However, I believe almost any company can aspire to PMI’s envisioned goal of embracing, valuing, and utilizing project management and attributing their success to it.

So what prevents this?

Improvement requires real commitment and effort, both in terms of behavioral change and ongoing investment.  The behavior changes required for successful project management capability improvement are not painless and many executives and mid-level managers are simply unwilling to relinquish their real (or imagined) power to make these changes.  Ongoing investment in capability improvements is also challenging, especially for public sector companies struggling with restricted or reduced operating budgets or public companies striving to meet or exceed shareholder expectations – this is the one advantage that private sector, non-public companies enjoy.  As Richard Branson said about Virgin “Fortunately we’re not  a public company – we’re a private group of companies, and I can do what I  want.”

Project management maturity does not exhibit causal determinism.  As there is a lag between improving practices and realizing the benefits of these improvements, you can’t force someone to value project management – they’ll either take that leap of faith and believe in it or they won’t.  If the executive who championed the initiative leaves the company or gets distracted with the latest Big Shiny Thing and if there is insufficient critical mass developed to sustain and further the improvements, project management maturity is likely to die on the vine.

One way to reduce the likelihood of this happening is to take an agile approach to your project management improvement initiative.

• Engage your executives in prioritizing which practices or capabilities to improve by helping them understand the benefits and costs of each
• Demonstrate tangible value at frequent intervals to re-kindle enthusiasm in the improvement initiative
• Develop and implement improvements using a cross-functional/cross-role team working closely with one another

To paraphrase Jim Collins: Few companies attain great project management capability, in large part because it is just so easy to settle for a good project management capability.

(Note: This good enough article was originally published in May 2013 on kbondale.wordpress.com)