Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A service software company is like an outsource company. You give us the requirements, we band the result for you.

This is a unique situation where each project is short lived and vastly different from one to another.

I'm interested to learn if anybody is successful in running this kind of company and any good resource of setups like this.

Thank you!

share|improve this question

closed as not a real question by gnat, Walter, Thomas Owens Oct 11 '12 at 20:27

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

After the "short lived project" ends what does the customer do for maintenance and upgrades? Some studies show that creation/acquisition is only 20% (some show it as low as 10%) of software TCO (Total Cost of Ownership). I'm not bashing your idea, just asking, "and then ...?" – Peter Rowell Oct 11 '12 at 5:22
Very valid question and this is what I want to know more too. :-) – Seymores Oct 11 '12 at 5:29

There is something like a de-facto standard for running IT service companies - ITIL. It is a collection of good practices for many aspects of IT service delivery - administrative organization, dealing with requirements and customer requests. I am sure you will find a ton of useful advice in those books.

It is compiled from experiences of successful service providers and kept up-to-date.

share|improve this answer
Very useful, thanks! – Seymores Oct 11 '12 at 6:25
@Seymores you're welcome and good luck – kostja Oct 11 '12 at 6:44

You have to provide some benefit. Most software development firms are fully capable of doing their own project management, so your value strictly as a middle-man is not particularly obvious to the client.

Instead, you need to fill some hole that isn't already being filled. Here are some things that will help you stand out and provide benefit:

  • Provide a local in-person presence to the client
    This is by far and away the single most important and powerful thing you can do. There are tens of thousands of organizations on the Internet trying to do the exact same thing as you, and the probability is that half of them (if not more) are better at it than you are. What they aren't is local. By meeting in-person and face-to-face with the client, discussing their concerns, listening to their stories, responding to their questions, and most importantly giving them a tangible sense that you exist, you provide for a large percentage of clients a value-add that is worth, from my experience, up to around 50% of the project cost. The value of this is a personality thing that depends on the client's own disposition. So it doesn't always make a difference. But for those that need it, it's a huge difference.
  • Provide a guarantee
    Outsourcing is risky. There's a very good chance that they'll put out tens of thousands of dollars and be left with nothing of value at all. By taking on some (or all) of that risk, you can help justify your cost. Part of your job is to sort through the mountains of contractors and find the good ones. Your field experience can help decrease your own personal risk allowing you to offer a better deal to the client than he'd otherwise get. Our firm offers a solid and unconditional "satisfied or you don't pay" guarantee. This has gained us much more than it's lost us. On risky jobs we may double-book development and build a backup solution at the same time just to be safe. On the surface that sounds expensive, but the certainty is part of our product.
  • Translate into tech-ese
    Even if developers ostensibly speak the same language as the client, they rarely understand eachother. Part of your job, a large part of your job, is to speak to the client in terms the client understands, and speak to the developer in terms the developer understands. You need to find out what the client actually wants, and get that built, even if he can't articulate it. Developers work best with a black-and-white specification that leaves nothing implied. Clients typically lack the background knowledge to produce such a thing. That's your job.
share|improve this answer
THanks for the great input. – Seymores Oct 11 '12 at 7:25

Not the answer you're looking for? Browse other questions tagged or ask your own question.