Who Owns Risk?

Who owns risk

Who owns riskThis is a guest post from Christine Sato

Proper risk management is vital to any project manager. Any big project is sure to have a great deal of risk, which needs to be identified and evaluated. The ability to accurately identify the risk factors and gauge the stakes of a given project is instrumental to proper management of that project.

It is safe to say that the management of risk is the job of a project manager, but who owns the risk? The concept of risk ownership is a tricky one, with a few potential answers.

Defining Risk

Risk, as it applies to project management, is any element of uncertainty in a project. This can take the form of negative risks, or threats, and positive risks, or opportunities. Among these risks are known risks which can be planned for, and unknown risks which require adaptability to manage.

The project manager is responsible for risk management, which entails identifying the positive and negative risks, planning for known risks, and quickly adapting to unknown risks as they arise. They usually have the final say in risk management, but they can delegate some aspects of the risk management process through assigning owners to risk.

Project Management and Risk Ownership

Risk ownership, as it applies to project management, is mostly about assigning portions of risk to individuals. When these individuals are delegated ownership of risk, it doesn’t literally mean they own the risk; that would be the organization or individual that provides the capital. Rather, risk owners, as delegated by the project manager, are usually those who have intimate knowledge of the risk in question, and have a large amount of influence over its outcome. The ‘ownership’ in this definition of risk ownership means that they must own the consequences of the risk, meant in the same way that one owns their mistakes.

Aspects of Delegated Risk Ownership:

  • Identifying threats
  • Identifying impact
  • Assigning responsibility
  • Implementation of risk response
  • Reporting risk
  • Identifying risk interdependence

Bearing Risk Vs. Owning Risk

The literal owners of risk, the ones who financially back the project in question, are referred to as risk bearers instead of risk owners. The risk bearers could be the board of directors, an individual entrepreneur, angel investor, or other financial backer. Since these individuals are the ones bankrolling the project, they can be said to literally ‘own’ the risk, and will usually have the final say on any decisions made by the project manager. However, for the purposes of project management, these individuals are referred to as risk bearers, with the ones managing the risk being risk owners. In some cases, risk bearers can also be risk owners: for example, a member of the board of directors can be assigned ownership of one aspect of risk by a project manager.

Conclusion

Risks are part and parcel of any serious undertaking. Any business project is a roll of the dice, and the project manager is responsible for weighing the odds. In this aspect, risk ownership can be defined in three ways, with three groups of risk owners. Individual team members own specific aspects of the risk, requiring them to accurately monitor and mitigate them. The suppliers of capital and resources literally own the risk, seeing as they are the ones with the most at stake.

Lastly, the project manager has the most important role, owning risk as the final say in the risk-making process. They are responsible for taking the input from individual risk owners, weighing it against the desires of the risk bearers, and owning the final consequences of their decision.


Christine Sato founded the site CPA Review Courses – an online resource dedicated to helping professionals pass all four sections the CPA Exam on their first try. Christine provides cpa review courses and guides and gives expert cpa study tips in order to ease the process of becoming a CPA.

 

“Digital” Transformation

transformationMany folks are talking about the ‘digital’ transformation that is happening across many industries and businesses today.  These folks mention digital transformation as if its something new or different than any other transformation project that companies have had to undergo through their lifetimes.

Last week I read a post titled “Why most digital transformation projects will fail (and how to make sure yours doesn’t)” written by Martin Gill, VP and Principal Analyst at Forrester Research.   Martin provides a very good overview of why he believes most digital transformations will fail (and I agree wholeheartedly with everything he writes).

The interesting thing about Martin’s article is that he doesn’t focus on the ‘digital’ aspect of the transformation. This is significant because transformation isn’t really anything new. Companies have had to transform their business models or they’ve died.  Digital transformation is nothing special olr new…its just another change that companies have to undergo to remain competitive.

They key for ensuring a successful transformation of any kind is proper change management. Whether that transformation is a digital transformation or the ‘next’ transformation to come along, if you can’t implement a well managed and properly planned change management project, your transformation project will fail.

At the end of his article, Martin gives his advice for ensuring your digital transformation project succeeds. He writes:

The way organizations have been planning and managing large-scale change is no longer fit for purpose.

We need a new approach. An iterative, customer-centric, and agile approach. One in which your digital strategy is engaging, easily consumable by all your key stakeholders, compelling, and, above all, responsive to the inevitable change we all face.

Notice that he leads off by stating that the key priority for ensuring success is a quality change management approach.  He doesn’t talk about getting buy-in for ‘digital’ or some other topic…he talks about the importance of change management.

