Estimation and the Inestimable


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?

The Art of Consulting – Judgement


If it didn’t sound bossy I would have adopted a strapline such as ‘We tell our customers what to do’ for LLP Group. It reflects our inescapable responsibility as consultants, our duty to advise. When we’ve collated the evidence, evaluated the objectives, determined the priorities and analysed the constraints, we must make a judgement as to the best course for our client.

As I wrote in my first post on The Art of Consulting:

A consultant uses his knowledge, experience, intelligence and imagination to investigate, understand, and advise on the resolution of problems brought to him by a client.


The art of good judgement is probably the most difficult we must acquire. It certainly isn’t acquired in the classroom, but rather through years of experience, and, sad to say, through our mistakes as well as through our successes.

As young consultants we’re usually too obsessed by theory or by technology, too willing to take a risk on unproven solutions, and we overestimate the capabilities of our clients and their eagerness to embrace new ideas.

As we age we get better at balancing perfection and pragmatism, at aiming for the achievable rather than the ideal, and in understanding the limitations of our clients and ourselves.

A junior consultant can be trusted to:

  • —Solve a technical problem
  • —Provide important research

An intermediate consultant can be trusted to:

  • —Determine what a client wants or needs
  • —Devise the most expedient solution
  • —Divine or determine priorities
  • —Perceive dependencies
  • —Calculate the risks
  • —Estimate effort
  • ——Judge whether the client is right or wrong

A mature consultant can:

  • —Judge what is really in the client’s best interests
  • —Advise on what is practically achievable
  • —Decide whether it is in the consultants’ interest to deliver the project
  • —Determine if a client is ready for the solution
  • —Determine if the consultants can do a good enough job
  • —Motivate the client and the consultants involved

When we advise, our judgements must be:

  • —Reasoned
  • —Discussed
  • —Documented

And, like it or hate it, with judgement comes responsibility, and often, indeed, legal liability (whether limited to a large number or unlimited). This is why consultants often obtain professional indemnity insurance as protection, and this is why we reserve the right to refuse, to say no, to withdraw in some circumstances, if our advice is ignored.

—It’s important we remember that a consultant is responsible for his or her advice in the circumstances. We cannot take responsibility for issues over which we have no control.

That doesn’t mean, however, that we should always insist that our advice be followed to the letter. We must often make compromises. After all, we are sometimes wrong in some particulars.

But if we feel that an important aspect of our advice is ignored in a way that we cannot mitigate, then, if we do continue to work with our client, we must document our misgivings and advise our client on how we believe the outcome will be affected.

We must also always be willing to admit that we are wrong or have made mistakes. Even our clients might admit that it is human to err. Admitting mistakes as early as possible, however awkward, reduces the risk of failure, and on occasion, might even earn you some respect.

I remember many occasions in my work as an IT consultant where things went wrong because I made a mistake (it is actually quite impossible to get complex business systems to work perfectly the first time). I’ve learned to avoid being defensive. It’s always better to say, ‘Sorry, I made a mistake.’ In most circumstances clients accept that this is inevitable and that they, too, are not immune to error. In most cases they are sympathetic, forgiving and supportive.

On the other hand, if you are evasive and concealing, trust might be forever lost. —We can also avoid mistakes by admitting our limitations. Our clients must know what we know and what we don’t know. —If you’re not sure of something – say so, and say why. Never lie – you’ll be caught out sooner or later – and don’t hide something that you think might hurt you later.

But, even so, remember you’re always, at least partly, a salesperson. —Make the best of the circumstances you’re in. See the glass as half full, not half empty and don’t advertise problems if you can solve them quietly. We also have a responsibility to put the best gloss on things that we can.

See also:

The Art of Consulting

The Art of Consulting – What’s the Role of the Consultant?

The Art of Consulting – Impartial, Honest and Independent

The Art of Consulting – The Essential Skills

The Art of Consulting – Listening

The Art of Consulting – What’s a Good Question?

The Art of Consulting – Representation and Analysis

The Art of Consulting – Writing Simply

The Art of Consulting – Designing (Completeness & Simplicity)

The Art of Consulting – Designing (Pragmatism)

The Art of Consulting – Designing (Affordability, Flexibility, Maintainability, Elegance)