Evaluating Risk

Loren S. DeLaOsa, CIPT, PMP Risk

What is risk? Project risk is defined by the Project Management Institute as, “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” Risks to a project are maintained in a risk register, with a trigger and response mechanism. Risk management tools allow uncertainty to be addressed by identifying and generating metrics, parameterizing, prioritizing, and developing responses, and tracking risk. These activities may be difficult to track without project management tools and techniques, documentation, and information systems.

The risk process is a multistep process consisting of identifying, understanding, mitigating, assigning a trigger event, and having a risk response plan. In a project, identified risks are put in a risk register, understood, mitigated, assigned a trigger event and a risk response plan.

While this article discusses negative risks and how to reduce their impact, remember that there are positive risks as well. There’s a risk that are positive, like getting a grant. It’s uncertain, but you do what you can to enhance it by writing a good proposal and sending it in on time. A speaking engagement might lead to a new opportunity. Enhance that with good preparation, a polished presentation, and being ready to take advantage of anything that arises. You want to mitigate negative risks, but enhance positive risks.

Let’s step through this in the context of owning a house. There are many identified negative risks to a house, theft, earthquake, flood, fire, etc. We will use a single item in our risk plan to go through the various items:

  1. Identification: We could have a house fire.
  2. Understanding: A house fire could be large or small. It can have a variety of causes, including unintentional or intentional. It could start from poor maintenance or faulty construction. (This is qualifying and quantifying risk, determining impact and probability).
  3. Mitigation: We’re pretty sure we don’t want a house fire. We take steps to reduce the impact of a fire. We keep fire extinguishers in the kitchen and garage. We keep important documents and mementos in a fire-resistant safe. We have a system that automatically calls the fire department. We buy house insurance. We have a fire escape plan. We also take steps to reduce the probability of a fire. We follow fire department recommendations on creating a “fire-safe” home, for example not storing oily rags. We make sure wiring is good and don’t overload outlets. We are careful when cooking over open flame on our gas range, never wearing lose clothing or overheating oils. We decide we love our propane grill, so we keep that, but we move it further away from the house.
  4. Trigger event: FIRE! (The risk is realized in project-management parlance.)
  5. Risk response plan: If the fire is small, use an extinguisher. If the fire is large, follow fire escape plan the house. The smoke alarm automatically notifies the fire department whether we are home or not, regardless of the size of fire. After the event, damaged is assessed and we call the insurance company and repair experts.

Understanding a risk is the process of qualifying and quantifying. If it is expensive to fix, does that change our understanding? No, it doesn’t – but it might change how much we choose to mitigate or what our risk response plan looks like. For example, you identify the knees on your jeans are thin and could rip. By looking closer, you understand it’s likely. You mitigate by choosing to do nothing and accept the risk, since patching looks silly and is an expensive use of time. Trigger event, the jeans rip. Risk response, you put on a different pair from the closet and get rid of the ten-year-old jeans.

Realize that some requirements can change greatly and without warning – this can dramatically change a risk profile in a very short amount of time. If a risk area has a particularly large impact, mitigation should be considered. Whether that mitigation is considered is dependent on the cost of mitigation vs. the cost of the realized risk.

The largest task is understanding risk, qualifying and quantifying it. Generally, risk is viewed across two dimensions – impact and probability. The impact, “does it matter”, of the risk event is viewed as very low, low, medium, high, or very high. The probability, “is it likely” of occurrence is viewed the same way. Impact multiplied by probability results in a simplified risk score. Depending on the risk score, different responses can be modeled. Below is the scoring system from the Project Management Body of Knowledge 5th Edition (PMBOK v5) in two tables:

Multiplying impact and probability results in a risk score, categorized as high, medium or low. This is showing in Table 3, below. Based on the risk score, determination can be made on how to address the risk.

A quick demonstration of an assessment. A meteorite could land on my house. What is the impact? Well, most meteorites are fairly small, under 25 milligrams. Larger are very rare, but possible. Let’s call that low impact. What’s the probability? The earth is fairly large, most of it water. The chances of a meteorite hitting my house instead of anyplace else is very low. Low Impact (.1) x Very Low Probability (.1) = Low Risk (.01).

