This 1000%. There's so much institutional friction with these projects for so many reasons; some of them political, some of them interpersonal, some of them just because someone doesn't want to. So many of these projects fail because people just don't want to work towards the goal, or simply do as little as possible and things move slower than molasses.

People don't want or care to change their processes. They do things that way because they've always done things that way. They see tools not as a way to get more done or be efficient, but as something that's "moving their cheese" and they don't like it. It doesn't matter how overworked they are by remedial tasks that could be automated, until you show them everything finished, end-to-end, working flawlessly, they won't be interested in the slightest.

The sad thing is that if there were some strong executive leadership behind these projects and they saw it as a positive thing, there could be better traction and better results. Instead, most execs look at these projects as mundane details and hand them off to whatever sad middle manager is going to take the heat for the project going south. The result is no teeth behind the initiative which even further exacerbates the issue of people not caring or lifting a finger.

In all fairness, this perception of tools is often entirely rational. Changing workflows incurs a high cost, and any new tool must supply a benefit in excess of that cost. If it doesn't, then opposing the new tool can be the correct stance. And in my experience, at least half of the time, the new tools do not provide sufficient benefit.

Some of tools make claims that, if trivial to implement, would provide huge huge benefits. Unfortunately, there's a cost to learning a new tool, and then to implementing its use. Since you don't know the tool yet, you can only make educated guesses as to whether it will be easy or hard to learn, easy or hard to implement, make your process better or worse, help sell your product or make you more efficient, etc. You can't know for sure (unless it seems so much like something you already DO understand, and in that case, why would you use someone else's tool)? And that's only for yourself.

I'm not saying you shouldn't try new tools. To the contrary. It's just hard to know which ones are the right ones for your organization. Hence cargo-culting of tools that may or may not be a step backwards for your organization, or have all kinds of hidden-costs that are difficult or even impossible to foresee.

Will they be paid more for the increase in productivity?

I then began to notice this pattern in other people. If you give them efficient software they wont be able to bullshit their way out of any argument. Productivity is the enemy. Everything possible must be done to prevent the people above from figuring out what is really going on.

One very simple example I ran into recently. A new and improved app was made but it had exactly the same flaws as the previous one. An amount of time is assigned to tasks but if you add up the tasks for a day they greatly exceed the real world number of minutes worked. Then when complaints come in they simply assign extra minutes to the task pushing the total amount of work further over 8 hours. The number of characters for feedback was also reduced. When I jokingly asked about it (knowing how their game works) they pretended it was to hard to divide the work over the day. You cant just say a 70 min task must be done in 50! All hell would break loose! It is then left up to the assignee to figure out how to cut the corners. The managers carefully monitor the feedback, if anyone finds out corners are cut the employee is called in to explain for it. Eventually the smart ones figure out how to cut corners without anyone noticing it.

The entire show depends on the clients inability to add up all the minutes.

[1] - https://www.w3.org/PICS/services-960303.html

SaaS can be on-premises.

> Sally in accounting refuses to change

The tools need to adapt to the user, the user shouldn't need to adapt to the tool. That said, if there are obvious efficiency gains (e.g. you can stop typing "COMPLETED" three hundred times a day and just click a button that fills the field for you; even better, the process marks it 'completed' once all the human verification has taken place) and the user is stubborn, well, maybe the tool should offer the efficient solution, allow the inefficient behavior, and log metrics on the whole thing. Management might take interest.

True; the distinction between SaaS and COTS becomes moot in practical terms then, and all of my comment still applies.

>>The tools need to adapt to the user, the user shouldn't need to adapt to the tool.

Again, that's:

- True for an IT project whose goal is to support whatever the user is currently doing (and what many of us are trained to do / think in current IT paradigm).

- Not True for a business transformation project whose goal is to change business processes for the better - and, basically incidentally, deliver a COTS ERP to support them through an IT portion of the project.

We are not talking about where the button is or how many times it takes to click or what the icon looks like. We are talking fundamental business processes and workflow, which are core to how a business operates internally.

For business processes which are company's core business, presumably they have them figured out. That's great, and IT should support them.

For back-office ERP, this is not your company's core business; you're probably not a special snowflake; and the market's average/best practices are likely miles ahead of your legacy over-complicated business processes. YOU need to change if you want to reap the benefits of shiny expensive new software.

There is extremely limited point in implementing a new back-office ERP (HR, Financials, CRM, EPM, etc) if you're not willing to approach it as BT project; radically change how you do things; and expect a shiny new tool to make you more competitive automagically without your processes and maybe even culture/habits changing.

My fundamental point remains: what the big consulting companies do with ERP / backoffice implementation (when done right) are primarily BT projects, and incidentally involve IT implementations; and treating them as IT projects, whether that's Sally in accounting refusing to change or Bob the developer accommodating Sally thinking it's the right thing to do, will cause them to fail. (generalizations and oversimplifications abound in above statement; but it really takes a very very large and repeated application of a mental sledgehammer to dislodge some universally-good but specifically-counterproductive ideas and habits from the ERP space)

A couple of people at the time were really unhappy about the change because there were some differences, at least at the time, in the ability to create nested folders/labels like they were accustomed to doing in Exchange. Basically, Gmail messed up the organizational scheme they were accustomed to for client and contracts.

They were basically told to deal with it but the point is that even when going to some standard SaaS makes sense, people are very resistant to making changes in their standard tools.

No matter how much buy-in you get, people can be unreasonable about making any accommodation for change.

(Note, FWIW, though I think we're on the same page - the "business processes" I'm talking about in relation to ERP are less interface/program-mechanic based, and more along the lines of "Who is authorized/must approve" "How do we run accounting" "What is our procurement workflow" "How do you calculate taxes" etc)

Doesn't always work especially if I don't remember quite what I'm looking for. But it's overall a reasonable tradeoff compared to filing a bunch of stuff, most of which I'll never look at again. It is a shift in mindset though.

I like to get emails out of my inbox as soon as I don't need them anymore (so my inbox always only contains the email that still requires my attention). But I don't do any sort of serious categorization/tagging/etc. -- the cost/benefit to doing that far too high.

Instead, I have a folder for each entity that I exchange emails with, and move the emails into the appropriate folder when I'm done with them, with no further categorization.

"one-off" emails (marketing, registration, etc.) just get deleted.

It's at least 50% sales.

By time spent? Not on anything but the tiniest projects which are likely to be loss-leaders anyway.

By value added? For consulting company, sure, that's one way to look at it; for the customer, probably not :P

For the purposes of my post, pre-sales/sales/RFP/whatever were assumed to be done prior to start of implementation.

Though I will agree that how ERP project is pitched/sold may well have an impact on the delivery:

- the IT vs BT categorization per above is likely implicitly or explicitly setup at these early stages

- who the stakeholders/champions are / who signed off on purchase and why - the CIO because their previous product is EOL? The VP of functional department (HR/Finance/etc) because they want to realize value in changing processes? Etc

- are the timelines and deliverables reasonable

- is the goal / value realized / ROI well defined and agreed

- are the requirements and scope well defined and agreed

- etc

(edited to change nested brackets into bullet points :P )

Later on, back on the selling side, I now appreciate that "qualifying out" opportunities is definitely a critical activity otherwise you well spend huge amounts of money chasing stuff that you probably won't win or, worse, win and make a loss on.