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 ...
7
An impediment or issue is something that is impacting the project now.
A risk is something that might occur in the future. Typically, we look at risks in terms of the likelihood they will occur and the impact on the project if they do occur.
If the impact/likelihood of a risk is high enough, we'd usually try to mitigate it in some way. This might involve ...
6
As others have mentioned Agile modifies risk management as compared to Waterfall. A well managed project will include looking at risks outside the scope of the project, and these should be handled more or less the same.
There are areas of risk that Agile methodology should help mitigate.
Time to Market / Scheduling Error: In a waterfall project it can ...
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
Aside: I may be reading too much between the lines of this question; I think this is a workplace politics problem rather than a strict PM problem. As a consequence, my answer is correspondingly pessimistic, jaded and cynical.
What is the probability that the functional unit will fail to deliver? What is the impact on the project scope/schedule/quality?
...
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
This speaks to pessimistic targeting on your estimations. Sounds like the team has a long runway and, as Parkinson's Law suggests, the team is taking advantage of every bit of it. There's another phenomenon, as well: Student Syndrome.
Challenge the team: target more aggressively. Cut your durations and bring your dates in at baseline time.
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
Add buffer to your project. There are two ways to do this:
Either taking a Critical Chain approach and have a bucket of buffer for the whole schedule (this would be my recommended approach), or, for a more quick and dirty approach...
Add time between the delivery date and the start of the next task.
This kind of situation is dealt with extensively in the ...
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
Pretty much all the risk will come from things the team has not done before (and every project has some aspect of that, unless you're experts in the particular field, in which case it isn't a 'project' so much as a 'job' - rolling out SAP in yet another enterprise, for example).
So, assuming you've got some things that the team has never done, first you ...
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
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
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
You are correct in saying that risk management is typically not explicitly addressed in Agile projects. That is, the process designers intended for typical project risks to be addressed through the practices outlined in the process. As a result, Agile teams traditionally do not use any kind of intentional risk management approach. This works for many ...
3
Remember to include opportunity costs in your cost/benefit analysis of either approach. While the price to get raw information might be lower for crowd-sourcing (for example), it may take more time to validate the data, standardize the format and get the website off the ground.
It strikes me that you could mitigate risks by hiring a subject matter expert ...
3
Crowd-Source. With a similar system to the one used here, merits and demerits could boost agreed upon information to a higher rank, calculated alongside a reputation value bestowed upon the actual user who submitted the data. The users should have incentive to participate and interact, like the badges offered here. Vanilla Forums are a great open source ...
3
With data. This is risk management. Identify the threat, assess its drivers and triggers, analyze its likelihood and downstream impacts, and escalate pursuant to the risk procedures outlined in your project management plan.
There are pollyanna personalities out there. If your PM is one of those, then it is your job to overcome that to the degree ...
3
In general, pointing out a problem is only partially helpful. Suggesting possible solutions usually elicits better responses. So in addition to pointing out the risks, please come up with mitigation plans and contingency plans for each risk.
Quantifying the probability and impact of the risk will help. Does this project have a project risk register? Have ...
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
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
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
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
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
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
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
This is a very interesting issue, but in many companies often underestimated.
From my experience, developers often do not realize that usage of a library or third-party code without checking a license can bring very serious legal consequences.
An additional issue, besides usage of a particular piece of code, are patent-protected solutions. Often a person ...
2
Risks are always in the future and are not certain. Issues or impediments are either in the future, is occurring now, or has happened in the past with ongoing adverse sequelae. To distinguish a risk with a future issue, it comes down to degree of certainty. If it WILL happen, with 100% certainty, it is an issue. In addition to this, an organization may ...
Only top voted, non community-wiki answers of a minimum length are eligible
