Every business process secretly wants to fail

Raymond

Business processes ensure uniformity and help catch errors. The people who created the process did so with the most noble of intentions, but secretly, every process subconsciously wants to fail. It just doesn’t know it yet.

I got a bug saying that my widget does not meet XYZ requirements, and it contains a link on how to fix it. The instructions tell me to visit the XYZ dashboard on an internal Web site and gives me step-by-step instructions on what to do to fix the problem.

Step 10 tells me to click a button that is disabled.

There is a message next to the button that says, “Your widget does not meet the requirements for this button. Review this link for information on how to fix this issue.” The link takes me back to the instructions. The one that told me to click the disabled button.

So I’ve come full circle.

The page also says “Problems found: Widget dcd0ae46937a has a doodad without an impact statement.” (Repeat for three more widgets.) Those widgets are not my widget. I don’t know why it cares about those widgets. There is also no way to search for those widgets.

It occurs to me that I can find widget dcd0ae46937a by URL hacking. It has one doodad, and there is an impact statement for it.

Now stuck, I email the team that manages the Web page for help. One of the team members replies, “Oh, I checked (unrelated web site) and found that widget dcd0ae46937a inherited doodads from its parent, and it’s those doodads that don’t have impact statements.”

Okay, I contact owner of the parent widget, and they fill out impact statements for the inherited doodads.

I go back to the XYZ dashboard, and my widget has disappeared!

I ask the team what happened to my widget. No answer, but after a few days, it reappears, so must have been some sort of glitch.

I go through the instructions again, and once again, I get stuck at step 10 because the button is still disabled.

I URL hack my way into the other three widgets. I enter an impact statement for the doodad. I click “Save changes”. I get spinning dots.

I wait ten minutes. The dots are still spinning.

I open a new tab, go to the page. Oh, the impact statement was saved okay. It’s just that the “Save” button is broken.

All right, now that the doodad is fixed, I go back to my widget. Finally, the button is enabled, so I click it. I am asked whether my widget conforms to “Contoso quality guidelines”.

There is no link to the Contoso quality guidelines.

I ask the team where I can find the Contoso quality guidelines. They send me a link to the original page of instructions.

I’ve come full circle a second time.

I tell them, “Yes, I followed all those steps. I had to, because if I didn’t, the button is disabled. So why is it asking me whether I did something that the page already validates on its own?”

They say, “Oh, maybe that’s not the Contoso quality guidelines after all. Try this page.” They send me a link to the “Fabrikam quality guidelines. Fabrikam is a subsidiary of Contoso, or the parent company of Contoso, or something like that.

The Fabrikam quality guidelines document says, “To check if your widget meets quality guidelines, search for it in the quality report on web site Q.” Web site Q doesn’t exist. I find that web site Q was decommissioned and replace with web site Q2. Web site Q2 also doesn’t exist. Because Q2 was decommissioned and replaced with Web site Q3. Web site Q3 does not have quality reports.

The quality guidelines say, “You can also look at the Maelstrom report on quality guidelines, on web site Q.” Okay, so another link to the twice-dead web site. And of course, Q3 doesn’t have the Maelstrom report either.

Okay, well the next section of the quality guidelines show how to perform the quality check manually. So now I’m going through all the manual steps. Finally got to step 12 of 15. This says, “The widget must be registered in the widget catalog. To check if it is registered, please check web site W.” Web site W also does not exist.

So that’s where I am. We’ll see what the XYZ team says for this.

It’s taken a month to get this far, and I still cannot get my widget to meet XYZ requirements.

Every process secretly wishes to fail.

The kicker is that I don’t even care about this widget! Another team created the widget, and they are the ones who use the doodads in the widget, but ownership of the widget got transferred to me because I took over the component that contains the widget. So I’m on the hook for getting the widget to meet XYZ requirements, even though I personally would be fine with just deleting the widget.

Epilogue: The team that created the widget originally did some investigation and concluded that they aren’t using it after all. They told me that it’s okay to delete it.

Bonus chatter: That every business process secretly wants to fail is another example of Le Chatelier’s Principle for complex systems: Every complex system resists its proper functioning. I learned this and many other valuable lessons from the book Systemantics, which I wholeheartedly endorse.

Previously: Le Chatelier’s Principle as applied to announcements and administrative overrides.

10 comments

