The best way to convince people to change is to show what's in it for them.
First, realize that you have a long road to get from where you are to where you want to be. Doing this as a 'big bang' effort will likely cause problems with delays, pushback and it's difficult to sell as it's a lot of effort. Doing this bit by bit is the key.
You say the process is working, but has room for improvement. And in the comment you say "make sure that management trusts that we know what we are doing" -- you don't need trust, you can sell concrete benefits.
Work out what concrete benefits will the company see from these improvement. Sell each process improvement as something that addresses a concrete problem, not something that just 'could be better'. Argue why the extra effort up front saves time in the long run. Perhaps you find late bugs in development (a very common symptom of insufficient process), you can say:
Remember bug X in project Y. We found that late and had to do a lot of rework to address it. I believe we could have found it earlier by doing A, B or C. Can we trial one of these process improvements on a new project and see if it makes a difference.
Or perhaps the biggest problem you see is the amount of extra effort/overtime and the risk of employee burnout, so spin the improvements as addressing that.
Basically, identify what business impact of the process weaknesses are then sell the process improvements to directly address that. In the same way you'd sell anything, investing this amount now saves X times that later.
Do this for each improvement and do them separately, once you have a few proven improvements you can argue for creating a roadmap. Start with the improvement that you think will make the biggest impact for the least effort (low hanging fruit -- this is probably peer reviews, but not always).
You should definitely start with by approaching the software lead, but don't say "We should do code reviews". Explain why you think code reviews are important, how you would recommend they're done, how much resources (time and effort) you thing it will take and what the benefit to the lead is and what the benefit to the company is. Give him a complete proposal that he can take to his boss so that he have to spend time on it.
If they implement the proposal collect metrics to prove it works. If it doesn't work be prepared to work out why and reassess. It's easier to do this if you trial the improvement on only a few projects, so you can compare and contrast.
If the lead is on board you could start talking about a long term improvement plan, if he needs convincing work out the plan on your own and only share it once you've got a few successes under your belt.
Other assorted points:
Realize you're pushing against inertia in the organization. Particularly if they're more experienced engineers that have been doing this for a while. A lot of people really don't understand that the 'best practice' has moved on from when they were training -- or they were trained purely in software engineering (i.e. programming to solve issues) rather than the full software process. Here find the people most open to change, work with them to convince the others. There will be some holdouts but eventually they'll come round when they see the benefits (note, from experience, 'eventually' can take years ...)
If you get nowhere you may just have to accept it. Do what you can on your own, be an example. Talk about what you're doing differently, why you're doing it and what the benefit is for everyone else. If nothing else it'll make your life easy.
Ensure that whatever improvements you put in place are 'best practice', do research on them, as linked in the comments Joel On Software is a great resource, and there are plenty more if you search for them -- Google is your friend here, here's a nice breakdown from IBM. And of course there's all the information and advice on the StackExchange network (StackOverflow and Programmers are a good start). You can also use these resources to help sell the improvement.
You're unlikely to persuade the company to pay for external trainers or auditors, but they are useful because people tend to listen more when they've paid for the advice. One approach here is to show the your competitors are certified (i.e. CMMI) and argue that this is something that would interest customers.
Finally, let's talk about common code library. This is a lot more difficult to sell -- the copy/paste and tweak workflow is exceedingly common and if people are not used to using libraries they can be very much against them as it appears to be more work (or at least more learning).
Here the best way to start is to do it yourself, identify a few bits of code that could be common and start to build your own common library. Follow best practices, design upfront, document everything, build unit tests in to make it as bulletproof as possible. Start incorporating this into your projects. Then after you've done it you should be able to show why it's better and faster. Again, this is better with the support of the lead and some time, but just doing it where you can will make your life easier if nothing else.
