Welcome to the Utopia Forums! Register a new account
The current time is Thu Oct 18 00:19:36 2018

Utopia Talk / Politics / Wage slavery ep 2.0
Nimatzo
iChihuaha
Mon Oct 08 09:43:56
I have to preface this with I don’t think that I am exceptionally intelligent or knowledgable, I am painfully aware of the gap between me and truly brilliant minds. I am conservative in my estimates and I look for trouble. I don’t boast and I do not deal well with compliments, I just smile and nod, maybe I mumble a thank you.

When I started my job, already back then there were talks about this new IT solution, to unify, simplify and well, you know solve ALL the problems everyone is talking about. Warning sign nr 1.

I was a couple of weeks in to the new job and told the divisions chief, hey psst, I have some experience with introducing new IT tools etc. If I can be of any help, please let me know. Several departments who have never had to work together are supposed to be going into the same system that deals with the daily operations and well EVERYTHING but economy.

Early 2018 the project starts with the goal of implementing late 2018, I am one of the key people for our department (not lead), we go through a course to learn the system, it is at this point I realize, this is the first time ANYONE in the company has seen the software let alone had any in depth understanding of what it can do and the limitations it has. Warning sign nr 2. I laughed out loud at the implementation date at this point

Two months in the other department (we are 4 and our department is the most complicated) has ground to a halt, too many gaps, no solutions. In may 2018 another “workshop” together with the developers to identify gaps (lol). Two people connected to the project burn out. Late this summer the overall project manager is kicked out and replaced by an external. Because at this point the resources allocated had run out!

During all this time my pessimism indicator goes up and I begin to wonder if this will not be the kind of disaster that ends up destroying a place, considering all the ifs and buts attached. You can’t do this, you can solve this by doing this much more time-consuming thing etc. and so on.

I explain what should have been fucking obvious to a few key people. In 2015 when you people started looking for a software solution, all the work we did in 2018, it should have been done back then. You should have sent 3-4 people who know the processes and the organisation and accept that you may end up burning 100 000 Euros and at the end of it say, no this does not suite our business. We did this after signing the contract! I am sparing a lot of details, but the people involved in the decision, well the person who started this, he can barely use Outlook and that is not an exaggeration.

So now I just had a conversation with the division chief, where the conclusion was, we want you to take over the lead for our department. We are not happy with the progress of Mr A and we have heard your opinions, you look for solutions, you communicate properly, and you are honest, everyone including the developers think this.

I am sitting there wondering, do I even want this cluster fuck? I will be surprised if this goes well. And if I am the man for the job, then god help us. Because honestly I did not say or do anything, but pointed out obvious things for people who understand something about computer systems and who have been involved in a couple of IT project. This failure could have avoided 3 years ago!

Well it’s too late, I already said yes. If I do not survive this winter, tell my wife and son I love them.
hood
Member
Mon Oct 08 09:53:44
Implementing new software is a fucking bitch, especially if you have zero familiarity with it. One of the teams I work with legit does that for a living - they implement EMR software for physicians and provide ongoing support. IDK how they manage dealing with shithole vendors, stupid ass end users, and all of the other shit that goes on.

Good luck. While I'm sure you know it, I would become an expert on the software in question.
The Children
Member
Mon Oct 08 09:59:08
wtf does all this gotta do with wageslavery u dumb piece of shit. u mockin me bitchass fool.

u still commuted by bus for the last 10 years. but go ahead and try 2 enlighten us the pleasures of a stinky crampy public bus twice a day for 50 min each.

u dumb fuck.
Hot Rod
Revved Up
Mon Oct 08 10:25:32

Good luck Nimatzo.

I hope you get a handle on it soon.

Paramount
Member
Mon Oct 08 11:46:55
Well, good luck. You can fix this if you want too and if you sacrifice your time to it. I hope your wife is okay with it. It would suck if she wants to divorce you because you spend too much time on a software.

” well the person who started this, he can barely use Outlook and that is not an exaggeration. ”

Well, I have met people who didn’t know how to double click with a mouse.
Seb
Member
Mon Oct 08 13:39:14
Classic waterfall IT delivery failures.

Not user centric, requirements improperly specified, failure to understand use in context, long lead time, procurement centric, and staff engagement an afterthought.

