Go Small or Go Home?

Go Small or Go Home?

Professor cook provided several Project Management (PM) articles and I’d like to get your thoughts about, “The Value of Project Management,” by the Project Management Institute, 2010. The title peaked my interest and a few questions crossed my mind as I read the article.
• Is Project Management valued? What’s the big deal? Is it critical for success?
• How does Project Management affect or get affected by how a company goes to market? Or is it affected at all?

In the article, it states McKinsey & Co. surveyed senior executives and found over half of them considered “a strong Project Management discipline is a top-three priority for the company as they look to the future.” (p1) Wow. This impressed me. PM made the top three important corporate disciplines! A couple of ideas came to my mind:
1. That PM would rank so high in importance!
2. That the value a firm places on PM is linked to their future.

How about you? Are you surprised PM was ranked among the top three priority disciplines? Does your company value PM this much?

The article continues and recognizes that PM provides a way for a company to control costs, allocate resources, save time and improve project results. These benefits are especially important during a recession when streamlining operations, and minimizing costs is paramount for survival. Another finding from the Economist Intelligence Unit survey found another eye-opening statistic about PM: that 90% of global executives consider PM as “either critical or somewhat important” for their projects’ success and for the company to stay competitive. That’s 90%! Again, another impressive statistic. Between the McKinsey & Co. survey and the Economist’s survey, it seems likely that PM is very highly valued and important to an organization.

How does PM affect a company’s Go-to-Market strategies or get affected by them? To me, this relates to three things: buy-in, speed (delivery dates, deadlines), and scope.

PMs need buy-in to get the job done especially with cross-functional teams, shared resources, tight timeframes, or restricted budgets. The more top management supports the project, the more buy-in across the organization is expected. The PM can deliver results and meet Go-to-Market objectives more easily with buy-in. Speed-to-market also affects the PMs role. For example, the article tells us about Intel, an IT company in Santa Clara, CA where speed-to-market is critical. To address the need for speed, Intel will intentionally reduce scope to gain speed. This gives them a faster turnaround, a competitive advantage, provides them with more flexibility, and most of all, smaller scope provides them with a learning mechanism for quick customer feedback to make product modifications to get it right or as customer needs change. Intentionally reducing scope also, “…encourages project teams to hone in on key deliverables that can be achieved in a shorter amount of time…” p4. By choosing to “go small”, Intel goes fast, learns fast, and adapts fast. Customers get incremental value with every product revision.

Isn’t this a clever approach to PM? Would “going small” work well in your industry? Or is this approach impossible because your projects require long project life cycles?

The Art and Science of IT Project Planning

Software projects face a unique set of challenges when it comes to scope estimating and this is especially true for new software developments. Research has found that poor cost and schedule estimates are much more detrimental to software projects than any other problem. Typically, estimates are based on historical project information and/or expert opinion, which can be more of an art than a science. The author, William Roetzheim, suggests a more systematic approach to planning estimates for new software projects using research-based techniques.

Based on his experience with software projects, Roetzheim suggests companies take an approach similar to that found in the PMBOK when it comes to life cycle cost estimating accuracies. Initial estimations should be within +/- 50% of the actual cost and the budget should continue to be refined as the project’s requirements are more fully understood.

Screen Shot 2015-08-02 at 3.47.37 PM

The first step to estimate scope is to determine metric used as a measure of scope. In software there are numerous options, but the most common is the number of source lines of code (SLOC), which is the number lines of code written by humans and is usually given as thousands of SLOC (KSLOC).

To determine the number SLOC, you can use one of two options: the direct estimating approach and the function points (FPs) with backfiring approach. Using the direct estimating approach, you break the project down into modules and use multiple expert opinions to estimate the number SLOC’s per module. This is called a Program Evaluating and Reviewing Technique (PERT) calculation and is done by obtaining optimistic, pessimistic, and most likely values. The most likely value is weighted times 4 and the mean and standard deviation are calculated and used to create an estimate with a high level of accuracy.

The FPs with backfiring approach uses the estimate of the number of logical internal tables and external inputs, outputs, interface files, and queries to estimate the number of ways the program must interact with the users. Then you multiply the raw data by its FP conversation factor to fund the number of FPs.

Screen Shot 2015-08-02 at 4.43.29 PM

Then using backfiring you convert the FPs to SLOC using the function point for the applicable language.

Screen Shot 2015-08-02 at 4.43.43 PM