With a language to describe risk, it is possible to apply it to other contexts. Breakdowns of impact (how broad and/or deep is the effect) and probably (how often and how likely). A papercut has low impact, but 99% likelihood of getting 1000 per second would be high risk. This kind of analysis determines “severity” of a bug in software, a “crash-on-every boot in every scenario” being both high impact and high probability, making it a high risk to product success.

In classic project management, risks are identified, qualified/quantified, mitigated (ignore a risk, insure it away, work to min/max probability, work to min/max impact – there are positive risks as well as negative risks), assigned a trigger event (what causes a risk response) and a planned risk response. This material becomes part of a project risk register, the “if this, then that” plan.

This rubric can provide a better way of discussing risk. Risk process provides a predictable, data driven way to speak about risk, and why mitigation or risk response is important/not-important. If a mitigation or a risk response is a lot of work, disruptive, or expensive, that factors into that part of the plan – not the discussion of the risk itself.

Work-Back Schedules, or Magic Has A Price

Loren S. DeLaOsa, CIPT, PMP Time
“All magic comes with a price, dearie.” Rumplestiltskin

In ABC’s Once Upon a Time, Robert Carlyle’s character regularly reminds other characters that “magic has a price”, one action coming at the cost of another. I was thinking of this as someone asked for a work-back schedule, and had nearly titled this article with a Star Wars quote instead: “It’s a trap!”

A work-back schedule, before a project is even planned, is meant as a requirement or constraint. “After this date, the project has diminished or no utility, therefore this is a constraint.” Constraints are planned for. If you must have a thing by a certain date, other things like scope and cost will change. All magic has a price.

Work-backs, however, are often used as project traps. Consider the scenario: You have a fixed number of resources, not flexible in the short term (say three months). In brainstorming, the team has dreamed up some scope, which is to say aspirational deliverables that provide utility. Now comes the trap. Leadership looks at the scope and says, “Hey, looks great – I have to have this in three months, give me a work-back schedule to deliver all that scope.”

See what happened there? A project constraint was introduced, but hasn’t yet been accounted for. Instead, an expectation was created. The job of the project manager is to manage that expectation. “Oh, good to know that requirement – let me talk with the team and work out what can be delivered with quality in that time frame, and let’s review after.” While a wise leader will understand, some will reply with, “Oh, just give me a back-of-the-envelope estimate, I won’t hold you to it.” Don’t give into the temptation of telling someone what they want to hear because it’s easiest. The price of doing this is project failure, because it is nearly inevitable that stakeholder expectations will not be met. “I won’t hold you to it” is just the bait for the trap. Once the jaws close, you’ll be held to that estimate. The only way to successfully navigate this is to use the situation as an opportunity to gather stakeholder requirements.

It seldom works to say, “No, but…”, since people stop listening when they hear “No.” Instead, “Yes, and…” tends to work better. People have problems, projects exist to resolve them. Project managers exist to orchestrate solving problems. To solve a problem, it’s important to fully understand it. Rather than complying to an early schedule demand, a bit of magician’s misdirection will help get things on the right path, “But of course! Of the deliverables you see here, can you help me understand which are the most important to you?” Answering questions with questions also works. “When can I have this?” can be answered with “which of these is highest priority?” There’s also the truth, “Any schedule I propose at this point would not be based on data, and therefore not realistic – help me better understand so we can get you the results you want.” Understanding requirements and constraints is essential to designing the right solution. Knowing how the stakeholder processes information will let you use the correct approach to gather requirements and understand constraints.

Once upon a time, you may have faced this situation – but if you didn’t before, now you understand the price of magic.

The Business of Privacy

Loren S. DeLaOsa, CIPT, PMP Practice

University economics classes provided me with some great terms, like “negative externalities”. A negative externality is a cost suffered by a third party to a transaction. Group A is producing widgets for Group B, but dumps expensive-to-clean up waste into a river of drinking water that Group C uses. Group A produces for a lesser expense, Group B gets the benefit of that production, but Group C bears the cost. That’s a negative externality.

