Expert, Schmexpert

Every now and then I'm asked to bid on a project and then the would-be client takes my bid to another develper, to get the same features, so the client thinks, at a lower price. After all, database work, web development, business process reengineering done by one software development organization is as good as that done by another, right?

Tell that to a person undergoing heart surgery. Even the crudest of measures -- the number of heart operations done per week by a heart surgery team -- shows great predictive value in survival rates. Still don't care who does your heart surgery?

But software development is easier, right? So anyone with training can do it, right? This is all just sour grapes on my part, right?

I don't think it's just sour grapes, as I remain busy, so having work to do isn't an issue. If I got more business I would be giving more business to associates, which has some pleasure in it, for sure.

Mainly, though, I am saddened when people with whom I am working make uninformed decisions. If my prospective clients read this and choose the lower price, that's fine, because they will know what they are not getting, as well as what they are getting.

Don't all software professionals produce alike? Those who write about software development think not. Formal degrees tend not to predict productivity in this field: most of the really top people I know all trained in other fields (as did I) and many have advanced degrees (MBA, CPA, PhD) in those fields (as do I). We find this work as challenging, and as engaging, than that which we used to do.

So how can there be so many people engaged in this field if it is so complex? The answer is that only a certain number are handling the complexity. For the rest, the complexity goes unmanaged.

The results aren't as immediately visible as in heart surgery. The results are as certain, though: unmanaged complexity leads to random results. Oops.

What To Look For

So, what to look for when you are putting the success of your business in the hands of someone else? It's a difficult issue.

Should you look for "number of prior projects like this?" The problem with this is you could be buying an organization good at marketing.

Should you look for happy clients? Good start. In a sense, the best proof does lie in the pudding.

Should you look for the biggest organization? If it is a company that has to survive on its own, this could be a favorable sign. In other cases, it might mean only that the company had a lot of money sunk into it and committees made safe, not necessarily good, choices. Some of the really terrible software I have used was written by a very large company for Medicare.

Should you look for the smallest organization? Small isn't necessarily better, although you might get more personal attention. Small might also mean not enough talent to handle multiple areas of complexity.

External signs, with the exception of happy clients, are not good predictors of success for your project because, with the exception of "happy clients" none really taps what is the essential ingredient: the ability to manage complexity well. This can be done in large or small organizations, but always is done by individuals and small teams: large organizations may at their best be able to handle the complexity of managing teams, but it is the teams that manage the complexity at the software/business process level.

And determining the ability to manage complexity is not easy for a software development client. One place to start is the proposal: does one proposal show more recognition of complexity of the task, and show knowledge of managing that complexity, than another? If so, that organization has demonstrated at least two aspects of its capability in managing complexity: recognition and planning.

It might be the case that the organization capable of managing complexity costs more: it costs more to manage complexity than to leave it unmanaged. When you take that proposal to the lowest bidder, you may be getting only that for which you are paying, in terms of the ability to manage complexity. How will you know? Time will tell...

~Hank