Creating a software company: Processes?

Let's say you want to create a software "services" company. By that I mean a company that offers software development services to customers, perhaps on a turn-key basis. (As opposed to a product company or ISV) Now if you want to grow to a bigger employee base than, say 10 people, you will need some way to co-ordinate activities and keep things organised.

What you need, they'll all say, is a well defined process.

There are some big standards in this sort of setup: ISO 9000, CMM and the like. I'm not a fan of multi-letter acronym standards; for small companies, these are more a pain in the backside than of any serious help. And for the entrepreneur, these are an absolute nightmare!

What you want is effective project management, and the ability to learn from your mistakes. That's all. Here's my take on what you need, and how you can ensure that you can grow your staff strength and still keep your sanity. Note that some of this can also apply to product companies (ISVs), so if you're an ISV with some time on your hands (oxymoron?) I hope this will help you.

Ensure you have the following tools:
1) A stable version control system
2) A bug/defect tracking system, with post-mortem cause analysis (a custom combobox might do)
3) A time tracking system
4) A project management tool.

Then, start writing. You need to write down, CLEARLY:
1) How you specify work. If you work with fixed specs, ensure there's a place to store (and search for, usign google desktop or such) specs. If you work on T&A, ensure you put in feature requests into a common area (perhaps in the bug/feature tracking tool)

2) How you develop: This involves your entire software development process; write down the different ways you can. I.E. where the customer's involved, where dev, qa and systems come in, whether you use milestones and deliverables, when QA does regression, how you use automated tests + smoke tests on builds, how you use automated builds (please do) and so on.

3) Version control: What happens when a new project is started, what is the format of user checkin comments, do you use edit-and-merge or exclusive locks, do you expect personal workspace checkins or only buildable checkins (or both) etc. Work carefully with defects as well: bug fixes should perhaps be marked in some way with the defect code.

4) Defect reporting: Write about how defects will be reported (area, steps to reproduce, workarounds, "owner" of a bug, bug states, approval procedure etc.) And write about how you will analyse WHY a bug occured, as a post-mortem process after the bug. (bad Spec, bug reported wrong, dev error, feature-not-bug, etc.)

5) Time tracking: Write about how your people report time they spend. Is it per spec, per product, or freehand? Are you using billing codes? Can you create estimates and link them with actuals alongside?

Now try and link them all together. Run through a cycle of projects and come back and refine these processes.

You may find that you need:
a) Better Specification and feature control. There are requirements management tools that can help.
b) Estimation recording and analysis
c) Organised learning and a central knowledge base

Or more such things. Now schedule a review of your original documents after every project cycle, and you now have a process of "improvement" also.

As a uISV, you probably hate this kind of stuff. But if you plan to be more than a handful of employees, having this planned out is essential.

Over the next few posts I'll try to write a bit about each of these topics, and a sample process document for each of the above.