Risk Management Is Project Management for Adults

The title of this article is a quote from Tim Lister, and is a universal principle for the success of any project in the presence of uncertainty. All software development projects are subject to risk and uncertainty because they are unique, constrained, based on assumptions, performed by people and subject to external influences. Risks can affect the outcome of projects either positively or negatively.

“If There’s No Risk On Your Next Project, Don’t Do It” 

Greater risk brings greater reward, especially in software development. A company that runs away from risk will soon find itself lagging behind its more adventurous competitors. But by ignoring the threat of negative outcomes project managers and executives can drive their organizations into the ground.

Positive Risk

Risk includes both opportunities and threats. Where negative risk implies something unwanted that has the potential to irreparably damage a project, positive risks are opportunities that can affect the project in beneficial ways. You should manage and account for known negative risks to minimize their impact, but positive risks you should manage to take full advantage of them.

There are many examples of positive risks in projects: you could deliver the project early; you could discover that the problem is easier to solve as expected; you could re-use your solution for other problems; you could acquire more customers than you accounted for; you could imagine how a delay in shipping might open up a potential window for better marketing opportunities, etc. Just be aware that positive risk can quickly turn to negative risk and vice versa.

Risk or Uncertainty? 

In project management, or more specifically in risk management, many professionals commonly use risk interchangeably with uncertainty. This is incorrect.

“Uncertainty is risk that is immeasurable.” – Frank Knight

Risk has an unknown outcome, but we know what the underlying distribution looks like. Every game in the casino has a known distribution of winning and losing. Hence you can play and manage risk. Following basic strategy for Black Jack for example. But where the hand of your new and unknown Poker neighbor is a risk, how he plays that hand is an uncertainty. Events of the past are no guarantee for the future.

You cannot manage uncertainty, but you can manage risk. What you can do is reduce the amount of uncertainty. For example by doing a proof of concept or a business case validation for your project.

Risks and Issues

Consider the following circular definition of risk: A risk is an issue that has yet to occur, and an issue is a risk that has already materialized.

Before it happens, a risk is just an abstraction. It’s something that may affect your project, but it also may not. There is a possibility that ignoring it will not come back to bite your ass. Risk management is the process of thinking out corrective actions before an issue occurs. The opposite of risk management is crisis management, trying to figure out what to do about the issue after it happens.

“The opposite of risk management is crisis management” - Tim Lister

Varieties

Risks may be encountered in an almost infinite variety of forms and intensity, it is most useful to consider two varieties:

Incremental risks - These include risks that are not significant in themselves but that can accumulate to constitute a major risk. For example, a cost overrun in one subcontract may not in itself constitute a risk to the project budget, but if a number of subcontracts overrun due to random causes or a common cause affecting them all, then there may be a serious risk to the project budget. While individually such risks may not be serious, the problem lies in the combination of a number of them and in the lack of recognition that the cumulative effect is a significant project risk.

Extreme risks - These include risks that are individually major threats to the success of the project, or even the company as a whole. Their likelihood is typically very low but their impact very large. Examples of such risks are dependence on critical technologies that might or might not prove to work, scale-up of bench-level technologies to full-scale operations, or dependence on single suppliers and employees. And of course aliens, always account for a space attack by aliens...

Transitions

Imagine the moment when something that used to be a risk suddenly becomes an issue. It used to be an abstraction, a mere possibility, and now it is not abstract at all. It has happened. This is the point at which the risk is said to materialize. It is the moment of risk transition.

Transition is a key concept for a project manager—it is the triggering event for whatever is planned to deal with the risk. Well, almost. The actual transition may be invisible to you (for example, your biggest client goes out of business). What you do see is a transition indicator (the client not paying your invoices for a while). For every risk you need to manage, there is some kind of transition indicator. Of course some indicators are more useful than others.

Response Strategies

Depending if a risk is positive (opportunity) or negative (thread) you have following response strategies available to you.

