When I was in academia, I was amazed at how slow industry was to adopt new processes.  Then I moved to industry and found that the  issue isn't individual practitioners.  In many instances, it is the corporate/company that has to be convinced.  I could adopt 'Agile' tomorrow, but that would only be for my personal projects as the corporate initiative is more iterative.  

The *hot* new software process, developed in academia, may be accepted immediately by a small startup because they're familiar with it  or only need a week to train everyone in their company.  In a larger organization, turning 'on a dime' to a new paradigm is not so easy.  It is something that has to be staged, education will be required for all the practitioners currently involved, and the new process has to somehow be mapped back to help support existing products.

In the software industry, people might not want to invest lot of resources and time on processes which are not tried and tested. Hence the first criteria to make software practitioners adopt a new process, is to test the process thoroughly beforehand with a personal group of practitioners, or start testing as part time, as an extra activity apart from work. The results out of this experimentation should be published and demonstrated to the stakeholders. I think this will leave a lasting impact and would become a convincing factor for practitioners to adopt a tried and tested process. 

Deploying a new software development process in organization or on a project is usually done for some real reason. So question should by why do you need a new process and what its deployment should accomplish (even in measurable form). So apart from reasons that some users need new software to solve some set of problems, usually new process could be considered in order to deliver software more quickly, cheaply, or with higher quality. Goal could also be to be able to develop the software more cheaply in the long term (i.e. to have it more maintainable).

The process itself is also dependent on what we want to accomplish architecturally. I may want to force a clean interface (for some real business reasons) at some point in the architecture, and I would do this by strict organizational division (where teams have to hand-over between themselves). 

So if I would go to convince software practitioners to work in different way, I would first try to establish, communicate, and explain all the reasons why we need a different process, how the new process will improve things and how that fits with the organizational goals. And of course, a new process often comes with new languages, tools, and frameworks that people should come to trust and get used to also. So it may take even more convincing and sometimes you have to just get a different set of developers in the process.

You need to:

Bear in mind that most practitioners don't have close links to research and that the research community is churning out research literature at an incredible rate.  Even those few practitioners (like myself) who try to keep an eye out for interesting ideas find it very difficult to spot those worth following up on.  

Personally, what I usually find is that potentially interesting ideas haven't been validated in any meaningful way so it's very difficult for me to justify the (large amount of) time needed to figure out if they are worth pursuing.

Eoin makes some great points.

After posting my original answer, I remembered a discussion I had with a Development Director I was shadowing (Development director was 4 managers above my peon position, shadowing was his attempt to show what executives did).  He said that he would invest $$ in a new paradigm/tool/process if (and *only if*) you could guarantee that it would save 10% (or more) of his development budget costs.  if it wouldn't save at least that much, then there was no interest in changing things.  A slight, incremental saving wasn't worth the expenditure that it would require up front.

In industry, it is *all* about Return On Investment (ROI).

I will relate my personal experience in installing a new solution development process in the last company I worked.  I am recently retired after 35 years in industry and am now working on my PhD in areas related to the software process I championed.

Some context: a consulting company developing solutions for medical device manufacturers, solutions developed on off-the-shelf Product Lifecycle Management software, I was the solution architect (in charge of everything non-personnel related), a new team of experienced people, a new customer (primarily the R&D department), a new (to us) off-the-shelf PLM product.

The process improvement change required several months of preparation on my part outside of normal working hours.  The core was a document and presentation of what the new process would look like, the roles of the people, the work artifacts produced and most importantly the rationale (design decisions I made) behind the the new ways to do things.  Since I was the solution architect I could push the new process and techniques down everyone's throat. (so to speak)

Putting a new process or new ways of accomplishing sub-tasks in an existing process in place involves organization change, which means people changing.  That is the hardness part.  This involves illuminating the problem, explaining the improvement, explaining the business benefits, the rationale of why the improvement reduces accidental complexity, getting people to believe or at least willing to try and some command insistence.

In this case the improvements started with requirements elicitation and documentation: modeling the requirements (no text lists); incremental and iterative requirements elicitation cycles; paper prototyping of requirements and design for verification; creating small demo prototypes for verification and new documentation formats.

What was also needed was the flexibility to adjust the details of the new process and tasks with real-time feedback while maintaining the goals of the improvement.  By drawing analogies to other engineering disciplines and their processes it helped to convince the other team members.  After the first deliverable cycle everyone was on board for the other deliverable cycles.

If it is a new methodology, that means it is not a proven process that leads to success. Not many organization will have the resources to do something that has not been proven. If the existing process works, why try something new unless the current process has not been ideal. As many answers mentioned here, a software practitioner seldom brings a new process. It must be started from the top (management, organizational wide). So to bring a new process to an organization, we must first convince the management that it is a worthwhile process.

The bottom line for management is profitability. A cost-benefit analysis of the new process would be useful (or even a simple list of the advantages/disadvantages of the current process versus the new process would be helpful).

The important thing is to motivate the people and to make them aware of the new process. There are several ways to do so (the answers above provide good points).

Maybe something pragmatic: A good approach is documented in Ove's paper (see link below). Furthermore, in one of my projects, the process group created an "Avatar", which is a twitter account for a virtual person reporting the latest news from the process group. This very person was also the protagonist in the process-included tutorial. Kinda funny idea - and quite successful (the avatar has dozens of followers).

https://www.researchgate.net/publication/220542224_Experiences_and_Results_from_Tailoring_and_Deploying_a_Large_Process_Standard_in_a_Company

Article Experiences and Results from Tailoring and Deploying a Large...

The only reason to deploy a new process of software development is when there is problem in the current process. Where developers are frustrated, where there is chaos in managing the process or deep gap of understanding each other while developing.

The new process should be experienced in other similar companies in terms of complexity of the development, the size of the company and it's RND group and it has to be trained before to all steak holders involved.

A lot of companied are trying Agile development methodologies (as my former company). When deploying this method the trainer will need to have a Team players from management of from TL to practice each developer when he starts developing in a different habit he was used to. The pilot will not  be complicated in its requirements and still to have as many developers to join the practice.

The new process success is being measured from its beginning and transparency of the results is a MUST!

Good Luck!

Iris

Dan Matheson - a question, if you don't mind.  Was the new process you set up, based around the tool itself, or was the tool used to augment the process?  Often one sees a new methodology/process implemented, because there is a new tool that implements said methodology/process.  As we know from experience one methodology is not sufficient for everyone doing software development, so if the tool is rigid in it's implementation, it might be more an impediment than help in changing the culture to the new methodology.

It is difficult

I have a paper which explains some of  the (mostly psöychological) reasons developers do NOT accept new methods.

Jerry - sorry for the delay I was in the mountains and not connected.  There was no tool in the sense of a computer-based tool.  The tools were mostly mental, getting people to think differently and approach the problem and the process differently.  Not just thinking outside the box, but throwing the box away in some instances.

The driving factors were my experience and frustration with text-based requirements, the inability to be agile (incremental and iterative) with text-based requirements, and a desire to use an engineering approach to software solution development as in other engineering disciplines.

For the graphical specification of the requirements we used a UML tool internally and VISIO for the customer facing graphical artifacts.  Now that I have this experience I can envision computer-based tools and improvements to the UML to support the modeling of requirements.  I shall continue researching these ideas.