Once you have estimated the number of KSLOC, you take that number and multiply it by the effort required per KSLOC to find the estimate for the project. Researchers have come up with estimates for the effort required per KSLOC based upon different project types. For smaller projects, you would multiply the number of KSLOC by the productivity factor of the applicable project time to find the number of person-months the project requires.

Screen Shot 2015-08-02 at 4.11.04 PM

Since research has found that large projects tend to be less productive due to increased time spent communicating and coordinating, you must apply a penalty factor to the above calculation for larger projects. The calculation for the larger project would then = Productivity Factor * KSLOC^Penalty Factor.

Screen Shot 2015-08-02 at 4.11.15 PM

The author argues that the calculation above will deliver a reliable person-months estimate feeds into the project’s schedule and budget and that it should continue to be managed as the project moves forward in its lifecycle.

While the author’s presents his methods for estimating scope for a software project, he does make any recommendations on how to utilize them. If your company conducts software projects, does it use SLOC when estimating? Is there a specific process used to calculate time requirements and how does it compare to the process suggested by the author?

Roetzheim, W. (2005) Estimating and Managing Project Scope for New Development. Journal of Defense Software Engineering, 4-7.

http://static1.1.sqspcdn.com/static/f/702523/9277557/1288927629910/200504-Roetzheim.pdf?token=Iy0EhkuVC%2Fp4nH9ybNkoKNjsICw%3D

Legal Project Management

                                                      

Project management has long been used by different businesses to earn more profits through efficiency and predictability. How law firm can protect profits with the use of project management and their client can benefit from improvement in predictability of budgets and schedules in fix fee arrangement as well as in billable hour matter. This is an emerging field for project management.
Even I have worked as lawyer in law firm and I understand the difficulty of applying such tools in in legal field where almost each case, client, opponents and their clients are different.
But when I worked as a in-house legal officer, corporate client demands and expects definite answers and timeline from lawyers and they hate unpredictability specially when legal matter is critical for business future and there I understood the importance of systematic and disciplinary approach. for legal matters , It is always assumed as time taking process and final lawyer’s bill as surprised.  http://www.mmmlaw.com/assets/files/article_318.pdf  in this article, Author has mentioned very interesting thing that the “Lawyers are accidental Project Manager” as every legal engagement is a project with a fixed goal and limited duration but lawyers rarely embrace their role as a project manager and most lawyers embrace their responsibility to get a good legal result for their client but that is where interest ends. the process is a necessary evil to achieving substantial results. achievement will feel far less if it is not completed timely.

Nine steps can be followed to solve common problems problems by legal project management
1.Set objectives and Define scope
2.Identify and scheduled activities- Break the matter down in smaller task, that can be better budgeted ,scheduled, staffed and managed.
3.Assign task and manage the team
4.Budget guesstimating-Estimating and controlling cost with careful tracking,constant communication and early adjustment on task level
5.Alternative plans before problem occurs.
6. Managing and maintaining quality
7. Manage client communication- it is important to understand clients expectations and meet those objectives.As the project progresses circumstances change so need to report progress to them member and stakeholders.
8. Time-line,possibly in the form of Gant chart, which identifies projected timing of the task and interdependence among the task.
9.Negotiate change orders and be careful with scope-creep.

There is ERM Legal solution legal industry focused project- management Applications serves as a work space for matter and project managers during the scoping, planning budgeting and execution phase of the matter.

These skills are specially very much in demand therefore now days there is Law-MBA hybrid course offered and there are various position in fortune 500 companies as Legal Project Manager

As per one of the referred article “A recent American Lawyer Media Legal Intelligence survey found that firms that use legal project management report more productive client relationships, improved communication, greater cost predictability, and other benefits.”

There is lot of potential to use, develop PM tools to improve efficiency of the legal matter and disputes

References

http://www.legalbizdev.com/files/LPMsolutionsBx.pdf

http://www.legalbizdev.com/files/LPMgrowingBx.pdf

http://www.ermlegalsolutions.com/?page_id=10

http://www.mmmlaw.com/assets/files/article_318.pdf

Project Manager and the Client

