3 ms·

I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process

I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process for any work that would take more than X man hours. They'd shut you down because you didn't have have approval for the budget. Yes, even though they're paying you to sit at a desk, you have to get executive sponsorship for the budget to cover the wages that they're paying you anyway. But if you know your way around the incident / problem / change management processes and you know enough of the userbase, you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem", you get pulled into the next problem review meeting and asked what can be done. You think about it, tell them you have a solution but it'll take a few weeks to build and test. And either you skip through change control because it's a production incident, or the problem management team do all the process for you.

daveevad 4y ago
> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem" This is an interesting perspective but perhaps crosses the line.
- raffraffraff 4y ago
  Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle. After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets. Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!" All that from taking the ITIL course seriously. If you're going to hack the system, understand it

daveevad 4y ago

> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem" This is an interesting perspective but perhaps crosses the line.

raffraffraff 4y ago
Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle. After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets. Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!" All that from taking the ITIL course seriously. If you're going to hack the system, understand it