On the other hand, this is (still) quite common and your company may well survive.

I ran a line of business application cloud migration project once - we did it in under a year. If you know what you are doing, it's not impossible, but people keep insisting on thinking about this kind of thing as a tech project that can be done by nerds in isolation, rather than a business change project that needs broad staff engagement.
Seb
Member
Mon Oct 08 13:45:11
Missed the last paragraph:

You are being asked to be the chief "business" representative to the delivery team? Or the actually delivery team lead?

Honestly, it's not hard to do that job well, mostly all it takes is the mind-shift to not be a blinkered IT deliver professional who goes "mugh, user error" and "but I has a gant chart I wrote three years ago with milestones that I'm treating like a sacred prophesy".

But "well" will be entirely limited by the responsiveness of the delivery programme to constructive criticism if you are not running the actual deliver team.

Best possible scenario: they are open to being driven from the outside, and you get recognized as having saved the whole programme if it is still salvageable.

Worst case scenario: it's too late, they hunker down, and some how you get blamed for the projects failure.

Good luck!
Nimatzo
iChihuaha
Tue Oct 09 00:29:35
”Not user centric”

^This is painful, because we had the option (for a lot more money, but well worth it) to have a system design from scratch. Given that this system change is the most important change made ever and will be for many years to come, the money would have been worth spending to have a system designed around the process and people instead of craming the processes into software it really doesn’t belong.

If it was up to me I would have considered the 1.5 milion euroes a sunk cost and started over. But right now such sentiments are not really helpful, it is one thing to convince people they managed the project poorly another to tell them they wasted all this money for a suboptimal solution. It isn’t shit, but it is hard to quantify the net benefits through the haze of if’s and but’s.

I am not worried to get the blame, I have been and am up front with the division chief, ”I will do everything I can, but I will be surprised if this ends well”. I have ”covered” myself by being the first to voice concerns and being honest.

There was also a communicative conflict between our rep (he) and the old project lead (she) both are gone. Honestly, he fucked it up, he gets visibly frustrated and angry, he once (unknowingly) back talked her when she was sitting behind him. This actually has UP relevance since she is a leftwing (old school) feminist. Nimatzo is nothing, if he isn’t fair ;-)

I will be the rep for our department, also responsible for the implementation, as hood said, I will end up being one of the key users and ”experts”, so for at least 2 years after going live I will have to oversee the implementation and training that is necessary to fully implement all the functionality we don’t have time with now.

All your wishes of good luck is probably


Nimatzo
iChihuaha
Tue Oct 09 00:29:51
*needed.
Nimatzo
iChihuaha
Tue Oct 09 01:07:37
”thinking about this kind of thing as a tech project that can be done by nerds in isolation”

And this :) I was recently told that back in 2014-2015 when this was first started they took our two IT support people, one of them fresh in the company, to first go a project management course and let them handle it. With implementation in 6 months! I wish I was exaggerating for lulz, but I am not. So these two IT nerds (I love IT nerds) who had almost zero understanding of the daily work were going to implement this in 6 months :)

This haplened by the order of the person (now retired) I previously explained, can barely use Outlook. And so it was never in the plans that old guy was ever going to live with this system, since he would retire. There should be a rule, people who are nearing retirement age, don’t get to decide anything regarding systems.

From my limited experience, you would send 1 IT nerd and 1-2 ordinary nerds from each dep. who have a deep understanding of the daily work, they spend 2 weeks pulling the system apart. Then they can give you an answer. The developer has actually made changes to the code, the costs of which are shared, since it will make the software applicable broader, but of course there are limitations.
Seb
Member
Tue Oct 09 08:42:24
Nim:

Better than designing the tech around the process would be to start from scratch and design a new process and tech around the end user need.

Doing better things > doing things better.

Many managers think it's more risky to change process and tech, they are often wrong, as tech implementation and roll out will be disruptive business change anyway.
If not a discovery phase will show it and you can scope accordingly.

So if you are spending £££ on bespoking the tech, spend on changing the whole lot

The way you do this well is a proper discovery period, totally divorced from solution design. Fully understand the problem end to end, then start thinking of solutions (user needs, people, then process and then tooling).

