Welcome to the Utopia Forums! Register a new account
The current time is Fri Mar 22 11:01:35 2019

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.
Nimatzo
iChihuaha
Thu Jan 03 09:27:19
It was about 2 months in I realized how ALONE I am and how understaffed the project will be as there is no real way of putting the puzzle together other than pushing the go live date.

Master data. DONE
System configurations. BLOCKED
Migration of data. IN PROGRESSS
Data validation. TBA
End user training. TBA

Too many carts, not enough horses. On the other hand, this cluster fuck has really pushed my limits on everything and I can honesly say the past 2.5 months have been worth years of experience, both in terms of context specific knowledge but also more generally on a personal and professional level. My method is to jump head first into the tsunami wave and try to get comfortable drowning :)

Not out of the woods yet!
Seb
Member
Thu Jan 03 12:26:07
Nim:

Yup, nothing beats a programme that's on the rocks for a learning opportunity.

What's blocking config?

Data migration is normally a complete bitch. Are you buying in a migration partner or contractor? Would recommend it.

Are you validating and cleansing data prior to migration?

I forget, is this an ERP?

Nimatzo
iChihuaha
Thu Jan 03 14:03:34
Resources and last minute (still) process changes is blocking.

Me and the our local Admin (who has gotten another job and will be leaving mid launch btw. Wouldn't want to make this easy) are specifying the data templates, but a contractors is actually doing the work.

Some data cleaning has been done prior, but the first test migration will likely show I have missed something, it remains to be seen. Validation will be made afterwards with the data in the old system.

It is a project management software with a niche application, it would likely reveal too much about where I work as this place is one of a kind. It does communicate with an ERP and a CRP, it is "production system" critical. If it doesn't work, you are not piling up unpaid invoices, you are not working. We can communicate with the clients and they can follow the projects and most of this work is done in a web portal while the client will be mostly for back office. It will publish documents, keep track of validity.
Seb
Member
Thu Jan 03 14:25:40
No offence, but I would probably not have done the data model yourself. This is what solution and data architects are for ;)

If you are smart and rigorous, you'll do a good job but just because you can do it didn't mean you should do it!

There's always mistakes when you do it t yourself for the first time: it takes a particularly focused and anal mind to catch all possible ways it doesn't work and if you and your admin are doing other things it's almost gauranteed not to work first time.


Still, that's what test migrations are for though.

Can you do a dual running period - or are your forced into a big bang cutover?


Dukhat
Member
Thu Jan 03 18:28:55
More like Golden Shackles than Wage Slavery if Nim is going to be taking over a lead IT role though I don't know if 150-200k a year is really golden shackles. More like silver shackles in today's prices.

I guess he tried to hide how absolutely boring the subject matter is. Just deliver the minimum viable product and move on.
Nimatzo
iChihuaha
Fri Jan 04 02:27:32
Seb
I am not sure what you mean with the data model. It sounds like something I didn’t do :)
I specified what data from the old system should end up where in the new system and in the event it didn’t exists as a place I created a space for it in the relevant functions. The fundamental structure was there and of course many things were simple 1 to 1.

No there is no dual run really, the old system which was management and ERP combined is being shut down late 2019. So it is with the knife against the throat kinda. There is no plan B (I asked).

Dukhat
I have worked here for over 2 years now and will be living in and with whatever end product I deliver. I am very much ass on the line and have skin in the game. I am not moving to a new company and project in a couple of months.
Nimatzo
iChihuaha
Fri Jan 04 02:37:26
Or rather how the data should be coverted. We had to radically and not very intuitively alter our service structure because of how the software works, this is still my biggest gripe and which I have realized is the root of most problems and stated as the biggest flaw. This software was not made for a place with such a complex flora of services.

Exactly what data we needed to move was 80% obvious (and predefined) 15% have emerged through my detective work and 5% will be discovered hopefully in the migration/validation, in theory :)
Sam Adams
Member
Fri Jan 04 11:29:47
"and 5% will be discovered hopefully in the migration"

Yikes.
Seb
Member
Sat Jan 05 13:56:06
Nim:

Data modeling is roughly what you describe.

Developing a schema e.g. a "case" has attributes like "number" which is a unique inteher "start date" which is a date "last reviewed date" which is a date, and a "closed date" which is a date, "caseworker" which is reference to our employee database, "case owner" which is a reference to our employee database.

The challenge is, as you say, making this work for your processes, and ensuring it works for edge cases (e.g. if a case can be closed then reopened and you want metrics on cases wrongly closed).

Mapping from as-is to to-be is also challenging.

It's not that it's particularly complex or difficult, it just requires a lot of focus and a particular mind set to catch all the possible exceptions, but also not get too micro and make it to difficult for the user or too many constraints (the more detailed and specific the get, the note you can create obscure edge cases).

So I find in general it's best left to specialist BAs who've developed a knack doing it day in day out than trying to get a smart generalist don't as part of a broader piece of work.

5% - good luck!
jergul
large member
Sat Jan 05 15:18:50
I would strongly advise listening to Seb. It would be a good cover your ass maneuvre in the likely event to project exceeds cost and time projections.

You don't want to take the fall for what seems to be a very bothersome project.
Nimatzo
iChihuaha
Mon Jan 07 12:25:05
Seb
Something is lost in translation. The data models are already done in the new system. It is vendor software. My part in this is the mapping and there is no one better suited since I built the masterdata and I am very familiar with both old and new system. As for catching all of them, yea we have spent I don’t know how many hours examining different real cases for every step. The developer did not really understand how complex our data was, until recently when I joined and started to get really detailed. So much that the rep told me she worries about the other departments, since they are ”not on the same detail level”. This is overall not just the data migration.

Not getting obsessed and lost in details, yes this is an advice one probably needs to be reminded of, especially since those of us in the project have to live with whatever we deliver. It is easier to get stuck trying make things perfect.

80-15-5 is just a visually pleasing ratio. but honestly it could be worse. Customer data, yea that one is a fucking mess. A portion of which we will unfortunatly inherit. Basically whenever someone adds a customer in the CRP (anywhere in the corporation) this will automatically and unfiltered be pushed out as an identity to whatever systems (our system among others) listening to the plugin. This will create duplicates with slightly different names but identical GUIDs will be created. And the way migrated customers are dealt with is not the same as those that are fresh. And the different ways in which customer relations (to each other) has to be dealt with. There was this nice idea that whenever a customer changes name or merges or anyone farts at their HQ this information would be automatically in our system. In hindsight this was probably always a terrible ”feature” to want.

^I remember a meeting we had on this, the whiteboard looked insane with 15 rather complex cases. And the workarounds did not cover anything in a satisfactory way and would be work intensive to maintain systematically. So I said, ”this may be a stupid question, but why are we doing all this?” The customer data we buy in the CRP to be automatically updated isn’t how we want it in the system AND this will only work for Swedish customers, for foreign ones there is no update. Is this really worth it (especially since we have no solution)? I gave a ”napkin sketch” for another simpler option, which as it turned out will be the one we will go for. I wish I could say my solution was great and genius, but it infact it was the less shitty one. We had consensus on that :)

Jergul
The one thing I do not worry about, is getting blamed. I am by all accounts the fire department in my current role, I am here to extinguish the flaming house I was called to. I made efforts early on to explain the cluster fuck we are in, how it happened and severely lower expectations. The project budget ran out summer 2018, months before I joined. Mostely due to what turned out to be worthless customizations. I am actually quite certain the cost at launch will be so high that it will rival the offer we had for a system from scratch. I could be wrong of course, so I keep all my alibis and ”folders” in order.
show deleted posts

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