There’s two basic ways we, as a society, deal with those issues. We can accept them, or we can seek government intervention. The basics of a business education suggests that government exists to provide a framework and level playing field for market participants. Government is the only entity with coercive powers. In the United States, this power is expressed through both legislation and the court system. Either can impose penalties for failure to live up to standards. Regulation isn’t “bad” or “good”, it just changes incentives for different parties, hopefully resulting in fairer outcomes for all stakeholders.

It is understandable how Equifax, as a company, had loose controls. There is a constant drive to reduce IT costs, even for companies in the business of information. Do more with less can strip IT departments of both personnel and knowledge in a race to the bottom; do enough, and just enough, to conduct business and no more. In all, Equifax had few incentives to be responsible in a data breach that affected nearly every adult citizen of the United States. The current environment has been favorable to deregulation of business. Third parties, which includes every person who had their personal data exposed, have no power and were therefore not considered when making company choices. While this is understandable, it is not acceptable.

My interest in privacy and security is rooted in my interest in ethics, and I want to inspire you to share that interest. Business leaders must be responsible and accountable for the actions of the organizations they lead, and we must give our people and projects an ethical framework to do business in. It is essential that we be good corporate citizens, and live up to the trust that society has placed in us.

Celebrate Success

Loren S. DeLaOsa, CIPT, PMP Cantrips

I mentioned in an earlier post that it was important to celebrate success. It provides closure for a project, and can be a bonding experience for a team that might disperse to other projects.

Ship gifts are a traditional thing. My brother got this cool leather jacket from the Windows division years ago which he still wears. Most ship gifts, though, aren’t quite that nifty. Mind you, I’ve kept them all just the same, much to Hermione’s annoyance.


Now, I never served, but I do know what a challenge coin is. After having gone through three v1 cloud product releases with this same team, this is actually my favorite ship gift. It was a lot of hard work, and a good way to end one journey and start another. You were in Azure?  Heck, yeah, I was in Azure and look at what we did!

Third Time’s a Charm

Loren S. DeLaOsa, CIPT, PMP Cantrips, HR

Femme Hai Le Grand Requin Blanc

Thrice repeated, once fulfilled. Or, at least, that’s how I remember that going. In line with my goals to talk about the industry and environment, I feel compelled to talk about things like this. I’ve seen many articles about harassment online, bleeding over into real life and the workplace (tough read, language). It’s been going on for some time. It isn’t unique. It’s still going on. It’s not just in technology. The crisis of inclusion is everywhere, in no small part to industry and individual attitude. And this is my third post on the topic.

Industry leaders agree that inclusiveness is important, but it is essential that this message be carried to every level of every organization. We all need to be part of the solution. Once again, to quote Lieutenant General David Morrison, retired, “By now I assume you know my attitude to this type of conduct” and “the standard you walk past is the standard you accept.” Don’t accept bullying or harassment. Demand a higher standard, and accept nothing less.

Manage your Mythology

Loren S. DeLaOsa, CIPT, PMP Practice

It’s no secret that Bioware’s 2003 Knights of the Old Republic renewed my interest in Star Wars. My office contains a tasteful collection of photos and memorabilia. It surprises coworkers who visit for the first time, breaking the ice, and often starts a conversation. People will smile, and tell me a story. I’ve learned a lot of things that way. One coworker reflected on how he loved Star Wars as a child, and was thrilled to share it with his own children who likewise loved it. Another coworker’s daughter has a ForceFX lightsaber – I know, since her dad liked mine and bought a boxed one from my collection as a present. A young coworker from China was a fan of Star Wars, and is now my friend, because of our mutual journey “to be Jedi, not dirt-farmers on Tatooine.” My office serves a purpose, putting people at ease and giving us something common to relate to.

In the days when my company was occasionally referred to as “the evil Empire”, everyone recognized my tiny super-charged sports car:

