Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
ALT.Consultancy: Reflections on doing it my way

Awhile back there was some discussion on the new ALT.NET list about what it would be like to start a consultancy with a bunch ALT.NET minded people. The hypothetical scenario proposed there wasn't quite what I did, but I thought I'd go ahead and share my experiences and how we addressed (or are still addressing) some of the problems in running a business like this.

The Background

Rob Eisenberg and I founded our company Blue Spire in October 2006. We were long time friends, and had worked together for about two years prior to starting the company. In that time, we were learning about Agile in general, as well as patterns, TDD, OR/M, the myriad of awesome OSS tools, etc.  We didn't know it, but we were developing a culture between the two of us. The elements of this culture included:

We started our consulting firm with the belief that we could deliver quality, human friendly software in less time and for less cost that the majority of other firms. (The genesis of this thought occurred over a decade ago when I was subcontracting for a large consulting shop, working on an 18 month project with a team of around 25. I'm sure I was pretty cocky back then, but I felt at the time that a team of 5 could have delivered more in less than a year.)

We began with just the two of us, and we envisioned growing to a team of 4 to 6. Smaller is better. Even at the beginning though, we felt that consulting was just a stepping stone to something else.

Kicking It Off

The question was asked on the list if such a shop could compete.  What kind of sales and marketing would you need? How do you break in and demonstrate to potential clients that you can provide a better value than super consulting company X?

We've had zero down time since we started, and we've had almost zero sales and marketing efforts.  We started off having lunch with other software development shops in the area. We told them what we were doing (without being derogatory) and we talked about overflow work, and subcontracting. There's enough business out there that the competition is pretty friendly.  We also offered ourselves at very, very reasonable rate. (We're now charging double from what we started, and we're probably going to raise our rates again this year.)

The majority of our clients have been other software shops. What's cool is that they saw our value pretty quickly. What's bad is that we were sometimes restricted from using the practices and tools that we wanted.

We also decided it was important to connect with the local developer community. Both for our own continuing professional development, but also for growing the reputation of our company. Rob has especially put in efforts to speak at Code Camps, and the local user group. It helps that we are genuinely excited about sharing. (This even helped us land a really fun agile coaching gig for the internal development team of a state agency.)

Convincing Clients

We've focused on Scrum for project management, and we were lucky to have a client who was already intent on using it. Nonetheless, even that client (who was not a software shop) required a statement of work. We estimated as best we could, and the client agreed that the SOW was a target and not a guarantee.

In our "sales pitch", we tell clients that software development in inherently unpredictable. We contrast "release early, release often" with "throwing the spec over the wall".  (There's usually a lot of resonance if they've had software developed before.) We (cautiously) explain to them that no one really knows exactly what they need up front. Change is inevitable.

What Really Happens

Our projects have usually taken one of the following forms:

  • The client budgets a set amount of hours.  We provide a conservative statement of what we think can be accomplished in that time.  We explicitly qualify the risks as soon as they are known.
    We get the client to buy into the project, by allowing them to manage the priorities for each iteration in the project (usually 2 - 4 weeks). In this way, they share the responsibility with us for hitting the desired target.
    Because of the iterative nature, they are aware of risks and problems early.
  • Some client are too deeply rooted in the idea of "build me X, in Y hours, for Z dollars".  We try to avoid that situation, but we've been there.  When that occurs we greatly exaggerate the hours (3x or 4x).  Funny enough, the exaggerated estimate is often within the client's expectations.  We've alternately benefited and been burned by this arrangement.  I don't like to do it this way.
  • This last arrangement is a mixture of the other two, and it's only been useful for periods where we would would have been between projects and when a client has some flexibility in scheduling.  Essentially, we budget some initial time to size tasks.  Again we pad the hours to mitigate risk, and then we allow the client to pick and choose the tasks.  We commit to delivering an individual task for the number of hours we estimated, but we are not committed to delivering the entire project for a set amount.

The first option is preferred and honestly it is the one that provides the most cost effectiveness for the client.  We only use the other arrangements when the client isn't comfortable with the first.

Some Final Thoughts

Here's a few additional observations:

  • Having the right clients is paramount.  You want a genuine trust relationship.  We had one project where trust was eroded (if it was ever present on their side) and it was by far the most stress I've had in years.  It's hard to turn down business, but sometimes you really need too.
  • Scheduling is difficult. Managing the pipeline is one of the more difficult tasks in managing a small shop.  When is this project really going to be over? What if the client wants to extend? How much downtime can we afford? At what point are we over extended?
    Everyone that I've talked to that has a small project-based business seems to have the same difficulty.  So far, we haven't made any clients mad, but we've had a few periods of overtime.  This would be easier if we were a larger company, but size has many disadvantages too.

I'm a developer at heart, and running a business has been challenging (and distracting). So I'd love to hear from anyone else who is doing this sort of thing.


Posted 05-18-2008 7:48 PM by Christopher Bennage
Filed under: , ,

[Advertisement]

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)