By the way, I haven't yet registered on the PMI website yet, so I've not booked my exam. The guidance is that we should do this asap because as we learnt from the Communications Management process, the chances of recollection after a month are pretty slim. So I plan do register over the weekend. Registration a project in itself!
So yesterday covered Chapter 11 Project Risk Management and Chapter 8 Project Quality Management
Again, it is interesting that the team participating in the training, consisting of Delivery, R&D and the Services organisations, did not own the Risk Management and Quality Management activities of the PMP processes, going back to the nature and culture of the company. For sure, we do manage risks, but in our own areas of expertise. In my case, as a Software Project Manager, we utilise the Agile Development Methodology and I do risk management every iteration, during the initiation/planning stage, through the iteration until delivery, repeated every 6 weeks. But that's in my own world of development, as a "development owner", and the development of a software stack, though a project in itself, is usually just a piece of the puzzle, the puzzle though is managed by top management, and they don't call themselves project managers...when in fact, they are - we're not given that visibility. However, I have initiated brainstorming sessions pro-actively myself and contributed to generating the risk register, but I haven't been accountable a program activity apart from maintaining responsibility and accountability for my deliverable.
The same can be said for Quality Management. We don't have a specific Quality Department, although quality is built-in from the ground up as part of our Development Methodology. We have very strict product quality control, including but not limited to Zero MISRA Warnings, Zero Compiler & Lint Warnings, Minimum Acceptable Line Coverage, Minimum Branch Coverage, Measure Code Complexity, Minimum Defect Criteria, Root Cause Analysis, Rolling QC, Continuous Integration, Component Unit Test, and very strong Configuration Management System and use Static Analysis tools like Klocwork as well as search for Open Source violations with Blackduck. ..So we are pretty solid code product quality - it wasn't easy of course, and we learnt from past mistakes. We have build masters, war rooms, in fact we do way more than covered in the Build Master.
On the Quality Assurance side that, according to PMI is the process of measuring and controlling the quality of the project itself, well, we don't really do much of this - although we do monitor and question if our project processes are working and whether anything can be optimised - but we don't really measure our performance against a baseline, or have metrics in place that illustrate the health of the processes. Certainly worth considering, but again, this is usually a department wide policy initiative that needs top-management buy-in.
As a project manager however, the PM is ultimately accountable for the quality of his/her project. Even though I don't manage the QA of my project personally, I must ensure it is being done and followed to the letter. In the software product development world, projects pretty much have to respect the product rules of development and management, so thankfully, much of the work is just automatically inherited.
----------------oOo------------------------------
Chapter 11 Project Risk Management
Risk Management today is considered the most import thing in the project management arena, since it is very difficult to measure in reality. Some companies use the title "Risk Manager" as a substitute for "Project Manager" in job descriptions.
What is a Risk?
A risk is a possibility than an event with adverse consequences for the project will occur. An event is a point in time. Classic mistake of PMs is to confuse problems and issues as risks. The opposite of risk is opportunity, which need to be managed as well. Good PMs maintain two registers: Risk Register AND an Opportunities register.
Risk can be considered as a measure of uncertainty. As the project matures, i.e. as we go deeper into the project lifecylce, the amount of uncertainty decreases, but the amount at stake increases. When the amount of uncertainty equals the amount at stake, at the intersection point, the risk is considered to be the greatest, nearing the end of execution.
Exam question: Risk Aversion - due to human nature, some people are risk takers, others are risk avoiders. It's about a person's willingness to tackle risky situations.
Six processes in Risk Management:
1. Plan Risk Management - Planning process
2. Identify Risks - Planning
3. Perform Qualitative Risk Analysis - Planning
4. Perform Quantitative Risk Analysis - Planning
5. Plan Risk Responese - Planning
6. Monitor and Control Risks - Monitor & Control
To Summarise:
Risk Management is identifying the risks, create a risk register, assign owners to risks, actively monitor and control the risks throughout the lifecycle of the project, especially the execution phase. However, according to PMI, the most crucial process in getting your risks sorted out, is the Planning stage.
Exam Terminology
Business Risk - a normal risk of doing business with an opportunity of gain or loss. Business risks dealt with top management.
Pure Risk - risk not related to the business with a possibility of loss only. Project managers deal with pure risk not business risks.
Categories of Risk
- Technical/Quality/Performance - Reliance on unproven or complex technology, unrealistic performance goals, changes to technology used, project management risks: poor planning
- Organisational - cost, time, scope objectives internally inconsistent, resource conflict
- External - legal issues, changing owner priorities, country risk, weather
Qualitative Analysis - Essentially tools that allow you to determine the risk factor, by assessing the risk against Probability and Impact, for each assigning a weighting (high, medium, low) point system in calculating the risk factor:
Risk Factor or Risk Rank = Probability score X Impact Score
This is added to the Risk Register
Risk Map - A tool used to visualise the areas of risk according to the risk factors
Quantitative Analysis - is all about MONETARY impact. Tools:
- Decision Trees - visual aid that maps the path of various decisions/routes showing the monetary output
- Simulation - use Monte Carlo simulation, assuming statistical distribution
- Sensitivity Analysis - ability to assess what will be the impact of changing something on a project (a tool is normally used)
- Expected Monetary Value (EMV) - Do not confuse this with EVM Earned Value Measurement - they're not related! EMV is the sum of the values of all possible outcomes of the risk event (random variable) weighted by their respective probabilities
Strategies for Negative Risks
- Avoid: eliminate the exposure to the risk. Could change the scope of work, remove constraints or use alternative resources or suppliers. This may affect overall project objectives, customer satisfaction and profitability or cost.
- Transfer: insurance or subcontracting, but remember the accountability remains with you, the PM! Transfer could involve subcontracting the work to an outside organisation, possibly better equipped to deal with the risk due to Resources, Expertise, Experience, Economies of scale. This of course may introduce new risks and costs. Insurance: substitute a known, small cost for an uncertain damage.
- Mitigate: This is very much a main part of pro-active risk management. Reduce the probability of the event. Focus on the risk factors by acquiring information to reduce the uncertainty. Take preventative steps for example, select more suppliers. Reduce the impact of the event, have recovery plans in place, also keep reserves - materials, resources, budget, time.
- Acceptance: it may turn out that the risk is not serious enough to warrant the time, energy and money to mitigate. Suitable for low impact, low probability, high mitigation cost events.
Strategies for Positive Risks
- Exploit: to ensure that the opportunity is realised
- Share: allocating ownership to a third party who is best able to capture the opportunity for the benefit of the project
- Enhance: modifies the "size" of an opportunity
- Accept: no change in the project management plan to deal with the risk
Residual and Secondary Risk
- Residual: risks are those that remain after avoidance, transfer or mitigation responses have been taken
- Secondary: risks that arise as a direct result of implementing a risk response
Risk-related Contractual Agreements
- Fixed price contract
- Insurance
- Performance bond
- Bonuses and penalties
Risk Register
A good risk register contains the following:
- Category of Risk
- Event (what is the event)
- Consequence of event
- Probability of occurrence
- Impact
- Cost
- Response to risk (Avoid, Transfer, Mitigate, Accept)
- Contingency/Recovery
- Risk Owner
- Status
Depending on the size and nature of the project, one can use Excel or a tool. Read more here
My Own take on the Subject
Risk is an interesting area that can consume a majority of one's time, it is almost a full time job. To manage risk well, the project must have a culture of embracing risks, i.e. in general people are afraid of communicating the risk and wait too long, and when the event occurs and becomes a critical issue, it's too late to say "I knew this would happen all along". People from all levels of the project should be empowered to communicate any concerns they have on the project - active feedback and active response from the project team is required. During the course of monitoring and controlling the project, the PM should ask the right questions - it's not often that people give you the most truthful answer, and generally when a PM requests for a status update on a task or activity, the usual response is "just provide enough info to get the PM off my back" - So more often than not I find myself drilling down to get the answers I seek, and in so doing try to uncover potential issues before-hand...I am a big fan of Tom Demarco - take a look at his books in the side bar. I recommend reading all of them, but it's a pity that having read all of them myself, I find myself in the wrong company environment that don't appreciate the professionalism behind some of these topics, and are quick to dismiss my attempts as academic exercises, not fitting with practicality and people rely on their past experience to manage ongoing projects...In any case, should the right opportunity come my way, I'll seize the it to ensure I implement some of these practices...
----------------oOo---------------------------
Chapter 8 Project Quality Assurance
Main aim of QA is to ensure Customer Satisfaction at the end of the project.
Quality Assurance (QA) - deals with Project Processes
Quality Control (QC) - deals with the product / deliverable
Primary responsibility for quality lies with the project manager.
Exam prep
Quality Initiatives:
- The Deming Improvement Cycle - always iteratively checking: Plan, Do, Check, Act
- TQM (Total Quality Measurement)
- Six Sigma - all about the standard deviation between -3 sigma and +3 sigma, normal distribution. 99.73% normal case, six sigma 99.99% failure rate
- Failure Mode and Effect Analysis - Fishbone or Ishikawa diagram
- Design Reviews
- Voice of Customer
- Cost of Quality - how do we measure the cost of quality? Important topic
Quality management process:
1. Plan Quality - Planning
2. Perform Quality Assurance - Executing
3. Perform Quality Control - Monitoring and Control
Cost of Quality - Conformance
Ensuring conformance to requirements - money spent during the project to avoid failures:
- Prevention - Quality planning, training, process control, field testing, Design validation
- Appraisal - Process evaluation, test evaluation, quality audits, maintenance and calibration of eqipment
Cost of Quality - Non-Conformance
Money spent during and after the project because of failures
- Internal Failure - these are failures not visible to the customer that we can fix internally
- External Failure - this is noticed by the customer and can be the following: Scrap, Rework, Expediting, Additional material of inventory, Warranty repairs or Service, Complaint handling, Liability Judgements, Product recalls, Product corrective action
Operational Definitions - Metrics
- Metric = measure. A numerical representation of an attribute of interest
- Criteria - indicators used to compare and evaluate alternatives
- Performance measurements - indicators used to determine how well the project is being executed
Tools & techniques for Quality Control
- Cause and Effect Diagrams
- Control Charts
- Flowcharting
- Histogram
- Pareto chart
- Run Chart / Trend
- Scatter diagram
- Statistical Sampling
- Inspection
- Approved change requests review
- Variability analysis
- Pareto's law
No comments:
Post a Comment