Tag: Risk

Dear 007, Am I Finished?

Written by Marcos Ferrer on August 20, 2015. Posted in Articles.

Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:

Dear 007:

My project manager tells me to “finish the requirements”, but no matter what I turn in, she says it is not finished. When I ask what else she wants, she says she wants everything. When I suggest that everything costs infinity, she says I have an attitude.

She is right (about my attitude). What should I do to “finish” the requirements?

Signed,

More Finished Than She Thinks

Dear More Finished Than She Thinks:

I assume that you, like most BAs, understand that requirements are rarely “finished” in the sense of being complete to the satisfaction of every stakeholder.

The most complete requirements ever written for a cell phone did not include the contingency factors inherent in a pair of boot-cut Calvin jeans worn two sizes too small and stuffed with an understructures oversize phone chassis.

Don’t even ask about rubber gasket temperature requirements for Space Shuttle boosters – they WERE included as requirements, but ignored by project management in spite of their completeness (“But Reagan is sending a teacher into space and giving a big speech – it’s a deadline!”). Deadline, indeed, but not a requirement.

SO, I assume that the words “finished” and “everything” means something different to your PM than they do to you. Let’s try a few definitions – if one of these fits you may realize what to do.

Does finished mean? :

I (the BA) can’t tell that anything is missing
She (the PM) can’t tell that anything is missing
We (the other Business Stakeholders) can’t tell that anything is missing
They (the Implementation SMES) can’t tell that anything is missing
It (the solution as implemented) can’t tell that anything is missing (everything” works)
Notice that none of these definitions involve anyone saying “I can see that X, Y, Z are missing” which would be more helpful.

Now for a definition that helps. Completeness is best defined at a GIVEN LEVEL OF DESCRIPTION. In the BA profession, we look to BABOK for the correct categories and levels of description. In this case, requirements have the following levels of description:

Business Requirements (High-level statements of key business needs, approaches and strategically justified capabilities that must be met regardless of stakeholder wants)
Requirements[Stated] (stakeholder wants and concerns not necessarily analyzed)
Solution Requirements (functional, work to be done)
Solution Requirements (non-functional, qualities of any solution to be implemented)
Transition Requirements (temporary needs and efforts, until “full” implementation)

“Our business has a need to deliver legal documents to its customers every day on less than one hour’s notice,” might be a COMPLETE business requirement. Make sure to comb your requirements and collect all the “high-level” actual business needs (as opposed to personal preferences, see below). You will discover some “low-level” requirements that imply high-level requirements, and vice versa. Separate them (analysis) into their own groups, rewrite them to fit their level and category. THEN IT BECOMES EASIER TO SEE WHAT IS MISSING AT THE HIGH-LEVEL. This is where MOST IT project mistakes get made and is the most important to get complete.

“I want a car so I can make those deliveries for the business” is COMPLETE in the sense of being a stakeholder requirement [stated, not analyzed]. Make sure that you comb your “requirements” and collect all the “not-really requirement” statements and put them into an “elicitation” document for further analysis. The “requirements” are not finished, because they are not analyzed, but COMPLETE in the sense of being everything the stakeholders said).