The reason you care about the above-mentioned transition is that when the indicator fires, you intend to take some action. This is defined in your contingency plan. But much work can be done before the transition starts. And you should. Buying a life insurance after your dead is difficult...

Risk Management

So what is risk management? I always explain as the combined outcome of the five activities below.

1) Risk discovery: your initial risk brainstorm and subsequent triage, plus whatever mechanism you put in place to keep the process going

2) Exposure analysis: quantification of each risk in terms of its probability of materializing and its potential impact

3) Contingency planning: what you expect to do if and when the risk materializes

4) Response planning: steps that must be taken before transition in order to make the planned contingency actions possible and effective when required

5) Ongoing transition monitoring: tracking of managed risks, looking for materialization

The first of these is an overall activity, while all the others are done on a per-risk basis.

Risk management is something that most of us practice all the time—everywhere except the office. In our personal lives, we face up to such risks as sickness and early death. We mitigate by buying life and health insurance and by making arrangements for who will look out for the kids if something bad happens.

We don’t pretend to be immortal or that our earning capacity can never be harmed by bad luck. Each time we take on a new responsibility—say, a mortgage—we go over all the awful things that we hope won’t happen and force ourselves to think, what if they do?

You should do the same for your software development project.

Read more…

Why Do Technology Projects Fail so Often and so Spectacularly? My Personal Top 10 Reasons

It was to be a great digital leap for Germany’s biggest discount grocer. Instead, after seven years and €500 million, Lidl’s new inventory management system with SAP is dead on arrival. Now everybody is asking why.

Big technology projects fail at an astonishing rate. Whether major technology implementations, postmerger integrations, or new growth strategies, these efforts consume tremendous resources over months or even years. Yet, as study after study has shown, they frequently deliver disappointing returns—by some estimates, in fact, well over half the time. These reports show that 25 percent of technology projects fail outright; that 20 to 25 percent don’t show any return on investment; and that as much as 50 percent need massive reworking by the time they’re finished.

And the toll these failed projects take is not just financial. These defeats demoralize employees who have labored diligently to complete their share of the work. Reputations are lost, and legal issues arise.

But the question is why. Why do so many technology projects fail—and fail so spectacularly? From my experience, it’s usually not technology problems that derail technology projects. I am of the opinion that most technology project failures can be attributed to poor management, while only a small percentage are due to technological problems. Reports seem to support my theory.

Below you will find the reasons for project failure that I’ve encountered most in my work as a project recovery consultant.

1) Poorly defined (or undefined) done

Project failure starts when we can’t tell what “done” looks like in any meaningful way. Without some agreement on our vision of “done,” we’ll never recognize it when it arrives, except when we’ve run out of time or money or both. Without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish. Capabilities drive requirements. Therefore, without first identifying the needed capabilities, we cannot deliver a successful project, and it will end up a statistic, like all the other failed projects.

2) Poorly defined (or undefined) success

Besides not having defined what done is, one of the more common problems I see with IT projects is an ill-defined goal or definition of success.

A project can only be successful if the success criteria are defined, ideally upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it's essential to work actively with the organization that owns the project to define success across three levels:

1) Project delivery
2) Product or service
3) Business

A company will say they want to improve customer service, for example, but no one ever bothers to say what that looks like. Shorter call times? Fewer calls? Higher customer satisfaction? How will you know when you’ve succeeded? If you don’t know, you’re doomed to fail.

Related: When is my project a success?

3) Lack of leadership and accountability

Too often, technology projects are deemed “IT” projects and relegated to the IT department, regardless of what the project actually is. But for any project to work, it needs strong leadership from the top down. If a project doesn’t have buy-in and support from C-level executives as well as specific department leaders, it’s difficult to get employees on board and hard to know who is in charge when leadership questions arise.

The moment projects are dubbed “IT projects” and left to the IT department, a lack of accountability can also develop. Executives may wrongly believe that they can’t understand what’s happening, and leave it to the tech guys to figure out. This is a mistake. If your tech team can’t adequately explain what’s happening on the project or why it’s needed, that’s a huge red flag. And if the executives aren’t driving the project and holding the team accountable, it can easily spiral out of control.