Also, you can often slash costs by adopting more modern solutions than traditional systems. E.g. a giant oracle or sap system for ERP is hideously expensive to bespoke and then huge costs of ownership and change. You can buy smaller more flexible elements and get the same outcomes with small parts loosely coupled.

Also, and this might be in your gift - try to loosely couple process and technology as possible. Baking in too much of the existing workflow constrains continuous improvement efforts later.

Most workflow tools end up with overly complex data models because engineers treat everything they hear from end users as part of a rigid data model, which then needs to be reconfigured if processes change, or gets corrupted. E.g. a field with a drop down of team names, or a set of handling instructions that don't include some new criteria - and then people end up using other fields to communicate them instead.

Figuring out when to leave it to the operator and when to constrain them is hard. You need really good BA and service design skills - not developers. That's not their core skill set (whatever they may claim).

Personally I wouldn't touch this - I'd end up very unhappy as it sounds like they did everything wrong and it's unsalvageable.

The sunk cost falacy is hard for management to accept, but my gut says the write off option sounds like it will be cheaper in the long run through lower cost of ownership.

On the plus side, between 60-80% of IT projects end in failure (when you use these kinds of methods).
Nimatzo
iChihuaha
Tue Oct 09 16:08:18
”Better than designing the tech around the process would be to start from scratch and design a new process and tech around the end user need.”

The process is fine! It can also for shall we say ”regulatory” reasons not be radically altered. But I understand what you mean, I have on several occasions seen two production sites building the same product owned by the same company, one is old and one was built the previous years. When you are not weighed down by the sins of the past, the sky is the limit.
Seb
Member
Tue Oct 09 16:50:06
Nim:

Fair enough.

Want the worst "do things better Vs do better things" story I have?

I come across a program to "automate" a process. My job is to do assurance on it.

An org needs to get a count (for regulatory reasons). The process to get that count is to weigh a stack of forms. From the weight, they know how many forms, hence how many things.

The forms are delivered on pallets from another org that didn't really understand why they had to ship these forms to the first org or what was done with the forms. They just knew they had to for regulatory reasons.

At the, let's say fullfillment centre, the pallets are opened up and the forms repackaged into bundles by hand and weighed on scales.

The process takes loads of people, takes quite long, and the cumulative errors over lots of individual scales (which take ages to calibrate) build up. The measures are rekeyed off the scales into a database.

The first orgs plan is to, at their fulfillment centre, have bespoke high precision scales big enough to take an entire pallet, and they send the measurement automatically to a DB. No more rebundling, no more rekeying. Much efficiency. Much accuracy. Big ROI.

Only it turns out that the second org prints these forms out from a CMS, onto special high quality paper, using old fashioned printers because it's a regulatory requirement to still produce these forms, even though they digitised years (possibly decades) ago, to the exacting specifications set by the first org to ensure accuracy.

Whole thing could be replaced with a single line of SQL code.







Nimatzo
iChihuaha
Wed Oct 10 00:56:27
Some what understandable, regulation can be a djungle and easily scare off any attempts to be creative, especially if you are subject to inspection and surveillance. If the company can’t have a semi dedicated regulatory affairs specialist then those things will not be reviewed. And most companies while effected by regulation in one form or another are not so regulatory intensive to justify hiring regulatory affairs specialist. Was it something like that? Or just ineptitude?

>>between 60-80% of IT projects end in failure<<

Also without fact checking, some how I believe you. The competency is very low in most places. Everyone has IT specialist, but not always in house or they have too much to do already, but really you need more people with general understanding of computer systems. It is a generational issue perhaps, future orgs driven by millenials will have learned :)
jergul
large member
Wed Oct 10 03:37:36
I don't think the moral of the story was "regulatory jungle". Its more that incremental changes can lead to breakthroughs in process if someone has the time to step back and say: "single line of SQL-code".

"Old fashioned printer" still means digitalized input. Digital typography has been mainstream for close to 50 years.
Nimatzo
iChihuaha
Wed Oct 10 04:09:51
The moral of my post is that regulation is a jungle and can scare off attempts to change, making the low hanging fruit some what understandable.

>>Its more that incremental changes can lead to breakthroughs in process if someone has the time to step back and say: "single line of SQL-code".<<

Someone, yes, maybe even someone who understands the regulatory demands on the org.

