About Dave Gordon

Dave Gordon is a project manager with over twenty five years of experience in implementing human capital management and payroll systems, including SaaS solutions like Workday and premises-based ERP solutions like PeopleSoft and ADP Enterprise. He has an MS in IT with a concentration in project management, and a BS in Business. In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management.

Complexity, Profitability, and Risk Management

Writing in the Agile Pain Relief blog, Mark Levison ascribes the collapse of the global economy to the complexity of the market for sub-prime loans. He quotes Andrew Haldane’s analogy of a dog trying to catch a Frisbee as a complex application of physics, easily avoided with a simple heuristic. In advocating for simplicity, Mark asks: “Why didn’t the financial regulator system catch the problem early, while it was still small?”

The regulators didn’t catch it because it was legal, however ill-advised. It is the job of legislators to define what activities are illegal, and they are loathe to proscribe highly profitable activities. This is especially true when the people making those profits donate to their election campaigns. So the people who saw the coming disaster avoided it by cashing out, buying up over-sold assets at the trough, and mocking the rest of us. Sort of a social corollary to natural selection. The complexity was profitable – it was greed that made it unsustainable.

As for Haldane: there are no physics problems in nature. They exist only in the minds of humans who reduce their observations to abstractions, in order to decant generalized rules that they can discuss with similarly inclined humans. Dogs bark at physicists, for good reason.

Complexity is More Profitable than Simplicity

Complexity is relative and temporary. At one time, sending a crate of spices from east Asia to Europe was an incredibly risky, complex endeavor. Now we just send it via DHL and it gets there the next day, if we pay a little extra. Making complex activities routine and reliable is the source of all commercial success – the activities are no less daunting, but the risk and capital cost has been spread across far more participants and transactions. There is tremendous profit potential in reliably reproducible complex activities, executed in volume for a small commission.

Consider modern self-service retail transactions: you wave your six-pack of Dos Equis over the barcode scanner and insert your credit card into a slot. The inventory is updated, the supply chain is notified, the purchase is made available for stock level analysis, the sales tax is calculated, accounting system updated, and the total charged to an individual credit account, all without human-introduced errors. Repeat 80 million times a day for the modern US economy, and you begin to see real cost savings.

Risk Management Controls

Controls simplified for non-practitioners, rather than optimized for results, produce sub-optimal results. Similarly, risk management practices dumbed down for the disengaged decision maker, rather than optimized for predictable, reproducible results, result in more catastrophes.

There is generally a strong correlation between risk and reward, except for the category sometimes called “stupid risks.” Think Darwin Award contestants or investors in sub-prime REIT assets. Agile methods work only to the degree that that they provide frequent points at which course corrections can be made and marginal expected benefit (reward) can be compared to marginal uncommitted cost (risk) in order to inform decision-making at both project and portfolio levels. It is as easy to apply Agile methods poorly and fail miserably as it is to model your approach on a ballistic trajectory, making all your decisions at the beginning and then adjusting based on the actual point of impact before you start over.

Predictable, Reproducible Results

The best argument for Agile methods is demonstrated, predictable, reproducible results. Nearly twenty years after the Snowbird conference, we have plenty of evidence of what works. Simply professing Agility, absent top-down commitment to excellent management practices, doesn’t change a damned thing. And neither does decrying Dilbert-style management. We have to embrace the complexity, master it, and make it our super-power.

All that said: a rigorous approach to defining the business case, followed by an unambiguous definition of “done,” ruthless execution, and continuous risk management still won’t guarantee results. But if you want a guarantee, buy a toaster – they’re simple.

Aligning Projects with Organizational Strategy

PMI Talent TriangleEvery three to five years, Project Management International conducts a role delineation study. The 2015 project management RDS led to development of what PMI calls the “Talent Triangle.” This is a list of competencies in three groups: technical project management, leadership, and strategic and business management. While most professional project managers “get” the first two, many are dubious about that last item. But employers expect us to think beyond our immediate responsibilities. In talking with business and government leaders, PMI found a recurring theme: Project managers need to take an active role in aligning projects with organizational strategy. The most recent RDS reinforced that finding.

The Project Manager as Reporter

“[M]ost companies see ‘project trees’ rather than ‘strategic forests.’ Only a minority attempt to balance key attributes of strategy implementation across the portfolio, such as alignment to different strategic priorities (47 percent) and risk and reward (35 percent). Worse still, a large number of firms that do seek such balance fail: only 32 percent of respondents believe their organizations balance the relevant portfolios against strategic priorities; just 22 percent say the same of risk.”Implementing the Project Portfolio: A Vital C-Suite Focus

One of the recurring themes I’ve seen on my consulting projects is the difficulty of harmonizing processes and systems after a merger or acquisition. Executives negotiate these strategic deals without bothering to sweat the implementation details, because that’s the job of middle management. Of course, much of that sweat falls from the brows of project managers, who typically work across domains to implement that strategy. Few of those middle managers are positioned to see what’s going on outside their domain. They aren’t aware of conflicts, don’t realize what is being done to work around resource constraints, and may be oblivious to critical risks the organization is exposed to. This is especially true for middle managers who are stakeholders, but not sponsors of the projects under way. They are parties in interest, but not participants. It falls to the project managers to keep them informed, and sometimes to prompt them to action. And in the best case, get everyone pulling on the same end of the rope.