Related: How to establish an effective Steering Committee (and not a Project Governance Board)

4) No plan or timeline

How can we get to “done” (see above) on time and on budget and achieve acceptable outcomes? We need a plan to get to where we are going, to reach done. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for risk. The complexity of the plan has to match the complexity of the project.

Without a clear timeline and plan with milestones, any project (but technology projects in particular) can wander off the original path and meander through many detours and dead ends. A clear plan and someone to keep track of it is vital for keeping these projects moving forward.

Also, the famous watermelon reporting (green from the outside and bright red from the inside) is far more likely to happen when there is no clear plan and measure of progress.

“Plans are useless, but planning is indispensable.” – Dwight D. Eisenhower

5) Insufficient communication

As mentioned above, someone on the tech team needs to be able to explain the project details regularly to the “non-tech” executives and other stakeholders. It’s vital for someone on the team to have strong visualization and storytelling skills in order to communicate clearly and regularly what’s happening with the project.

Related: Outsourcing technical competence? and 10 Principles of Stakeholder Engagement

6) Lack of user and performance testing, or failure to address feedback

The thing about technology projects is that ultimately, they’re made for people, not machines. A lack of real-world user testing before launch is a common problem. The software engineers, solution architects and business analysts think they know what users want, but users may have an entirely different set of needs and problems. Once user testing is conducted, the project has to prioritize addressing the feedback, or the end user won’t be happy—and ultimately won’t use the technology created for them.

On a similar note it is essential to test under expected load very early. Even the best system won’t be used, or be very ineffective, when it is just too slow.

Related: Start your project with a Walking Skeleton and It's never too early to think about performance

7) Solving the wrong problem

I’ve seen this time and time again with IT projects: companies think they’re creating something to address the problem, but it turns out they’re addressing the wrong problem. In our customer service example, if the company decides that shorter call times is the metric for improved customer service, employees become incentivized to get off the phone as quickly as possible, which may or may not actually improve customer service. Yes, call time decreases, but customers may be even less satisfied than before.

“We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.” – Russell L. Ackoff

Related: Understanding your problem is half the solution (actually the most important half)

8) Trying to adapt standard software to business processes instead of the other way around

Adjusting standard software to quirky business processes is a recipe for disaster. Going back to the Lidl SAP project, apparently one of the biggest problems was a “but this is how we always do it” mentality at Lidl. Changing the software necessitated reassessing almost every process at the company, insiders say. But Lidl’s management was not prepared to do that.

Unlike many of their competitors, Lidl bases its inventory management system on purchase prices. The standard SAP for Retail software uses retail prices. Lidl didn’t want to change, so the software had to be adapted. Many more accommodations had to be made, and the more changes there were to the code, the more complex and more susceptible to failure the Lidl software became.

Performance fell, and costs rose. Altering existing software is like changing a prefab house—you can put the kitchen cupboards in a different place, but when you start moving the walls, there’s no stability.

“Something I learned in ERP for dummies: Don't customize software to your process unless the process is your competitive advantage.”

9) Continuing to pursue bad ideas

In Hollywood, they say it’s easy to make a bad film from a good script but impossible to make a good film from a bad script. Though you won’t always recognize a bad idea straightaway, once you do, never assume that you’ll make it work or believe that you’ve put in too much effort to change course. The sunk cost fallacy is real.

For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive headfirst into executing the project. The minute you recognize that an idea won’t work, you have to pull the plug. It’s usually impossible to fix a bad idea, and you’ll only waste time, money and energy trying to put lipstick on a pig.

Related: No validation? No project!

10) No real decisions and death by committees

