Guest post by Mike Clayton

Why Every Project Manager needs to Understand Risk

Project management is a discipline born from necessity.  If projects were not so challenging, we wouldn’t need a separate toolkit and processes.  But we do need them, because when we try to create change under constraints like schedule, performance and budget, we face the unknown.

Your response as a project manager is to define and plan your project with care, gathering all available data and then applying your experience, expertise and reasoning to generate a plan.

Planning Fallacy

Daniel Kahneman and Amos Tversky described “planning fallacy” as the consistent belief that you can deliver to a schedule – even when you have a track record of over-runs.  Believing your plan is an error almost as serious as failing to make one in the first place.

“Plans are worthless, but planning is everything”
President Eisenhower

Shift happens! Things go wrong.  The universe is no respecter of your plans.

Risk Management

So a second discipline – deeply intertwined with project management – is born of the same necessity: Risk Management.  A risk can be defined as:

“uncertainty that can affect outcomes”

Notice how this definition contains the two principal components of risk: uncertainty, which is measured by likelihood, and impact, which can be measured in many ways: financial, schedule, reputational, or the level of disruption to your project, for example.  Uncertainty arises for many reasons.  Here are seven of the most common:

1. Projects are one-off endeavours, creating new products, services, assets or processes.  There is no specific history or experience to call upon when you are planning.
2. Planning assumptions can be flawed due to lack of information or data, or incorrect information or data, or faulty interpretation of the information or data you have.
3. You may miss something important in your planning, which you either failed to identify, identified but missed the significance, or could never reasonably have known it.
4. Someone intervenes in an unexpected manner – unexpected because either your analysis of your stakeholders missed what should have been predictable, or because sometimes people act in an unpredictable manner.
5. A genuinely unexpected – possibly even unforeseeable – event occurs.  If it was really unforeseeable, it is often referred to as a “black swan” event.
6. A predictable event occurs, but its predictability extends to insufficient precision, rendering planning impossible.  Extreme weather and natural events are in this category: we know earthquakes happen in certain places, but cannot yet anticipate precisely where and when, and to what extent.
7. Plain old human error – someone makes a mistake.

For all of these reasons, Project Management students need to make a careful study of risk management, and learn to feel comfortable with uncertainty.  You need to be able to identify, analyse and plan for risk.

This is why I wrote “Risk Happens! Managing Risk and Avoiding Failure in Business Projects”.  It is written with new and less experienced project managers in mind, but I believe that there is plenty of material that experienced professionals will find useful and thought-provoking.  You can find out more at http://riskhappens.co.uk.

Win a Copy of Risk Happens!

My particular focus in training project managers has always been on practical tools and techniques.  I have carried this attitude into Risk Happens!  I am interested in what you think are the best – and most innovative – risk management tools and techniques.  Contribute your ideas at the end of the post and Josh and I will award the best response with a complimentary copy of Risk Happens!

You have until October 31, 2011 to win so leave a comment now!

Original link: Risk Happens

Related posts:

1. Risk Happens! Winner

Guest post by Travis Anderson

Earn PDUs while learning how Oracle Primavera is adamant about riding the world of project failure. Get started by visiting the registration screen at Oracle Primavera Enterprise PPM Virtual Summit. http://vshow.on24.com/vshow/primavera2010/#home

Once you get your login information, go to the Auditorium and watch Joel Koppelman, Sr. VP & GM of Oracle Primavera Global BU, as he delivers an informative key note presentation called Enterprise Project Portfolio Management: Helping You Manage Change in a World of Constant Change. Joel indicates that projects create change, result from change, and require change. Project Managers need to be ready to handle change by being tolerant and equipped to respond in a dynamic and collaborative fashion. The processes and tools of yester year are simply no longer effective.

Also visit the Resource Center, Exhibit Hall, and Networking Lounge to read white papers, listen to podcasts, and learn valuable insights on industry trends.

I hope you enjoy this virtual summit. Please share your perspectives by leaving a comment.

Original link: Oracle Primavera Enterprise PPM Virtual Summit

No related posts.