”If the company can’t have a semi dedicated regulatory affairs specialist then those things will not be reviewed. And most companies while effected by regulation in one form or another are not so regulatory intensive to justify hiring regulatory affairs specialist.”
jergul
large member
Wed Oct 10 04:42:36
Nimi
Or that process designers understand the regulations that are relevant to the process they want to design. A matter for the job description.

The regulatory demand for the example in question is: There must be paper copies to specific standards and the number of paper copies must be known.

The stepback was to realize: "Hey, the paper copy producer could electronically count the copies as that are produced, then specify that number on the pallets we get. This is a coding issue, not a scale issue".

Now I get that "a regulatory specialist" would be a nice job to have. For a lawyer perhaps. Or some other fluffy science type.
jergul
large member
Wed Oct 10 04:45:42
The term is "compliance officer" btw
Seb
Member
Wed Oct 10 05:38:18
I this case though, there wasn't even the legislative requirement on org 2 to specifically provide forms. Just to report (and it was a 1-to-1 relationship). Both public sector orgs.

Both orgs had lost sight of the rationale for the process and a view of it as an end to end thing.

Complete lunacy.
Seb
Member
Wed Oct 10 06:50:58
Jergul:

More that unless you take a step back and look at the process end to end and the user need/full intent, you very easily spend a fortune on optimising and automating stupid processes rather than optimising for outcome.

The printers took digital input but something about the ink and paper specs (the weight of the ink and paper matters for the weighing accuracy, but of course the printing org doesn't know or care why) meant it was old hardware and they had some bespoke middle-ware involved.

The regulatory requirement was simply org must report to us the number of things.

The literal only reason for printing the forms out was to weigh them.

The way they had done that since a very long time ago had been "the people doing the things have to complete a form which is attached to the thing, which is then submitted to/collected by us, so we will then send the forms to org B to count, and that fulfills our obligation"

Obviously some negotiation had happened to agree how it would all work, and org B set specifications in how the forms had to be made in order to accept them for counting.

Then everyone forgot.

At some point org A switched to "people doing the thing submit an online form to us, but we are required to send these forms off to org B, we must keep doing that then".

And org B never really thought back to what they were trying to achieve beyond guessing the number of forms in a bundle.

Seb
Member
Wed Oct 10 06:50:59
Jergul:

More that unless you take a step back and look at the process end to end and the user need/full intent, you very easily spend a fortune on optimising and automating stupid processes rather than optimising for outcome.

The printers took digital input but something about the ink and paper specs (the weight of the ink and paper matters for the weighing accuracy, but of course the printing org doesn't know or care why) meant it was old hardware and they had some bespoke middle-ware involved.

The regulatory requirement was simply org must report to us the number of things.

The literal only reason for printing the forms out was to weigh them.

The way they had done that since a very long time ago had been "the people doing the things have to complete a form which is attached to the thing, which is then submitted to/collected by us, so we will then send the forms to org B to count, and that fulfills our obligation"

Obviously some negotiation had happened to agree how it would all work, and org B set specifications in how the forms had to be made in order to accept them for counting.

Then everyone forgot.

At some point org A switched to "people doing the thing submit an online form to us, but we are required to send these forms off to org B, we must keep doing that then".

And org B never really thought back to what they were trying to achieve beyond guessing the number of forms in a bundle.

Nimatzo
iChihuaha
Wed Oct 10 10:57:31
Well a regulatory specialist, may have caught that, but it seems like something that does not require specific expertise in this case. The thing is if your an org that has been around for 20-50 years there are legacy stuff, the complexity that lies in there together with the cancerous sprawl a growing organization can have. It is scary to rip the curtains and say, let’s rethink everything! Usually things are working good enough. Long term you will lack agility and viability of course, but people are so locked in the 3 month increment. Even with long term planning, the 4 quarter cycle sets so much of the agenda and general tone in so many places. It is inescapable.

Some of this contextual, certain places operate more or less like they would have in the 19th century, seems to work. Slightly hyperbolic, but one is amazed. Weighing documents to count them, it is up there among the most bizare things I have heard. Did you ever figure out, how this ended up there?

On the flipside, a shitty system implementation or just simply the introduction of critical software people are suppose to work in, that can kill you. Put great people in a shitty system and the system wins, Demings said. This is the big risk in our project, people have burned out, people have been kicked, people may quit, many people can quit. And the way the job market looks, the employer is not in command. Why stay here with this shit when I can go elsewhere and raise my salary to boot.
TJ
Member
Wed Oct 10 11:14:28
"Why stay here with this shit when I can go elsewhere and raise my salary to boot?"

Possibly warranted or unwarranted loyalty in a conflicted process. Are they equally favorable options? That is only a question you can answer. :)
Seb
Member
Wed Oct 10 11:19:38
Nobody knew, just "it's always been this way". But I'd guess pretty much how I said . Once, it was all paper based. Then volumes got too high to count every bit of paper and weighing them was a damned clever idea (I'd guess sometime around the 69s or 70s, but could at a push have been early 80s.)