“Bicycle couriers average 12 miles an hour in city deliveries, vs. 7 miles an hour for cars. Feasibility ANALYSIS suggests outsourcing delivery to couriers (or we can buy the stakeholder a bicycle instead of a car).” This might be a COMPLETE solution requirement (functional) – DELIVER LEGAL DOCUMENTS. Collect all the actual work functions implied in all your requirements, and list them in one place. It becomes easier to see what is missing (e.g., PREPARE PACKAGE WITH CORRECT DELIVERY INFO, and CONFIRM TIMELY DELIVERY WITH CUSTOMER). To be complete, list all the IMPORTANT business processes, and let the less important arise as needed (e.g., we need to ASSIGN DELIVERY TO COURIER SERVICE as a critical business function, but we can decide to implement this assignment via text message as we negotiate with the courier service. Is the requirement complete, if this “text message” spec is unresolved? Not really (see the beginning), but it is LOW risk and focus belongs on other higher level issues (e.g., how to MEASURE delivery performance objectively, once assignments are made).

“Delivery in less than on hour” was already stated as a business requirement – it is (for this simple example) the COMPLETE solution non-functional requirement – a service level guarantee. Can you think of any functional requirements that would help guarantee that service level? Put those above – group like with like.

Finally, transition requirements. Who has to be informed, trained, won over? Do we have to convert data from the secretary’s Rolodex to a label print system for the courier packages? What is the implementation plan (oh project manager mine). The project plan (think about it) is largely “transition requirements”, and should lump upon the head of your PM as much as on you.

IN short, if you use BABOK categories, you avoid level mixing, confusion, and you gain the ability to see what else belongs at that level. If you do it right, you will perceive redundancies between levels. This is normal, and shows traceability and shows that requirements are related across levels (that is why it is so easy to mix them up and get confused about how complete they are). An example of a seemingly redundant requirement was “Delivery in less than an hour”. At the business level, it is a service strategy defined by a performance level. At the non-functional level, it drives measurement, verification and other functional requirements. By putting it in both places as appropriate, COHERENCE is achieved, which helps stakeholders in perceiving completeness.

ALWAYS START BY FILLING IN THE HIGH LEVELS TO MAXIMUM COMPLETENESS. IF there is no time to “finish” a lower level, you might not even start it. Don’t spec the detail steps of MANAGE USER PRIVILEGES just because you can – stick with high value high-level critical business processes such as VERIFY TIMELY DELIVERY, and try to “complete” the success scenarios. If you have time, go for the top 3 alternate scenarios. At each step, decide how much you can accomplish and put BABOK boundaries on the work so the completeness can show.

THEN when your manager says to “finish” the screen color requirement, you know which requirement and what is missing.

Je suis finis – et vous?

Please comment below – let me know what you DIDN’t get, so I can finish it 🙂

Intelligent Analysis from Intelligence Analysis: Using Psychology Tips in our BA Tool Kit

Written by Bronia Shaw on August 4, 2015. Posted in Articles.

Have you ever wanted to be a spy?

We may not be qualified to be the gun-wielding, smooth-talking James Bond, but maybe a savvy CIA analyst might be more up our street. There are, of course, parallels in many types of analysis work and while our projects may be a little less glamorous than counter-terrorism, there are things we can learn from the world of Intelligence Analysts.

Richard J Heuer Jr in his book “Psychology of Intelligence Analysis” discusses the topic of when to make decisions. He explores methods used by doctors making diagnoses and applies this to the world of the CIA. How to know when you have enough information about a government, regime or situation to spot risks and make informed decisions.

It also applies to our world.

We all conduct interviews and workshops, dig into documents and ask questions but we determine for ourselves when enough-is-enough. Or rather time usually dictates when enough is enough. Heuer proposes that instead you could rather consider a smarter approach.

Make Decisions Earlier

Heuer warns that more knowledge leads to more confidence in a decision but not necessarily more accuracy. Using the example of horse racing pundits he shows that pretty good estimates are made with reasonably scant information and that experts recognize the limitations of their guesswork at this stage. As they are given further information about form and conditions their confidence levels grow, but interestingly their accuracy does not grow proportionately or even by much in real terms.

In business this may mean that when we gather a small amount of information we may get a reasonably accurate picture. As long as we can deal with the uncertain feeling, we save a lot of time and resources gathering more when the only outcome is greater comfort. Understanding the confidence level of stakeholders when they provide information gives us a good indication of when enough is enough.

Analyze Root Causes

How else can gathering more information be counter-productive?

Heuer tells of how analysts propose a theory while gathering or reviewing intelligence but that sometimes this would lead an analyst to use new information to strengthen an incorrect theory. Each piece of additional intelligence was being wrongly valued according to whether it reinforced the existing understanding.

How can this affect us? When considering the possible options of a new business proposition we need to check if fresh information reinforces more than one choice, not just if it supports the current favorite. If we have determined a product to offer, simply getting a positive response from a focus group on that particular product doesn’t make it the best proposition. They may be reacting to a particular product feature that is a feature of more than one product.

Knowing what probing questions to ask to uncover the underlying facts is for careful consideration by analysts. It surely grows with experience but can be honed when explicitly considered.

This book is just one example of the many that discuss psychology or the techniques learned from psychology studies. We have a mine of information we can extract and apply as a modern Business Analyst.

Consider another couple of examples:

How not to raise a risk

“Does fear persuade or does it paralyze?” is the title of a chapter from one of my favorite business books “Yes! 50 secrets from the science of persuasion” by Goldstein, Martin and Cialdini. They refer to the study of a public health leaflet highlighting the dangers of tetanus infection. The study gave leaflets to students were either frightening or not and that either had a plan of action or not. Which would motivate the students to get a tetanus injection? The leaflets with a high-fear message only generated action if a plan was included. The authors then note: “it’s important to accompany high-fear messages with specific recommendations for actions that will reduce the danger.” Readers of the leaflet were less likely to resort to denial if they had a clear action plan.

We, as Business Analysts are key experts in reporting potential risks to project management but if we often find that our warnings fall on deaf ears then perhaps consider how we present the risk. If we don’t already recommend or suggest mitigating activities then doing so could improve our chances of the risk being reduced.

Warping views with information

Daniel Kahneman in his book “Thinking, Fast and Slow” shows us the effect of “availability” of information, that is how often we come into contact with information and how readily we recall it. Availability affects our perception of our world and, therefore, our judgment. He discusses a study where participants were asked to judge the likeliness of different causes of death. They were then compared against statistics of the time. He notes that “Strokes cause almost twice as many deaths as all accidents combined, but 80% of respondents judged accidental death to be more likely.” This is revealing. He argues that “estimates of causes of death are warped by media coverage.” If we see multiple reports of tornadoes or earthquakes, then we are more likely to deem them as a higher risk, even where true probability states otherwise.

So how can we apply this to our Business Analysis work?

If we discuss one type of business problem using multiple examples then we can only expect that the participants will, for at least a short time after, view that type of problem as larger than it really may be.
After experiencing the realization of a project risk we would expect stakeholders to view avoiding similar risk as disproportionately more important because the information is easily called to mind.
We must be careful then that we don’t set up a situation where we create an increase in the availability of information prior to discussing subjects that may need to be downplayed to meet our objectives.

Getting the most out of the people we encounter during our project life-cycle and the time that we spend with them is so important. There are many more exciting tips and techniques discussed in psychology best-sellers. In the future I hope we see some of these techniques becoming part of the formal toolkit of the successful Business Analyst and not just the CIA.

Leadership Lessons – When Were you Last Engaged?

Written by Peter de Jager on July 31, 2015. Posted in Articles.

No. That isn’t a question about your personal life, it’s a question about your work life. Are you still engaged? Or has the passion for your work worn off? More to the point? Are our staff still engaged? Do they look forward to arriving at the office, or are they regularly having to buy new alarm clocks because the old ones don’t hold up to the Monday morning mauling to shut them up?

The issue of ’employee engagement’ has become a bit of a trend lately. Head to Google Trends (www.google.com/trends) and type in ‘Employee Engagement’ for a visual representation of that trend based on Google searches. (Compare it to how my specialty of ‘Change Management’ is trending. Oops. Do I need to change my topic?)

The first thing we need to do is define what we’re talking about. What is ‘Employee Engagement’ and then, why should we care about it.

Here’s a definition I use that’s in synch with what I’ve seen as common usage;
“ an employee who is engaged with their job feels a certain amount of ownership in the outcome of their actions, they care about their work, they show initiative when something needs doing, rather than waiting for someone to point them in the right direction”.

Why is it important? Consider yours truly, the writer of this column as an absurd example. I’m a one man company. I must be engaged in what I do, not necessarily all of what I do, but at the very least with the core of what I do, otherwise there are ugly consequences.

I could not care less about ‘accounting’, yet it must be done – so I outsource that administrivia, and several others, to someone else. Problem solved.
But, the core of what I do is ‘take the stage’. The instant that becomes a chore, something I do on autopilot because I have to? Then I am on the fast path to being an ex-speaker.

In a typical office, the consequences of lack of engagement are similar, but they are easier to hide, or at least to ignore. A single unengaged employee out of a staff of 5 or 10 might be regarded as not much of a problem, but if 50% of staff are unengaged, then productivity and quality begin a precipitous drop.
If all of our staff are disengaged from what they do, then who owns all that which needs doing? Who cares about the deliverable? Who takes the initiative? If ownership, caring, and initiative is all falling to a handful or even a single individual? Then we have a serious problem. Especially when increased ownership, caring and initiative without recognition and/or reward is a very good reason to stop caring… anyone for a good game of domino effects?

When employees become disengaged, then even day-to-day operations require conscious effort to drive them forward, an effort that might be better used thinking about tomorrow.
So why do we disengage? Here are five possible reasons – there are others.

Not enough feedback.

We’re simple creatures. We like to know how we’re doing. Without feedback? We have no clue if we’re going in the right direction. Feedback is food that feeds our motivation.

Lack of opportunity to grow

We also don’t like standing in the same place, at the very least most of us find that boring. Even if there are no new positions to move into, are there at least new things we could be doing?

Lack of recognition

This boils down to a simple question? Do you care that I care? Not everyone is ‘self-motivated’, many us, make that nearly all of us, appreciate being appreciated.

Here’s a challenge. I dare you to do this. One Friday afternoon. Order in a few pizzas, some cans of pop, some dessert. Call everyone into your office and tell them, “I know you’ve all been working hard. I just wanted to say. “Thanks!” You don’t have to say anything else. Just ‘Thanks!’ This works even better if you’ve never done such a wild and crazy thing, especially if your organization has banned office celebrations. (This must be the case, because office parties have become a rare beastie.)

Let me know what happened. My e-mail is at the end of this collection of articles.

Lack of Trust

I don’t think anyone needs to spend much time elaborating on this. Nobody cares to put extra effort into an organization they no longer Trust. On a scale of 1-10… how much Trust is there in your organization?

Stress-Burnout.

Things are tough all over and getting tougher. If you want to muse something over on your own? Go back to Google Trends and do a search on ‘Recession’…. compare that chart to the one you got when you searched on ‘Employee Engagement’.

Not all of the above are solved easily, some are, others are way beyond our scope and powers. The problem of employee disengagement is a real one. If allowed to grow (or encouraged to grow!) then sooner or later the organization is coasting (grinding?) to a halt. The first step in solving it is accepting that it is a problem… and with that? Here’s the closer;

Here’s a personal question.. What do you do on autopilot at work? What have you disengaged from? What have your staff disengaged from? What’s that costing your organization? Do you know? Do you care? (Careful with that last answer… it’s a doozie)

You Can’t Have Your Agile Cake and Eat it Too!

Written by David Shaffer on July 31, 2015. Posted in Articles. 1 Comment on You Can’t Have Your Agile Cake and Eat it Too!

It’s probably safe to say that many organizations that perform software development are either using some form of Agile methodology or are in the process of implementing Agile. Management in these organizations very likely believes that Agile will deliver numerous benefits to the organization thereby allowing them to receive numerous accolades, applause, and recognition for their incredible foresight. Unfortunately, these lofty expectations are often wildly out of line and potentially detrimental to their organization. Frustration and disappointment are the typical reality in organizations adopting Agile for the first time. Understanding the root causes of this frustration will help avoid disappointment and the disruption to productivity in your project teams.

In my experience, the number one cause of team frustration and disappointment experienced by large development groups moving from a command and control Waterfall structure to Agile has been executive management’s need to feel as if they are contributing to a project by deciding priorities and dictating deadlines.

The Agile Manifesto simply states that software development teams should place more value on individuals, team interactions, working software, customer collaboration, and responding to change. In contrast, Waterfall places value on heavyweight processes, tools, plans, and documentation. Organizations looking to move to a more Agile methodology have typically been managed as command and control Waterfall shops. The command and control management style consists of executive management deciding on project priorities and then dictating deadlines. Project Management then creates a work breakdown structure or some other tool to identify all the tasks required for project completion and the Waterfall begins! Management’s comfort level with this command and control style is a major source of friction within an Agile methodology. Let’s face it, executives don’t complete any of the direct work related to a project. They don’t write requirements, write code or test the product. Therefore, the only way they feel they can contribute to a project is to use the big stick associated with the command and control style of dictating a deadline and forcing the team to perform heroics to meet it.

Software development teams are well aware of the Agile Manifesto and what it promises. They are generally excited about the opportunity to work in a more Agile environment and be freed from the confining command and control mindset. When our department embarked on the journey to convert from a very strict Waterfall methodology to Agile, there was tremendous hope, excitement, and enthusiasm. Teams were very anxious to move away from our current process which literally dictated that development could not begin until every requirement was officially approved by management. Obviously this was an ineffective and unfulfilling way to develop software since the inevitable requirement changes that were discovered could not be implemented without going through the entire requirement review and approval process. Projects were routinely late, over budget and failed to fully satisfy the needs of the business. After a few years of this inept performance there was a complete reorganization of the top levels of management and a mandate that our department look to Agile to save the day. Once the new management was in place, the Agile consultants began to appear. These consultants began coaching the organization on the techniques associated with Agile. Terms such as “Standup”, “Iterations”, “Retrospectives”, “Backlog Grooming” and “Iteration Planning” spread through the organization like wildfire. In hindsight, I could have made quite a fortune running a buzzword bingo game back then! Optimism was high and new objectives for learning and implementing Agile littered everyone’s yearly performance objectives.

The initial rollout of Agile went relatively well on a small proof of concept project. Based on these results the management team approved the use of the new Agile methodology on the complete redevelopment of our flagship product. This was to be an eighteen-month effort. The first misstep in our rollout of Agile was the demand that the Business Analysis group identify all of the Use Cases associated with this effort up front so we can estimate the entire project and calculate a deadline. Old habits die hard and it’s tough to teach an old dog new tricks would be appropriate cliché’s to describe this situation. The BA group pushed back against the idea that all Use Cases could be identified up front and stated that we thought we were going to be Agile. Nonetheless, we were forced to provide our best guess and the Project Management group came up with a hard deadline 18 months away. The team was now committed to delivering a complete rewrite of a product that was in production and being modified for seven years in a span of eighteen months! It’s ironic that our first step in the new Agile world was to complete a typical command and control task of identifying all work up front and spitting out a deadline. The team expressed the discomfort with this deadline but was assured by management that everyone understood this was a target and not a commitment. In reality, whenever a date is communicated to upper management, it becomes the expectation for delivery no matter how many times it is said to be only an estimate.
The team began development utilizing all of the shiny new Agile tools the consultants taught the group. Standups were attended and the textbook questions of “What did you do yesterday?”, “What will you do today?” and “Do you have any roadblocks?” were asked and answered. It became apparent pretty quickly that these questions were not very helpful. The team asked if we could abandon that script and simply use the time to communicate directly without the constraints of the three textbook questions. Project Management’s initial response to this request was negative. We have to follow the Agile methodology which says we must ask these three questions during a standup!
This is the second major cause of friction and frustration with an Agile rollout. Project Management begins emphasizing the Agile tools and processes over team collaboration and interpersonal interaction.

Ironically this is a completely anti-Agile approach. Over time, we were successful in convincing Project Management that the team should be empowered to decide on the structure and frequency of standup meetings. Unfortunately, this was quite a battle and caused a fair amount of friction between the development group and the PMs. It’s fair to say that the bloom was off the rose and the initial excitement and optimism associated with the Agile rollout was starting to wane.
This was the first of many battles between the development team and Project Management over the use of the Agile tools. The development team was forced to provide initial point estimates for each Use Case and Change Request that was accepted into each iteration. The Project Management team then used these point totals to calculate team velocity. Team velocity was then used to compare the supposed productivity of each team. Management was informed each week how many points each team was able to accomplish, “Team 1 completed 80 points this iteration while Team 2 completed 40 points!” This inevitably led to the question from management as to why Team 2 was half as efficient as Team 1. This is yet another source of friction and frustration with an Agile rollout. Point estimations used in calculating team velocity is simply an Agile tool which may help predict approximately when a feature may be completed by the development team. However, since old command and control habits are hard to break this tool is easy to use as a way to question the effort of a development team. Questioning effort based on an initial estimate that was provided without knowing all of the complexities related to the work leads to low morale and further disillusionment with the Agile method.

The team dutifully soldiered on with development and attended the structured Agile meetings. Standups, Iteration Planning, Backlog Grooming, Retrospectives, and Showcases were all scheduled to occur each iteration and were well attended. However, as time went on the usefulness of holding a retrospective at the end of each iteration began to wane and was questioned. Over many iterations continually answering “What worked?”, “What did not work?” and “What should we improve?” devolved into repeating the same things over and over. Additionally, holding mandatory showcases at the end of each iteration was also proved to be more of a negative than a positive experience. Each iteration did not necessarily deliver a full set of functionality for a feature, so showcasing the team’s work like clockwork caused confusion with the stakeholders. In light of these discoveries, the team pushed back against Project Management to see if the frequency of these mandatory Agile meetings could be adjusted. Similar to previous requests this was met with resistance. The PM’s argued “Agile says we must have a retrospective and showcase at the end of each iteration!” Once again the command and control mindset of dictating heavy process to the development team was rearing its ugly head. Morale on the development team sank once again and further disillusionment with the idea that we were Agile continued.
As we marched towards the non-negotiable deadline set many months ago, it became apparent that we would struggle to complete all of the work included within the Minimally Viable Solution (MVS). Business stakeholders began to realize (or started paying attention to) what was actually included in the MVS release of the product and began demanding additional features. Management bowed to this pressure and asked the teams to squeeze in as many additional requests as possible before the deadline. The development teams heroically worked 60+-hour weeks and delayed summer vacations in the final iterations to deliver the product at the deadline. This effort further skewed the team velocity reports since it showed the teams completing 100+ points per iteration. Some in management inevitably asked why they were so productive late in the project or commented how a fixed, non-negotiable deadline drives project completion. In reality, this experience further soured the development teams on our new “Agile” process since it certainly felt like the old “command and control meet the deadline or else” Waterfall process.

At the completion of the project the development teams, project management, and executive management began working towards a more agreeable Agile methodology that would be more in line with the actual Agile Manifesto. The keys to developing an Agile methodology that actually delivers the promises of greater efficiency are the following:
1). Recognize management’s comfort level with a command and control management style which dictates process and deadlines.
2). Recognize Project Management’s comfort level with dictating process and resisting team empowerment

