8
Dev went on vacation leaving his work unfinished. How to manage this without informing the customer?
What should be my actions in this situation now? I cannot tell the
client that the development of the feature has stopped because the dev
went on vacation. This would be unprofessional.
Honesty is the best. You don't necessarily need to mention vacation, but being up front that, due to circumstances, the work will not be completed as originally ...
6
Risks are typically classified into these two categories: Known Unknowns and Unknown Unknowns. You can break the latter down into Unknown Knowable Unknowns and Unknown Unknownable Unknowns. Known knowns are not risks since this implies certainty.
You have two types of drivers when it comes to your budget and schedule risks. The first driver is ...
6
Dev went on vacation leaving his work unfinished. How to manage this without informing the customer?
In terms of how to do better next time:
It sounds as if you identified the risk as one of medium risk (might be ready) and high severity (huge business value), and you decided to monitor the risk (communicated with him on a daily basis and the progress seemed satisfactory).
Monitoring the risk basically left you in a situation of "success-oriented ...
5
We create assumptions because we don't have the answer to a question. If we don't have an answer to a question, that means we have uncertainty. If that uncertainty is tied to an objective, it is then a risk. This mean, the moment you create an assumption, you have a risk, and it remains a risk until either you find the assumption was correct or you ...
4
TL;DR
Risks can be accepted, controlled, or transferred. Your project plan should certainly include risk analysis and recommended controls, but the risks properly belong to the project stakeholders. As the project manager, you should focus on documenting the risks and providing reasonable project controls for those risks that aren't accepted or transferred.
...
4
In my opinion you're right. If a future event has no influence on project (or, if it has 0 probability of happening), it should not be considered as risk.
Of course, having "None" in your risk log can show exactly this - the item was evaluated, its impact is considered negligible, so you should not care about it any more. It can be beneficial to keep them ...
4
Q: What qualifies as a trackable risk?
A: Anything that anybody thinks is a risk to the project goals (usually time, cost, scope and quality)
As a Project Manager I try really hard to persuade anyone and everyone that has an interest in the project, to raise any risks they see fit. At the same time I encourage a culture of openness to risk and especially ...
3
This sounds like it would be a HUGE risk. Because it is huge, I would escalate it at the highest levels of the organization and it needs to be addressed by the project sponsor and project manager.
3
PMI defines risk as:
Risk is an uncertain event or condition that, if it occurs, has an impact on at least one project objective. (PMBOK, p275)
So, by strict definition, opportunity is risk. This seems counter-intuitive, but you can think of it like this: you don't know if the opportunity will happen, so the risk is that it may or may not happen or that ...
3
If the design document you refer to is the design document for a project delivery, and in that design document risks are raised, then those would be drawn into the risk log for the project and managed in the same way as risks raised in any part of the project.
However you appear to have made an assumption that the design document ruling DR out of scope for ...
3
Both Marv and Mark have great answers to this, but I want to add something on the classification of risks. I agree with Mark that risk management is not the end but the means to an end and keeping it simple and straight forward are two great rules; however, classification of risks, and other more formal risk documentation rules, may not help your current ...
3
Does this have the ability to affect the successful completion of your project? if so, it is a risk. I'm not sure that dividing risks into "operational" and "project" helps me to close the project successfully. A risk is any unknown that could affect the schedule, cost, quality, or scope of my project. The lack of backups isn't a risk per se. Absence of ...
3
In my view the way to think about this is that the risks on the Project's Risk Log pertain to risk to the goals of the project. In other words, things that could happen that prevent you from delivering the project on time, cost and quality and particularly against the acceptance criteria.
So in your case (depending on what your project actually is!) a lack ...
3
Risk management in product development
Here is a more recent (2010) research paper on risk management in product development. It has a link to the full PDF:
Product development risk management and the role of transparency
(Abstract)
The paper has references to Risk management standards and frameworks proposed by NASA, Department of Defense and Project ...
3
A bit of googling will probably give you too much information. I'm going to take the position that you facilitate a risk assessment for your project the same way you facilitate a risk assessment for any project. The key is to facilitate; Subject Matter Experts (SME's) will propose risks peculiar to the project.
The number of methodologies for facilitating ...
3
The first question I would ask is: is this person truly considered "key," does this person really possess such a unique set of skills and abilities that it would be near impossible, or very expensive, to replace? This situation can certainly occur, especially for FOIK projects, but often times I find it is more a false perception of that individual.
...
3
Codegnome's law states that you should always solve the problem before you automate the solution. You're creating a formula before you define the terms. I recommend that you define countermeasure first, and then think about what formula you want.
You're exploring the notion of inherent and residual risk - Inherent risk is P*I - what is the risk if you do ...
3
Dev went on vacation leaving his work unfinished. How to manage this without informing the customer?
1) What should be my actions in this situation now? I cannot tell the client that the development of the feature has stopped because the dev went on vacation. This would be unprofessional
In fact I agree to Thomas' "Honesty is Best" approach. Having another developer assigned to the task will definitely not align with the budget and I suppose that this ...
2
I don't think this is a disaster. We have done various projects on such conditions and it can work. Essential things are:
Ensure that you are partners in the project (which is generally a good idea when it is a real project) and not competitors.
Ensure you have explicitly defined what risks are moved over to the customer side as out-of-scope.
Ensure you ...
2
That sounds like a disaster. I think that set up would be a set up for a bunch of finger pointing and blame down the line. If they want to have influence over the costs, do T&M or cost plus. In fact, that's pretty much what this is or will be except without the finger pointing and lawsuits.
2
In addition to @CodeGnome's advice, you may also want to consult the Society of Information Risk Analysts.
riskscience podcast currently discussing concepts of risk tolerance that may be related to "risk profiling". In a recent episode they've discussed a number of risk frameworks beyond those that @CodeGnome cited. They are focused on information risk ...
2
TL;DR
Risk assessment is a broad topic that can (and has) filled many books. There is no simple answer to your question. However, there are certainly starting points.
Borrow from Security/Audit
The security and audit fields have some well-defined threat (risk) assessment models. For example, OWASP details the Microsoft Threat Modeling Process. While this ...
2
As with everything else in the project, you have two types of risks that affect quality. The first is aleatory risk, which is random variation that you cannot reduce. This type of risk would affect performance, in that there is variability in the creation of the product that would produce variability with quality specifications. You would have some ...
2
Risk = a chance to lose.
Opportunity = a chance to earn.
In my understanding, PMI puts Risk & Opportunity together because an opportunity becomes an opportunity only if it becomes reality; until then, we have to deal with the risk of that opportunity not becoming reality.
Example: I'll emigrate to another country because I think this will give ...
2
Www.threatsandopportunities.com best answers the issues above. Risk comprises known outcomes with associated probabilities, given the occurrence of an vent r condition. Threats are negative outcomes and opportunities are positive outcomes as they affect the cost, schedule, or performance objectives of a project. PMs handle threats through avoidance, ...
2
Opportunity is not risk. They are totally separate and different - the good news is that PM frameworks are likely to start to back-out of this habit - see the foot of this blog post on exactly this question and the note on PMBoK notes in 2013 Why Opportunities on projects should never be called risk.
2
A risk is a potential occurrence (positive or negative). An opportunity is a possible action that can be taken.
Opportunity requires that one take action; risk is something that action can be taken to make more or less likely to occur but is ultimately outside of your direct control.
2
In project terms an opportunity is something (tangible or an "effect") identified within the project deliverables that could unlock or otherwise facilitate a positive or beneficial effect.
Such things are sought and documented within the Business Case to counterbalance and justify the cost. Opportunities are the same things though are largely uncovered or ...
2
What defines opportunity, under the heading of risk, is the improvement to your already planned objectives. It is important to weed out real project opportunities from actions, which are things you already plan to, need to or must do.
Opportunity is added value. It CAN and often DOES change "the scope, deliverables, costs and benefits of the actual project"...
Only top voted, non community-wiki answers of a minimum length are eligible
