This pattern is also seen in almost every enterprise application purchase I've seen over the last 10-15 years. The process is as follows:
1) RFP, RFQ then purchase your ideal enterprise application.
2) Start customizing it to meet your old way of working (and before you really understand it) while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
3) Complain that it won't really let you work the way you did a) on the mainframe which was designed based on b) the way you did it with paper and pen.
4) Throw in the towel or force your users to adopt some practice that was neither a) your original process or b) the vendors optimized process.
I've seen this pattern with:
1) Oracle ERP
2) SAP
3) Jira (twice)
4) PeopleSoft (twice)
5) Workday
6) ServiceNow
7) Remedy (twice)
One of the most solid recommendations I can give is that when you purchase a software system, don't do any customization for the first 12-18 months.
> while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
Do they?
If you've seen the pattern you describe almost everywhere, and the key second steps (well, “customize out of the gate to fit your business processes”) are exactly what the vendor markets heavily, what makes you think there huge numbers of customers who are both not customizing and doing just fine?
I've seen and heard of a few cases where customers use software of that kind and minimize customization of the software and instead try to adapt their business processes to the software. And usually those are at least as much horror stories as any heavy customizers.
Really, as much as it's not in the vendor’s interests, big bang implementation of this kind of software that becomes immediately central to a wide array of business processes is probably a bad idea for the same reason that big bang software system replacements usually are, even when there is no existing software system being replaced. Incremental, iterative improvements to business processes and supporting tools are probably a better idea. But big-bang, notionally close-ended projects are more succinct “achievements” on manager/executive CVs resumes, and no one is courting buyers and giving out swag for continuous improvement.
Oh yes. I'm going through exactly that with Jira right now. Not that I'm at all a fan of the thing, but when you look at what's there, you get at least a sense of how Atlassian thought it should be used.
Enter some individuals who think that they know better and have determination to force that Jira-shaped peg through their round hole, even if they have to use a jackhammer to do so. The result is the worst possible outcome, and every user gets to pay each day for it. m(
Do you disagree in only this specific case or do you disagree in general and cite this specific case as being emblematic of why they're wrong? It's not clear to me what your point is.
1) RFP, RFQ then purchase your ideal enterprise application.
2) Start customizing it to meet your old way of working (and before you really understand it) while ignoring the fact that X's 10000 customers seem to do fine with the default configuration.
3) Complain that it won't really let you work the way you did a) on the mainframe which was designed based on b) the way you did it with paper and pen.
4) Throw in the towel or force your users to adopt some practice that was neither a) your original process or b) the vendors optimized process.
I've seen this pattern with:
1) Oracle ERP
2) SAP
3) Jira (twice)
4) PeopleSoft (twice)
5) Workday
6) ServiceNow
7) Remedy (twice)
One of the most solid recommendations I can give is that when you purchase a software system, don't do any customization for the first 12-18 months.
P.S. Okay ... go ahead and put your logo on it.