That was both good and bad. Image has both connotations and complexity. The license plate was a good display of humor and an interesting talking point (“You’re Darth Loren? Wow, I was expecting someone taller!”), but also associated with, literally, the Most Awful Guy in the Galaxy. Should everyone’s first impression be that they’re going to be subject to “aggressive negotiations”? No, better to be known a Jedi Knight who was revered for restraint, wisdom and dedication. That’s the sort of person people want to work with. It’s not just what you’ve done, it’s what people think you’ve done.

That transformation took time. The company changed, I changed with it. I learned and grew. I sold that car, but it took time for people to forget SITHLRD, and see THEJEDI instead. That’s why I titled this article “Manage your Mythology.” You need to be thinking of the image you put forth, and how your actions influence perception. It’s not just the story you tell, but the stories that are told about you.

Consider, do you always say what you’ll do, and then do what you said? Do you honor agreements you’ve made, even when it turns out they disadvantage you? Are you helpful, willing to go the extra mile to lend a hand or freely offer knowledge that might assist? Do you do simple things, like smile and say hello at the coffee station? Contrast that striding into a room in black armor, announcing that you are there to get things back on schedule! Yup, that makes a lasting impression; nope, it’s not the reputation you want to have.

So here are some tips and thoughts about managing your mythology:

As you tell your story to others, something I was told to consider was to the effect of, “will you get caught out and will anyone care?” By this, it’s meant you are welcome to tighten and brighten your story, but it should be true. Consider “my friend Sue and I got ice cream, and you can’t imagine what happened next!…” Well, Joe was there, too, but he’s not part of the story. Will anyone care? Probably not. Contrast that to Milli Vanilli controversy. That had to be pretty humiliating, but was entirely preventable. Never lay claim to things you didn’t do, and correct misconceptions quickly before they snowball.

ABCD – Always Be Continuously Discovering. There are so many interesting things in the world. Learn. Grow. Follow your passions. Pick up new skills. Share your knowledge. If you find something you’re interested in, learn about it. The more you are curious, the more you discover and the more interesting you are. Maybe you have an interest in construction. That can lead to new opportunities for you, and new stories about you. “Hey, yeah, I know Jeff – we volunteered together building houses for the homeless! Great guy!”

Recognize and thank people for their contributions. I would like to sincerely thank you for reading this article. I am passionate about project management and mentoring. I am thrilled that you are seeing these words. Thank you. I appreciate your support.

Networking is important. Aside from myths about LinkedIn and some ideas on how to use it, two things to consider. First, be interested in someone else’s story. You never know what interesting thing you might learn. For example, I’m a licensed bartender. Bet you didn’t see that one coming – and it’s true! 🙂 Second, just like interviewing, it’s never about what someone can do for you – it’s always about what you can do for them. Did you find out someone has teenager who plays guitar? Do you know the owner of Seattle’s greatest guitar store? Maybe there’s a connection here!

The internet never forgets. I searched myself and found a letter I’d written to PC Magazine when I was maybe fourteen years old. FOURTEEN. People have destroyed their careers over errant Twitter comments. Or doing questionable things during a conference. The world has changed. If you’d be embarrassed to have something on the front page of the New York Times, don’t do it and definitely don’t publish it. Always be on your best behavior, always be just and ethical. It’s important because you never know when something is being recorded for the world to see.

Be positive. Learn how.

Some people will call all this “managing your brand”. That’s legitimate, but a “brand” doesn’t resonate with people. A story will. Components of that story are your professional image. CBS has a good article on that. Here’s another from Forbes. And another two articles, one here and one here, on managing image. The image you project, the things that you do, become a “brand”, and that brand comes alive in the stories you and others will tell about you.

Neil Gaiman has spoken about the importance of stories. Once we are gone, stories are all that remain. Make sure that you not only tell good stories, but that good stories are told about you. Manage your mythology.

Harassment

Loren S. DeLaOsa, CIPT, PMP Cantrips, HR

I actively support a corporate culture of inclusiveness and respect, and have no tolerance for bullying or harassment in the workplace. Work, however, is only a portion of people’s lives. Technology is all around us, and the internet can be a source of  suffering. If you, or anyone you know, needs assistance, RAINN has resources to help. No one is alone.

Privacy and Projects

