I want to know everything that's in our project and whether it should be included in a release

By installing version control you know what's been checked in and changed by each programmer and when. By installing continuous integration, you know what artifacts are built and whether the latest changes actually compiled and passed tests. You can then look through the list and say, "This DLL has these five features -- I don't want those." You know what's there, and you can easily determine what should and should not be included.

When we change or add something, I want to minimize rework

SCM helps reduce rework. Why? Let's say you have a team of five people with no version control or continuous integration. This has been working okay, because you each have your own module that you work on. However, sometimes Joe and Sally both work on module B, and sometimes they overwrite each other's changes! They then have redo their changes. By installing version control, even if Sally checks in her change only half a second behind Joe's change, the version control will still prevent her checkin, will show Joe's changes, may even merge her changes, and will show those things that it can't automatically merge. She can talk to Joe right then, they can hash out the differences, and the team can proceed having incorporated both Joe's and Sally's changes.

Continuous integration helps reduce rework. When someone changes something, as soon as that change is added to the common pool, everyone knows if it integrates with all the other code, as every change is immediately integrated. Sally checked something in, and it broke the build. Joe now knows that Sally's change didn't work, so he also knows that he should not start work on something else that depends on Sally's change. Thus, until Sally's change works, Joe won't waste time on something that depends on flawed code.

I want to know that if some change breaks something, we can easily back that change out

Using atomic commits, like Subversion supports, if used properly, allows you to say: "I want to know that if some change breaks something, we can easily back that change out." This is as easy as saying, "In the log, Joe, checked in this change, and we know that's what broke this feature of Sally's, so we'll just right-click and revert changes from this revision, and it's as if the change was never included."

I want to know that every time we release, our release process won't add bugs to the project or cause the program to behave strangely.
I want to be able to reproduce anything we do: same inputs mean same outputs -- I want to be able to consistently replicate what I've produced

After talking with managers and technical staff, I determine what's expected in the final release. I find out the idiosyncrasies of the code, such as which DLLs should be COM-visible. I determine who did the last release, if applicable, and write down the steps they took. I then put together scripts that codify every step and which automate laborious or repetitive tasks. Therefore, for any given input, the exact same outputs will be generated on every release.

The customer keeps changing things -- I want something that can help me respond, adjust and incorporate changes easily and quickly

The customer says, "I want a new feature that wasn't in your initial plan." You talk it over with the developers, and you find out that it will be a significant amount of work and will require major changes to one existing module. How do version control and continuous integration help you "respond, adjust and incorporate changes easily and quickly?" One solution is to branch and set up a separate continuous integration server for the feature branch. Then, every change that the developers make to this branch will be logged in version control, and the feature will only compile and work if every change builds in continuous integration. Furthermore, you can merge over changes developers are making on the mainline, and so by the time you finish developing the new feature, you simply tell version control to merge all of the tracked changes back to the mainline, and your working, complex change is included without disrupting the existing development -- all of this from a confined area where it could not slow primary development.

I want to have more control/situation awareness over the development process

If you want significant control, we can set up a change control board with specific policies. We can organize the repository and set up access controls on SVN such that only specific people are allowed to change specific pieces of code. By instigating a best-practice whereby we "checkin early, check in often," there will be many log entries, and you will be able to read those log entries to know what exactly is in your code base. By including everything in source control, you know all the pieces that are needed, and by setting up an automated release process through scripts and steps documented right in those scripts, you know every element of the release workflow. If we set up a bug-tracking system, and you incorporate a policy where everyone must use that for every change made, we can even integrate certain bug trackers with source control, and you have a direct link to read what the programmers have written.

I want to be able to release to my quality assurance department more often

When continuous integration is running, every time the build is good after a change, that's a potential point to release to QA. Furthermore, with appropriate influences, you can develop a culture where developers keep the source in a "release-ready" state by the nature of what they check in. If every programmer checks in once a day, that's a lot of potential change points to hand off to QA. Even if you only make a QA build once a day, if the release process has been automated, you can easily kick off that release process every day and have a release for your QA team to look at, knowing that the release works (because the automated release process ensures that) and the code compiles (because continuous integration ensures that) and the only changes since the prior day are all included in the version control change log (which has datestamps), so you know what got included that may cause any bugs the QA folks find.

I want to buy something that saves me a lot of money down the road and pays for itself many times over.

Process improvements should be iterative and should be taken in small chunks. With that mindset, we can implement small, discrete improvements that each stand alone and which each provide some benefit to your organization. You can decide you've gone far enough and stop adding improvements, or you can continue taking bite-sized chunks. You may also be interested to know that most of the tools I recommend are inexpensive or free, which significantly reduces licensing costs. Also, by using virtualization, we can ensure that your hardware is fully utilitized and that you are exacting as much benefit as possible from any new hardware investments. If the new systems and processes save developers only 5% of their time (less than half an hour a day), and you have ten developers all paid $40/hour, and your total improvements cost, say, $8,000, that means you'll have paid for the cost and be saving money two and a half months after purchasing my services.

I want to work with someone who's honest, and I want to honestly tell my customer where we are

Integrity is part of our services, a foundational tenant to our business (our values). That's something that you'll really have to find out for yourself, so I would encourage you to talk to others who have used our services or to give us a try on a small project. And regarding the other concern, when you can look in your bug management software or commit log and see everything that's currently done, you can honestly tell your customer, "This is what we have right now." If continuous integration and an automated release system are also set up, you can even say, "...and I know that what we have works, with these specific bugs we've found." If you want to take it a step further, add all future tasks into your bug/task tracking system, and you can say, "...and here's what we have yet to do. We're 65% of the way there."

I don't want to hire some new body full time or have to put them on payroll

We are an independent consulting company, so we'll work with you as an independent contractor within your existing contract, or we'll set up a new contract between our two companies. Either way, you're getting our services for as many or as few hours as you want, and there's no long-term relationship other than what's spelled out in the contract.

I don't want to have to think about this new solution. I want to plug it in, push a button, and have it just work for me.

We source the hardware, and we simply tell you what to buy. We install and set up all the hardware and tools. We work directly with team leads and developers to determine what modules there are and what pieces need to be incorporated in a release. When it's all set up, we even schedule and deliver a presentation to the team on the new systems and how to use them, and if you want further training, we'll outsource the training to an appropriate vendor. If you want ongoing maintenance to really ensure those new systems stay out of your hair, we'll set up a maintenance contract with you to keep your existing systems running and to continually improve processes. We can deliver a turnkey solution.