One of the symptoms of lower organizational project management maturity is having more projects active than can predictably be delivered by teams. Even if processes have been implemented for work intake or prioritization, if governance committees continue to accept all project requests presented to them (i.e. the project funnel is a tunnel) the likelihood of staff overworking but still under delivering is high.
In most cases, this may not be the worst thing that could happen – so long as project and functional managers are able to keep their team members focusing on completing the most critical milestones, delays on less important projects might be an acceptable inefficiency.
Where this does become more concerning is when there are multiple genuinely important projects underway and this gets coupled with a work allocation model that has most staff performing operational and project duties. In such cases, there is a strong probability that at one or more times of the year, there will be a convergence of “can’t miss” milestones across multiple projects conflicting with the completion of one or more critical operational initiatives.
In an organization with lower levels of maturity, this situation can be similar to the chaos that would ensue if a half-dozen footballs were dropped in the midst of an unsupervised group of preschoolers. In the organizational context, staff will focus on the project milestone or operational activity which has been given the greatest priority by their project manager (in strong or some balanced matrix organizations) or by their direct reporting manager (in functional, weak or some balanced matrix organizations). Since not each team member will receive the same instructions or priority directions, the risk is high that nearly all milestones will be missed.
To avoid such entropy, the easy answer is for the organization to take on less work – they should cut their coat according to their cloth. However, this requires a fairly detailed quantitative understanding of staff capacity and capability as well as a governance team that is judicious about project selection & scheduling – both signs of a higher maturity organization.
Failing this, what else can be done? Try to avoid milestone convergence at all costs.
While the ultimate tool to help achieve this might be a detailed cross-project/operations schedule, this will take a tremendous amount of effort to develop and, in low maturity organizations, it will be out-of-date the moment it has been published.
A simpler approach is for project & functional managers to maintain a list of critical milestones for their project and operational responsibilities for the next few quarters. The only information required to be captured is the name of the initiative, the milestone description, the true degree of schedule flexibility for the milestone (or rather, the impact if the forecast date slips) and the forecast date.
When developing project schedules or creating operational calendars, project and functional managers should review this list and if they are in a situation where a new milestone will conflict with existing ones, a quick meeting should be called to identify the “pecking order” at the milestone (NOT project or initiative) level, and rescheduling should take place on all other initiatives. If this can’t be done for a particular convergence point, at least the organization will have a sufficiently advanced “head’s up” to assign additional staff or other such techniques of avoiding contention.
Reducing the number of active project and operational responsibilities for staff is a long term goal for lower maturity organizations, but a good short term objective is to shift focus to key milestones across concurrent work streams to avoid perfect storms.
(Note: this article was originally written and published by me in June 2013 on my personal blog, kbondale.wordpress.com)
Anyone that has taken a course in risk management knows that there are multiple strategies available to respond to identified negative risks including avoidance, transferral, escalation, acceptance and mitigation.
One would assume that risk owners would select the right response for a given risk, but most of the risk registers I’ve ever reviewed usually reflect only two responses – accept and mitigate.
For low severity risks which are usually characterized as having either a very low probability of occurrence as well as a low to medium impact if realized, the effort required to eliminate them may cost more than the benefits of doing so hence acceptance might be the best response. For risks which lend themselves to mitigation and whose severity is significant enough that it merits the effort, developing and executing an active response, that might be the best strategy.
But when was the last time you actually saw a project team propose and execute an avoid or transfer response strategy?
There are a couple of common ways in which an avoid response could be used – one is to reduce or modify scope which in extreme cases could even imply electing not to proceed with a given project.
For example, if a highway is to be built spanning multiple cities in a developing country, yet I know that the region between two of the cities is plagued by insurgent activity, I might propose that the project’s scope be reduced to skip connecting those two cities until order is restored to avoid incurring any labour-related safety concerns.
It is also possible to avoid a risk by changing one’s approach to delivering scope – in the highway construction example, while the straight path between two cities might be the shortest, if that would result in the destruction or disturbance of some ancient ruins, significant stakeholder risks could be avoided by taking a longer route.
With a transfer strategy, the objective is to shift the risk to a third-party. While the common method of doing this is to purchase insurance, outsourcing a subset of your project’s scope to a subcontractor who assumes full risk of quality or schedule issues is also an option.
One of the key benefits of both the avoid or transfer response strategies is that they can completely eliminate specific risks which is an ideal outcome in those cases where risk severity is extreme. However, the efficacy of these strategies tends to diminish over the lifetime of a project – during initiation and planning, they can be quite effective, but once scope and approach are nailed down, it can be a much costlier proposition to avoid or transfer risks.
As with all risk management activities, neither of these responses is free so it is important to balance the cost of avoidance or transfer against the expected financial and non-financial (e.g. reputational) impacts of risk realization before making response recommendations.
As Mr. Miyagi said in the Karate Kid Part 2: “Best way to avoid punch, no be there!”
(Note: this article was originally written and published by me in December 2013 on my personal blog, kbondale.wordpress.com)
Whether there’s a legitimate benefit or merely a placebo effect at work, there does appear to be some correlation between having had a flu shot and avoiding or at least reducing the severity of respiratory viruses. There are, of course, a multitude of other proven and unproven preventative measures including a good night’s sleep, frequently washing hands and (if you really want to make a fashion statement!) wearing masks over one’s mouth & nose.
Similarly, in project management, there are a number of preventative measures available to us to avoid unpleasant surprises. The whole risk management knowledge area could be thought of as a major preventative measure as it helps us to better manage the unknown. Stakeholder analysis and management processes are also heavily focused on prevention of future issues.
A lesser applied practice is assumptions analysis.
Uncertainty is an intrinsic part of projects and yet, when we define approaches, derive estimates or develop plans, we are doing so with this uncertainty present. If we wanted to plan our projects with full certainty, we would never complete any projects. Hence, in the absence of total clarity, assumptions get made.
While it is bad enough to provide a single-value estimate without presenting some idea of potential variation, it is worse to do so without providing the underlying assumptions which support that estimate. Similar, when picking an approach to meet project scope, there are usually multiple options considered and assumptions are likely made which would guide which option gets recommended.
Assumptions by themselves are not bad. However, if we don’t document them and then fail to analyze and validate them, we run the risk of executing a theoretical plan which does not reflect reality.
On the other hand, if we regularly review & validate key assumptions, we might just buy ourselves the lead time needed to take corrective action to avoid the impacts of variances between we had previously assumed and what is real. Furthermore, while we might consider disproven assumptions as being a source of future project issues, they could just as easily provide us with opportunities which could be exploited if we get sufficient lead time.
Assumptions analysis is a key input into risk identification, but it could also be performed independently as a routine preventative activity. If you are maintaining an Assumptions Log for your project, you could dust it off every few weeks over the life of your project and validate that core assumptions are still valid during regular project team meetings.
An ounce of assumptions analysis might save you a pound of firefighting!
(Note: this article was originally written and published by me in April 2014 on my personal blog: https://kbondale.wordpress.com)
Ask almost anyone who has worked on a project whether they believe that risk management is important and you will be unlikely to hear otherwise.
So why do we continue to struggle with implementing risk management practices in an appropriate, value-focused manner?
Ineffective risk descriptions – your team might have identified a high severity risk which requires an immediate response, but if the risk description isn’t meaningful to your stakeholders, it is unlikely to generate the sense of urgency you were hoping for. When in doubt, share the descriptions of your key risks with a trusted peer who is not very familiar with your project and ask them if they perceive the need for a call to action.
Insufficient divergence or convergence – when identifying risks, you want to cast as wide a net as possible. A key expectation is that you will be able to transform as many critical unknown-unknowns into known-unknowns as possible. Having a broad, diverse set of participants and using techniques such as brain-writing can push past the inertia of just identifying obvious, low hanging risks. However, once it comes time to analyze and respond, focusing needs to occur on the vital few, leaving the remainder on watch-lists for occasional monitoring.
Addiction to mitigation – I’d written previously about the benefits of considering all response strategies, especially when facing a particularly nasty threat. To channel Mr. Miyagi “Best way to avoid punch, no be there”. Trying to convince your sponsor to reduce scope early in the project to avoid a critical risk might not be a conversation you look forward to, but it’s likely going to be a lot more pleasant discussion than the one you’ll have if the risk gets realized.
Failure to refresh – the risk register must be considered a living document for it to provide any value. As your project progresses and changes occur, if you don’t iterate back through the identification, analysis, and response development processes, the efforts spent at the beginning of the project on these is wasted. A longer term outcome of this behavior is that team members and other key stakeholders will be even less likely to commit their efforts to risk management.
Assumptions don’t get analyzed – assumptions are an important input into risk identification. Until an assumption is validated, there is always the likelihood of it being wrong, and if so, this could impact the project. Not only is it important to capture key assumptions made while planning the project but it is a good idea to review them at a regular interval to test their validity so that appropriate responses can be executed. This is another good reason to have a diverse group of stakeholders involved in risk management procedures – the narrower the selection, the greater the likelihood that assumptions won’t get challenged or revisited.
Lessons don’t get learned – the issues which occurred on one project should provide a clear warning to future projects. As part of the preparation for a risk identification session, a review of some key lessons identified on completed projects which bear any similarity to yours might yield some gems to review with the team during the session. Empirical evidence of the realization of some risks on past projects can go a long way towards overcoming biases.
Letting risk owners of the hook – risk management is only marginally useful if it doesn’t result in any change. If you are unable to secure the attention of your risk owners and maintain it through to the successful development and implementation of response strategies, you’ll be as effective as Cassandra – foretelling doom without the ability to convince anyone to act on it. In addition, if your risk owners avoid their responsibilities without follow-up and escalation from yourself, the message you will be reinforcing is that there’s little value in risk management.
We all know that it’s in our best interests to eat a balanced diet, exercise regularly, get plenty of sleep, and avoid or at most moderately indulge in vices. It’s demonstrating discipline, focus, and persistence to put it into practice where most of us fail. This might happen because the returns of following good personal health habits like these don’t get earned immediately. The same can be said of project risk management – benefits realization lags behind the effort invested.
Johann Wolfgang von Goethe - “Knowing is not enough; we must apply. Willing is not enough; we must do.”
(Note: This article was originally written and published by me in March 2016 on Projecttimes.com)