Loren S. DeLaOsa, CIPT, PMP Practice
“Scientia potentia est.” Thomas Hobbes, Leviathan

“Power tends to corrupt and absolute power corrupts absolutely.” Sir John Dalberg-Acton

Knowledge is power, power corrupts.

Economics classes point out that information is needed for rational decision making, and rational decisions result in the efficient allocation of resources. What happens, though, when one party has information that the other doesn’t? Suppose you bought a house that the owner knew had toxic mold problems but failed to disclose? The seller walked away with more money than would have been possible had information been disclosed, not only an inefficient solution, but one that most people would label unfair. No one would willingly pay more than something is worth to them. Knowledge is power.

The power of private and personal information has been used to impact lives all over the world. It isn’t just a potential. The United States Supreme Court nomination of Robert Bork was upended by his video rental history. Identity theft cost the US $15B in 2014 and 700,000 stolen tax returns in 2015. In World War II and elsewhere, information cost lives.

Privacy matters.

You, your projects, and your company must take privacy into account. This is an article on basic principles. There are also numerous articles to help convince a team that privacy matters. For example, this one on LinkedIn, this one from Santa Clara University, this one from The Atlantic, or this one on a blog. There are resources available from the International Association of Privacy Professionals. Privacy is an ethical obligation. Even if it wasn’t, consider the sanctions that can be levied by the European Union’s General Data Protection Regulation laws for failing to meet requirements.

Remember, information you don’t have, you can’t be forced to disclose or accidentally leak. Information you have, you also have an obligation to secure and protect. When you collect it, you must state for what purposes you will use it and then comply with that statement. Information belongs to the individual, and it’s their right to ask for it to be corrected or deleted. It’s really just that simple.

This article started with two quotes, and finishes with another:

“If you can’t be a good example, then you’ll just have to be a horrible warning.” Catherine Aird

 

Never Miss a Date!

Loren S. DeLaOsa, CIPT, PMP Practice

You can make every software development project successful.

Interested?

Ready?

Here’s the secret: Apply PMI’s project management knowledge areas.

It’s that simple.

I’ve been in software development since before high school, and have seen every type of success and failure imaginable. Maybe your project isn’t year-long, involving 200 people across many countries with a budget of a hundred million dollars. Maybe it’s five developers in a basement for a couple of months. I don’t know the particulars of your situation, so I couldn’t do the business analysis necessary to suggest one development methodology over another. Instead, I’m suggesting that the application of knowledge will make your projects better in general. If you understand these knowledge areas, and understand them well, you will understand what trade-offs you are making in your process and projects. That will enable you to better direct your projects to successful outcomes, regardless of the size of your project or development methodology you choose.

