In my projects, I've always been the one who took care of infrastructure, standardization and quality assurance from the development perspective. The funny thing is that I'm no admin and no QA guy, so most of it wasn't even my job. In this article, I'm going to list a few things that in my opinion as a software developer are essential to a professional software project.
What you need is no secret: If you read a few books and follow some technology blogs you know the bits and pieces. I'll list a few things from a Java/Maven perspective, so some of this may or may not apply to other platforms.
First of all define a common coding style. I shouldn't even have to mention this, but there will be chaos and conflict among developers if you don't have it. Just use Sun's Code Conventions, make some exceptions like "maximum line length is 120 characters" or "no tabs allowed" and you're halfway done. Provide a bit of example code (one class, one page of paper) and put it up on a wall. This style guide should include rules for things like logging and exception handling strategies as well. Too few developers are even aware that you need a strategy here, so write it down! Don't forget to define package namespaces for your project.
For Java projects provide organization-wide Maven archetypes that give you a solid basis for your project. Use existing open source ones to get you started! The effort for this pays off with each new project in reduced setup costs. But wait, each of your projects is different? Oh please, then adjust your build scripts. That's no excuse to start from zero each time!
On a related note, invest in a proper internal Maven repository setup. Maybe use a stripped down version of Atlassian's setup. You don't want your builds to break just because some external repository isn't available. Define rules who may deploy what to your repository. I've seen a lot of chaos here, so remind people to actually think before deploying stuff and breaking builds.
Get yourself a proper bug tracker and define how you're going to use it. It doesn't have to be fancy, a Trac installation will do in most cases and it will give you a wiki for your technical documentation, too. Do you just track issues or also tasks for developers? What's the workflow? Who may open a ticket, who may close it? What amount of testing is required?
For god's sake, define rules for working with your revision control system. How often should developers check in? How should a commit message look? How does your release process look like? When do you create a branch, how are releases tagged etc. Read up on the features of your system, branching may no longer hurt. Move on if you're still using CVS.
A professional software project needs continuous integration. Period. Set it up (I recommend Hudson), define the proper reports and actually read them. It's crucial to check test coverage and other metrics right from the beginning. If you add reports later, you will typically get warnings for every other line of source code. Nobody will read those reports anymore and it's too much work to clean up the code.
Provide developers with a proper workstation setup that corresponds to the platform you're targeting. Yes, it's a good idea if everyone on the project used the same JVM and application server versions. If that's what your production environment uses, even better! It might improve the chance that things actually work. Just saying.
I'm barely scratching the surface here, but it's enough for one article already. For many of the points above you can find articles on the web (check my blog's best practices category, for example). And still, it's frustrating how little many software companies invest in those bare essentials.