If you want to ensure your digital transformation project (or any other transformation project) succeeds, make sure you have a good idea in how to enact change within your organization. Without proper change management, any transformation you undertake is doomed to failure.

Finding ‘the’ system

384207390How long have you been looking for that ‘perfect’ system?

You know….the project management ‘system’ that will be your savior.

Or the governance process that will ensure that your IT group is running ‘right’.

Or that Social Media approach that will make your marketing efforts ‘perfect’.

Or…perhaps that perfect system that will make you money in the stock market.

The thing with finding ‘the’ system is that there’s never a system that’s right for everyone.  In fact, there’s never a ‘perfect’ system…there’s only systems.

As a project manager,  you are taught that the Project Management Institute’s body of knowledge is “the” way to manage projects…until you are taught that Agile is the way to go…and then you learn that some other form of managing projects is  the ‘best’ approach.

As an IT leader, you’ve been groomed to think ITIL will solve your troubles…until you realize it won’t.   You bring in consultants to implement the latest and greatest approaches and are promised they are the answers to your prayers.  But…you soon realize you’ve just spent money on yet another buzzword…sure they buzzword helps, but it isn’t “the” answer.

As a marketer, you were giddy when you realized how powerful social media was for ‘building your brand’, so you threw money at it.  You hired ‘ninjas’ to run your campaigns.  Then…realized that the perfect ‘system’ they promised you wasn’t working.

As an investor, you  spend years looking for that ‘holy grail’.  Maybe you spend hundreds, thousands or tens of thousands of dollars for systems, newsletters and software…to no avail. Nothing is working ‘perfectly’.

Welcome to the real world. There is no perfect.  There’s only approaches that work for some and don’t work for others.

Rather than spend money / time searching for ‘the’ system, find what works for you.

Image Credit: Perfect by -= Bruce Berrien =- on flickr

The magic and mystery of 1 percent

This post sponsored by the Enterprise CIO Forum and HP.

What do you think about 1%?

Its tiny isn’t it?  Minuscule even. I mean…1% of a a dollar is 1 cent. 1 measly penny.  Who cares about pennies these days?

A 1% increase in salary is a slap in the face to many employees. Most argue that they’d rather not get anything than be given a 1% raise.   For someone making $75K a year, a 1% raise equates to $750 a year which is $62.50 per month before taxes.   Not exactly a lot of money…but I’ve never seen the people complaining about their ‘small’ raise actually give that raise back either 🙂

Sure…1% of something ‘small’ is small initially, but over time, something small can grow into something big.