Having managed small/simple and large/complex projects, risk management is something that I know I have neglected on the small/simple ones in the past, but the need for it becomes apparent on the large/complex ones.

There was a discussion recently Inside pmStudent e-Learning about this.

I’ll share my thoughts, and I’d like to hear yours.

Scaling it Down

photo by Soggydan Dan Bennett via Flickr

A basic principle for me on small projects has been scaling down the important project management processes to suit the environment, not eliminating the need for the process at all.  I didn’t always feel this way, but after managing larger projects my perspective changed.  I now see the value in thinking about even the smallest projects in a structured way.

Sometimes distinct activities become merged on smaller projects, but I have come to the conclusion that this isn’t optimal either.  I find there is a clarity of purpose and thought that comes from respecting the boundaries between discrete project management processes; a focus that yields better results and maintains the integrity of the process.

Intuition

The smaller and more simple a project, the easier it is to intuitively have a grasp on the risks involved.  If your project is 2 weeks in duration, you are going to be thinking about risks while planning the project whether you want to or not.  And because of the short time frame, you’ll probably be pretty good at it if you know anything about the domain and your team has done projects like this before.

The longer a project stretches out, and the more moving parts get involved, the less validity our “gut feel” has in identifying and assessing risks.  That is why on a longer term project you want to do continuous risk management, making sure to identify and assess risks along the life span of the project.  If a project is only a month long however, you may only do this activity once or twice and it’s not going to be a 2-hour discussion for the team.  It should more likely be a 5 minute conversation.

Steps for Risk Management on Small Projects

1. Ask the question “What worries you about this project or your piece of the project / what opportunities do you see” to team members….individually or in a group setting
2. For a short project, pick no more than 3-5 that seem likely or would have a big impact
3. Formulate these in terms of “Given [situation] there is a possibility of [event] resulting in [impact].
4. Prioritize these risks, figure out who the owner is, and figure out 1) how to mitigate if possible and 2) what you might do if it happened.
5. Follow up as necessary (at least weekly in your one-on-ones) with the risk owner to hold them accountable for their planned actions.
6. Report status of the continuous risk management process in your project status reviews.

On a short term project, I wouldn’t spend too much time on risk management.  It’s important, but should be scaled down.  This could be reviewed monthly or so if the project is long enough for that.  Plus on a short project I would consider the PM as the “risk board” and perhaps the technical lead and sponsor too.  It’s all a matter of scale and your particular project’s environment.

What do you think?  How do you manage risk effectively on small projects?

Original link: Risk Management on Small Projects

Related posts:

1. Small Projects: How To Rock Them
2. Risk Happens! Winner
3. Risk Happens

Psych!

Unfortunately, there is no ONE best type of contract because the risk the vendor and customer share is determined by the contract type.  The best thing you can do is understand who bares the risks or benefits of each.  Being I don’t know if you are a vendor, a customer, or a project manager, this objective description of each contract type should help shed some light on the subject.

There are three categories of contracts: Fixed-Price, Cost-Reimbursable, and Time and Material (T&M).

Fixed-Price is a contract category involving setting a fixed total price for a defined scope of work to be provided.  Fixed-price may also incorporate financial incentives for achieving or exceeding selected project objectives, such as schedule delivery dates, cost and technical performance, or anything that can be quantified and subsequently measured.   Vendors under fixed-price contracts are legally obligated to complete these contracts, with possible financial damages if they do not.  Under the fixed-price arrangement, vendors must precisely specify the products or services being offered.  Changes in scope can be accommodated, but generally at an increase in contact price.  The three common types of fixed-price contracts are Firm Fixed Price Contracts (FFP), Fixed Price Incentive Fee Contracts (FPIF), and Fixed Price with Economic Price Adjustment Contracts (FP-EPA). [risk is on the vendor]