I found the first article below when scrolling through the Project Management Interest Group on LinkedIn. Check it out: (https://www.linkedin.com/grp/home?gid=37888&trk=my_groups-tile-flipgrp).

“Becoming the Master of Client ‘Touch’” sparked my interest as I deal with clients on a daily basis. The word “touch” represents contact with a client that let’s them know you are thinking about them as well as things that may be significant to them. The article provides examples of client “touches” such as hand-delivering a proposal, sending industry specific articles to clients, and sending tools or check lists that make their lives easier.

In summary, the article highlights how the project manager has a responsibility to reach out to clients in quick, meaningful way that ultimately make the client feel comfortable with you. I see clients work with those they truly feel comfortable working with time and time again in my line of work. It is important to keep in mind all of the great skills we learn getting our MBA, but it is also very much about relationships we form.

The second article, “Managing Projects, Helping People,” suggests numerous ways that a project manager can walk the fine line of managing a project and a client relationship. Two aspects from the article I have found successful in client relationships are being honest and being an educator.

Being honest includes discussing how something may be a challenge for your team. By being honest, the client may be able to bring a perspective to the particular challenge you had not thought of previously. You can also include the client in the decision-making process to help build harmony on ideas. I have found explaining concepts, financials or outcomes in an honest light (i.e. why we are losing money on a particular portion of their business) and most importantly showing the client alternatives are a key part of the long-term relationship with the client.

Continuous education to the client can be a long-term benefit to the client/manager relationship. Often times the client hires a team, led by the project manager, because they are not knowledgeable about a topic. The article suggests using your expertise and starting from the beginning of the process explaining things at a high-level. It is important to detail and explain what things mean line-by-line.

When the project team presents a deliverable, it is key to take the time to educate the client on deliverable when can make it faster for decision-making. Six short steps can aid in successful presentation of deliverables:

  1. Start with short history of project highlights strategy and goals as well as what has been done to date.
  2. Explain what the deliverable is meant to do and how it will impact any downstream decisions.
  3. Present the deliverable thoroughly and with enthusiasm, covering the process behind the decision and variations that were discussed.
  4. Conclude presentation with a series of guiding questions
  5. Give client time to think and review before discussing
  6. Always receive formal feedback and follow-ups in writing

http://psmj.blogspot.com/2011/07/become-master-of-client-touch.html?m=1

http://teamgantt.com/guide-to-project-management/managing-projects/

Managing Work Life Balance

Work life balance is one of the more difficult parts of life when balancing personal goals in the present, and future.  The continuous competition between working, personal life, and family seems as it always compete for the few hours of the day.  The importance of balancing these aspect can allow anyone to be successful is all aspects, but setting boundaries is a must and focusing on one’s personal goals .  The following posts will outline and give some personal perspective the the attached HBR article.

1. Understanding your goals – Defining success in your life is a very personal experience and it is different for everyone.  This could mean being happy working in a stable job or range from moving up the corporate ladder which requires a significant amount of risk or travel.  To be successful in life one must under stand what they want, but also realize the this will evolve over time.  This article also notes a couple difference on gender like woman defining professional success as individual achievement while men may look at on going learning opportunities and development challenges.

2. Building support networks – The book “True North” and the HBR article touch on having those around you inside and outside of work who can help you deal with life responsibilities.  The true north specifically says that have two separate groups is always beneficial.  This brings two different perspectives and allows you to have an unbiased opinion in personal and business life.  For instance I have very close friends from who I grew up with, business associates from my previous jobs, but through my time at depaul gained people who I can bounce ideas off of who will give me a different perspective.  The reality is when you are young you thing you can control everything, but life brings difficulties in which you need others to support you.  Having a support network makes a world of difference.

3. Technology – Cell phones and the availability of emails makes it difficult to disconnect from work.  This pressure adds and competes with an employees or executives personal life. The phrase business never sleeps comes to mind, but on the other hand employees are ineffective when they do not unplug from work.  The importance of removing technology allows for the executive to be 100% when they are at home and keeps the family bonds strong.  Investment in your personal life adds value to the work and allows you to be vested.  Mixing these two spheres of ones life leads to confusion, issues and mistakes.

If you have any more ideas or thoughts pleas check out the attached link.

https://hbr.org/2014/03/manage-your-work-manage-your-life

thank you for reading

Risk Identification HAZOP

Of the four steps of the risk management process that we discussed in class, I find the first step, risk identification, to be the most important and intimidating. The scary part about risk is the surprise factor. It seems that most failures stem from the unforeseen problems. Therefore it is vital to determine the best way to identify all risks upfront so that they can be avoided.

The little experience I have with risk analysis is from participation in hazard and operability (HAZOP) sessions for process equipment that my company designs. Although I have only participated in a few sessions, the format of the HAZOP sessions left a lasting impression. During a session, there is one HAZOP expert that leads the meeting and, oddly, might not even be familiar with the system or how it operates. All of the other attendees usually have more knowledge about the system and how it should and could operate. After looking at a flowsheet of the system, the HAZOP expert dissects the system and defines certain “nodes” which allow for isolation within the system. From there, each node is evaluated through a set of standard possible upset conditions. It is a laborious process because each node must be evaluated at the same set of possible upset conditions even though the possibility of an occurrence could be nonexistent.

The approach used for HAZOP is similar to the Risk Breakdown Structure (RBS) that we discussed in class. If you can break a project up into tiny pieces and apply a standard set of thought provoking questions or scenarios, it will help in revealing risk. For me, I always got some enjoyment when a risk was found from what originally seemed like a nonsensical situation. Without the systematic approach of running each node through the same conditions, the risk would have been limited to what we imagine would happen based on previous experience. By having an outsider trained in risk assessment lead the group through the thought exercises, the questions asked were not bound by the bias of the engineers.

Based on my experiences with risk identification, I suggest including a variety of team members and non-team members when brainstorming the potential risks of a project. It is important to have both experts and non-experts on the project. Also, never feel like a question or potential scenario is not worth mentioning. You might find that the likelihood of the risk occurring is greater than you imagined or the question/scenario might spark an idea that reveals another risk.

Do you have any advice or tips to add on how to improve risk identification?

Cross-functional teams are dysfunctional

During my 15 years in the corporate world, I have seen several instances where projects fail just because it was managed by a cross functional team. I find that the projects always succeed when it has one leader and a good champion from the top management instead of a whole cross functional team to support.

The author of this article claims that he has studied cross-functional teams in industries such as communications, software, pharmaceuticals, semiconductors, agricultural, chemical, manufacturers, retail, utility, consulting, internet software, government, insurance, and banking and have found a strong correlation between the minority of successful projects and their oversight by a high-level team that was itself cross-functional. The article also states that projects that had a single high level executive champion had a 76 % success rate.

In a detailed study of 95 teams in 25 leading companies, the researchers have found that almost 75% of the cross-functional teams are dysfunctional. The cross functional teams seems to be failing on several criteria such as meeting budget, target dates, specifications customer expectations and aligning with the companies strategies.

The article claims that the main reason for the dysfunction is the team members working in silos. People in a cross functional team usually don’t work well with each other because they have completely different expertise and background. The solution recommended is to create a “Portfolio Governance Team (PGT),” where high-level leaders make complex decisions on the various projects together. As the high level learns to work together, that attitude cascades down and their team members will start to work together. Cisco has created a cross-functional team with representatives from marketing, software engineering, manufacturing, quality assurance, and customer service, to intensify security for router lines. The team had a three-layer structure. Project managers allowed for around 100 people to attend the meetings, but only a core group of 20 had to communicate back to their functions. Above these levels was a small governance team, made up of two vice presidents, the company’s chief development officer and the leader of the core team of 20 people. This implementation of cross-functional governance worked well for that project and several other projects and Cisco is now the number one router security vendor, with business growing at about 80% per year for 5 years.

The following are the recommended rules for the portfolio governance team.

  1. Every project should have an end-to-end accountable leader:

Instead of having one leader, each functional team should have a leader. E.g. VP of engineering should be the owner for the engineering action items and Director of marketing for marketing activities.

 

  1. Every project should have clearly established goals, resources, and deadlines. Before the beginning of any project, there should be an approved budget, and a charter defining priorities, desired outcomes, and timeframes. Establishing those early on is one of the key roles of the PGT.

 

  1. Teams should have the project’s success as their main objective. Different members will have other priorities, but for the project to succeed the contribution should be part of the compensation and performance review for each individual.

 

  1. Every project should be constantly re-evaluated. PGTs should keep a list of projects and priorities and routinely cut those that aren’t working or that don’t align with business goal

 

 

Reference: 75% of the cross-functional teams are dysfunctional by Behnam Tebrizi (HBR)

 

 

 

 

Which one “Qualitative” or “Quantitative”?

In the last MGT 598 class, we talked about project risk management.  The risk management process can be summarized in these four steps: Identification, Assessment, Response and Control.  These are typical processes and were widely discussed in many project management literatures.  Most literatures discussed how to identify and evaluate risks with quantitative approaches. One of them is from Guy Merritt and Preston Smith.

Merritt and Smith first introduced a tool called the “Standard Risk Model”.  This tool is used to evaluate project risks based on “facts” because they are easy to quantify:

Standard Model

The Standard Risk Model

Source: “Techniques for Managing Project Risks” by Guy M. Merritt and Preston G. Smith

With this model, we will have objective measures for the likelihood of risks (Pe) and impact of risks (Pi).  We will also get an estimate for total loss, Lt.   The four project risk management processes mentioned before will fit in different pieces of the model.  Putting these pieces together will give us a complete picture of how to manage project risks.  The author also illustrated how to apply this mathematical model by case studies.  This tool seems great because all four risk management steps were integrated in the model.

However, when we manage project risks, is it always true to use measurable facts only?  Do we need to consider non-measurable but material risks to the organization, for example, operational inefficiency, employee morale and loss of historical data, etc?

A year ago, our company implemented a project to migrate our ERP system from JDE to Oracle.  We planned the project for a while.  We tried our best to identify possible risks and evaluated financial impacts associated with all risks.  One of the risks we identified was loss of historical data.  Although we understand the importance of keeping track of historical records, we were not able to move all data to the new system due to time and budget constrain.   The risk mitigation plan was to allow two employees to have read-only accessibility to JDE.   This way we not only saved data migration costs but also license fees on the number of users.  In the meantime, we are able to keep track of old records.  While this seems a perfect plan, it has risks itself.

First, read-only function is not supported by JDE.  If for any reason, we have technical difficulty that we cannot access to the system, we will not be able to login and retrieve data.  Second, limited accessibility is like putting all eggs in one basket.  If an employee leaves the company without transferring knowledge to the successor, it will be difficult to retrieve historical data in the old system.  What happened to us was the second case.  The two employees with accessibility to JDE were no longer with the company.  We wanted to retrieve 2013 sales data but we were unable to do so because nobody knew how to do it.

I was not sure if we had thought about the risk of losing talents before.  This obviously has negative impact to the financial planning team.  We were not able to use historical data to perform financial analysis.  Although the impact is not easy to measure, I believe this kind of risks should be considered in project risk management.  How does your company identify risks?  Do you consider both measurable and non-measurable factors?

 

Article link:

“Techniques for Managing Project Risks” by Guy M. Merritt and Preston G. Smith

http://www.strategy2market.com/wp-content/uploads/2014/05/Techniques-for-Managing-Project-Risk.pdf

Sure… as long as I don’t have to do anything

I was cleaning my garage this weekend and wondering to myself how I got stuck doing this alone.  I know that my husband is in agreement with this project, so how am I doing all of the work?  When I looked back at the start of the project, I realized that I had missed an important step in project management: getting stakeholder buy in.

I don’t usually make this mistake at work because I know that I need resources to accomplish my projects, so I ensure that I have stakeholder buy in and that I have the resources I need to accomplish the project successfully. In my personal life, I tend to want to complete the projects more and seem to have an ‘approval at any cost’ mentality. However, this leaves me frustrated when I am doing all of the work on something that I think is beneficial to everyone.  I need to get buy in on the importance of these projects.

I read three articles on stakeholder buy in and I have three tips for ensuring that you gain and maintain stakeholder buy in throughout your project.

1. Involve the right people early

At the start of a project, it is important to identify all key stakeholders and who has influence.  Your stakeholders might include your boss, because you need them to approve the use of your time to this project.  A stakeholder may be an external partner who you need timely feedback from or a department leader who can fund your project financially.  I identified my husband as a stakeholder with influence and I checked for approval before starting to move all of our stuff out of our basement and into our garage to prepare for a garage sale.  I was successful in involving him, but I didn’t actually get buy in for resourcing the project.  When I asked about the idea, my husband’s response was “Sure, as long as I don’t have to do anything” and because I wanted the project to get done, I agreed to those terms.  This brings me to my second tip…

2. Set expectations

It’s important for everyone to be on the same page throughout a project.  Set realistic expectations about what you plan to accomplish and what you need to accomplish it.  I did not set expectations for what I needed from my husband; I didn’t even set realistic expectations for myself.  When my husband said that he didn’t want to lift a box, that didn’t sound too bad… until there were two giant workbenches that I needed him to help me move out of the basement.  After moving 50 or so boxes of our stuff, I have realized that I can’t do it all by myself I’ve been frustrated that he doesn’t want to be involved.  I have made a classic mistake of not managing stakeholder expectations.

3. Communicate, communicate, communicate

The article on Managing Stakeholder Attitudes discusses the importance of understanding “how supportive or opposed the stakeholder is towards the project.”  This will help determine how to communicate with stakeholders to aid in the project’s success.  You need to ensure that, whoever your key stakeholders are, they find enough value in the project that they’re willing to give you resources.  You can do this by framing the conversation around their needs, “WIIFM – what’s in it for me”, or around a colleague or department’s needs.  My husband had agreed to the project with no promise of his help, in fact, not needing his help was a condition of the approval.  That should have been a major red flag.  In order to gain his support, I need to focus more on what’s in it for him.  He has been asking me when we can pull our cars back into our garage where they normally reside (WIIFM #1). The workbenches in the basement also need to be cleared in order for his heavy bag and weight bench to be accessible, so I know he thinks that is important (WIIFM #2).  Decluttering our basement and making money at a garage sale is another selling point that I think he can get behind.

Once you have their support, you need to keep them informed to ensure they know that you are actively working on the project and to build excitement about it.  When providing status updates, compromises or setbacks need to be discussed just as much as successes in order to establish and maintain trust.  I did not do a good job in communicating status updates or progress, although the giant stacks in our garage are a pretty big status update.  We have our garage sale on August 7 where the entire town as a permanent free garage sale day and in order to be ready by then, there’s a lot more work that needs to be done.

This week, my husband and I need to have a discussion where we review the project goals, next steps, and available resources, much like a long overdue project kick off meeting.  Hopefully, we will both agree on the project scope and importance and I will get some help!

Have you ever found yourself in this position, either at home or in your professional life, where you think you have stakeholder buy in but you realize, as your resources slowly slip away, that you don’t actually have the buy in that you need?

Have you ever had someone approve a project, but not really support it?

http://smallbusiness.chron.com/stakeholder-buy-project-51429.html

http://www.projectaccelerator.co.uk/the-three-types-of-stakeholder-communication/3985

http://www.projectaccelerator.co.uk/managing-stakeholder-attitudes/3661

Risk Management Process

Risk Analysis is not a simple process. It involves many steps and different levels of granularity to identify, analyze and respond to the identified risks. As this topic was just recently covered in class, I decided to find out how the company I currently work for performs risks analysis.

Based on the methodology currently used within the organization, risk analysis process includes input deliverables, such as stakeholder analysis, legal contract, project management plan and issues log, and output deliverables such as project schedule and risk register where the risks are further subdivided based on the categories (technical risk, cost risks, schedule risk, quality risk, contract, legal risk, etc.).

I found it interesting that the first step in the process is identified as stakeholder analysis. As we all know stakeholder involvement, active participation and support are some of the important keys to project success. The goal of this deliverable is to analyze the relationship, level of engagement and future adoption levels for stakeholders and identify any issues or potential risks. This activity is usually performed by organizational control management team at the beginning of the project and is continuously updated throughout the project as well.

The deliverable of legal contract is self-explanatory – it includes project definition, project scope, description of services to be provided as well as pricing and payment terms, and is used as a building block for identification and analysis of potential legal issues and risks.

Another deliverable is project management plan that identifies main project management processes such as scope management, schedule management, cost management, quality management, resource management and communication management, and serves as an input to identify and analyze risks associated with direct project activities.

Issues log deliverable contains other problems that come up on regular basis, require to be resolved, but might not necessarily fall under any of the deliverables mentioned above. Typically additional project issues could be process or system requirements that are not compatible with each other, incorrect assumptions, missing information, etc.

After these input deliverables are collected, the risk analysis process is performed that includes risk identification, prioritization and response strategy steps.  Although risk identification step is done in the beginning, it is also a continuous process as new risks may emerge and become apparent during project. Risk prioritization is done in order to identify high-priority and high-impact risks which are calculated based on the risk exposure, probability of occurrence and level of impact variables. Finally, the response strategies are developed in order to reduce impact and threat to the project as well as to assign resources that will be responsible for executing the response when needed.

Therefore, by using input and output deliverables, risk analysis process provides structured plan with the main purpose to minimize the probability of adverse and detrimental events happening during the project as well as to lower the negative impact of these adverse events if they occur.

Additionally, when researching the risk management topic, I came across an article – “The Six Mistakes Executives Make in Risk Management”, that highlights some of the interesting facts and discusses six mistakes that are made during risk management. Do you agree or disagree with some of the statements made by the author?

https://hbr.org/2009/10/the-six-mistakes-executives-make-in-risk-management