Comments are closed. Login to edit/delete your existing comments

  • Mike Morrison

    Bonus points if, when you you get to a functioning website, it was written for IE5 and is horribly broken by default in any browser written after, say, 2001. IE5 compat mode in IE mode within Edge gets you a somewhat functional site, but it fails at the last step, and you lose all of your work in the webform. And this is in the internal web site for the corporate process standards documents, so you can’t even sign off that you’ve read and understood the document (the one that outlines the utterly broken process).

  • Mike Morrison

    On the subject of useless automated email announcements: my company some time ago changed over to a new defect tracking system, which is awesome. It works in modernd-day browers and is objectively better to use for searching for defects and collaboration. But it has the terrible habit of sending out email blasts for EACH change made to a defect. If I update three related fields in a defect, that’s three emails. Forget about having a daily digest of changes, such as a nightly list of defects updated in the last day; no, that’s not enough email spam for this system. The result is that all of those emails get shunted to a folder, one that I rarely check, and I’ve spoken with many people on the team who do the same in their own ways. So we have yet another system for automated emails that get auto-ignored or deleted.

  • Antonio Rodríguez

    Problems with Win16 compatibility? Just wait until everybody’s on Win64, and the problem will solve itself! Win32 problems can be solved this way, too; but please be patient: Win128 still doesn’t have a launch date…

  • Roger B

    Every time I have to go through an absolutely “critical and mandatory” process that was kicked off by some automated compliance tool, I can guarantee you my experience has been like I was the very first person to ever attempt it. Completely broken and soul crushing. I used to care about the things it was asking because I was naive and believed it really was critical and mandatory, but I can without a doubt say that’s not the case.

  • Dave Gzorple

    This is why you lie… uhh, massage the truth. No-one actually cares whether your wossname meets the whatsit requirements, they just want to see a ticked checkbox. For all intents and purposes, no human ever checks any of this stuff, and on the remote chance they do all you’ll get is a note to fill the form or whatever out properly in future (my best response was an amused “you’ve been using this same no-op response for years, you really should update it at some point”). I’ve been using this for years for paperwork-production exercises, just invent something plausible and put it in there.

    I found this out years ago when I was filling out a form justifying an over-the-limit equipment purchase, because of some glitch in the 3270 (which tells you how long ago it was) the details were never filled out and half the form was left blank. Nothing ever happened because all that mattered was that the paperwork was filed, not that it contained anything useful.

    • Raymond ChenMicrosoft employee

      You might be able to get away with ignoring some processes, but others are harder to weasel out of, such as regulatory compliance. “Failure to complete this process will result in the deactivation of your Widget.”

  • Scarlet Manuka

    Maybe “business process” means something different in our team?

    For us, a business process means “When you get a request of this type from the rest of the business, there is a documented guide to handling it, which includes all the extra bits you wouldn’t immediately think of and deals with all the edge cases.” These documents are typically written or at least reviewed by experienced tech leads and are intended to allow anyone in the team to manage these requests. Team members using the document are expected to expand it as required if anything is unclear or any steps are missing, and to rectify anything in the documented process that is out of date or does not work.

    Our business process documentation saves us significant time and effort every week and allows us to deliver higher quality. There’s always more to write and update, of course, like any other sort of documentation. But we couldn’t cope without it.

    For other sorts of business process – it helps us greatly to manage our work queue to be able to insist that all our requests come through as tickets rather than chat messages or emails (we still get a lot of those, mind you, but we can then say “OK, put it in a ticket for us”). And the change management controls reduce risk overall, even if not all of them make complete sense (like the complete change embargo over the Christmas break because of the limited support available if anything breaks – including processes where the process SMEs are at work during this break to ensure continuity of the process, and go on holiday afterwards, when all the changes will be released).

    Of course our organisation is far smaller than Microsoft, and our team isn’t software development per se. Maybe that makes a difference. Or maybe it’s just a question of whether you have anyone maintaining your business processes and adjusting them as needed to make sure they make sense. If you have an onerous business process for changing your business processes, you are not going to stay out of trouble for long.

    • Raymond ChenMicrosoft employee

      Part of the problem is that the people who created the business process are not the same people who use the business process, so they don’t realize that the process they created is onerously difficult, or that the instructions which may have been correct at the time they were written have since fallen comically out of date. As a hapless consumer of the process, you have no ability to fill in missing steps or clarify things that are unclear because you don’t know the correct answer! You also don’t have write access to the web server that hosts the instructions, so all you can do is say “Please update the instructions to include this information”, and that’s usually where good ideas go to die because the people who created the business process are busy with other things.

      • Timothy Byrd

        It’s an inherent problem with automated systems. In the book “Peopleware”, Demarco and Lister have a chapter titled “The Self-Healing System”:

        “When you automate a previously all-human system it becomes entirely deterministic. The new system is capable of making only those responses planned explicitly by its builders. So the self-healing quality is lost. Any response that will be required must be put there in the first place. If ever the system needs to be healed, that can only be done outside the context of its operation. Maintainers come in to take the system apart and reconstruct it with one or more new planned responses added.”

  • John Dyer

    I never expected Raymond Chen to say “so must have been some sort of glitch.”

    Interesting…