Let’s take a look at saving money. Let’s assume the above salary increase of 1% on $75K. Each year you get another 1% raise.  If you take your annual salary increase each year and save it and get a 1% annual return, you’ll save $11,181 over 20 years. Thats not a lot.  If you increase the savings 1% more, you end up with $22,361 after 20 years (double your money…not bad. Increase your savings 1% per year over 20 years (for a max of 16% savings) and your savings go from 11K to 120K (source). Note: in the chart below, savings are shown in today’s dollars, assuming inflation is 3 percent per year.

Take a look at this chart to see the magic of 1%:

That’s the magic and mystery of 1%.

On small scales, 1% is small. On large scales, 1% is huge. That’s the magic and the mystery of 1%.

Let’s take a step away from the savings world and look at things that are more easily understood and applied.

The Magical 1% in the Real World

Let’s take a look at an area that most of us are familiar with.

Assume you are a project manager in charge of a large enterprise software implementation.   You have a budget of $350,000 to complete this project.

After the first month, you realize that your project is slipping. This slippage will create a budget hit of roughly 1% for the first month because you’ve got to bring in an additional person to cover this slippage.

You go to your project sponsor with this information and she tells you “don’t worry…what’s 1%…I never worry about this type of stuff till it gets to 5 or 10%”. Note: I’ve actually had project sponsors tell me this. Many times.

You shrug your shoulders and go about your day. You look for ways to bring in this slippage and get the project back on track. You realize that the slippage is from your project team members not giving you their full allotted time to your project.  You ask around and are told that there are other projects ‘just as important as yours’ so you’ll just have to manage your project with the resources you have.

You take your issue up the chain of command. You talk to the VP. You talk to the CIO. But…they both tell you that every project is important and you need to do what you can with what you have. Besides…they say…what’s 1% slippage really going to cause anyway…its small so don’t worry.

You resign yourself to having to pay this additional person every month you can figure out how to get more in-house hours.  So…you are seeing a 1% budgetary hit per month.

But…1% is small, right?  Nothing to worry about, right?

Wrong of course.

For the sake of argument, let’s just say that this is costing you 1% per month of your $350K budget . You are getting hit for an additional $3500 per month that you weren’t expecting to have to spend.

1% is small.  $3500 isn’t.

After 3 months…you’ve spent over $10K that you weren’t planning to spend. After 12 months, you’ve spent $42K.  Now…THAT is a lot of money.

But its only 1% they said. Its small. But its not.

That’s the magic and mystery of 1%. Don’t ignore it because its small. Don’t overlook it due to its size. 1% is small and large at the same time.

This post sponsored by the Enterprise CIO Forum and HP.

IT Projects – doomed from the start?

110..365 | The End? By Katkamin on flickrI just ran across an interesting research report titled “Doomed from the Start? Why a majority of business and IT teams anticipate their software development projects will fail

The report provides the results of a survey completed by 596 IT and Business executives with the majority of respondents being IT professionals (476 out of 596 were IT professionals).

The results are interesting.  A quick summary of the results is provided below:

  • 75% of respondents admit that their projects are either always or usually “doomed from the start”.
  • 80% of respondents admit that they spend at least half their time on rework.
  • 55% of respondents claim that business objectives of IT projects are clear
  • 23% of respondents state that they are always in agreement when a project is done.
  • 73% of respondents claim that the IT team is successful or very successful in delivering projects that meet the business expectations. Note: “successful” was claimed to be meeting 70% or more of the project goals.
  • 75% of respondents  claim that IT is a valued, trusted partner and critical to the company’s success

Interesting stuff.  Good to see that last point for sure.

I wanted to take a second for a little discussion on a few topics…

At times, I think that part of the problem with most IT projects is the attitude of the IT team…and this survey seems to highlight that with the fact that 3/4 of respondents believed that projects are doomed from the start.  You start a project expecting it to fail, you are going to most likely fail.

Almost 3/4 of respondents claim the IT team is successful in delivering 70% or more in project deliverable.  Since when did meeting 70% of a goal mean success? Calling 70% of project goals a success is kind of like saying ‘meh…just do the bare minimum to squeak by’. In school, a 70% is a “C-“….I don’t know many teachers that would be telling a student that they were successful if they finished the year with a “C-” average.

If meeting 70% of a project’s goals is considered a success, then yes…the projects are doomed from the start.

Image Credit: 110..365 | The End? By Katkamin on flickr

Hope isn’t a tactic either…

...Hope...By ĐāżŦ {bad contact, no biscuit} on flickrYou’ve probably heard the old saying that “Hope isn’t a strategy”.

I’ve written a few words on the topic of Strategy, Tactics and Hope in the past and have even talked about minding the gap between strategy and tactics.

Most people and organizations understand – at least in theory – that they need a strategic plan to be successful. And…by strategic plan, I mean something that drives the direction of the organization….it could be a 500 page document or it could be a short half-page plan.

Many people / organizations take this strategic planning process very seriously. Teams are formed. Meetings are held. Numbers are crunched…and document written.

The outcome of a strategic planning process is the final plan (hopefully). Everyone signs off on the plan. Everyone looks at that plan as the saving grace of the organization.

Project teams are built. Implementation plans are developed. Everyone’s excited.

Then…nothing happens.

And…nothing continues to happen.

Why?

Various reasons of course. Granted…there are many organizations that build a strategic plan and do what needs to be done to make that plan a reality…but there are also many that don’t.

One common cause of failure that I’ve noticed in organizations is a simple one…nobody stops to really consider the tactical approach to the strategic plan.

Those same organizations that have eschewed hope as a strategy embrace it as a tactic. They ‘hope’ they have the right people in place. They ‘hope’ everyone knows their role and their responsibility in make the strategic plan a reality.

Now…no organization actually uses the word “hope” in their planning, but it becomes clear when the strategic plan is reviewed and compared to the implementation plan.

Granted…in my posted titled Strategy, Tactics and Hope, I used the word ‘hope’…but I meant it in a different way (really..I did!) 🙂

In that article, ‘hope’ is from the employees side…they have to believe that they can achieve the goals in the strategic plan.

The hope that I’m talking about here is the replacement of the planning and thinking process with a “hoping” process.

These organizations build elaborate strategic plans but fail to build on elaborate tactical plans to reach their objectives and just hope that things are in place to meet their goals.

Don’t fall into the trap of hoping…hope isn’t a strategy….and its not a tactic either.

Image Credit: …Hope…By ĐāżŦ {bad contact, no biscuit} on flickr