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.


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.


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.

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.


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

Do projects matter for IT?

This is a guest post by Aren Cambre. Aren is a manager of web technologies at an educational institution. The way he explains it is, “If the web site looks like crap, they’re yelling at public affairs. If it’s broken, they’re yelling at me.” He has a M.S. Computer Science and is plodding towards a doctorate. His personal blog of random mis-mash is at http://arencambre.com.

Project Management Lifecycle By Ivan Walsh on flickrInformation technology (IT) focus is shifting from classical projects to agile services.

Here’s why.

Reason 1: Much of IT defies project definition

A classical project has a predetermined start, end, and result. When done, the result goes into “maintenance mode”, and you jump to the next project.

But what if something never has a “maintenance mode”?

For example, the web is never done. A university’s web site must be exciting and work quite well; the key audiences are technologically progressive prospective and current students. What university wants technophobic students? Relevant university sites must keep up with rapidly evolving consumer technologies.

A university’s web site is a good example of an agile service: an adaptive mix of agile applications and expertise. These are where a lot of IT’s attention is going.

Agile services don’t end. They are not classical projects.

Reason 2: Small projects don’t matter much

Isn’t a service just a lot of mini-projects? And isn’t the last trend to make projects smaller?

Neither matters much. Small projects are really large tasks or iterations in an agile project.

By themselves, small projects don’t tell the value of IT. Agile services do.

Reason 3: Virtualization and clouding

The largest classical IT projects are implementations. Virtualization and especially clouding make it easier to create new things, sometimes almost erasing implementation projects.

Taking away implementation focus shifts attention to maximizing value of existing investments. Again, emphasizing agile services at the cost of classical projects.

Reason 4: Agile is where it’s at

Classical projects use waterfall, a prescriptive method from the manufacturing and construction industries. It’s from a time when the pace was steady, change was resisted, and top down was how it happened.

Relevant IT is the opposite: fast-paced, adaptive, and responsive. That’s why agile project management is natural for IT: it encourages adaption, continual reassessment, early problem discovery, and faster completion.

I’m not the only one seeing this. A proxy is Atlassian JIRA versus Microsoft Project Server. JIRA is for agile, whereas Project Server is for waterfall. Look at their Google search trends (source):

But this isn’t just about improving how projects are done. Agile does something that waterfall can’t: manage services.

Paraphrasing Men In Black II, “Waterfall projects: old and busted. Agile services: new hotness.”

Do classical projects belong in IT?

To be clear, classical projects still have a place in relevant IT. Really complex projects aren’t entirely going away, and some may need waterfall. Same goes for projects with well-understood paths and vanilla outcomes.

However, “well-understood” and “vanilla” are starting to be outsourced, such as email, web systems, ERP systems, and more. If not outsourced, they may be heartbeat functions, increasingly undifferentiated from plant operations. Or their business value is not intrinsic; the value is in what others—users, innovators, developers—can wring from them.

Agile services are the future of IT. It’s how we work, it’s how we provide business value, and it’s how we communicate what we do.

Image Credit: Project Management Lifecycle By Ivan Walsh on flickr

Done Never Is

Never By Olivier H on flickrLast week, David Aponovich from ISITE Design wrote a nice piece titled Avoiding the CMS Death Spiral on ISITE’s CMS Myth blog.

If you don’t know who ISITE Design is, you should…especially if you are in the digital marketing space. Those guys are top notch. I tried to hire them many times when I was working at the Boy Scouts but could never get the projects funded (might just be why I’m not there anymore).

Note: I tend to use “CMS” to mean “Web CMS” or “WCMS” – in this article these terms/acronyms are interchangeable to match what David originally used it in his post.

In Avoiding the CMS Death Spiral, David writes a nice piece that anyone looking at choosing a Content Management System should read.  In the article, David offers up a few pieces of advice, with one being:

Realize too that if you invest in a CMS, you’re now in the software business – whether you like it or not. A CMS project is never “done”. Staff accordingly for post-launch maintenance and support, or be prepared to pay an agency to maintain the platform for you (to one degree or another).

A CMS project takes on a life of its own, much like any other software project. That said, most organizations undertaking a Content Management System project fail to understand that real underlying issues that they will face during and after the project. Most people think a CMS project is as simple as selecting, paying for and implementing a CMS….but it isn’t.

A CMS project is everlasting.  There will always be ‘something else’ to do.  There will always be a new feature or some functionality that will be needed for some new web feature or function.

Done never shows up on a CMS project.  Done never is.

Of course…there are times of ‘done’ according to a project plan.  The goal of a project can be reached.  There is a point when a CMS is ‘implemented’. But…there will always be changes  and there will always be new items to add.

That’s what organizations need to understand. Many think a Content Management System is something you buy and install and use.  But, I’ve never found that to be the case.  There’s always something more to be done.

So…if you are currently looking at implementing a Web Content Management System, think long and hard about how you are staffed today and how you will be staffed in the future.  Don’t make the mistake a former client made in thinking that after the purchase and implementation of a CMS, he could reduce headcount. In fact – he needed to increase headcount or at least move headcount around to ensure proper staffing.  That particular project was never staffed properly for the long term from the IT group’s side.

I’ll leave you with part of my comment on David’s post. I wrote  (I noticed a typo in my original comment – I’ve left it here for completeness – but should be buy):

One of the biggest mistakes I’ve seen with CMS projects is the failure to staff. Most clients but [sic] a CMS platform, pay a vendor to implement it and then expect ‘done’ to arrive one day.

That day never shows up because there are always constant changes coming. Always new features and functionality for CMS driven websites. Done never arrives so clients always feel like they are spending way too much to ‘implement’ their CMS…when in reality they are just seeing the reality of the software business. Done never is.

Image Credit: Never By Olivier H on flickr

Oh boy! Another Project Management Certification…

1965 QANTAS Certificate By Serendigity on flickrI just saw an announcement that the Project Management Institute has a new Project Management Certification for Agile that they are piloting now (hat tip to PM Bistro).

According to the description on PMI’s webpage about their new Agile certification, the new certificate will:

validate a practitioner’s ability to understand Agile principles and concepts. The practitioner can then select “Agile” from their “toolbox” of project management approaches based on the needs and demands of a specific project.

Will I go after this agile cert? I doubt it.  I’m not doing much in realm of formal project management these days. Plus…I’m not a big believer in certificates, even though I earned my PMP in 2006.

I’m not focused on pure project management in my consulting so it may not be worth the effort…but I’m thinking it might be interesting to see what topics the PMI feels are important in an agile project and how I can ‘select’ Agile from my PM toolbox when needed.

That said, don’t let me discourage you from going after it…jump over to the PMI Agile Certification page to learn how you can be a part of the pilot.

Image Credit: 1965 QANTAS Certificate By Serendigity on flickr

If you'd like to receive updates when new posts are published, signup for my mailing list. I won't sell or share your email.