A project often has multiple parties interested in its outcome and groups may even have divergent goals and expectations. I once spent months working with multiple enterprise and solution architects on a new data analysis and modeling platform, only to have our carefully crafted design dismantled by the company’s various heads of department demanding changes to meet their individual needs. Our problem was that we failed to establish who really owned the project and therefore didn’t deal with potential conflicts and disappointments in advance.

Feedback and governance is an essential part of any project. But decision-by-committee rarely leads to the best outcome. Every project should start by establishing clear, workable goals and give one person the ultimate ownership and accountability for meeting them.

Related: Many decisions are no decisions (and this makes projects difficult)

Read more…

10 Benefits of Project Portfolio Management Done Right

Project Portfolio Management is a combined system of tools, methodologies, and processes to support your organization in reacting to change with the speed that is necessary for your organization to thrive. It helps you to do the right projects and to do projects right.

Project Portfolio Management (PPM) does not involve making project-by-project choices based on fixed acceptance criteria. Instead, decisions to add or subtract projects from the portfolio are based on the four goals of PPM:

1) Maximizing the value of your portfolio

2) Seeking the right balance of projects

3) Creating a strong link to your strategy

4) Doing the right number of projects

But how does this help your organization? Why does it makes sense to implement it?  Below you will find ten clearly measurable benefits that you can expect when implementing PPM in your organization. Let’s explore each of these benefits in detail.

1) More Insightful Decision-Making

The first benefit of PPM concerns its ability to drive better business decisions. To make good decisions you need good data, and that’s why visibility is so crucial, both from a strategic, top-down perspective and from a tactical, bottom-up perspective.

Anything that can be measured can be improved. However, organizations don’t always do sufficient monitoring. Few organizations actually track project and portfolio performance against benchmarks. Worse, strategic multiyear initiatives are the least likely to be tracked in a quantitative, objective manner. For smaller organizations, the absence of such a process might be understandable, but for a large organization, tracking is a must.

Not monitoring project results creates a vicious circle: If results are not tracked, then how can the portfolio management and strategic planning process have credibility? It is likely that it doesn’t, and over time, the risk is that estimates are used more as a means of making a project appear worthy of funding than as a mechanism for robust estimation of future results. Without tracking, there is no mechanism to make sure initial estimates of costs and benefits are realistic.

When you have a good handle on past project metrics, it makes it much easier to predict future factors like complexity, duration, risks, expected value, etc. And when you have a good handle on what is happening in your current project portfolio, you can find out which projects are not contributing to your strategy, hindering other more important projects, or not contributing enough value.

Reviewing the data of your project portfolio gives you project history that reflects the symbiotic relationship between money, time, people, value, and projects. Informed decision-making forces you to draw findings based on organization-wide benefits rather than personal interest, contributing to overall portfolio success.

High-value projects are those that align strategically with the organization’s long-term objectives. Effective portfolio management collects information from those project initiatives that performed well in the past and successfully delivered business value. It explores the probability of similar projects flowing in the pipeline, preparing your people to obtain the appropriate briefing and training beforehand.

Your organization is as good as the data you have. The longer you rely on outdated or irrelevant information, the more you just guess and operate in the dark. PPM gives you a reporting and monitoring strategy that will help you get the insights you need. See “How to monitor your portfolio” for more details.

2) Better Risk Management

It is important for organizations to create portfolios that reduce risks, but at the same time, it is necessary to take enough risks to move forward and stay competitive. You must target a point on the scale between playing it so safe that you never reach your full potential, and taking too much risk and losing everything.

Where this point is depends on your appetite for risk, the stage of your organization, your industry, and many other factors that you know better than I do. After you have decided on this point, your project portfolio needs to be balanced in such a way that the combined set of projects have the risk profile and upside potential you want.

PPM helps you create this balance by making the risk vs. value balance visible, transparent, and part of the decision-making process. See “How to evaluate your portfolio” for more details.

3) Optimized (NOT Maximized) Resource Utilization by Doing the Right Number of Projects

