"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.
> 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.
> 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.
At times, people are very insistent on doing the wrong thing. At a certain point as an employee, you have to shrug your shoulders and do what they ask. It's their company.
How can it be fear of loss when there's absolutely no risk of loss?
> Economic stability or the loss of is a primary driver of productivity in our society
Precisely the point I was making.
Generally people don't care about the corporations they work for, so the only motivation to be better is the possibility of better outcomes for them as individuals - or in some cases, to avoid losing what they have (best performers in theory have a better chance to survive a layoff). Note that I'm not making any judgement on whether this is the best way of motivating people - only that it's the one we currently have.
If there's no risk of loss and no recompense to win (i.e. the only possible outcome is to stay exactly where you are regardless of how much or how little effort and accountability you put in the project) doing as little as possible and taking no accountability is just inertia - it's not moved by fear.
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.
>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.
That assumes that the three "easiest" goals have known, straightforward, guaranteed ways of attaining them. Naturally there will be some uncertainty, some extrinsic factors, some good and bad luck that will get in that way of any of the goals, so ignoring two goals entirely all year risks that you catch some bad luck on one of your 3 "easiest" goals and don't end up hitting all of them.
>Or if you only need to hit 80% of each, to go for all low-hanging fruit until hitting 80%, then shift focus.
If you need to hit 3/5 you need to set the goals so that they are easy enough to surely succeed. Maybe you fail two to make them look hard, after you know you passed three.
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.
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.
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...
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 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.
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.
It's a good blog post and highlights a real issue. As discussed well in this thread, there may be incentives that make PMs weigh certain risks higher, but I'm struggling to come up with a project manager task that isn't, in some way or another, about managing risk. I would be curious if you have specific examples you're thinking of. I agree with you in terms of many people conflating the two; i.e., they pretend they've mitigated a risk but all they've done is pass the buck. As you point out, they've confused themselves about what risk management really is.
Regarding the extension of the water heater example, I get what you're aiming at, but I'm not sure I agree. I deliberately used the term "licensed" because that is a risk management mechanism. Credentials and legal structures are a way we can manage risk. In this case, a license is a mechanism to ensure the work is insured in case it's done incorrectly. A bonded contract is another mechanism that mitigates the risk that the contractor won't complete the work. An inspector is a mechanism to manage the risk that the installation wasn't performed to code. None of these require me to know about mechanical systems, or hoop stress vs. longitudinal stress, or any other design elements. Now I agree on a simple example, this may be stretching the analogy. But when we get to really complex projects, I don't think it's entirely reasonable for a PM to be familiar with the aspects to that degree. Of course it's preferential, but on some projects I've been a part of, it's all but impossible for a PM to be knowledgable about control theory, and environmental compliance, and aerodynamics, and material science, and contract law etc. to a sufficient degree to manage the risk themselves. That's why they have systems engineers, codes, inspectors, and quality assurance plans, etc. These are the frameworks for 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.
Details can be hard, even if small. Don't get me wrong, I try to do it myself every time I write, but I often find myself wondering if it's worth to link to a definition or will it be too obvious and come across as condescending. Maybe is just me.
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.
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.
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.
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.
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.
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.
> 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?
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?
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.
It's long gone, nothing special, just uploaded a screenshot of the raci as it was being edited in a spreadsheet. Then just explained the context and the teams listed.
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.
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.
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
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.
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.