21
Deadlines are missed all the time. While it is a badge of honor to hit it, there are acceptable variances where the schedule can still be claimed a success. Further, it will likely have zero impact on your first client because it likely planned for a late delivery as contingency. Your second client is dead in the water. He is being severely impacted by the ...
8
So the developer felt ignored when he escalated a threat, so he showed 'em and showed 'em good? Organizations have every right to either mitigate their threats or simply accept them and continue on. It's a business decision based on threat level and costs to mitigate and other considerations. They do not need to have a risk escalator prove them wrong by ...
8
1: First of all, make the right thing as easy to do as you can and make sure it's well understood.
In this particular instance a Github spokesman responded:
We haven’t been as clear as we should have been on how to responsibly
disclose security problems, and for that I’m sorry.
Also, think about what the wrong thing would be, and consider that there ...
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
If I were Egor's project manager, I would consider myself to have failed Egor.
My second principle is "Communication is 100% of your (the project manager, scrum master, coach) job." This issue falls right into this maxim.
As project manager's it is our job to understand everyone on our team. In any endeavor with creative minds (software coding 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
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
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
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
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
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
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
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
Your risk management plan lays out the method, process and tools you will be using throughout the project to manage risks. It's a document you do at the beginning of the project and that should get signed-off. It should cover how you will identify, assess and track risks and will also include things like responsibilities, governance and decision-making ...
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
I agree with David (+1!) the best is to keep the customers we have, as deadlines are subjectively known to be broken. And David's answers is pretty much the same as yours, focusing on the current customer.
The open question here lies slightly beyond:
How could this be handled better?
As already stated, if there's no right or wrong... how can exists better ...
3
Being an entirely abstract question there is, as your interviewer said, no absolute right or wrong answer.
Here's a few other thingss I would take into consideration before making my decision:
Is there anyone else in the wider organization (outside my team) who can support the live user? If you're in an impossible situation don't be afraid to go for help ...
3
Question 1:
After the event, you may have limited scope to "help" the developer, especially if he has acted in any way that could be considered illegal. In such a case, the best you can hope for is to talk the issue through with the developer, show what damage has been caused to your company as a result of the developer's actions, and ask him to give his ...
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 this of it like this: you don't know if the opportunity will happen, so the risk is that it may or may not or that you ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
