DMS Facets

Relating several topics, including IT, Microsoft Access, sports administration, and micro-ISV business.

Three way street

0

Collaboration the hard way

crossedtracks I have recently had one of the more unpleasant experiences of my career in software, and have been reflecting on where did the process go off track.

Analogy

It was pertinent for me to think of a building analogy.

Let’s say you’re a plumber.  You’ve been looking after the plumbing needs for a particular client for 10 years.

Out of the blue, a building company gets in touch… “We have built new offices for your customer, and they’re waiting to move in. All we need is the water and sewage – when can you get it done?”

Well, supposing you value your customer, and you want to do your best by them.  Also, you know they are normally cost sensitive, so we have to aim for quick and simple if possible.  Especially as you are charging out your time anyway at non-profit discount.

On the other hand, this is obviously going to be a tricky job.  So you put aside your bamboozlement about why you weren’t involved in the process at an earlier stage, you adopt a task focus, and start drawing up specifications.

In the expectation that a collaborative relationship with the building company will yield greatest efficiency, you arrange for them to show you the new premises.  Trouble is, they keep forgetting to bring the key.  If there were ever any drawings, they have long since been misplaced, and the guy who can tell you what’s inside the walls is out of town. Only some of the holes you want to put through will they agree to.

You fly out of town at your own expense to kick the project into a higher gear, otherwise it will never get done.  The builder says he will do the plumbing himself, but rapidly backtracks when you call his bluff.

When you finally get inside, you find that everything not directly visible from the front door (which is as far as your customers have been allowed to go) is incomplete and in disarray.

And then, they have put a toilet pan in the middle of the board room, that they just know the customer will need, but they can’t let the customer in until all the plumbing is connected. But the only way to get to this board room toilet is by running pipes around the outside of the building and up through the garage floor.

Well, after a while you finally get it piped out, in spite of the difficulties. The builders are still not opening the doors, but somehow you’re getting it in the neck from your customers because they’re still out in the cold. And as for keeping it cheap, well, that idea went down the drain a while ago. Get the picture?

Reasons

All right, here’s the point. Unless I am mistaken, this type of process would not really happen in the building industry. It would not happen in transport, or hospitality, or fishing. But it does happen in the software industry.  Not frequently of course, but my experience is not an isolated example. Why?

I don’t claim to have the answers here.  But here are a few factors that may be relevant.

First, there is the notorious difficulty of being precise about software specifications in advance.  This is partly a result of the fact that software projects tend to be more individual, or in other words less similar to other projects that the developer has done previously, and so harder to put it within a familiar perspective.

Armen Stein discusses some aspects of this problem in this article.

Second, there is a tendency for the clients to not be clear about what they want; or not know what is possible until they actually see it; or not understand what is involved technically in achieving what they seek.  The average person would have a much clearer idea of what has to be done to put a door in a wall, than they do about what has to be done to synchronise data between two databases with different structures.

Perhaps even trickier, given the customer’s extensive experience with some aspects of computing as an application user or power user, they can therefore believe they actually do understand what is involved in database application development, whereas in fact they do not.

Third, there are the many competing technologies, some of them with their passionate adherents, and others where the approach to be taken is decided based on the familiarity and skills of the developer.

I am an Access enthusiast.  If a job can’t be done using Access, then it’s not a job for me.  Whereas I certainly refer on, in cases of Access not being the suitable tool for the job, on the other hand my experience and expertise in Access allows me to recognise scenarios where Access can work well, which others with an incorrect conception of Access will not realise.

When it comes to putting in a toilet, there is probably not a lot of variation from one to another, from the core technology point of view.  But for a database to track an organisation’s membership and finances, there are a bunch of wildly diverse ways of setting this up.

I think this factor makes it more difficult for collaboration between independent consultants working on different aspects of the project.  And again, the fact that the clients are not necessarily aware of this factor, can exacerbate the problem.

Fourth, there are a lot of unscrupulous charlatans about.

Conclusion

This has been a learning experience for me.  In this industry, one needs to be acutely aware of the special factors as discussed above.  They need to be allowed for and compensated for.

Trying to shortcut the communication about specifications, done with the best of intentions in the interests of expediency, can backfire.

Finally, remember who the client is. Communicate primarily with the client, and communication with any third party or other provider should go via the client.

So, what do you think ?