The key to overcoming these realities is to develop trust between self-empowered development teams, project management, and executive management. Executive management must clearly define each role’s responsibility and authority within the project to ensure the teams are truly empowered to choose how they will utilize the Agile toolset. Once these roles and responsibilities are clearly understood, the development teams must earn the trust of management by consistently delivering working software while using the Agile tools. It takes time to establish trust. Allowing self-empowered teams to utilize the Agile tools according to their needs removes the friction associated with combining a command and control mindset with Agile.

I will provide a framework for communicating team responsibilities and authority levels to ensure Agile success in a future article.

Strategy Spotlight: 3 Organizational Structure Risk for the Business Enterprise

Written by Richard Lannon on January 26, 2015. Posted in Articles. 2 Comments on Strategy Spotlight: 3 Organizational Structure Risk for the Business Enterprise

Recently I delivered a workshop on Risk Planning and Analysis for the Business Enterprise. I was asked about the various levels of risk within an organization. In response to that question, I explained that there are many levels of risk that could be organized along standard company structure. My preference is to use three structure approach – – strategic, tactical and operational.

Strategic Risk: Generally strategic risk is at the enterprise level and requires a business risk management enterprise plan. There are many models that can be used. At this level risk management, planning and analysis should be part of the strategic planning process. An enterprise risk management plan should be created that addresses strategic planning elements, cultural risk appetite and attitude, governance, stress testing, identification, measurement, response and control. These elements should be brought forward as a standard in the rest of the organization. On a regular basis the organization should complete an enterprise risk environmental scan to ensure they keep their business risk artifacts current.

Tactical Risk: This level of risk is at the project management level. Often it is part of the project management process for key approved initiatives. Its objective is the successful completion of the project while addressing risk concerns effectively and efficiently as possible. Often tactical risk analysis requires that the organization have a risk management plan that provides the guidelines as to how risk is to identified, qualified, quantified, responded, controlled and monitored. Guidelines should be provided by the business enterprise so that project teams do not create their own risk management standards.

Operational Risk: The here and now of any organization is the operational level. It is what happening with the frontline of the business from your customer facing employees, the manufacturing floor equipment and product assemblers, to the field maintenance people. Operational risk varies by company and by industry. One thing is for sure, operational risk needs to be aligned with business guiding principles to ensure people and equipment is functioning appropriately. For example, safety is a huge issue in a number of industries. Therefore, risk response mechanisms need to be put into operational place to minimize risk impact.

Risk management, planning and analysis are a huge discipline that impacts all levels of the organization. It is not something that is meant to be done neither in isolation nor with a single group. When you consider risk management consider all levels of your company. Maybe by putting together a solid risk management plan there will be a less of a need to carry a rabbits foot.

Don’t forget to leave your comments below.