In order, the top ten reasons for failure, in order of importance:

  1. Communication Management – Three articles on communication so far. That wasn’t an accident. Projects, first and foremost, live or die by communication.
  2. Risk Management – The solution has been architected, coding has progressed, things are looking good, however the implementation can’t be stabilized. Review indicates a different architecture must be chosen. The schedule is blown, the budget is gone, the project fails. The qualification and quantification of uncertainty is what risk management is about. Every project I’ve seen that failed to “make its dates” had no risk management strategy. It’s not only identifying risks, it’s actively communicating and managing them in a timely manner. A good risk plan will save a project by stating what conditions it will trigger and how act appropriately to manage the impact. Think of it as carrying an extra set of batteries for when you take photos on vacation. Batteries die? No problem! You have another set. Yup, it cost a little money – but documenting your vacation experience is priceless.
  3. Time Management – The usual cycle is for managers to look for estimates, wring every bit of “buffer” out of estimates (the estimator’s attempt to manage uncertainty, which is to say risk), then create a ship date. Has this ever produced an on-time project? Not that I’ve seen. A schedule is a map of the project. It contains all activities (scope), resources to complete (cost), and when those resources need to do the work (time). Failure to create a realistic schedule, then failure to manage against it, cause project failures.
  4. Integration Management – This failure happens on two dimensions. The first is the organization’s leadership doesn’t believe that they need any project management, so either fails to have a project manager or fails to listen to an experienced project manager. The second version of this failure is assigning a project manager who doesn’t have the knowledge or skills to do the job. “You’re great at laying bricks, Bob – we’d like you to manage the construction of our next building.” Unfortunately, Bob is great at bricks, but doesn’t know anything about monitoring and controlling a project.
  5. Scope Management – As the project progresses on an agreed plan, things get added – hey, it should be a simple fix to allow users to change background colors, right? Sure! Scope is everything you’re going to do, and, inversely, everything you’re not going to do. Poor change control, along with an unwillingness to adjust either schedule or cost baselines, results in failed development projects. Every accepted change changes the whole project; have a change control process. Reject scope when appropriate, or accept and re-plan other aspects of the project.
  6. Stakeholder Management – The project was completed in record time, and is ready for implementation. The IT director is assigned the job of deployment and says, “Hey, wait – this won’t work. Half our users are only intermittently connected!” There are basic questions for the start of every project: Were all the stakeholders enumerated? Where their needs and requirements considered? What is the urgency of solution delivery? Failures in this area causes work products to be rejected. Scrum tries to control for this with a product owner who is the source of requirements, but also assumes the product owner has done the right business analysis and thoroughly understands all other stakeholders. If the product owner isn’t a business analyst, you’re probably doing it wrong.
  7. Cost Management – A project merrily moves along, assuming full dedication of all personnel. The reality is that developers are often assigned to many different projects. Managers often fail to account for that and consequently over-allocate developers. Part of that is failure to account for the productivity loss in context switching. Also, managers wrongly assume their project is top priority. Just because it is important to YOUR career doesn’t mean it’s important to someone else’s! Adding more developers doesn’t necessarily mean a project gets done quicker, even if those developers are more senior. As the number of people go up, more work is lost to the “friction” of working cooperatively.
  8. Quality Management – Yup, we wrote a lot of code. Too bad it doesn’t work in integration. Guess we should have planned for that. A quality acceptance plan is important to ensure a development project meets the goals that are set out for it. It can also be a check against gold-plating.
  9. Procurement Management – Okay, okay, stop me if you’ve heard this one: Manager throws out an RFQ, picks the lowest quote, and three months later gets something that doesn’t remotely resemble what was expected. There’s a whole process for managing procurement properly. Not every project has a procurement component, but if one does, it is essential to manage it properly.
  10. Human Resource Management – Each part of this list has started with a dreary failure. Instead, let’s talk about success. A couple years ago, Avengers was a popular movie. I held a “bug smash” (“bash” == “finding”, “smash” == “fixing/resolving”) for one of my teams. It was Hulk-themed, as in “HULK SMASH!” A twice daily report went out recapping the contest, morning and night, for a week. We gave out $50 gift cards along with Hulk-themed prizes for most bugs, most severe bugs, most code reviews completed and most helpful as nominated by peers. It was the most fun we’d had all summer and a good team building exercise. Be a source of motivation and inspiration, and celebrate success with your team.

There you have it – your spell book for success. Go study, then be successful.

Numerical Nonsense

Loren S. DeLaOsa, CIPT, PMP Cantrips
Figures often beguile me, particularly when I have the arranging of them myself; in which case the remark attributed to Disraeli would often apply with justice and force: “There are three kinds of lies: lies, damned lies and statistics.”
– Mark Twain’s Own Autobiography: The Chapters from the North American Review

It wasn’t actually Disraeli, but numbers are persuasive. If I said, 68.7% of statistics are deceptively presented, that sounds pretty authoritative, doesn’t it? It’s also completely made up. That’s an egregious example, but one of the first uses that occurs to any student of statistics is misuse. For a clear view of what that looks like, head over to Math With Bad Drawings’ article “Why Not to Trust Statistics.”

There’s two messages here. First, as a consumer of statistics (the language of business), understand numbers and question them. Know how the information was gathered, how it was summarized and why it was presented as it was. Remember that correlation does not imply causation. Second, as a producer of statistics, you are ethically bound to represent information in an unbiased fashion. Manipulating math to use a “magician’s force” on a decision is unethical.