Risk Appetite, Tolerance and Threshold are very important concepts in risk management and are often misunderstood. If you failed to understand the stakeholders’ risk appetite, tolerance and threshold, your risk management plan may be jeopardized. Not just this, how can we have a productive conversation about risk management unless we use the same language?
Before we proceed further and discuss about these very important concepts, lets revisit the definition of Risk. As per the PMBOK Guide 5th edition, “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.”
From the above definition, you can conclude that a risk can either be an opportunity or a threat: An opportunity has some positive effect on project objectives, while a threat brings some negative impact. The objective of risk management is to increase the probability of positive risks (or increase the impact), and reduce the probability of negative risks (or reduce the impact). Every individual has specific behavior towards risks; some people may want to accept the risk and others may want to avoid it. This behavior depends on the risk attitude of the individual, and for a proper risk management plan, you must find the risk attitude of your stakeholders. There are many factors that determine the risk attitude. These factors can be broadly divided into three categories: Risk Appetite, Risk Tolerance and Risk Threshold.
Risk appetite can be described as the amount and type of risk an organization is willing to accept in pursuit of its business objectives, Risk tolerance is the specific maximum risk that an organization is willing to take regarding each relevant risk & Risk threshold is the threshold to monitor that actual risk exposure does not deviate too much from the risk target and stays within an organization’s risk tolerance/risk appetite. Exceeding risk threshold will typically act as a trigger for management action.
To explain what I mentioned here, let me take help diagram listed towards left side. PMBOK lists below definitions for these 3 terms.
PMBOK® Guide, Fifth Edition defines it as “ The degree of uncertainty an entity is willing to take on in anticipation of a reward.”
PMBOK® Guide, Fifth Edition defines it as ”The degree, amount, or volume of risk that an organization or individual will withstand.”
PMBOK® Guide, Fifth Edition defines it as “ measures along the level of uncertainty or the level of impact at which a stakeholder may have a specific interest. Below that risk threshold, the organization will accept the risk. Above that risk threshold, the organization will not tolerate the risk.”
Appetite is often referred in terms of Low, medium or high. If you speak to your stakeholders and they mention that they have been able to grow because of risks they have taken in life and believe in order to grow further they need to take more risks, you are getting message that they have high risk appetite.
As the definition indicates, Risk tolerance is amount of risk that individual or organization will withstand. E.g. if you invest in stock market, even if the stock goes down by 2.5% or 5%, you might be ok with it. However, you have put a stop loss at 10% making that as Threshold limit.
Project management is a profession that’s growing fast and offers great compensation. According to Project Management Institute’s (PMI) “Earning Power: Project Management Salary Survey,” the median U.S. salary for a project professional is $108,200. Additional research indicates that there could be 700,000 new project management jobs to fill in the United States alone by 2020.
Another interesting observation in report is the salary of certified PMP’s Vs non-certified project managers. Below is the snapshot of the same.
Below is the salary info for Project managers in India:
I would suggest our readers to go through the entire report for encouraging details about the future of project managers and project management. Unlike highly specialized professions, project management is one that spans industries, geographies and even organizational size. From the classic “two guys in a garage” startup to the world’s largest multinationals, all the changes that take place in an organization happen through projects and programs.
Organizations have never had so much pressure from change. Change is unrelenting, and the rate of it can disable companies. So it shouldn’t be surprising that there’s a high demand for professionals who can manage projects successfully from start to finish—while keeping the bottom line in mind.
So how do you capitalize on this opportunity? You need to skill-up and prove your credentials. The only way to do that is not just learn project management methodologies but also to clear certification exams like PMP or Prince2. You can contact us at +91-7760347754 guidance and training. We train professionals, provide 35 PDU’s and help them get certified.
This answer to this question is very simple. A big yes!!
Why? Let me point our multiple reasons but then before going there, let me ask you one question. Are you sure you want to give PMP exam in next month or 2? If the answer to this question is yes, then the economics of being PMI member will make lot of sense to you.
As illustrated above, you not only save cost by becoming member of PMI and then writing your exam, but also end up getting loads of additional benefits.
Yes, it’s easier to prepare the control charts using Minitab. However, what if you move into organization that does not have minitab? Would you ask them to procure minitab even before telling the management the magnitude of the problem? Or would you rather use your knowledge to prepare control charts in excel? I believe you would utilize this opportunity to showcase your knowledge and not be dependent upon a tool.
So what are control limits? Control limits, also known as natural process limits, are horizontal lines drawn on a statistical process control chart, usually at a distance of ±3 standard deviations of the plotted statistic from the statistic’s mean. Before we proceed further and deep dive into calculation of control limits, let me distinguish between control limits and specification limits. Do not confuse control limits with specification limits. Control limits are based on process variation. Specification limits are based on customer requirements. A process can be in control and yet not be capable of meeting specifications. Control limits are the horizontal lines above and below the center line that are used to judge whether a process is out of control. The upper and lower control limits are based on the random variation in the process. We (and all tools in market) often use 3sigma as the control limit. Logic behind that is simple. Statistically for normally distributed continuous data the area bracketed by the control limits will on average contain 99.73% of all the plot points on the chart, as long as the process is and remains in statistical control.
Now, since have good understanding of what is Control limits, let’s look at how do we calculate control limits for continuous and discrete data.
For continuous data: UCL: Mean+3Sigma and LCL: Mean-3Sigma.
Where Sigma is standard deviation of data. Standard deviation can be calculated in excel with formula: Stdev.p (if you have population data) or stdev.s (if you have sample data). Only difference between these 2 formulas is denominator is either N or N-1 for calculation in excel.
For Discrete Data: there are 2 situations here. Either you are counting defects or looking at defectives.
- Below is how you calculate UCL and LCL if you are capturing defectives:
UCL: Percent Defective+3sigma and LCL: Percent Defective-3Sigma
Where Sigma is standard deviation of data. Standard deviation is calculated using this formula: Square root((Percent Defective-(1-Percent Defective)/Sample Size)
E.g.: ABC Company wants to identify number of defective bulbs they make. They determine that average percentage defective in sample of 100 is 2%. For this example lets calculate UCL and LCL for P chart (control chart for this type of data).
Now using above data UCL will be: 0.02+(3*0.0140) which is 0.062 and LCL will be 0.02-(3*0.0140) which is -0.022. Since the value is less than 0, LCL will be converted to 0.
- Below is how you calculate UCL and LCL if you are capturing Defects:
UCL: Mean of Number of Defects + 3 multiplied by square root of mean of Number of Defects and LCL is calculated as Mean of Number of Defects – 3 multiplied by square root of mean of Number of Defects.
E.g. ABC Company wants to identify number of defects in painted car panels they make. They determine that average defects in sample of 100 is 2. For this example lets calculate UCL and LCL for P chart (control chart for this type of data).
UCL is 2+3*(SQRT(2))= 6.24 and LCL is 2-3*(SQRT(2))= -2.24. Since the value is less than 0, LCL will be converted to 0.
Estimating can be a tedious task, and the final numbers are influenced by a daunting number of factors: scope, type of project, resources involved in estimating, type of client, unknown variables, potential risks and more. But estimating is critical to your project’s—and your organization’s—success. These tips can help practitioners arrive at an estimate that’s both useful and accurate.
- Always include contingency. A contingency is something that’s expected to be spent. Therefore, project managers shouldn’t remove it from an estimate simply to make the project look less expensive. In addition to a monetary contingency, also include the time and resources needed to handle the work the contingency implies.If the contingency is not needed, the project will simply be done earlier and the organization can keep the funds for another time.
- Avoid making numbers fit the budget. When working on an estimate, a project manager might be tempted to pressure the team to keep the numbers optimistically low. But this creates an estimate that is only good on paper; when the time comes to justify an overage, the team members will simply reveal that they were asked to estimate low numbers and overage should be expected. If the budget and scope are at odds, practitioners should instead adjust the scope: Ask the team to provide what can be done within the budget.
- Communicate team assumptions. A common mistake when estimating is listing tasks and numbers while not specifying assumptions behind the numbers. For example, team members may say they can create an online form in seven hours, but they’re envisioning a form with 10-12 fields, while you are expecting 20 fields. Employ good requirements management by making sure team members provide clear details on what they’re estimating to avoid costly surprises later in the project.
- Avoid using only high-level breakdowns. The more detailed the breakdown, the more accurate the estimate and the easier it is to get the whole team on the same page. For example, it’s too high-level to say: We will create an online store with a shopping cart. It’s clearer to state: We are responsible for the login, account creation, account management interface, shopping cart and confirmation emails.Clearer estimates may reveal higher costs, but it’s better to find that out while you can still control scope or expectations, rather than mid-project when you are reporting an overage.
- Double-check for commonly overlooked activities. In the strain to consider every task, deliverable and bit of scope, it can be easy to overlook ancillary activities, such as meetings, edits on internal or client feedback and bug fixing. But these often-overlooked activities happen frequently during a project—and can frequently derail estimating efforts. Though these tasks can have a huge impact on your estimate, it’s difficult to gauge how long certain parts of the project will take. Feedback, for example, can range from “Change these two sentences” to “I don’t like the concept, can you propose something else?” To handle this ambiguity, look at historical documents like past project reports and assess a percentage of the work rather than a specific amount of money or time.
- Include the accuracy of the estimate. Estimates are all guesses based on assumptions, but some guesses are more accurate than others. If the project involves using new technology, for example, then your estimate will be less accurate than if you’re using a system the team already knows. In addition, many estimates are done too quickly due to time constraints; in those cases, the accuracy of estimates drastically diminishes.It’s crucial to communicate the accuracy of the estimate, meaning to specify by how much the amount given can vary. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) provides the following guidelines:
- Rough Order of Magnitude Estimate: -25 percent to +75 percent
- Budget Estimate: -10 percent to +25 percent
- Definitive Estimate: -5 percent to +10 percent
By communicating this information to your client, you set expectations and avoid surprising anyone when the estimate changes. Please note that A ROM estimate takes place very early in a project’s life cycle — during the project selection and approval period and prior to project initiation in most cases. The main purpose of the ROM estimate is to provide decision-makers with the information necessary to make a decision on whether it makes sense to move forward with the project based on the estimated level of effort, in terms of completion time and cost. The point is to provide a “ballpark” estimate using the information available at the time.
The following information provides a comparison of the three general kinds of estimates as the project makes its way through the life cycle.
- ROM Estimate (Variance of -50% to +50%, or -25% to +75% depending on preference)
- A “ballpark” estimate used to provide a starting estimate to move forward
- A top-down estimation approach
- Use of previous expert knowledge and experience
- Not a great deal of time is spent to develop the ROM estimate
- Budget Estimate (Variance of -10% to +25%)
- Also a top down estimation approach
- Use of analogous estimation techniques helps provide a slightly more accurate estimate than the ROM estimate (e.g., referencing previous similar types of projects for effort)
- Definitive Estimate (Variance of -5% to +10%)
- A bottom-up estimation technique that requires a decomposition of work and its level of effort that is summed up to develop a more accurate estimate
- Generally performed during the planning phase and maintained through the remainder of the project
- This is the most time-consuming estimation effort of the three listed.When developing a ROM estimate, it is best to try estimating in buckets of time and cost. Providing categories may help estimators who otherwise would not be able to provide one number due to the limited amount of information available at the onset of a project. The example below provides categories of “Low”, “Medium”, and “High” levels of effort. Using such a scale may be easier than trying to pull a number out of a hat. It also sets the expectation on both sides — project team and client — that the ROM estimate has a large variance and should be recognized as just an initial ROM.
- Low Effort
- Hours: 40 to 80 hours to complete
- Cost: $1000 to $5000 dollars
- Duration: 1 to 4 weeks
- Number of Resources: 1 to 3 Resources
- Medium Effort
- Hours: 80 to 480 hours to complete
- Cost: $10,000 to $50,000 dollars
- Duration: 2 to 6 months
- Number of Resources: 4 to 10 Resources
- High Effort
- Hours: 480 to 2080 hours to complete
- Cost: $100,000 to $500,000 dollars
- Duration: 6 to 12 months
- Number of Resources: 11 to 20 Resources
- Low Effort
- Don’t forget risks. This part may be tricky depending on how aware of risk management your team is. Often, the team will do a quick assessment, agree that it’s a risky project and add more hours to the estimate.However, that’s not enough. Planning for your risk budget means using the registered risk and mitigation plans and accounting for the time needed to make those plans happen. For example, to prevent a technological constraint in a future phase of the project, you may plan to build a prototype. It would potentially avoid 200 hours of rework and would confirm the look and feel the team can obtain before the organization commits to the client. However, the prototype will still take 70 hours to build, and that effort needs to be taken into consideration when estimating the project.
MUDA: any activity in your process that does not add value. MUDA is not creating value for the customer. In short: WASTE
Type I muda: Non-value-added tasks which seam to be essential. Business conditions need to be changed to eliminate this type of waste.
Type II muda: Non-value-added tasks which can be eliminated immediately.
These wastes were categorized by Taiichi Ohno within the Toyota production system, they are;
- Transport: the movement of product between operations, and locations.
- Inventory: the work in progress (WIP) and stocks of finished goods and raw materials that a company holds.
- Motion: the physical movement of a person or machine whilst conducting an operation.
- Waiting: the act of waiting for a machine to finish, for product to arrive, or any other cause.
- Overproduction: Over producing product beyond what the customer has ordered.
- Over-processing: conducting operations beyond those that customer requires.
- Defects: product rejects and rework within your processes.
- Skills/ Talent: High skilled workforce to do work that can be done with lesser skilled workforce. We can also say this is failure to utilize the skills and knowledge of all of your employees.
- Resources: failing to turn off lights and unused machines
- By-Products: not making use of by-products of your process
Many “lean” initiatives fail to see past the elimination of Muda and believe that the point of Lean is to just eliminate waste. This leads to implementations that initially appear to save money but quickly fall apart and revert as problems such as customer demand fluctuations and supplier problems occur. They have failed to tackle the other forms of waste identified by Toyota (Mura and Muri).
MURA: Any variation leading to unbalanced situations. In short: UNEVENNESS, inconsistent, irregular. Mura exists when workflow is out of balance and workload is inconsistent and not incompliance with the standard.
MURI: Muri refers to Unreasonable, impossible, overdoing and overburdened. It can also be defined as “Asking the unreasonable or impossible.” Any activity asking unreasonable stress or effort from personnel, material or equipment. In short: OVERBURDEN. For people, Muri means: a too heavy mental- or physical burden. For machinery Muri means: expecting a machine to do more than it is capable of- or has been designed to do.
They have to looked in conjunction and not separately. When a process is not balanced (mura), this leads to an overburden on equipment, facilities and people (muri) which will cause all kinds of non value adding activities (Waiting is also an activity!!) thus leads to muda.
To eliminate MURA and MURI larger parts of the system need to be looked upon, not only a process or process step or operation, but at an entire Value Stream. Makigami, VSM or ‘Process Kaizen’ eliminates MUDA.
Muri is caused by:
- Working on processes you are not trained on.
- Poorly laid out workplaces.
- cluttered workplaces.
- unclear instructions.
- Lack of proper tools and instructions.
- Fluctuating demand.
- Lack of proper maintenance.
- Unreliable processes.
- poor communication routes.
Peter Schilling suggests:
1. Design the system with sufficient capacity to fulfill customer requirements without overburdening people, equipment, or methods (MURI.)
2. Strive to reduce variation/fluctuation to a bare minimum.(MURA)
3. Then strive to eliminate sources of waste!(MUDA)
BUT REMEMBER: Quality first, then cost – first stop shipping scrap.
When takling with these 3 we should:
- Take a careful look at your Mura and your Muri as you start to tackle your Muda.
- Ask why there should be any more variation in your activities then called for by customer behavior.
- Then ask how the remaining, real variation in customer demand can be smoothed internally to stabilize your operations.
- Finally ask how overburdens on your equipment and people — from whatever cause — can be steadily eliminated.
Example of Muri in Services: Incomplete information in ticket by frontline like issue type and user appointment details. Because of which 2nd line called back the user but the call was unanswered as user was not expecting call at that time. Only after multiple attempts 2nd line was able to resolve the issue and end of the shift, 2nd line was not able to meet their resolution goal and now have to hurry up to deliver minimum expected throughput.
Example of Muri from Health Care:
A Team Member’s task is to change linens. This task is routine. She goes to the storage area for linens on her floor, and finds none. She goes to another floor, and perhaps another, and ultimately finds the linens she needs, then returns to the task she was trying to accomplish in the first place. (She at least did not have to hire a taxi to deliver fresh linens from the service, as other caregivers reported they had done.)
At the end of the shift, however, manager would wager this Team Member wasn’t able to get everything done. Or she had to hurry to do things. Perhaps the work left undone is now passed to someone else and will disrupt their work. All of this is an example of overburden – asking (or implicitly expecting) Team Members to do more than they should, or more than they can. At the very least, the floor she took the linens from now has fewer than they probably need, and another safari will be launched from that floor tomorrow.
In both the above cases case, the Team Member is implicitly expected to “do what must be done” in order to deliver care. There are no avenues to address, or even call out, the existence of these problems. Calling them out carries at least an implied professional or psychological risk of being branded a complainer, or “not a team player.”
For management, the question is a simple one: Is this task one which you would deliberately design into this person’s work process? If not, then question why it must be done at all. But you can’t just question it. That implies the person doing it is doing something wrong. She isn’t. She is doing exactly what must be done to do the job she was given. Question why it must be done so you can remove the necessity to do it.
Example of Mura: One obvious example is production processes where the manager is measured on monthly output, the department rushes like mad in the final week of the month to meet targets, using up components and producing parts not actually required. The first week of the month is then slow due to component shortages and no focus on meeting targets.
What are the data requirements for a capability analysis?
- Distribution fit
- Your data must follow the assumed distribution for the analysis, such as a normal distribution (or nonnormal data transformed to fit a normal distribution) for Capability Analysis–Normal. The validity of the capability indices critically depends on the validity of the fit of the distribution used for the analysis. If your data do not follow the assumed distribution, the results will be inaccurate. If you are unsure which distribution best fits your data, use Individual Distribution Identification to identify an appropriate distribution or transformation.
- Process stability
- Your process must be stable and in control. A process is stable if it contains only variation from common causes, but no variation due to special causes.
Tools for determining whether a process meets the requirements for capability analysis
You can use the following tools in Minitab to assess whether your process satisfies the requirements for the analysis:
- Xbar or Individuals charts to determine whether the process is in control. If the process is out of control, the capability indices are invalid.
- R, S, or MR chart to track the variation in the data and assesses whether the process variation is acceptable.
- A run chart to look for evidence of patterns in your data.
- Probability plot to verify that a chosen distribution fits your data.
- Capability histogram and capability plot to visually compare the distribution of data from your process to the specification spread. It also includes capability statistics to assess capability of your process quantitatively.
You can use Minitab’s Capability Sixpack to evaluate the main requirements for capability analysis. This analysis includes control charts, a histogram, a probability plot, and a capability plot, as well as major capability indices. Chooseand select the normal, nonnormal, or between/within analysis.
Example of using Capability Sixpack to check assumptions
Source: Minitab Support files.
A leading professional skill development/ certification company invited us to create and maintain a Business Process Management System. The organization has a aim to train a very large number of job seekers, mid level and senior level managers by providing skill enhancement professional certification training and then help them with placement.
This meant that the organization would have to penetrate multiple tier 1 and 2 locations in country however this had to be done in short span of time and quality of delivery, consistency and participant satisfaction is of prime importance.
By engaging us, the organization wanted to strengthen its operational capability by identifying and rigorously defining its major processes, standardize it and have stringent checks in place to ensure process mandate. This exercise also had to be supported with analysis of risks inherent in carrying out day to day activities and a complete framework for measurement of performance in order to proactively take corrective action and have no risk on reputation because of expansion plans.
Methodology and Analysis :
We developed a core operational framework that was aligned to its business goals. Each of the business processes such as business acquisition, training delivery, placement; content development and student certification were broken down into their respective sub-components and tasks. The team then partnered with the process owners to create a sound operational process along with performance measurement criteria in the form of metrics and Service Level Agreements (SLAs). Detailed cross functional process maps were created to show hand offs and interdependencies between the various departments in the organization. A data tracking mechanism was set in place to enable regular reporting and to identify performance lags.
We also assessed the potential for failures within the processes and their impact on internal customers, employees and the organization. The team partnered with the process owners in identifying methods to eliminate these failure points by changing the manner in which critical process steps were executed or by mitigating the impact of these failures, should they occur, by incorporating stronger checks and controls.
By the end of the engagement, the company had more clarity on the ‘what’, ‘when’ and ‘how’ of each of their core business processes, besides being equipped to manage everyday operations in a seamless manner. This exercise also enabled the organization to become automation ready by deploying a suitable BPMS suite at a later point in time. Company was able to scale up operations in multiple cities and mitigate the risks arising out of mitigation plan.
We can easily calculate the DPMO but then how does it get converted to process Sigma level? Confusing? Below table illustrates the corresponding sigma level for different DPMO values. Don’t want to use this table and have excel do the work for you? Yes, you can have excel as your assistant and help you derive the sigma value using below formula:
=(NORMSINV(1-$B2))+1.5, where the data in cell B2 is entered as a decimal (for example, B2 value of 20% defects calculates as 2.34 Sigma Level, 30% is 2.02 sigma value, 40% is 1.75). Eliminate the 1.5 from calculation and you will have current Z value of the process.
Here is the table that provides the numbers for each sigma level but for accurate results to the last decimal level, use excel:
What is a Project?
Project is a temporary endeavor with definite beginning and end data undertaken to create a unique product or service. Project can be completed by delivering the intended value or at times might get terminated due to various reasons. A successful project is one that meets or exceeds the expectations of your stakeholders.
Building a web portal/ payroll system for a company is a project. The process of building web portal/ payroll system takes a finite amount of time, and produces a unique product.
Operations, on the other hand, are repetitive. Generating bills every month, providing customer service/ technical service to your customers/ employees and broadcasting news everyday are examples of operations.
Subprojects are components of a project that often contracted out.
What is Project Management?
Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements.
Project management is accomplished through the use of the 5 processes detailed in PMBOK.
Project managers or the organization can divide projects into above phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle.
Project managers deliver projects while balancing the following constraints (Knowledge areas):
- Human Resources
These all are so intertwined that a change in one will most often cause a change in at least one of the others that is why we say Integration management is key.
- If time is extended, the cost of the project will increase.
- If time extended with the same cost then quality of the product will reduce.
- If scope is extended then cost and time will also extend.
Changes to any of these legs sets off a series of activities that are needed to integrate the change across the project.
What is Program Management?
A program consists of a group of related projects and Program management is the process of managing multiple on going projects. An example would be that of designing, manufacturing and providing support infrastructure for an automobile make.
Program management involves centrally managing and coordinating groups of related projects to meet the objectives of the program.
In some cases Project Management is a subset of Program Management. The project manager may report to the program manager in such cases. A portfolio consists of multiple programs.
What is Portfolio Management?
A portfolio is a collection of projects, programs subportfolios, and operations that are grouped together to facilitate effective management of that work to meet strategic business objectives. Organizations manage their portfolios based on specific goals.
Senior managers or senior management teams typically take on the responsibility of portfolio management for an organization.
Portfolio management encompasses managing the collections of programs and projects in the portfolio. This includes weighing the value of each project, or potential project, against the portfolio’s strategic objectives.
Portfolio management also concerns monitoring active projects for adherence to objectives, balancing the portfolio among the other investments of the organization, and assuring the efficient use of resources.
Why do we need Project Management?
We need project management to manage projects effectively and drive them to success. Project Management starts with the decision to start a project upon weighing its need and viability. Once a project starts, it is crucial to watch the project progress at every step so as to ensure it delivers what all is required, in the stipulated time, within the allocated budget. Other drivers influencing the need of project management are:
- Exponential expansion of human knowledge
- Global demand for goods and services
- Global competition
- Team is required to meet the demand with quality and standard.
- Improved control over the project
- Improved performance
- Improved budget and quality
Project Management Skills:
Many of the tools and techniques for managing projects are specific to project management. However, effective project management requires that the project management team acquire the following three dimensions of project management competencies:
- Project Management Knowledge Competency: This refers to what the project management team knows about project management.
- Project Management Performance Competency: This refers to what the project management team is able to do or accomplish while applying their project management knowledge.
- Personal Competency: This refers to how the project management team behaves when performing the project or activity.
Interpersonal Skills Management:
The management of interpersonal relationships includes:
- Effective communication: The exchange of information
- Influencing the organization: The ability to “get things done”
- Leadership: Developing a vision and strategy, and motivating people to achieve that vision and strategy
- Motivation: Energizing people to achieve high levels of performance and to overcome barriers to change
- Negotiation and conflict management: Conferring with others to come to terms with them or to reach an agreement
- Decision Making: Ability to take decision independently.
- Political and cultural awareness: Important to handle various personal and professional issues.
- Team Building: Ability to create a productive team.
What is PMBOK Guide?
PMBOK Guide is the bible for Project Management. PMBOK stands for Project Management Body of Knowledge. There are ten knowledge areas defined in PMBOK Guide, which are as follows:
- Project Integration Management
- Project Scope Management
- Project Cost Management
- Project Time Management
- Project Risk Management
- Project Quality Management
- Project HR Management
- Project Communication Management
- Project Procurement Management
- Project Stakeholder Management
Each Knowledge area has certain processes. There are a total of 47 processes in PMBOK 5. Each process has following three important parts.
- Tools & Techniques
The PMBOK covers each of the 10 knowledge areas and 47 processes with their inputs, outputs, and tools & techniques.
Further the discipline of Project Management has five process groups.
- Monitoring and Controlling
Each process is part of one of these five project phases. It is important to know the process group for each of the 47 processes.