Traditional project portfolio management is all about value optimization and optimizing resource allocation. Both are designed in such a way that, in my opinion, it will result in the opposite. As we have seen time and again, running projects at hundred-percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will become even worse because of time spent on re-planning, and value is only created when it is delivered and not when it is planned. Hence, we should focus on delivering value as quickly as possible within our given constraints.

This brings us to lean thinking. Lean is sometimes described as focusing on smaller batch (project) size, shorter queues, and faster cycle time. The focus is on delivering value quickly. In truth, lean is much more than this. The pillars are respect for people and continuous improvement resting on a foundation of manager-teachers in lean thinking. Queue management is just a tool that is far from the essence of lean thinking. But it is a very helpful tool that can have a very positive impact on your project portfolio management process.

PPM gives you a framework and guidelines to help you do this.  See “Doing the right number of projects” for more details.

4) Alignment With the Strategy of the Organization 

One of the biggest mistakes organizations make is not linking projects with strategic goals. Many organizations have a well-defined and well-scoped strategic process. This can be augmented by better and broader idea capture to provide supportive tactics, but the execution of it is the critical challenge. Indeed, as is widely recognized, weakness in execution, not a weakness in strategy, is a primary reason for organization failure. Knowing this, it is important to link the strategic theory governing the organization to the experience of project management. Without this linkage, either the project portfolio is blind to the needs of the organization or the strategic goals are empty, with no support at the execution level. It is clear that this is an area that organizations must get right for long-term success.

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat. – Sun Tzu

PPM makes this linking part of every step of the process. See “How to categorize your project backlog“ and “How to evaluate your portfolio” for more details.

5) Increased Project Delivery Success

One of the best ways to demonstrate the value of PPM is to show how it creates an environment that leads to repeatable and predictable project success. While not discounting the skills of the Portfolio Team, the essence of an effective PPM is providing a process framework and technology infrastructure that allows you to continuously meet your organization’s objectives. Repeatable success is gained by establishing best practices and proven project management methodologies and enforcing their use throughout the organization.

PPM consists of methods that factor in the scale, complexity, duration, and deliverables of a project. With an effective PPM strategy, you can leverage the processes and lessons learned from previous projects. A central repository of historical and real-time data helps you prioritize projects, preventing them from being wrecked by ‘guesstimations.’ This way you can be a proactive organization, not a reactive one.

Unsuccessful project delivery leads to project failure. Project failure can be caused by many factors such as cost overruns, schedule delays, poorly defined requirements, mismanaged resources, lack of strategy alignment, unresolved issues, or technical limitations. PPM allows organizations to ensure these risk factors are transparent and minimized within project delivery.

While it is easy to see how your projects perform in the present, what matters more is ensuring this success repeats itself in the future. Aggregating your projects gives you a consolidated view. This leads to your demands being captured in order to evaluate and prioritize your projects. Individual roles and responsibilities can be allocated to workload, which structures your workflow.

Repeatable success is achievable with a framework that sets boundaries to tightly control the project. It mandates the usage and effectiveness of technical infrastructure and establishes practices that improve governance. Repeatable success equals progress toward your organization’s objectives when the projects were aligned with those objectives in the first place. Many projects fail to deliver benefits even if they’re executed successfully.

6) Faster Project Turnaround Times

Too many organizations try to save money on projects (cost-efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings. You might, for example, be able to complete a project with perfect resource management (all staff is busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only six months.

What's that six-month difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid that you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios where the benefits outweigh the cost savings (see "Cost of delay" for more details).

On top of delivering the project faster, when you are done after six months instead of 12 months you can use the existing team for a different project, delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team.

An important goal of your project portfolio management strategy should be to have a high throughput. It’s vital to get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

There are many reasons why PPM can reduce project turnaround times by an average of 10 percent. Lean governance, workflow, and standardization tend to reflect repeatable, proven processes. The defined processes aligned with PPM technology allow team members to keep the work flowing and will typically increase productivity because it answers two important questions: “What do I stop doing?” and “What do I do next?” As we all know, strategically aligned projects should always result in value for the organization. With shorter time to market, this value can be realized sooner and in many cases can give organizations a head start on their competition. See “Project portfolio throughput: Faster is better” for more details.

7) Maximized Organization Impact

You will maximize the impact of your projects for your organization when you follow the process of PPM. Since PPM is built around the four goals below, you will do the right projects—namely, the ones that push your strategy forward and deliver actual value whilst fitting your appetite for risk.

1) Maximize the value of the portfolio.
2) Seek the right balance of projects, thus achieving a balanced portfolio.
3) Create a strong link to strategy, thus the need to build strategy into the portfolio.
4) Do the right number of projects.