Online form submission probably early to mid 2000s. They didn't figure out the insanity until 2013 ish. And I think they might still be weighing some forms even now because they also botched that simple step by having it be part of a much larger digital transformation that went wrong.

Seb
Member
Wed Oct 10 11:19:38
Nobody knew, just "it's always been this way". But I'd guess pretty much how I said . Once, it was all paper based. Then volumes got too high to count every bit of paper and weighing them was a damned clever idea (I'd guess sometime around the 69s or 70s, but could at a push have been early 80s.)

Online form submission probably early to mid 2000s. They didn't figure out the insanity until 2013 ish. And I think they might still be weighing some forms even now because they also botched that simple step by having it be part of a much larger digital transformation that went wrong.

Seb
Member
Wed Oct 10 11:28:39
The quit thing is a line I often use to try and get senior managers to prioritise this stuff. Crap IT frustrates people, and eventually the good and ambitious leave. The trigger is often something else, but being stuck and not able to do the job to the best of your ability because of the shitty state of your tools creates the fertile ground where people think existentially about their careers.

It's terrible because it's a filter on the best that leaves you with the worst. For case management its a killer as you want to automate dumb stuff and have your people handle edge cases. But if they've all fucked off, and you have armies of dumb time servers, you end up having to invest in scripts and stricter process flows as they can't handle ambiguity, which creates more edge cases; and then you get all the errors and failure demand from their inability to work effectively.

Automation and tools that helps a few smart people be super productive and doesn't try to lock them into a rigid process, that have the smarts and judgement, and because there are few of them you can afford to pay them well, is a terribly underutilized model. But those that do use it gain huge competitive advantage though excellent customer service.

Nimatzo
iChihuaha
Thu Oct 11 02:19:36
TJ! :)
It was a general sentiment I observe, I am not going anywhere... yet. When I started I here 2 years ago, I said I will reassess the situation in 5 years.

Seb
>>Nobody knew, just "it's always been this way".<<

Classic answer, code for "we have no fucking idea why we are doing this". If the reason (purpose/goal) for why something is being done isn't clear, then there is not a lot of room for the people preforming it to rethink it, as far as incremental improvement goes.
Seb
Member
Thu Oct 11 02:39:45
The other good one (in the public sector at least) is "the law says we have to do it this way". Then you ask them to show you where in the law it says that, and it turns out not to.

The number of things still done on paper because "legally we need a wet signature"
Nimatzo
iChihuaha
Thu Oct 11 03:54:21
An update on the OP. We sat yesterday with the fundamental structure. I understood my predecessors issue, btw I still have him on board and he did took it very well. He will be indispensable early on, until I get the hang of the system. Anyways, his issue, he had snowed himself in on certain "problems/limitations", so when I questioned why why why? He thinks and says, no I guess no, this isn't an issue either!

And I fully understand him given how poorly the project has been handled. Him and the old project leader did not get along at all. He thought she was stupid and understood nothing about our work, and she thought he was backwards thinking and rigid. I know this because I had to be "bar tender" for both and listen to their bitching about the other.

Anyway, this is still a disaster and everything I said earlier, despite taking small steps forward still applies.
TJ
Member
Thu Oct 11 09:01:02
Nim:

Nothing wrong with reliable stepping stones to improve a resume. Succeeding in a high degree challenge is always an impressive entry.
show deleted posts

Your Name:
Your Password:
Your Message:
Bookmark and Share