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 announcement of the acquisition of Disciplined Agile (DA) by PMI is almost a month old so I thought I would share my thoughts on it.
There is no doubt that PMI has been flirting with agile progressively over the past decade. The launch of the PMI-ACP credential, the addition of adaptive life cycle considerations to the PMBOK® Guide, Sixth Edition and the release of the Agile Practice Guide were all signs of this growing interest.
However, PMI suffers from being perceived as a champion of bureaucratic, traditional approaches to business value delivery which has generated a fair bit of cynicism from the agile community. The partnership with the Agile Alliance which led to the development and publication of the Agile Practice Guide were viewed by some as a unhealthy dalliance or a marriage of convenience.
Correcting perceptions and developing sufficient intellectual property (IP) would have taken PMI many years to do organically so acquiring legitimate thought leadership, credibility and IP was the better strategic move. A key decision was to choose either a method-centric (e.g. SAFe, LeSS) or method-agnostic (e.g. Disciplined Agile, Modern Agile) organization. Given the need to address a global market with varied needs, agnosticism won out.
There are a number of potential advantages to PMI, DA and practitioners.
PMI now has the ability to incorporate the significant intellectual property of DA within their knowledge base and by doing so, enhance the value proposition of their standards and practice guides. While tailoring considerations were minimally explored in the PMBOK® Guide, Sixth Edition, they can now go much deeper by leveraging the DA process decision-making framework. PMI can also expand the breadth of their credentials and by doing so, will add credibility to the existing DA ones. Given the strategic relationships which PMI's senior leadership has forged with major global corporations, this acquisition will open doors for DA which might not have been possible otherwise which in turn might accelerate the evolution of DA. It is also an opportunity for the DA framework to go beyond technology delivery.
But there are some risks, including the dilution of thought leadership, the obsolescence of existing credentials and the risk of PMI actively competing with partners (e.g. Registered Education Providers). PMI might also make the mistake of not fully integrating DA into their offerings which would limit the benefits realized from this acquisition.
If there is a single piece of advice I'd like to pass along to PMI & DA, it is from Audrey Hepburn: “If I get married, I want to be very married.”
During the last week PMI announced that, based on the feedback they had received from stakeholders, they would be delaying the significant changes to the Project Management Professional (PMP)® certification exam which had originally planned to be launched in mid-December 2019 to July 1, 2020.
When I first read this, I felt a burst of vicarious relief for those exam candidates who were likely experiencing a lot of stress with the original date.
I have no doubt that this was the right decision for PMI to take.
The proposed changes to the exam are likely to be more significant than others made over the past decade. With the last batch of changes to the exam having been implemented in March 2018, a significant update within two years will not only cause candidates angst but will also reduce the return on investment for the study materials which training companies would have so recently updated.
After further reflection I realized there are some good lessons in change management with this decision:
I have no idea who was the decision maker at PMI who pushed for this delay to the launch date, but this demonstrates the sort of good judgment which we should demand from change leaders.
Completion of a project usually focuses on financial and administrative activities such as transitioning verified and accepted deliverables to customers, getting final sign off on the project, closing open contracts, recognizing team accomplishments, survey stakeholder satisfaction, archiving key project outputs and so on.
But with an adaptive life cycle, the approach taken when performing certain activities might vary. Here are two examples of this:
So is there any difference to how projects which were managed using an adaptive or agile life cycle would end compared to those following a traditional or predictive one? At a high level, no, but our approach to specific procedures should always be tailored to fit the context of the life cycle used to deliver it.
It is common to see teams new to those agile frameworks which use time boxes struggling to define product backlog items small enough to get completed within a sprint and still represent value. If they have been used to traditional, predictive delivery approaches, they would have been encouraged to decompose scope down to a manageable level of control, but these work packages would still usually be larger than what is expected of a sprint backlog item.
Some teams respond to this challenge by using long sprints.
While this gives them the opportunity to complete more work within a sprint, it has downsides. The team might be inclined to batch their work by completing one stage of their delivery process for a number of sprint backlog items rather than completing these items individually over the life of the sprint. Long sprints might also reduce the team's inclination to sufficiently refine and split stories.
Other teams try to avoid the challenge entirely by skipping sprints in favor of a continuous flow approach. A mature team can effectively use this delivery method, but new teams without coaching support might end up with an ever-growing work-in-progress backlog as work commences on a work item but as soon as it gets blocked another work item gets pulled.
Shorter sprints make it harder for a team to ignore the reasons for why their work items aren't getting done, including:
While there is no silver bullet to deal with these causes, if a team remains true to the pillars of inspection and adaptation, their ability to deliver consistently should improve over time.