The Project Manager as Counselor

Project managers have little direct authority, but the good ones cultivate influence. Sales people and consultants aspire to be “trusted advisers,” who can point out strengths, weaknesses, opportunities, and threats. But in order to become a walking SWOT analysis, you have to be perceived as knowledgeable, trustworthy, and collaborative. And as a project manager, you additionally need to be perceived as an agent of change – which you are, courtesy of your projects. Influence comes from perception.

Your stakeholders need current, actionable information, but they also need someone who will listen to their concerns and respond to their requests (even with “No”). You need to be able to frame conversations with your stakeholders in the context of the organization’s goals and the strategy to reach them, rather than your project’s goals. That requires hard conversations about priorities and risk tolerance with your project sponsor and senior folks who can put that strategy in context. You need to be able to facilitate conversations and guide decisions that are focused on the stated direction of the organization, rather than the personal goals of one manager. I’ve seen too many projects get bogged down delivering a scope change that never should have been approved, because it was considered and rejected by the portfolio manager before funding was approved.

A Strategy Provides a Structure for Decisions

A strategy isn’t magical, nor is it a guarantee of success. But it provides a structure for making decisions and taking action. Strategy depends on execution, and modern organizations are holding their project managers accountable for execution in alignment with strategy. Project managers who deliver on these expectations will be recognized for it, and those who don’t will be recognized for failing to deliver. Plan and act accordingly.

Managing Risks That Evolve Over Time

Most project managers are used to making a qualitative risk analysis in two dimensions: the likelihood that an event will occur, and the impact of the event. And most risk management plans include some sort of “T-shirt” sizing scale to facilitate classification of probability and impact as small, medium, large, and so on. While not particularly rigorous, relative categorization does have the benefit of getting SME participation without making great demands on their time or making them uncomfortable with complex quantifying processes. A qualitative approach can be useful for determining which risks are significant enough to require a risk response strategy or additional quantitative analysis.

But to paraphrase Rod Serling, there is a third dimension: time. Some risks are always present, while others are episodic or cyclical, or even overtaken by events. For that reason, it can be valuable to model the expected life cycle of a risk, in order to determine whether it needs special handling.

Characterizing the Evolution of a Risk

Let’s consider three cases:

  • A risk that impacts a task or deliverable. For example, an external event or delivery that, if delayed, would delay a project task on the critical path. We’ll call this a dependency risk.
  • A risk associated with an assumption. In many cases, a critical assumption can’t be confirmed to be accurate until somewhat later; thus, the possibility that it is incorrect will linger until that time.
  • An external / environmental or internal business risk that might have significant impact but only in some specific window of time. We’ll call this a “fly-by” risk.

There are other scenarios, but in the typical IT project, most will fall into one of these categories.

Dependency Risks

Most project schedules include dependencies—one task can’t begin until another is complete. While good project plans have some slack built in, a task on the critical path that is delayed can have significant impact. For example, if your project has a requirement to go live at the beginning of a quarter, all it takes is a delay in the right place to significantly impact the schedule and all associated project costs. Thus, the probability of the event occurring is spread over a rather narrow span of time, but the impact follows it and can be spread over a much longer period.

In developing responses for dependency risks, it can be helpful to prepare both a mitigation strategy to reduce the probability of the event, and a contingency plan to manage the event as an issue if it happens anyway. Dependency risks naturally have an end date; the event probability of a properly managed dependency risk should be expected to be reduced as that date comes closer. Part of your risk management strategy should include diagnostics, a specific expectation of the probability reduction over time, and triggers to proactively initiate conversion of the risk to an issue before the end date.

Assumption Risks

Most projects are planned with at least a few assumptions—consider them to be accepted risks. Good project plans identify the assumptions as such, and include tasks to validate the critical assumptions. Where the validity of the assumption is questionable enough to represent a significant risk, the validation tasks should get a correspondingly higher priority. Risk responses for assumption risks may have to include revisiting the budget and business case. You don’t want to preside over a “zombie project” when the cost / benefit ratio has shifted in the wrong direction.

Assumptions are necessary for decision-making in the absence of certainty—we simply need to have a plan for how we’ll deal with newly found certainty, before we get to it.

Fly-by Risks

Chapel in the SkyWhile an asteroid strike isn’t a significant risk for most IT projects, year-end processing and other business-as-usual activities can be. I’ve seen more than one project delayed when resources were pulled for an emergency response to an event we already had on the calendar. If you know you might have to compete for resources during some finite window of time, identify it as a risk.

You may not be able to reduce the probability of the event, but it may be possible to transfer the risk by assigning tasks during that critical period to other resources. It may also be possible to avoid the risk by proactively juggling some tasks during the planning stage to reduce your exposure during that window. This usually doesn’t need to be more complicated than incorporating public holidays and staff vacation or maternity leave plans into your schedule.

The Evolving Project Risk Exposure Profile

While it isn’t necessary for all projects, it can be helpful to express your project’s risk exposure profile over time. There are a number of ways to graph the combination of probability and impact of multiple risks over a timeline. Showing your key stakeholders how the risks to the project are being shepherded to retirement can go a long way toward retaining their support when those events you are trying to prevent happen anyway. If you can demonstrate how your risk management plan will ultimately eliminate risk exposure at some point near the end of the project, you’ll probably get a lot more engagement in reaching your goals.