Cost-reimbursable is a contract category involving payments (cost reimbursements) to the vendor for all legitimate actual costs incurred for completed work, plus a fee representing vendor profit.  Cost-reimbursable contracts may also include financial incentive clauses whenever the seller exceeds, or falls below, defined objectives such as costs, schedule, or technical performance targets.  Why would anyone ever use this contract vehicle?  Assume the customer doesn’t know what they want.  By absolving the vendor of risk, they may actually get something delivered.  Three of the more common types of cost-reimbursable contracts in use are Cost Plus Fixed Fee (CPFF), Cost Plus Incentive Fee (CPIF), and Cost Plus Award Fee (CPAF). [risk is on the customer]

Time and Materials (T&M) is a hybrid type of contractual arrangement that contains aspects of both fixed-price and cost-reimbursable contracts.  They are often used for staff changes, acquisition of experts, and any outside support when a precise statement of work cannot be quickly prescribed. [blended risk]

So there you have it, the three categories of contracts.  Some people make it their job to know these inside and out.  I wouldn’t recommend getting too far into the weeds unless this topic really interests you.  If there is one takeaway from this post, I would say remember which party is at risk and which party will benefit. It’s not fun being on the short end of that stick.

Image courtesy of: Shutterstock

Original link: Contract type: Here’s the best one…

No related posts.

Josh asked me to write about some of the challenges and obstacles that we face in our environment. In order to do that I should explain a little about that environment.

