3

I'm an individual contributor in a company where our 'deliverables' are ultimately an information product that goes out to a customer. There is a kind of "assembly line" in the process of creating the product, in that it involves a lot of sequential processes and obtaining things from 3rd parties to integrate into the product, etc. It's not really important to the question what the specific product is, so I didn't want to make it too identifiable.

What is significant though is that the deliverable/product makes up a large proportion of the company's revenue, so it isn't just a silly small item on a budget somewhere that can be missed without anyone noticing.

We've been plagued in the past with delays and hiccups on the way to producing the deliverables, which perhaps you might expect to be the case with so many moving parts and dependencies. (Anyone who has worked in IT or in project management will no doubt understand this!)

The problem though is that management don't seem to learn from this that we need contingency plans, backups (e.g. for key people), "what if" scenarios, etc. The culture seems to be just using 'hope' as a strategy, or making unquestioning assumptions about 3rd party delivery dates, etc. Some of the examples of this I've experienced are:

  • Key person dependency

We identified a key man (bus factor) risk on a major stream of client work, after layoffs and attrition (people leaving and not being replaced due to 'cost cutting' exercises..), highlighted it and asked "what if something happens to John or he leaves us to go to Company X" (Company X was recruiting a lot of our people at the time, but short of 'poaching'). The management response was essentially "hmm... we have to hope that doesn't happen as we don't really have a plan for that!"

  • Reliance on vaporware

We were integrating with a 3rd party software system (think of a component of Azure or AWS for example) which was in "beta preview" at the time and needed to be fully released in order for us to use it for the client deliverable. It was due to be made 'general release' in October, our deliverable was due in December. Of course October wasn't guaranteed and there was legal language supporting the right to delay it (or scrap it) etc. There were still a number of significant bugs with that software at that point and we thought October may or may not happen. When we raised it we just got "they're still stating October so that's what we have to work to"...

  • Assuming upstream 3rd parties are infallible

We were dependent on a 3rd party (different company) to complete a particular piece of work that is "upstream" of ours. They had done this work for us before, generally with good quality but sometimes missing deadlines. In the past, with a missed deadline situation we did meet our own deadline through imposing "crunch time" of 70-80 hour weeks to catch up and eventually a couple of all-nighters, I heard off the record that HR were not too impressed and 'had words' about Working Time Regulations etc. So if this delay happens again we don't have that option any more (although I would probably just do it "off the record" once to get it done!) ...

About 2 weeks before we were due to receive the work we hadn't heard anything out of the 3rd party (good or bad) and asked whether we could check with them that they were still 'on track' or if not, come up with an alternative plan. We were told that we shouldn't interfere in the "vendor relationship" and that we should assume the date we're working to will be met, as they haven't communicated otherwise. Which might be ok if we didn't have the precedent that they got delayed before and didn't communicate until the day it was due, and then because we asked where it was!

Problem

The instances above are a few examples of the kind of "hope as a strategy", "assume everything will work out" and no contingency planning I am up against.

Whenever someone brings up the idea that something might go wrong or we need a Plan B in reserve etc - they get criticised for being too negative, looking for things to go wrong, 'it seems almost as if you are hoping for failure', being "hysterical", etc. I don't know what the motivation is for management to think like this, especially as it seems to be endemic (rather than just a quirk of one particular manager). It seems almost like a kind of learned helplessness.

Questions:

