Whenever someone proposes a process change, or forces me to switch to a new tool, I send a variation of this email to them. In this post I use the example of Dropbox Paper, but you can pick any other shiny tool.
I think we need to write a detailed doc every time we propose a process change. Like if we are pushing for adoption of a new tool we should write a pitch doc with a strong WHY (the need), WHAT exactly is part of the switch, and HOW we will measure success. For most of us, google doc was working fine and I am yet to understand what the move to Dropbox Paper helped us achieve.
If the document makes sense, and a lot of end users [the unfortunate few who will have to use this new tool] agree with the upside and downside, then only it should be adopted. Note: There is a huge switching cost associated everytime we move to a new tool or process.
And regarding success metrics, I sincerely believe that tool improvements/upgrades are more about downside protection than upside maximization.
Example. Moving to Jira from Google sheets might help a good team track bugs better, but it won’t help a dysfunctional team improve its shipping velocity from 2 months to 2 weeks.
Also, I am yet to see someone’s communication become 10X better because they started writing on Dropbox Paper vs Google docs.
As a team, we should focus more on better processes and less on tools.
P.S If you have worked for as many companies as me, you might have seen your own share of process/tool changes just because someone in management had shiny tool syndrome.