Risk management is not project management
mattrucker.com
mattrucker.com
"We do not want the risk. The 3rd party must be accountable for this."
Repeat ad infinitum.
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.
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.
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.
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
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 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.
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...
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.
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.
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.
Does that sound so bad, if it's by design?
Not at all. Just important to keep in mind when setting those goals.
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?
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.
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...
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.
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.
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.
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.
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.
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.
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.
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.
Never mind that they invented that saying because they didn’t want to be held accountable either.
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.
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.
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?
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 =)
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.
Ultimately, this is a sign of poor management and leadership.
It provided some really good analysis and recommendations.
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.
>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.
It's a matter of definitions, but something that is certain to happen being a "risk" seems reasonable.
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.
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.
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.