Over the past 36 months we have transformed ourselves from being a software development team in crisis to a strong team that is focused on delivering on it’s commitments. In 2005 we determined that the current approach to writing software wasn’t working. We were the poster child for “garage-band” style of software development, having inherited 1 million+ lines of classic (poorly written) ASP code [aka 1MLOC - I'll let you guess what the "C" stands for], and having very little recognition from corporate management that anything was wrong with the way things had been done.

When I came to lead the group in early 2007, I had put in countless hours trying to lead the business toward  implementing a PMO. While we actively maintain the 1MLOC, we have been working closely with a third party partner to replace the application. In parallel, we have a number of other small LOB applications that we have written using accepted best practices and design patterns. Needless to say, this means that there is a significant amount of churn and chaos when it comes to determining what’s going to be worked on and by whom. Enter SCRUM.

In early 2008 I approached the IT leadership and explained that an iterative and incremental approach to developing software was far superior, in our environment, to the code-and-fix triage approach to project management that had been promoted in the past and that this would be well suited to supporting the behemoth 1MLOC application while still allowing us to be agile enough to respond to the business’ needs in a timely manner. They bit.

So, what is our environment like, how do we handle some of the obvious gotchas, and what are the advantages/disadvantages to how we do business? Well first, I’ll say that this is what works for us, in our environment. I can’t speak to your situation, although if I can help, please drop me a line. Well, we currently have over a dozen product backlogs that are somewhere in the development/grooming workflow. We have roughly half that many Product Owners [none have been "officially trained", all have gone or are pending admission to the school of hard knocks] and the expectations of what it means to be a Product Owner are communicated loudly and often.

Some gravitate toward the role, others are a little thicker and require some additional coercion encouragement.

Regardless, we do the classic planning poker estimating that I described here and then, based upon our standing team velocity we let the Product Owner how much of the backlog we will be able to knock out during the next sprint. At that point, for any one of a couple reasons [the Product Owner needs more functionality than can be delivered in a single sprint/the team has some groundwork to lay in one sprint in order to deliver the key business deliverable in a second or third sprint/etc.], the team may decide that they need to deliver the next increment of work over several concurrent sprints.

In this case, the backlog of backlogs is queried and the next product owner is queried for budget and schedule requirements [we may even look at the current state of that PO's product backlog] and a reasonable determination is made [by my boss and the IT Steering Committee] whether it’s acceptable to the business for the subsequent development to:

• be delayed
• be preempted or
• be split [deliver Sprint 1-Product A, then Sprint 1-Product B, then Sprint 2-Product B]

From the team’s point of view, this decision is somewhat irrelevant as long as the sprint backlog is ready to be loaded into the SCRUM Dashboard [which is integrated into the Microsoft Team Foundation Server - our source control and overall ALM solution]. Once the tasks are entered into the Scrum Dashboard (which is a lot like SCRUMY except that it’s tied to coding tasks, time tracking, check-ins, build events, etc.) the team tracks their own progress daily which automatically updates the Sprint Burndown, Product Burndown, BurnUp, and a hundred other reports that are hosted in the Microsoft SQL Server Reporting Services site that comes out of the box.

The daily stand-up meetings are usually run by the team, as the ScrumMaster I sit in on them regularly; however, my prime directive is really just to make sure that they’re happening and that there are no discovered impediments that are/have not been communicated to me that come up as an outcome of the meetings. We have a weekly code review meeting for the whole team to see where we are, and we usually use this meeting to demonstrate the application state to the product owner. As part of our development team, we expect for the business to provide testing and QA resources so that we can be sure that the feedback loops are as short as possible.

So, you ask, what are the gotchas in this environment? That’s an easy list to start, but a very difficult one to call complete…so here’s my “easy list”…the hard ones will quickly become evident in your environment.

1. Training Product Owners – especially in a “Command and Control” environment, it’s difficult to convey the concept and importance of servant leadership. Similarly, it’s hard to get “busy” business folks to commit their time to things that are commonly deemed to be unproductive
2. Training Product Owners- getting them to understand the concepts of story points, estimating, life without requirements documentation and use cases, life without earned value, and ultimately the fact that the ROI and the “fit for purpose” functionality is their #1 responsibility
3. Death by meeting – herding all of those backlogs, training all of those Product Owners, daily stand-ups, retrospectives, code reviews, “demo days”, Planning Meetings, not to mention the other “normal” meetings that one usually gets pulled into [weekly staff meetings, employee meetings, annual reviews, etc, etc, etc]…leads to about 80% of your time being tied up in one meeting or another…it really is hard to do a lot more than manage your schedule and check your business card to make sure it matches your driver’s license
4. Leadership & Management – if your management doesn’t back you up and get out of your way, you will be tripping over one another. They MUST support you and then get out of your way. The proof is in the pudding…deliver a few times and they’ll get it.
5. Tools & Co-location – We are one team, in one location. We tried the distributed team thing for a while and, to be honest, the requirements for the team to be available to meet to review something on very short notice makes co-location extremely difficult. Likewise, much like there isn’t really a “SCRUMBOK” because SCRUM is prescriptive as far as Engineering Practices, there are hundreds [if not thousands] of electronic tools for the team to use…a definite gotcha is the temptation to jump into the midst of the tools arena before you really understand the process that needs to be supported by a tool. We found TFS and SCRUM Dashboard….it’s what works for us….that means squat to you….make your process work analog, and then digitize it….I can’t say this any more clearly…learn to love the whiteboard, post-it, and index cards…worry about the business now and worry about the rest later [it might actually take care of itself].

OK. So there’s a start. That list could go on for a while. So, to wrap up, you’re probably interested in understanding what are some of the pros and cons?

• PRO: We deliver working software, and we do it pretty frequently. This means that our Product Owners are pretty happy. Happy PO = Happy Business = Job Stability = Happy Employees = Better Software
• PRO: We get to deliver at a sustainable pace and we LOVE what we do. I hope that the death marches of 2006 are gone for good. We value people over process. Happy Employees = Better Software = More Projects = Job Stability = Happy Employees
• PRO: We get to be honest and transparent. With the PO on the team, there are no secrets about something taking longer than planned, or something not working as expected. The PO and the team get to figure out how to work thorough these challenges rather than worrying about doing damage control.
• CON: Estimating is really difficult, especially at first. Then, to make matters worse, budgeting is even more vague. For some organizations, this may be too much to overcome. I hate budgeting season…to ask me how much something is going to cost is to ask me for a complete and estimated product backlog, which isn’t terribly different than a preliminary project plan and schedule. Ugh. Budgeting Sucks.
• CON: If you are a “Command and Control”, “Do first, ask questions later”, “take the bull by the horns” kind of manager, you will really struggle with Agile. The CORE of Agile is in empowering the team, transferring that control to them, and settling into a support role….for a lot of folks, this will be impossible.

Original link: Chaos and SCRUM

Related posts:

1. Scrum Tune-up
2. Scrum is a World View

We had a LOT of snow over the Christmas holiday.  A LOT.

NOT the vehicle I drove around in!

Having barely made it out to my in-laws for my birthday celebration (and even more Christmas presents for my 3 spoiled sons) we stayed the night because it was getting worse and the snow plows weren’t going to be out until the next day in that area.

I wouldn’t have driven back on Saturday around noon but our dog Snickers needed to be cared for.  So I left the family safe and warm inside and I ventured out.

AND THEN IT HAPPENED.

No, I didn’t get stuck or slide into the ditch.  Fooled you!

I started thinking about the heightened level of risk all around me.  Looking at it from a project manager’s eyes who has always taken risk management seriously, I started to notice some things that were important to me in this risky situation.

Data

• Before I left in the first place, I checked my city’s website to check the status of our fleet of snow plows.  It enabled me to plan a route that was longer, but less risky.
• I also checked Twitter.  Unfortunately the references to “my street” were not helpful.  Sometimes data is unreliable for use in risk management decisions.

Equipment and Materials

In an area that gets a lot of snow, you have to be prepared.  Some years we don’t get a big blizzard at all.  Other years it can get pretty bad.

How do we mitigate this risk using equipment and materials?

• We own 4×4 trucks, snow blowers, shovels, and of course warm clothes.
• We own small cars too, but we don’t drive them when it’s like this out!
• We pack winter survival gear in our vehicles so that if we get stuck somewhere we don’t freeze to death.
• We throw shovels and chains when it’s bad just in case we get stuck or need to help someone else who is stuck in the snow.
• We make sure our cell phones are fully charged and the gas tank is full.

Contingency

As I was driving home, I made sure to leave a decent amount of space between me and the car to the front and side of me.  In case the vehicle on my side started to slide, I wanted to have plenty of room to react.  If possible I would speed up or slow down slightly so we were staggered and not directly across from each other.

The space in front of me was for 2 reasons.

• I wanted to have plenty of room so that if I started sliding when trying to stop, I would have extra room to gain control and not crash into the vehicle in front of me.
• I wanted plenty of room so that if a vehicle coming up behind me started to slide I could gently move forward into the buffer and prevent a collision from behind.

Attention & Feedback

All that buffer wouldn’t have done much for me if I wasn’t vigilant.  I had to be sure the channels of information flow were open so I knew immediately if something bad was going down, what it was, and in many cases respond with an action I had already pre-planned.

• All my windows and mirrors were well cleared of ice and snow so I could see what was going on around me.
• I kept the defroster on to prevent the wind shield and side windows from fogging up.
• When coming to a stop, I kept a constant eye out for cars coming up behind me so if they started sliding I could use that buffer in front of me.
• I paid attention to the cars beside me too so I could react if they started sliding or decided at the last minute to change lanes while they had poor visibility due to being too lazy to clear their windows properly (yeah, that one happened)

Method of Operations

Finally I drove the truck in such a way to mitigate my risk of being on the road at such a lousy time.

• I drove slow and deliberately.
• When stopping it was gradual so as to not start sliding.
• Looking ahead more than usual to see upcoming obstacles, etc.
• On 2-lane roads I stayed in the left lane.  This got me out of the way of crazy people who were turning on to the main street in little golf cart-like cars by gunning it through a 3-foot pile of snow the plows left. (yeah, that one happened too.  Several times.  Some got stuck, some made it through and careened out into the middle turning lane.)
• I used 4×4 low gear on unplowed residential streets and 4×4 high gear on the plowed streets.

There’s probably more that I just can’t think of right now.  (How about “not living in South Dakota” as a mitigation plan!)

So how does this relate to risk management on your projects?  How do you use data, equipment and materials, contingency, attention & feedback, and your method of operations to perform what I always like to call CONTINUOUS risk management?

Leave your comment below!

Original link: Risk Management in the Snow

Related posts:

1. Risk Happens! Winner
2. Risk Happens