20
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 ...
7
I firmly believe that risk should be communicated to the customer. Open communication and clear expectations can spell the difference between grave financial losses and an action plan for scenarios where the problems occur.
For instance, if the customer knows there is a chance that the project may be delivered with more than zero defects, and there is a ...
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
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
First, I like the idea of a risk board with the probability/impact axis. It can make the team more focused on the risks of the project and can create the desire to mitigate risks and thus pull them to the lower-left side of the board.
Now, I would add the following to the risk cards:
A unique ID for each of the risks, that can be used to identify them in ...
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
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 ...
5
In all of the larger programs I've worked on the customer requires, by contract, that risk analyses be reported to them on a regular basis. In addition to reporting a list of risks identified, the contractor reports on the mitigation plan, and status of the mitigation plan. The customer reviews and approves the mitigation plan or accepts risks.
If risk ...
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.
4
Generally speaking, not just around risks, I try to run as transparently as possible. What I know, my client will know; what I do not know, my client will know I do not know.
Like the WBS, you have an RBS. There are a ton of lower level risks with lower level impacts with which the client sponsor does not need to waste his/her time. I may withhold ...
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
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
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
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
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
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
If the project sponsor is the customer, it is imperative that he be informed about the risk. Only the project sponsor and / or the project board should have the ultimate authority as to whether to take the risk: the PM should only be the means by which the project is delivered within the environment that the sponsor has agreed.
If the customer is someone ...
3
Here's the problem I have with this concept - as the PM your job is to reduce, mitigate, or eliminate the risks. You're supposed to come up with a plan that will ensure the success of the project before you even start it. The reporting metric and examples you've used avoid all of this and imply that there's only a 50% chance of success before you even start.
...
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
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
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