Longer term, Can a situation like this be salvaged, if so, what sort of approach should I take to try and get it to change? (I don't have the financial details to be able to quantify it in number of $$$s lost, other than to be able to say it is "a lot"!)

In the moment, What should my response be to an answer like "we just have to assume the 3rd party will deliver it on time unless they say otherwise" (when history is against them)?

3
  • IMO it's basically a consequence of the somewhat dysfunctional fact that a faint hope of success / on-time completion is counted as higher present value, than admitting there was a mistake in planning. This is sadly common across the full spectrum, up to $100B companies that are global leaders in dozens of markets. Very hard to fight this openly, though savvy planners will account for it and/or conceal the mitigations to get them in place.
    – Pete W
    Commented Apr 16, 2021 at 18:14
  • 2
    PS - By volunteering 70 hour weeks to make up for someone else's unrealistic planning, you're enabling the continuation of the problem, because the unrealistically-hopeful planners can expect you to save them.
    – Pete W
    Commented Apr 16, 2021 at 19:14
  • 1
    @PeteW, I agree. Usually such people recognise that effective planning is hard work up front, and they are the kind of person who is always looking for the path of least resistance in the short term. When large chaotic workloads ensue, the same short-term strategy is attempted applied again, and they look to drag more people into an agenda of quick but ineffective fixes (and disrupt those people's own effective patterns of work). One must be careful to distinguish between responsible colleagues who need help to recover in an emergency, and those who are merely trying to spread their own chaos.
    – Steve
    Commented Apr 17, 2021 at 9:24

2 Answers 2

4

What should my response be to an answer like "we just have to assume the 3rd party will deliver it on time unless they say otherwise" (when history is against them)?

It sounds like the concerns have already been brought up so idk that there is much you can do at this point. Document the fact that these concerns have been raised so that if shit hits the fan you can cover yourself but beyond that you've done about as much as you can realistically be expected to do (short of going over your managers head, which I wouldn't recommend).

At some point, shit probably will hit the fan, and when it does, that's when changes will be made. That's usually how these things happen.

For example, during the 2021 Texas power crisis inadequately winterized natural gas equipment caused power outages but it wasn't until after the crisis that people seriously started talking about it.

Failure of imagination seems like a closely related concept.

I hate to say it but I think there can sometimes be an element of pragmaticism to this too. Trying to proactively safeguard yourself against all possible scenarios can be hugely expensive. What happens if the language you're developing your app end ceases to be maintained? It might be nice to have two identical copies of the app in different languages but then you double your staffing expenses.

2

I have run a company of 11 people, and at that size there are times when hope is the only strategy you have. You're building something on a huge company's beta, if they don't ship when they said they would, your project (and its revenue) will be late. Nothing you can do about it. Planning and promising not to ship until say February may reduce the chances of an embarrassing schedule slip, but it doesn't get you December revenue, which is the real problem. The cost of building it against two different things, or of waiting till things are released to build on them, may be too much for a company of this size. They may not like "we have to count on our vendor" but what other option is there?

That doesn't mean it's always the right strategy. In the case of the key worker, it may be appropriate to train others to take over. It isn't always, because somebody has to pay those others a salary to learn the key worker's job instead of what they would otherwise be doing, and the key worker may lose time explaining or documenting or correcting when they get it wrong, and on top of that may not like cross training people. The cost of making sure there is someone to take over may be too high. Or, it may not. I can't tell from outside.

In a huge enterprise, there is more "slack." I've been on projects, skunk works we used to call them, almost entirely populated by people who are employed full time by the enterprise, but don't have anything to do right now because their project was cancelled or their new project had a delayed start or folks are just more efficient than expected so they have some free time. (And not in the distant past either; I know of one underway right now at a company you've heard of. They're normal.) Cash flow is less of an issue, so you can do things like start the project when you expect general availability, so Plan B is develop on the beta, and release a few months after GA was expected, so plan B is you release just after GA happens late. Small companies can't do these things.

What I don't see in your question is whether any of these "hopes" turned out to be wrong. Was anything late? What happened when it was? Did things work out ok, did everyone get paid in the end? Do the customers understand that "we were building your thing on the latest Microsoft/Google/Apple/Amazon goodness, and as you no doubt saw on the news they are going to be late, so we'll be late too"? Often they do. It's great to be able to predict trouble, especially when there's something you can do to minimize it in advance. But constantly worrying about things that don't happen, or that happen and are pretty harmless in the end, or that you can't prepare for or mitigate, doesn't help anyone.

If you have the cycles, you could offer to make a plan for one of these worries -- the one that would hurt the most, or is most likely -- and write it up for them. Pros and cons, including emotional ones like "people don't like unpaid overtime" or "it's embarrassing to be late even when its not our fault" along with actual costs like losing a month's revenue or having to pay a typical recruiter commission, would be part of this. Maybe when you write up the plan you'll realize the company can't afford it or the costs are more than what you're trying to prevent. That should make you feel better about the strategy management is using now. Or, maybe it's obvious it's the right thing to do: you can present it to them so that they can see that too.

You could then move on to the next worry, either reassuring yourself, persuading management with actual plans, numbers, and thinking that they should act, or realize you need to work somewhere else. I expect any of those would be better than the frustration you're feeling at the moment. I'm cheering for #2 myself: as an overworked owner trying to keep everyone paid and sell enough work and prevent delays so that I would get some paycheque too, I would love a well thought out disaster-prevention plan and would, if it made sense, follow it, even if I hadn't been able to make that plan myself while busy trying to steer the ship.

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .