[HN Gopher] Risk management is not project management
___________________________________________________________________
Risk management is not project management
Author : el0hel
Score : 130 points
Date : 2023-12-15 16:57 UTC (2 days ago)
(HTM) web link (mattrucker.com)
(TXT) w3m dump (mattrucker.com)
| Etheryte wrote:
| 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.
| chiefalchemist wrote:
| 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.
| jacquesm wrote:
| This is because often the perception is that it works. Even
| the GDPR contains some subtle mistakes. In the case of a
| breach it is the controller that is responsible for reporting
| the breach to the DPA of the country where they reside, but
| it is the _processor_ that usually becomes aware of the
| breach. So processors that don 't report breaches to their
| customers are giving plausible deniability to the controllers
| they work with that everything was just fine.
|
| This is very frustrating because it is obviously not how
| things are intended to work but that's how less savory
| characters interpret it and so far they are getting away with
| it in most cases. The result is a whole slew of breaches
| being wiped under the carpet.
| chiefalchemist wrote:
| > This is because often the perception is that it works.
|
| Yes. But how can this idea persist? I mean one of life's
| basic rules is: No one care more about you than you. To
| pretend otherwise is silly. At a company level (read:
| bebolden to shareholders) its borderline negligent.
|
| Wishful thinking worked in kindergarten. It's not something
| working adults should be embracing so strongly. Right?
| jacquesm wrote:
| Well, yes, right, but that doesn't seem to stop anybody.
| I even see this sort of stuff in the boardrooms of
| companies that should know better. I don't know what
| drives it, maybe some sense of reinforcement from getting
| away with similar stuff in the past?
| qznc wrote:
| 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.
| mcny wrote:
| > 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.
| chiefalchemist wrote:
| 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.
| jacquesm wrote:
| You can outsource the work, you can _never_ outsource the
| responsibility.
| HenryBemis wrote:
| You can outsource the Responsibility but you can never
| outsource the Accountability.
| anonexpat wrote:
| Sure you can! Consultants/contractors are hired for that all
| the time.
| avensec wrote:
| Point well made, but I think they were trying to correct
| the usage of Responsibility. Responsible = Who does the
| work, which, of course you can outsource.
| cpeterso wrote:
| Exactly. This blog post is really about the difference
| between "Responsible" and "Accountable" in a RACI. I
| jokingly define RACI's R and A as the person who "Really
| does the work" and the person whose "Ass in on the line"
| when the project fails.
| cj wrote:
| Whoever hired and oversees the consultant is accountable
| for their work.
|
| Who do people point at when the consultant drops the ball
| on their responsibility? The person overseeing the
| consultant. Meaning the person overseeing is ultimately
| accountable even if they aren't doing the work.
|
| These nuances are important in project management.
| adontz wrote:
| "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.
| cassianoleal wrote:
| > It's because they are afraid.
|
| 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.
| sshine wrote:
| > _not making yourself accountable is just the path of least
| resistance, and one could argue it 's the right call_
|
| I've been frustrated with colleagues who would just do their
| job to a point of a project critically failing. But in
| retrospect, I must say they did the right thing.
|
| Taking heat as an employee should be voluntary, and it should
| be compensated, and it usually isn't.
|
| When you see an employee just doing their job, when a lot
| more is needed, you can trace it to a spineless leader who
| does not lead by example.
| ryandrake wrote:
| > Taking heat as an employee should be voluntary, and it
| should be compensated, and it usually isn't.
|
| It must be compensated! At the vast, vast majority of
| companies, the worker bees' compensation is multiple orders
| of magnitude lower than leadership's. Why should they
| shoulder the accountability? When you question these
| stratospheric executive compensations, one of the retorts
| is always "Well, they are responsible and accountable so
| that's why they're paid so much."
|
| Don't feel frustrated with a colleague who doesn't get
| fired when the project fails. Get frustrated with the
| executive leader 4 notches up on the totem pole _who makes
| $10M /yr for "being responsible"_, who gets a bonus when
| the project fails.
| lotsOstuf wrote:
| > if it fails, you get to keep your current position and
| compensation
|
| Sounds driven by fear of loss
|
| Human emotions do not have an infinite range unlike our human
| languages.
|
| Economic stability or the loss of is a primary driver of
| productivity in our society
| dijit wrote:
| that's ironic.
|
| 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.
| MattGaiser wrote:
| Only if the third party need vouching for.
|
| IBM survives in large part because they are a third party you
| can hire without really putting your own neck out there as
| the biz folks trust them.
|
| At a prior job it was CGI. CGI got a ton of work as when they
| failed, the lower level people didn't get blamed. Any other
| vendor would have led to the negative reflection you
| mentioned.
| dijit wrote:
| Depends, my CFO got a _lot_ of flak for choosing to use PwC
| when it turned out they couldn 't deliver.
|
| PwC was seen by him to be the safe choice because they were
| so large and essentially industry standard. He got flak
| because he didn't do appropriate due diligence. That was
| his job, so...
| pas wrote:
| and, did it materially change his career advancement,
| promotion, labor market prospects, etc?
| dijit wrote:
| Yes
| MattGaiser wrote:
| I don't want to jump on a man's career, but that is a
| step in a more competitive direction.
| cvalka wrote:
| If a CFO chooses PwC, 98% of the time they should be
| fired.
| hammock wrote:
| What if managers asked people to set goals with the explicit
| expectation of failure?
|
| 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.
| halgir wrote:
| If you have five different goals and only need to hit three
| of them, you're incentivized to focus all efforts on the
| three easiest ones, and ignore the other two entirely. Or if
| you only need to hit 80% of each, to go for all low-hanging
| fruit until hitting 80%, then shift focus.
|
| Non-cynical colleagues will act in as much good faith as they
| believe the manager is doing when setting the goals. But
| Goodhart's law lurks everywhere.
| PaulRobinson wrote:
| 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.
| BOOSTERHIDROGEN wrote:
| would like to know more about risks, any books you could
| suggest ? thanks.
| peacemaker179 wrote:
| The basic idea is discussed in the 1991 paper from Barry
| Boehm, who also developed the spiral model. This is probably
| a good start, since it's an easy read and fairly short. Some
| newer papers tried to research this topic further using
| empirical data, but n is usually pretty small and data is
| usually derived from interviews, rather than direct data from
| projects. I don't think there are any recent books on
| software development risks, usually it's just a sub chapter
| in software engineering books
| BOOSTERHIDROGEN wrote:
| Interesting, so risks inherently not changing pretty much,
| we all human after all, cheers.
| maroonblazer wrote:
| 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.
| Buttons840 wrote:
| What about something that will certainly happen, but happens
| probabalistically? You may not know enough to treat it as an
| "issue" even though you know "something" of the type will
| happen eventually.
|
| It's a matter of definitions, but something that is certain
| to happen being a "risk" seems reasonable.
| Buttons840 wrote:
| 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.
| smitty1e wrote:
| If you're the Commanding Officer of the ship, and you bring on a
| qualified Pilot for a tricky mooring in a harbor, it's still
| _your_ ship.
| jcims wrote:
| Odd side note. I asked chat gpt for feedback on the screenshot of
| a RACI and added some color on the parties involved and the scope
| of work.
|
| It provided some really good analysis and recommendations.
| maroonblazer wrote:
| 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.
| BOOSTERHIDROGEN wrote:
| Mind share your prompt and the output, thanks.
| ddkto wrote:
| > 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.
| lifeisstillgood wrote:
| 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.
| lifeisstillgood wrote:
| 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
| mindvirus wrote:
| 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?
| fnordpiglet wrote:
| 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.
| p_l wrote:
| However, even being on a possibly company-critical project
| means little to value of one's equity, especially post-IPO.
|
| There's little to no rationality involved in pricing of
| public shares, and nothing you do as individual contributor
| has any impact.
|
| Now, if you were a high level manager and could order a
| layoff...
| mindvirus wrote:
| I meant what the people are optimizing for. However, even
| equity has its faults: equity has to vest for it to be worth
| anything (and later, be exercised for strike + AMT). The
| expected value of impact could be high, but if they have a
| higher chance of getting fired and losing their unvested
| equity, they might not. Many people are risk adverse - for
| example, would you pay $100k for a 25% chance to win $1
| million? Entrepreneurs might say heck yeah, but most
| employees wouldn't.
|
| I think incentives are part of the solution, but culture is
| the other part. The organizations views toward risks and
| failure are going to shape how people place their bets in
| their career.
| toss1 wrote:
| This entire exercise seems wrong, or at best, incomplete.
|
| 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 wrote:
| _> 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.
| jes wrote:
| Wasn't familiar with RACI acronym:
|
| _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 wrote:
| 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.
| spc476 wrote:
| How hard is it to use <abbr title="...">?
| j-a-a-p wrote:
| 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.
| bumby wrote:
| 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.
| Joel_Mckay wrote:
| 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.
|
| Good luck, and a wonderful seasons greetings =)
| lars512 wrote:
| 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.
| mhss wrote:
| 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.
| layer8 wrote:
| It is. The article isn't really talking about actual risk
| management, as far as I can see.
| jimmaswell wrote:
| 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.
| sgt wrote:
| 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.
| michibertel wrote:
| Great Blog Post!
|
| 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.
| j-a-a-p wrote:
| 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.
| yed wrote:
| 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?
___________________________________________________________________
(page generated 2023-12-17 23:01 UTC)