Since I first started to learn about project management, risk management has always fascinated me.
That characteristic of uniqueness which separates operations from project work introduces uncertainties which, in turn, generate risks. Most mega-project case studies give credit to an effective risk management approach as a key contributor towards their success. But in spite of this, risk management continues to be one of the weakest practiced knowledge areas in the PMBOK.
If eternal optimism is the prevailing mindset within a company, it can be difficult for risk owners to envision things not going according to plan. What has always intrigued me is how the same leadership teams which can be moderately effective at implementing operations or business risk capabilities will be so much weaker when it comes to project risk management. A risk averse culture will take a long time to change for an overall organization, but a project manager should be able to influence it within the ecosystem of their projects.
Unhealthy levels of multitasking by project teams and stakeholders result in those practices perceived as unnecessary being jettisoned or being given lip service only. If a team barely has time to deliver the scope of their project, how can they or equally busy risk owners be expected to expend any real efforts on considering or responding to potentialities which may never be realized? And, if we combine this limited availability with "one size fits all" approaches to project risk management, it is no wonder that many teams will do the absolute bare minimum required to meet onerous governance requirements.
If team members and other stakeholders don't know what effective project risk management looks like, how can they be expected to improve? If there are no coaches to help teams improve their capabilities, improvements in risk management will rarely happen organically. Competent risk management requires exceptional interpersonal skills in addition to some basic technical skills, so hands-on practice with feedback from seasoned practitioners is needed to improve.
Finally, there might not be a realization of the positive correlation between effective risk management and successful project outcomes. In the absence of supporting internal empirical data or strong pressure from the outside to create a valid sense of urgency, senior leaders and project teams will be unwilling to sustainably invest in the required behavior and practice changes.
Providing practitioners with risk management training or evolving project delivery standards might help in some small way, but real improvements will only come when these root causes are addressed.
The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.
A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?
Their decision should consider a number of factors including:
For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.
When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.
The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.
Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!
Managing a high priority project can be a wonderful experience.
You will usually receive ample support from senior leadership in resolving critical issues, getting funding for team celebrations is rarely a challenge, and helping team members and other key stakeholders understand the importance of the project and how its success will benefit them should be simple.
But this is rarely the case. Most of the time, we are working on initiatives which, while important, are not top of mind for your senior executives.
Here are just a few of the challenges with managing such projects:
So what can you do to improve your odds of success?
"You should never view your challenges as a disadvantage. Instead, it's important for you to understand that your experience facing and overcoming adversity is actually one of your biggest advantages." - Michelle Obama
In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?
In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?
Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.
While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:
With great knowledge comes greater responsibility.
I’ve written a few articles on the risk posed by resource availability to most knowledge-based projects, and I still feel that this is a frequent cause of schedule & budget overruns. Other common risk factors impacting projects include requirements clarity, technology uncertainties and organization change resistance. Finally, project priority is a major source of risk these days – the “star” project that receives funding and focus today could morph into the “dog” tomorrow that is starved of resources.
A more subtle risk factor, and yet one that can be equally pernicious has to do with that unique project role – the stakeholder. I was once told this definition for a stakeholder: “Anyone with the ability to sink your project”.
One tends to think of negative stakeholder influence as a common source of risk to construction or other highly visible external projects, but any moderately complex internal project could also possess multiple stakeholders with competing agendas.
To address this source of risk, the best response is thorough and regular stakeholder analysis. If you are not sure that you have identified all of your stakeholders, seek advice from a peer or mentor. Meet individually with your stakeholder representatives early on and reinforce these relationships throughout the lifecycle of your project. It may be naive to assume that you can satisfy the needs of all of your stakeholders, so your objective should be to manage the impacts of their influence on your project. If it is not possible to work towards a “win, win” situation, you may need to solicit assistance from your project sponsorship or other stakeholders.
Project teams working on high stress, aggressive time line (is there any other kind?) projects tend to focus on their customer or their project steering committees. This myopia can be fatal – stakeholder influence is perhaps the best example of Dr. Hillson’s definition for risk: “Uncertainty that matters”.
(Note: I wasn't blindsided when I wrote this article in January 2011 on kbondale.wordpress.com)