Software development service business needs to change!

I have been working with different types of companies when developing products for Floobs and GigsWiz.  Before I began the startup episode of my life I was selling IT consultant services for small businesses. Selling software development-related services (also known as IT consultancy) is not an easy thing to do. Personally I have to say that there were more times that I have been disappointed as a customer than satisfied with these projects. One basic problem is to define the project and find out how valuable the service really is. Some of the most innovative companies in this field are using agile methods and doing a pretty good job in transferring that agility to their customer relationship. Majority of these companies work on an hourly basis which is problematic for the service provider. It is hard to estimate how many hours it takes to develop a feature. This morning I woke up with a new idea related to IT consulting / software development business. Maybe this could be the future?

We are developing GigsWiz using the Kanban process. In our process we have four phases; backlog, development, testing and deployment. Each feature goes through the process as ‘tickets’. Our tickets are basically user stories about features. We have one basic rule with tickets, they have to be as small as possible. We have a product owner and Kanban master from SCRUM process. We also have retrospectives but we don’t really do sprint planning. When developers take new tasks to development phase they plan the tasks together and start developing features. The requirements (graphics, texts etc.) are gathered to tickets in backlog phase. We measure the success and failure of our process by counting how many tickets we complete monthly.

Maybe software development companies could use similar process. Especially those ones who manage their own developers. Instead of charging per hour of work they could put price to each ticket. The backlog could be made together by the project manager from the company offering the service and the buyer.

I think that this kind of process would work quite well for companies who offer software development services. Maybe the smaller ones better than big ones. Instead of charging clients per hour they could charge them per ticket. I believe that they can get better price for a ticket than an hour because customers can enjoy the benefits of transparency and get more involved if they want.

In this model there are many benefits both for the company providing the service and the customer. Service providers have better understanding of how much value their developers are creating for the company and they know better what they are doing. Customers are happier because they understand better what they pay for.

What do you think?

August 27, 2010. Tags: . processes.

7 Comments

  1. Aki Björklund replied:

    I do something like this. When I sell my work, I try to base my fees more on the value of the job than the hours I put in. This requires that I find out why the client actually wants the job done and what is she expecting to get out of it, preferably in monetary value. Often she has not thought about it thoroughly enough and that leads to refocusing of the efforts.

    Then later, as a developer, I feel better when I can see that my work actually makes a difference. And, I can make a lot better decisions during development.

    • Kai replied:

      Thanks for the comment!

      How do you charge your customers? Do you have price/day, price/feature or something else…?

      • Petteri Torssonen replied:

        Hi!

        This was great article. Those charging methods would be interesting to read.

        Pete

      • Aki Björklund replied:

        Price per feature is more like it. Often I don’t go into feature level at all, I just give a price for a bigger, more manageable entity. If I have not enough information for value-based fees, I put in a guestimate price mostly based on some hourly fee. Unless explicitly demanded, I do not give out my time estimates or hourly prices at all. After all, why should the client care about such details, if she is paying a reasonable price compared to the value she is getting?

        With hourly rates a developer is lowering himself to the level of an assembly line worker. Sometimes software development truly is a bit like that, but why encourage that kind of thinking all the time?

      • Kai replied:

        @Petteri thanks for the feedback!

        @Aki thanks for reply! Now just hire a team and prove that the model works with larger organizations🙂 I am guessing that things get more complex when you have a team.

  2. Pyry replied:

    Interesting to read about your development process.

    I think the problem in selling tickets is the varying size of tickets. For example I guess a ticket could be a new feature as well as a localization fix. Ok on the average they will be roughly of one size over time. But will this cause the customer to avoid doing small fixes and the vendor avoid features?

    As a side thought the process gives me a bit waterfallish feel.

    • Kai replied:

      Thanks for the comment Pyry. I am not sure if i got you right but I think it is in common interest of the customer and vendor to do fixes and new features. In the end it is about prioritizing. Sometimes new features are more important than fixes and vice versa, right? If customer and vendor cannot agree what to do they have different problem at hand…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback URI

%d bloggers like this: