Regarding your comment on fix-bid’s leading to poor quality, I had a different experience at my firm. Yes, I agree that it does sometimes lead to poor quality as developers rush to meet datelines, but that’s where training and experience comes in to play. I myself have seemingly made short sighted decisions to get a piece of functionality out the door, incurring technical debt that would come back 6 months on and bite us and it up to the senior technical staff to work with (or fight against, depending on how you see it) management on when and where to take hits. It also required a change in culture where “hey, it works” is just not good enough.

But this is where the key account manager earns his salary. Ours would not only aid in the initial bid, but would manage the customer’s expectations and the project goes on. If there is a change, its a CR – more money. After the first cycle, our customers started to realized that they themselves had to ‘know’ what they wanted, or at least ask for our recommendations. That aided the process significantly. We’ve also reduced our project cycles to 3-6 weeks from 2-3 months in order to deliver quicker with less divergence from what the customer wanted.

Its too easy for technical people to just focus on the technical aspects of a projects. Working with our key account manager made me realize that that’s where battles are won or lost. Having the customer trust us and willing to understand our position, esp during changes or delays, enables us and them to work together to ultimately deliver solutions that results in a win-win for everybody.

It ain’t easy, but its possible.

“our biggest customer has changed their cost model and forced us to charge on a fixed price model – which would lead to more interest in training to increase overall efficiency. What may take 5 days, now take 4 – leading to a reduction of 20% input costs.”

This model has other costs. Almost every service company I worked at used a fixed-bid model (I am also an ex-service Co. employee). I agree that it increases efficiency, but it does not lead to well designed products, and it runs the risk of costing the service Co. money, rather than making a profit. Customers (of course) would ask for changes during a project, after the bid had already been signed off. Some of them were pretty significant and couldn’t wait for another development cycle. The only thing was they didn’t want to give us more time or more money to incorporate their changes! So inevitably we would deploy projects late and over budget (for us), leading to a lower profit margin, or even a deficit that we had to eat. This was even with extra hours put in to try to meet the goals.

The quality of the talent that we had was decent (if I do say so myself). We had some things to learn, and there was some allowance for that. The quality of our designs were often passable, not great. There wasn’t time for that. One service Co. I worked at more than 10 years ago allowed time for its developers to train themselves on new technologies, and to work on non-revenue-generating internal projects that would improve our service offerings. That was usually good and I enjoyed working on those projects. Even so we still had problems meeting deadlines and our budgetary expectations given the fixed bid model our customers used. I remember advocating for a T&M model at the time, because of the overruns. The discussion about T&M above has been interesting. There were some things about it I did not know.

I agree that long-term thinking ought to be part of the equation. In talking to service providers, though, I find that it isn’t, not to the degree I would naively expect it would. I wrote the post as a way of trying to empathize with that position.

“Cheaper is better” is a small factor in the sales process. Engaging a service provider is not like buying stock, where price is all that matters. Relationships, ego, history, and scale all play a role as well. I haven’t observed it directly, but from the externally visible behavior it seems like some buyers are swayed by the argument that they have a big problem needing big resources like the 12 person team, not one of those little problems that only require 5 people (ignoring the quality of the team).

Interesting read, and the math makes sense. However, there are a few more factors that should be included, I think. Time is one – doing the math over several projects instead of just one project, as both Dave Thomas and Derick Bailey commented upon. Another important one is competitiveness.

For a service company, there may be a competition to win the project. Let’s say one service company competes with the senior team (from your article), and the other service company competes with the senior-led junior team. Assuming the two companies estimate they’ll finish the project in the same amount of time, the company with the junior team will quote a price that’s 60 % higher than the company with the senior team. It’s obvious which bid the customer will prefer.

So while, in isolation, it makes financial sense to have a bunch of juniors and a few seniors, in the market, over time, it may mean that you get less business.

Maybe you should not target services companies. Instead, target service companies’ employers. If you can replicate the kind of efficiency, I believe companies with IT department/organizations would be interested to know the secret to producing the same result with fewer resources.

Let me make sure I understand your point. If I can serve my clients with 5 programmers instead of 10, that should let me serve twice as many customers. Is that it? A customer in the hand is worth two in the market, though. With my business hat on, there’s much less risk in selling more to an existing customer compared to trying to find a new customer. So, as far as I can see, it’s a bad assumption that an increase in productivity will automatically turn into more customers.

I agree with your point about having a portfolio of customers. However, that doesn’t negate the numbers suggesting that the “senior leadership” team is more profitable.