I’ve just spent the day training some of my colleagues in ‘non-technical skills for consultants’, those skills that aren’t specific to any particular profession but which you need irrespective of whether you’re a lawyer, an engineer, a project manager, an IT consultant, an architect or any other kind of expert peddling his or her expertise.

What’s common to all professions is the requirement that you listen, ask good questions, structure facts and opinions well (thereby demonstrating your understanding of your client’s predicament), document them well, explain them and present them well, design solutions, make good judgements, persuade your clients of the merits of your judgements, implement your recommendations well, and so on.

There are a lot of skills on top of the technical ones.

(See The Art of Consulting – Some Golden Rules)

They’re not really skills that can be taught. My aim is to show how important they are and to provide examples of how they can be exercised well or badly. How do you teach good writing other than by providing examples of clarity, simplicity and brevity? How can you teach good design other than by pointing at something that’s well designed or badly designed? What I’m trying to instil through this training is an awareness that these skills matter and that complexity, redundancy, cliché, obscurity, and so on, should be avoided.

Judgement is the hardest topic. Consultants must assess what they’ve found out (facts, opinions, capabilities, priorities, and assumptions), and recommend a course of action in the (well-documented) circumstances. That is what they are paid well to do. It carries risk, and consultants are often wrong, something that consultants and clients must always be willing to admit and understand. But clients don’t engage consultants to tell them what they already know. They engage them to tell them what to do.

One kind of judgement in particular haunts businesses of my kind – estimation of effort required. We (LLP Group and systems@work) configure and implement business software packages. We’ve had more than two decades’ experience of understanding what our clients need and we’re good at designing pragmatic, value-for-money solutions. We’re even quite good at estimating how long it will take to configure and implement such solutions, as long as they don’t involve extensive software development.

But when it comes to software development itself our judgements are too often unreliable. Of course, we usually pay the penalty for that ourselves, because software development is very often contracted on a fixed price basis. Even after nearly forty years in the business of software development I still can’t understand why estimating how long things will take to develop is uniquely difficult. But it is, and not only for my company.

I remember the scorn I expressed nearly thirty years ago when I first came to ‘Eastern Europe’ and was told, ‘Well, how can I know how long it will take until I’ve finished it?’ when I asked for a software development estimate. I was used to asking the question and getting a number in reply.

But of course it was always the wrong number, and almost always a number lower than the number of hours, days, weeks or years a task would actually take.

The fact is that it is hard to predict the implications of change deep inside a software system without fully working it out in advance. And fully working it out in reality means actually doing the task. When it comes to the development of our own very sophisticated business software packages – time@work, expense@work and forms@work – it is the same. I have received estimates for years for enhancement work, and they’ve always been wrong. And I’ve long since given up the blame game. Things just have a habit of taking as long as they take. So now I ask whether it’s a big task, an intermediate task, or a small task and we fit as many of them into the available time as we can, assigning appropriate priorities so that we do the most important ones first. And we accept that our release dates must recede into the future.

What is the alternative? Does anyone have an algorithm for determining the impact of change on a system (all the places where one change implies another) or for measuring the complexity of change (which implies how likely it is that the team will do it correctly)?

Consultants must make judgements all the time, but sometimes they must accept that their judgements will never be as accurate as they would wish them to be., especially when it comes to estimates of the human effort involved. Some tasks are simply inestimable.

One of my colleagues recommended the Window Method. Look out of the window and think of a number.

Another recommended taking the average of multiple estimates. But in this case you would still have to double the number, at least.

Another recommended obtaining estimates, measuring actuals, discussing the variance and applying sanctions. But I know this doesn’t work.

Any other ideas?