See “How to evaluate your portfolio” for more details.

8) Reduced Sunk Costs

For large or high-risk projects (what is large depends on your organization) it should be mandatory to do business case validation before you dive head-first into executing the project. In the Project Portfolio Funnel below you will see a phase called "Validation" after selection of a project has taken place. In this phase you typically have a business case validation and/or a technical validation in the form of a proof of concept.

PPM is about doing the right projects. In order to help with this I typically use an adapted version of the lean product validation from Jon Lay and Zsolt Kocsmárszky (https://leanvalidation.hanno.co/) as an obligatory step in the process.

We will distinguish between four different kinds of validations. Depending on the project that you want to validate the business case for, you do only one, two, three, or all four of them. When your project is about launching a new product or service I would advise you to do all four validations before executing the project. The results of these validations form your business case validation. Or the opposite, of course; they can also show you that you should not do this project.

A. Validate the problem: Is this a problem worth solving? If users don’t think this is a major problem, your solution won’t be appealing.

B. Validate the market: Some users might agree that this is a problem worth solving. But are there enough of them to make up a market for your product or service?

C. Validate the product/service/solution: The problem might exist, but does your product/service/solution actually solve it?

D. Validate the willingness to pay: There might be market demand and a great product or service. But will people actually be willing to reach into their wallets and pay for it?

As you can see, these validations focus on the introduction of a new product or service for your clients. But you can easily reframe them for all of your projects. Your market can be your employees instead of customers. For example, when you think about implementing a new CRM, but only a very small but vocal number of users see the benefit of it, and are actually quite happy with what they currently have, your market is too small. Or how about the willingness to pay for the accounting department for a new solution that triples the yearly operational costs? See “No validation? No project!” for more details.

9) Transparency

Project Portfolio Management relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. When transparency is complete, these decisions have a sound basis. When artifacts are incompletely transparent, these decisions can be flawed, value may diminish, and risk may increase. See “How to monitor your portfolio” for more details.

10) More and Better Ideas

Although there is clearly no shortage of ideas within organizations, most organizations unfortunately seldom capture these ideas, except in the few cases where a handful of employees are sufficiently entrepreneurial to drive their own ideas through to implementation. This can happen in spite of the organization, rather than because of it.

Organizations are effective at focusing employees on their daily tasks, roles, and responsibilities. However, they are far less effective at capturing the other output of that process: the ideas and observations that result from it. It is important to remember that these ideas can be more valuable than an employee’s routine work. Putting in an effective process for capturing ideas provides an opportunity for organizations to leverage a resource they already have, already pay for, but fail to capture the full benefit of—namely, employee creativity.

To assume that the best ideas will somehow rise to the top, without formal means to capture them in the first place, is too optimistic.

Providing a simplified, streamlined process for idea submission can increase project proposals and result in a better portfolio of projects. Simplification is not about reducing the quality of ideas, but about reducing the bureaucracy associated with producing them. Simplification is not easy, as it involves defining what is really needed before further due diligence is conducted on the project. It also means making the submission process easy to follow and locate, and driving awareness of it. PPM defines exactly such a process. See “Demand management” for more details.

You can buy my books The Art of Technology Project Portfolio Management and The Science of Technology Project Portfolio Management separate or as a bundle in my store. Just click here or on the image.