"We do not want the risk. The 3rd party must be accountable for this."
Repeat ad infinitum.
While it may look like that, dialog happens not because client representatives are dumb. It's because they are afraid. They have toxic corporate culture. It's not safe to fail or discuss possibility of failure. The usual, honestly. So they just want to have a chance to blame someone else and survive when everything goes south. And everything goes south quite often, because nobody is prepared, because issues are not discussed to say nothing about addressed.
Another fun red flag is vague definition of goals. Define goals as vague as possible to be able to report achieving them no matter what. For example I've seen a mobile application development company reporting success every quarter. It was logins, or downloads, or clicking some button. If your system is big enough, some metric grows compared to three months ago. The trick is to find that metric, report growth and get credit for good work.
Sometimes it's not. Sometimes it's just because they don't have to make themselves accountable for it because there will be no consequences - if it fails, you get to keep your current position and compensation but also if you succeed you also get to keep those without any gain. In these cases, not making yourself accountable is just the path of least resistance, and one could argue it's the right call for the individual in charge.
> Another fun red flag is vague definition of goals.
100%. I've been on clients where one of the criteria to determine success was "repeatability". When pressed to understand what that means, I could only get further vague and wildly abstract concepts. Nothing measurable, nothing even remotely helpful. Similar things happened for pretty much all other "requirements" we were given.
If you choose a 3rd party partner in the company I work for and that partner fails: it reflects badly on you, do it more than once and it can be pretty detrimental to your future inside the company.
You are responsible for the third parties you vouch for.
FWIW this is not ideology, this actually happened.
You have to know what you and others are optimizing for.
In big companies, it's rarely the success of the project. Usually it's a combination of keeping your job and growing your career.
Most big companies provide limited upside for success, and the downside risk is higher for the people. Consider:
1. The project is successful. You get a nice little bonus at the end, if anything. Maybe a promotion a year later.
2. The project is a failure and people can point part that you were responsible for. You get nothing, or worse, you're fired.
3. The project is a failure, but people can't point at you as the reponsible party. You keep your job, even get a small raise because you did your part.
Part of this is inevitable in my opinion, but organizations should really ask themselves what behavior they're incentivizing and rewarding, especially in a repeated fashion. If your people swing for the fences and miss -- what happens, and how does that compare to the people who bunt or stay on the bench?
First I would say most organizations aren’t optimizing for anything. They’re accounting constructs.
Second, however clumsily done, this is what equity incentives are supposed to achieve. The better you do, and its impact on the actual value of the company, the more your equity is worth. There are obvious problems in the model, but at least it’s slightly deeper thinking than the typical “you get paid don’t you?” model.
Wall Street, particularly front office revenue production, has very much a “you get paid proportional to the impact of your work” model. Often times when I worked in trading my total compensation could be many times my base salary (which while more than a teacher was less than say Amazon’s base salary). The problem though is the “impact” of one’s work can be manipulated by bias or short term acting, or worse what’s called trader option, where you take outsized risks assuming if it blows up and you get fired you can just work elsewhere, but if it doesn’t you make a lot more. But your firm carries the most risk because while your upside is uncapped your downside is capped - but your firms downside is not.
I would argue that what the author describes is not risk management. It's a CYA game. Risk management is a part of project management.
Real risk management identifies risk and defines mitigations to bring the risk down to an acceptable level. Passing the buck doesn't address the true risk; it only addresses the risk of who is accountable.
Imagine a scenario where you need a new water heater in your home. One of the risks is that a bad installation is that the water heater overpressurizes and blows up. Saying, "I hired a contractor to install it" doesn't mitigate that risk directly. The appropriate mitigation is installing a pressure-relief valve. Hiring a competent contractor can be a means to this end, but it's not a direct mitigation. If you hire a licensed contractor you may pass off the accountability risk but you aren't addressing the over-pressure risk. The client (and author) in this article are confusing what risks are being addressed.
Thanks for the feedback. I agree that risk management is a part of project management. What I, perhaps unclearly, was communicating is that people and organizations can often conflate the two. A project is not managed if all you've focused on are the risks. They are related, but distinct things.
Let's take your example and apply it to my post. Imagine I need a new water heater. I found a contractor/company to come and install it. Should I assume the installation company will bear all the risks associated with a potentially problematic installation? No, I will carry some risk. Ideally, I would argue homeowners should familiarize themselves with the basics of correct water heater products and installation because if it fails outside of the installer's (or manufacturer's) warranty period the homeowner is liable for repairs. It's a stretch of an example because homeowners often share risk with insurers, but I think my point is clear - one should not confuse project management _with_ risk management.
RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed. It is used for clarifying and defining roles and responsibilities in cross-functional or departmental projects and processes.
I wish more people briefly defined acronyms at first usage in a document.
I agree, but it's a hard balance to strike and depends on the writer's target audience. RACI is a pretty common acronym for anyone doing project management professionally. I'd not define REST, HTTP, etc; in an engineering doc.
For me an author disqualifies if there is an unnecessary use of jargon. In my experience the use jargon is often just a distraction from the fact that there is no thorough understanding of the subject.
> the project owner is always, in the end, responsible for the success of a project
This is very relevant to large government construction projects in the public-private partnership model (aka Alternative Financing and Procurement). These go best when the project sponsor (the gov’t) thinks clearly about what risks the private partner is best places to manage and transfers those risks to them (e.g. managing lots of construction sub trades), while retaining the risks that they are best placed to manage.
It becomes very expensive when the sponsor just tries to throw all the risk over the fence. As the author says, this gets expensive - either through change order or sometimes even in the upfront cost. If you pitch a risk to someone who is badly placed to manage it or who cannot quantify it upfront, they will cover their risk with a big fee.
You can shuffle the risk, but you can’t make it go away.
> This "accountability" exercise seems here to be viewed as: 'fix the blame in advance'.
That's not what "accountability" means. "Accountability" means "who has the ultimate say on what counts as success". In other words, the accountable person has to be a final decision maker: someone who has the authority to say "yes, the task is done" or "no, the task is not done".
That's why it doesn't make sense to put a 3rd party as accountable: they can't possibly be a final decision maker for your company. Someone in your company has to be the one to say whether the task is done or not.
In other words, the article's point is that viewing "accountability" as "who we'll blame if the task fails"--and thus being fine with saying "this 3rd party", as in "we'll just blame this 3rd party if the task fails"--is a bug, not a feature.
Companies will pay millions to offload liability. It can get pathological. I especially hate the scenario where you don't even have root or sudo on your own production servers and have to beg for logs and software installs.
That's going to basically force the company to move slower - it could be its demise. If you've got a chance, listen to Lex's recent interview with Jeff Bezos. They talk about two door/one door decisions and how companies should encourage anyone in a large company to take certain decisions without consulting the higher ups.
I've always seen risk management as essential to project management, not a separate concept. It's a way to manage expectations. The same work and results will get you a very different outcome if you managed risk and expectations from the start.
OP here. I think I did a poor job of communicating this exact point. I agree with you - risk management is a part of good project management. The point I was attempting to convey is when organizations consider projects (or project tasks) as managed when all they've done is shift risk without consideration of the ability to _actually_ accomplish said project/task. The myopic focus on risk can get in the way of _actual_ accomplishment.
What’s the point of explicitly assigning “accountability” to a client? They aren’t answerable to you so there’s no practical outcome to them being declared accountable. Why not just define the tasks they are responsible for and leave it at that?
At the end of the day, no matter which way you cut it, if you run a project you must be accountable for it, otherwise failure is certain. Even if you choose a 3rd party and get them to sign off on being accountable for delivery, it's you who chose them. It's much better to be explicit. Truly owning the project and being accountable for the outcome means you'll also be more honest with yourself. If there are hardships on the way, and there always are, you must work to figure it out, you can't roll it onto someone else.
We don't want the risk so we'll farm it out to another entity that ultimately has even less skin in the game. It boggles the mind that someone can make such a decision *and* stick with it. You'd think that at some point they'd come back down to earth.
P.E.R.T. was designed by smart people for smart people.
1. It colocates responsibility into time-bounded nodes
2. It offers concurrent redundancy to bypass high-risk teams
3. It may hide the global context from participants engaged in adversarial behavior
4. It decomposes into traditional project planning timelines for presentations
DevOPs/Agile is only good if your firm bills by the hour.
The paradox of cost optimizing labor for a fixed cost infrastructure investment often undermines the stated goal of a timely product launch. It is often not a risk mitigation decision, but rather a lack of respect for professional staff,
Most firms that needed the backbone resurrected almost always had a few overworked and underpaid staff that jumped to a better company before the IT debt came due.
You are probably thinking this is only for small firms, but even >$8B market cap firms fall into the same golden goose egg parable.
The mistake technical people make is assuming they could ever fix these political/structural issues with logic.
Well, you could try insurance/hedging. Then you either accomplish X or get your money back.
The risk of losing time remains though. If you want to lower that, you need redundancy: Outsource the project multiple times. That also costs multiple times as much though and still all of them might fail.
> The risk of losing time remains though. If you want to lower that, you need redundancy: Outsource the project multiple times. That also costs multiple times as much though and still all of them might fail.
If the task is impossible or the requirements are insane, sure.
You'll likely fail in all of those multiple times.
It is likely though that given enough bids,
Someone will find a loophole so they will be compliant to the letter of the requirements but not the spirit.
For example, you might say your software needs to run in a web browser and use standard/modern HTTP calls but you never specify it has to work on more than just windows so some vendor implemented the whole thing using xbap (silver light) and viola you can now use your stupid topaz signature input and your thermal check printers. But now the "website" works only on Windows.
But yeah if you give even a thousand different teams the task to create a time machine to go back in time, they'll all most likely fail.
Thinking from the "3rd party" perspective, how should they behave?
I often find myself
1. communicating the risks as transparently as possible
2. doing everything in our power to find solutions for things that have already gone wrong.
The more of the scope of services is handled by us as a 3rd party, the more emotional the discussions become when things go wrong in the end.
It certainly depends on the project. Depending on whether it is a one-off project or a project in which recurring value is generated. In the latter case, it is certainly easier to find solutions in this regard.
Here this is phrased at the project level, but the same sort of thing seems to be true of leadership roles. If you're leading something, no amount of delegation removes your accountability for it.
Projects aren't Fantasy Island. It's simply not reasonable to pretend something isn't true (i.e., you're accountable for your own projects) when it is. It's like saying, "The plane will fly because we're not going to believe in gravity anymore. Gravity is too inconvenient. Gravity be gone...".
Ultimately, this is a sign of poor management and leadership.
Hi! OP here. I didn't expect my first _real_ blog post to garner attention, so thank you! There's some great feedback here. I love the discussion around the topic, and I'll be sure to apply some of the community's feedback to my future posts.
I've found it (GPT4) to be quite good at analyzing situations where roles & responsibilities have become blurred. I've asked it for recommendations on how to approach delicate conversations with the people involved and it gave solid advice. It was also useful in brainstorming potential objections that might come from those people and effective responses to those objections.
Where I think this article goes a little wrong is the assumption that a RACI is about risk management. A RACI can tell you who is responsible for running the risk management process, but the R (responsible) and A (accountable), are not meant to move risk and absolve all others. They're just markers for "who is going to get this work done". They are about managing work, not managing the risks that can arise from that work.
Risk management is something a lot of people talk about, some people over-complicate, but few seem to do well.
I have an approach that is a mixture of agile and formal methods that is actually quite simple, and includes voices from lots of groups. I've done this on many dozens of software projects.
First of all there needs to be a list of risks. This list needs to be contributed to by all stake-holders, including third-parties responsible for any part of the delivery.
"We all agree these things could stop the project being successful".
Then you need to quantify the risks to prioritise them. The best way I've learned to do this is a number - between 1 and 10 - for "likelihood" and "impact".
A 10 on likelihood is "this is certainly going to happen", a 1 is "it very probably won't, but it could".
Impact is a bit more subjective, but a 10 is "if this happens, the project is guaranteed to fail and it's going to be awful", a 5 is "it would be pretty serious, but there are things that could happen to save the project despite it" and a 1 is "this probably doesn't matter".
Talk it through, everyone needs to agree these are sensible estimates.
"We all agree these are reasonable quantifications of the impact and likelihood of the risks".
Then multiply the two numbers. Low likelihood (2) but high impact (8) gets a score of 16. High likelihood (8), high impact (7), gets 56. Low on both (2 and 2), gets 4.
Order them. Start at the top scoring one. Figure out mitigations.
Mitigations are actions. They have dates by which they must be done, and owners who are accountable for those actions. They can include third-parties, but if they're not at the table, somebody with a contractual relationship with that third party who is at the table (say, the customer), is going to have to own the mitigation and be accountable for it.
Keep going until you get below a threshold (say, a score of 20), or you have eliminated anything above moderate score (say, 4), in either the likelihood or impact columns.
You've now got clear insight of what your risks are, quantified how important they are, identified mitigations and their owners and due dates, and can have regular conversations.
Mitigations could be rows in the RACI if they are strategic recurring processes or large items of work. But you can't just put it in there at the start and hope it gets managed, you need to actively manage to get it in there.
"We all agree these are the actions that will be taken, and by whom, and by when, to manage the risks we have agreed and prioritised together".
You will need to revisit this list - sometimes called a risk register - multiple times as the project progresses and you learn new things (agile isn't just for engineers).
This, I think anybody would agree, is project management.
I encountered a similar idea in a university project management course, which turned out to not be a completely waste of time, although I've forgotten most of the ideas. It was filled with useful ideas that I'd never encountered during my 10+ years on HN.
Let's compare the typical startup risk management strategy:
The project owner keeps all risks in their head, no formal tracking or acknowledging of risks. People mention risks and mostly go unheard; if the risk is low probability, it's excused, if a risk is high probability but low impact, it's excused. The project owner can't track too many things, so risks are dismissed rather than adding stress to the project owner who tracks it all in their head. If the project owner is feeling good and engaged, the project owner picks their favorite risk and then has a meeting and pressures people into dealing with it somehow. If the project owner is overwhelmed, just ignore the risks.
Good approach, very similar to the model I've used. A slight modification I make:
>A 10 on likelihood is "this is certainly going to happen", a 1 is "it very probably won't, but it could".
If something is guaranteed to happen it's no longer a risk, it's an issue, and then needs to be actively addressed to resolve it, starting by adding it to the Issues List. That effort is in contrast to efforts involved in mitigating the likelihood of a risk happening or its impact. E.g. it would likely justify reallocating resources to resolve the issue where, depending on the score of a particular risk, it might not. Also, in terms of reporting, issues are almost always reported to upper management regularly, whereas risks may not be.
Again, really good approach. I don't see risks managed explicitly enough, and I've been managing projects professionally for over 20 years.
This is a terrible post. The author conflates responsibility with accountability in a few ways. Most importantly, the long-established wisdom in project management is that (from the project perspective) responsibility can be shared, but accountability can not. The author suggests sharing accountability a few times.
Also, good project management is 90% good project risk management.
I wouldn’t want this guy manage my projects or do RACI for my projects.
Honestly this feels like so much crap. I refuse to believe any project can be planned more than one "phase" out - that is one technical person can sit down and say "yes I see how all the parts can be done and I could do it given time and nothing else". Ie the next step onto a stone across the pond.
Anything beyond that is what I call the zipper delusion - the idea that with enough planning we can move ahead like a zipper and all the parts, the third party deliverables just come together like a zipper.
Nah. A delusion brought on be looking back at a project and going "hey we did it" as opposed to remembering the hellscape accurately
Yes enormous projects are achieved, but it's not like it's a plan - we know we can lay a train track on land that's about 2% gradient (the technical next phase) but the bit that lays train track from New York to San Francisco is not a plan. And this sort of stuff where people
want third party risk offsetting and so on is much more "build train tracks over the State of ohio" - it's an adventure needing venture funding.
I think we would do much better stopping calling them plans and start calling them "ventures". You can be a venture manager for sure but stop asking for dates and deadline
So the real criteria for success for a project is "does this feel like Oppenheimer saying "we need to build a town in the middle of the desert for the worlds best scientists"? If so scale down your project or be very very sure your existence depends on not failing.
in constant search of homey analogies and metaphors - I would say plans that need to work like a zipper, are doomed to fail but plans that will work like a patchwork quilt, give usable results even from the first patch and are resilient to setbacks, and importantly can be industrialised - same patch fabric stitches can speed things up
Meh. Project management is all about risk management. This blog does not defuse that wisdom. This blog counters the (attempts to) mitigate the risk to third parties. I agree that is not a wise strategy.
adontz|2 years ago
Another fun red flag is vague definition of goals. Define goals as vague as possible to be able to report achieving them no matter what. For example I've seen a mobile application development company reporting success every quarter. It was logins, or downloads, or clicking some button. If your system is big enough, some metric grows compared to three months ago. The trick is to find that metric, report growth and get credit for good work.
cassianoleal|2 years ago
Sometimes it's not. Sometimes it's just because they don't have to make themselves accountable for it because there will be no consequences - if it fails, you get to keep your current position and compensation but also if you succeed you also get to keep those without any gain. In these cases, not making yourself accountable is just the path of least resistance, and one could argue it's the right call for the individual in charge.
> Another fun red flag is vague definition of goals.
100%. I've been on clients where one of the criteria to determine success was "repeatability". When pressed to understand what that means, I could only get further vague and wildly abstract concepts. Nothing measurable, nothing even remotely helpful. Similar things happened for pretty much all other "requirements" we were given.
hammock|2 years ago
Not just “moonshot” but “set 5 goals and you will be judged to succeed if you hit 3/5”
Or “set 5 goals and if you hit at least 80% of all 5, you get credit for making them all”
The concept is already known to sales orgs with quotas and OTE.
dijit|2 years ago
If you choose a 3rd party partner in the company I work for and that partner fails: it reflects badly on you, do it more than once and it can be pretty detrimental to your future inside the company.
You are responsible for the third parties you vouch for.
FWIW this is not ideology, this actually happened.
mindvirus|2 years ago
In big companies, it's rarely the success of the project. Usually it's a combination of keeping your job and growing your career.
Most big companies provide limited upside for success, and the downside risk is higher for the people. Consider:
1. The project is successful. You get a nice little bonus at the end, if anything. Maybe a promotion a year later.
2. The project is a failure and people can point part that you were responsible for. You get nothing, or worse, you're fired.
3. The project is a failure, but people can't point at you as the reponsible party. You keep your job, even get a small raise because you did your part.
Part of this is inevitable in my opinion, but organizations should really ask themselves what behavior they're incentivizing and rewarding, especially in a repeated fashion. If your people swing for the fences and miss -- what happens, and how does that compare to the people who bunt or stay on the bench?
fnordpiglet|2 years ago
Second, however clumsily done, this is what equity incentives are supposed to achieve. The better you do, and its impact on the actual value of the company, the more your equity is worth. There are obvious problems in the model, but at least it’s slightly deeper thinking than the typical “you get paid don’t you?” model.
Wall Street, particularly front office revenue production, has very much a “you get paid proportional to the impact of your work” model. Often times when I worked in trading my total compensation could be many times my base salary (which while more than a teacher was less than say Amazon’s base salary). The problem though is the “impact” of one’s work can be manipulated by bias or short term acting, or worse what’s called trader option, where you take outsized risks assuming if it blows up and you get fired you can just work elsewhere, but if it doesn’t you make a lot more. But your firm carries the most risk because while your upside is uncapped your downside is capped - but your firms downside is not.
bumby|2 years ago
Real risk management identifies risk and defines mitigations to bring the risk down to an acceptable level. Passing the buck doesn't address the true risk; it only addresses the risk of who is accountable.
Imagine a scenario where you need a new water heater in your home. One of the risks is that a bad installation is that the water heater overpressurizes and blows up. Saying, "I hired a contractor to install it" doesn't mitigate that risk directly. The appropriate mitigation is installing a pressure-relief valve. Hiring a competent contractor can be a means to this end, but it's not a direct mitigation. If you hire a licensed contractor you may pass off the accountability risk but you aren't addressing the over-pressure risk. The client (and author) in this article are confusing what risks are being addressed.
el0hel|2 years ago
Let's take your example and apply it to my post. Imagine I need a new water heater. I found a contractor/company to come and install it. Should I assume the installation company will bear all the risks associated with a potentially problematic installation? No, I will carry some risk. Ideally, I would argue homeowners should familiarize themselves with the basics of correct water heater products and installation because if it fails outside of the installer's (or manufacturer's) warranty period the homeowner is liable for repairs. It's a stretch of an example because homeowners often share risk with insurers, but I think my point is clear - one should not confuse project management _with_ risk management.
jes|2 years ago
RACI is an acronym derived from the four key responsibilities most typically used: responsible, accountable, consulted, and informed. It is used for clarifying and defining roles and responsibilities in cross-functional or departmental projects and processes.
I wish more people briefly defined acronyms at first usage in a document.
mhss|2 years ago
j-a-a-p|2 years ago
NoPicklez|2 years ago
Like another poster said, in an engineering doc they might not spell out what REST or HTTP stands for or means and that makes sense.
tamimio|2 years ago
ddkto|2 years ago
This is very relevant to large government construction projects in the public-private partnership model (aka Alternative Financing and Procurement). These go best when the project sponsor (the gov’t) thinks clearly about what risks the private partner is best places to manage and transfers those risks to them (e.g. managing lots of construction sub trades), while retaining the risks that they are best placed to manage.
It becomes very expensive when the sponsor just tries to throw all the risk over the fence. As the author says, this gets expensive - either through change order or sometimes even in the upfront cost. If you pitch a risk to someone who is badly placed to manage it or who cannot quantify it upfront, they will cover their risk with a big fee.
You can shuffle the risk, but you can’t make it go away.
unknown|2 years ago
[deleted]
toss1|2 years ago
There's a Japanese saying that I found useful:
"Fix the problem, not the blame."
This "accountability" exercise seems here to be viewed as: 'fix the blame in advance'.
Instead, the focus should be to identify the potential problems and reduce the risk that they will occur or mitigate the consequences.
"Accountability" should only be a tertiary tool to generate action to reduce risk or mitigate consequences.
pdonis|2 years ago
That's not what "accountability" means. "Accountability" means "who has the ultimate say on what counts as success". In other words, the accountable person has to be a final decision maker: someone who has the authority to say "yes, the task is done" or "no, the task is not done".
That's why it doesn't make sense to put a 3rd party as accountable: they can't possibly be a final decision maker for your company. Someone in your company has to be the one to say whether the task is done or not.
In other words, the article's point is that viewing "accountability" as "who we'll blame if the task fails"--and thus being fine with saying "this 3rd party", as in "we'll just blame this 3rd party if the task fails"--is a bug, not a feature.
Aeolun|2 years ago
Never mind that they invented that saying because they didn’t want to be held accountable either.
jacquesm|2 years ago
HenryBemis|2 years ago
jimmaswell|2 years ago
sgt|2 years ago
smitty1e|2 years ago
mhss|2 years ago
el0hel|2 years ago
layer8|2 years ago
yed|2 years ago
Etheryte|2 years ago
chiefalchemist|2 years ago
Joel_Mckay|2 years ago
1. It colocates responsibility into time-bounded nodes
2. It offers concurrent redundancy to bypass high-risk teams
3. It may hide the global context from participants engaged in adversarial behavior
4. It decomposes into traditional project planning timelines for presentations
DevOPs/Agile is only good if your firm bills by the hour.
The paradox of cost optimizing labor for a fixed cost infrastructure investment often undermines the stated goal of a timely product launch. It is often not a risk mitigation decision, but rather a lack of respect for professional staff,
Most firms that needed the backbone resurrected almost always had a few overworked and underpaid staff that jumped to a better company before the IT debt came due.
You are probably thinking this is only for small firms, but even >$8B market cap firms fall into the same golden goose egg parable.
The mistake technical people make is assuming they could ever fix these political/structural issues with logic.
Good luck, and a wonderful seasons greetings =)
qznc|2 years ago
The risk of losing time remains though. If you want to lower that, you need redundancy: Outsource the project multiple times. That also costs multiple times as much though and still all of them might fail.
mcny|2 years ago
If the task is impossible or the requirements are insane, sure. You'll likely fail in all of those multiple times. It is likely though that given enough bids, Someone will find a loophole so they will be compliant to the letter of the requirements but not the spirit.
For example, you might say your software needs to run in a web browser and use standard/modern HTTP calls but you never specify it has to work on more than just windows so some vendor implemented the whole thing using xbap (silver light) and viola you can now use your stupid topaz signature input and your thermal check printers. But now the "website" works only on Windows.
But yeah if you give even a thousand different teams the task to create a time machine to go back in time, they'll all most likely fail.
michibertel|2 years ago
Thinking from the "3rd party" perspective, how should they behave? I often find myself 1. communicating the risks as transparently as possible 2. doing everything in our power to find solutions for things that have already gone wrong.
The more of the scope of services is handled by us as a 3rd party, the more emotional the discussions become when things go wrong in the end.
It certainly depends on the project. Depending on whether it is a one-off project or a project in which recurring value is generated. In the latter case, it is certainly easier to find solutions in this regard.
lars512|2 years ago
chiefalchemist|2 years ago
Ultimately, this is a sign of poor management and leadership.
el0hel|2 years ago
jcims|2 years ago
It provided some really good analysis and recommendations.
maroonblazer|2 years ago
BOOSTERHIDROGEN|2 years ago
nitwit005|2 years ago
PaulRobinson|2 years ago
Risk management is something a lot of people talk about, some people over-complicate, but few seem to do well.
I have an approach that is a mixture of agile and formal methods that is actually quite simple, and includes voices from lots of groups. I've done this on many dozens of software projects.
First of all there needs to be a list of risks. This list needs to be contributed to by all stake-holders, including third-parties responsible for any part of the delivery.
"We all agree these things could stop the project being successful".
Then you need to quantify the risks to prioritise them. The best way I've learned to do this is a number - between 1 and 10 - for "likelihood" and "impact".
A 10 on likelihood is "this is certainly going to happen", a 1 is "it very probably won't, but it could".
Impact is a bit more subjective, but a 10 is "if this happens, the project is guaranteed to fail and it's going to be awful", a 5 is "it would be pretty serious, but there are things that could happen to save the project despite it" and a 1 is "this probably doesn't matter".
Talk it through, everyone needs to agree these are sensible estimates.
"We all agree these are reasonable quantifications of the impact and likelihood of the risks".
Then multiply the two numbers. Low likelihood (2) but high impact (8) gets a score of 16. High likelihood (8), high impact (7), gets 56. Low on both (2 and 2), gets 4.
Order them. Start at the top scoring one. Figure out mitigations.
Mitigations are actions. They have dates by which they must be done, and owners who are accountable for those actions. They can include third-parties, but if they're not at the table, somebody with a contractual relationship with that third party who is at the table (say, the customer), is going to have to own the mitigation and be accountable for it.
Keep going until you get below a threshold (say, a score of 20), or you have eliminated anything above moderate score (say, 4), in either the likelihood or impact columns.
You've now got clear insight of what your risks are, quantified how important they are, identified mitigations and their owners and due dates, and can have regular conversations.
Mitigations could be rows in the RACI if they are strategic recurring processes or large items of work. But you can't just put it in there at the start and hope it gets managed, you need to actively manage to get it in there.
"We all agree these are the actions that will be taken, and by whom, and by when, to manage the risks we have agreed and prioritised together".
You will need to revisit this list - sometimes called a risk register - multiple times as the project progresses and you learn new things (agile isn't just for engineers).
This, I think anybody would agree, is project management.
Buttons840|2 years ago
Let's compare the typical startup risk management strategy:
The project owner keeps all risks in their head, no formal tracking or acknowledging of risks. People mention risks and mostly go unheard; if the risk is low probability, it's excused, if a risk is high probability but low impact, it's excused. The project owner can't track too many things, so risks are dismissed rather than adding stress to the project owner who tracks it all in their head. If the project owner is feeling good and engaged, the project owner picks their favorite risk and then has a meeting and pressures people into dealing with it somehow. If the project owner is overwhelmed, just ignore the risks.
maroonblazer|2 years ago
>A 10 on likelihood is "this is certainly going to happen", a 1 is "it very probably won't, but it could".
If something is guaranteed to happen it's no longer a risk, it's an issue, and then needs to be actively addressed to resolve it, starting by adding it to the Issues List. That effort is in contrast to efforts involved in mitigating the likelihood of a risk happening or its impact. E.g. it would likely justify reallocating resources to resolve the issue where, depending on the score of a particular risk, it might not. Also, in terms of reporting, issues are almost always reported to upper management regularly, whereas risks may not be.
Again, really good approach. I don't see risks managed explicitly enough, and I've been managing projects professionally for over 20 years.
BOOSTERHIDROGEN|2 years ago
BobMortimer|2 years ago
Also, good project management is 90% good project risk management.
I wouldn’t want this guy manage my projects or do RACI for my projects.
lifeisstillgood|2 years ago
Anything beyond that is what I call the zipper delusion - the idea that with enough planning we can move ahead like a zipper and all the parts, the third party deliverables just come together like a zipper.
Nah. A delusion brought on be looking back at a project and going "hey we did it" as opposed to remembering the hellscape accurately
Yes enormous projects are achieved, but it's not like it's a plan - we know we can lay a train track on land that's about 2% gradient (the technical next phase) but the bit that lays train track from New York to San Francisco is not a plan. And this sort of stuff where people want third party risk offsetting and so on is much more "build train tracks over the State of ohio" - it's an adventure needing venture funding.
I think we would do much better stopping calling them plans and start calling them "ventures". You can be a venture manager for sure but stop asking for dates and deadline
So the real criteria for success for a project is "does this feel like Oppenheimer saying "we need to build a town in the middle of the desert for the worlds best scientists"? If so scale down your project or be very very sure your existence depends on not failing.
unknown|2 years ago
[deleted]
lifeisstillgood|2 years ago
j-a-a-p|2 years ago