Estimation and the Inestimable

Share

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.

estimates

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?

FPPs – Mitigating Some of the Risks

Share

I’ve written two sets of notes on the risks of Fixed Price Projects in the world of ERP implementations. My own experience at LLP Group has taught me that the more thought and definition you invest in a project before it’s started, the lower the risk for both you and your client. This is true irrespective of whether you are undertaking a fixed price or a time and materials project.

See

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

Although you would hope never to have to refer to it once a project has begun, the contractual paperwork and the project scope and definition that it refers to or contains, are of vital importance in establishing an understanding between you and your client. If you don’t encapsulate your thoughts, ideas and discoveries in these you might as well not have bothered. Protection is essential both for you and your client, and the best protection is a clear understanding precisely documented.

contracts.jpg

Contracting and Scoping

When you enter into an FPP agreement with a client inaccuracy is the devil, ambiguity is the killer, imprecision is the plague. There should NEVER be a list of tasks that includes completely unqualified items such as:

  •  8 Management Reports
  • Assistance with Data Import from legacy systems
  • Support during Go Live
  • Documentation
  • Etc

What’s wrong with these? They are open ended. What sort of reports? (And what is a report, anyway?) How much assistance with Data Import, and what legacy systems, and how many times? How long is Go Live?

So, an FPP must be well-scoped with dozens of pages of definitions and clarifications, and descriptions of what the client will get. And if all of this is done with a client who understands the FPP game, that both sides need protection from undue risk, this is perfectly possible. We should do it even if we don’t get paid for it. Ten days given for nothing before the project begins saves hundreds lost later. And if you do it well, you also have a chance to impress the client with your understanding.

These are some typical areas of risk:

  • Data Import/Transfer from Legacy Systems
  • Reports
  • Training
  • Documentation
  • Interfaces
  • G0-Live Support
  • Delays
  • Accuracy
  • Payment Terms
  • Get-Out Options

Let’s look at some of these:

Data Import/Transfer from Legacy Systems

This needs to be qualified:

You must list the systems from which data will be imported and the data items

You must quantify the data – how many records?

You must make it clear that you assume that the data are ‘clean’ (i.e will not fail repeatedly on import because they don’t conform to the requirements of the new system)

You must specify the format in which data are to be provided and make it clear that you are not responsible for and estimating for the job of exporting the data from these legacy system

Your scoping document and contract should include a clause such as this:

‘Our obligations under this agreement include the importing by us of data into NEW SYSTEM. To reduce the risk of an open-ended obligation to spend an unlimited time on this task, we assume that:

  • These data can be provided by you to us in text-file or Excel formats as specified by us and at the time specified in the agreed project plan, or if delayed, as notified to us with at least two days’ notice
  • These data are ‘clean’ in the sense that they conform to the parameters of NEW SYSTEM and do not need repeated correction and reimport (we assume that import will succeed by the second attempt)
  • You confirm the correctness of the data in NEW SYSTEM in writing before any dependent tasks in the project commence
  • Volumes do not exceed nnnnnn records from system x, nnnnnn records from system y, etc

 

We reserve the right to charge for any additional time incurred during the process of data import if any of these conditions is not met.’

 

Next time I’ll look at some more areas of risk that need careful mitigation.

FPP – Estimating Fixed Price Projects

Share

I posted a blog a few days ago on Fixed Price Projects (FPP – A Frightening Acronym). FPPs frighten me because part of LLP Group (a part I’m happy to have sold) worked with the wonderfully open-ended Microsoft Dynamics business software products. We sold, scoped, estimated, and executed such projects poorly, to the extent that we made no margin at all, sometimes on hundreds of days of consulting, even whilst satisfying our customers. Our consultants and developers were no doubt excellent, but our sales processes and project management skills were insufficiently sophisticated and cautious.

Because of this I’m wary of FPPs, even if I know that they can be done well, can be controlled and can be profitable. To that end, I try to make sure that everyone in the company is aware of the risks and how they might be mitigated.

My last notes were about the Sales process. Here are some thoughts about Estimating.

estimating

Estimating

Estimating is a process that must involve both the sales and the consulting/development team.

It’s a time-consuming business. But FPPs get off to a bad start if we calculate estimates poorly on the basis of incompletely understood requirements, and half-baked solutions. Even ten free days up front might save hundreds of days later.

Of course, it’s the sales team that has to sell the project and who, in conjunction with management, must decide on price (for a defined scope), but our sales and management team MUST listen to what the consultants have to say. If they say they must know more about the client’s requirements, then the sales team must provide them with more. Never be tempted to think ‘Well, if I add another five days or so, that’s bound to be enough’. It isn’t.

And ALWAYS add contingency to your estimate. (And then more.)

In the end it is a commercial issue as to whether you knowingly ‘sell’ fewer days than you know that you need to execute the project. Whether that is commercially wise or foolish has nothing at all to do with the deadly sin of starting a project with inaccurate estimates of how much time the project will actually take you.

What if your estimate is insanely too low, and you discover that once you’ve started the project?

Well, it’s important when creating an estimate to make your assumptions explicit. This isn’t a slippery way of avoiding commitment, a trick that you’re playing on the customer. No, it’s an honest statement of the basis for your estimate. If it turns out that there are material facts that you’re unaware of, then you’ll be glad to be able to go back to the customer and ask for more time. And make sure that you make it clear that it isn’t your fault that you didn’t ask. You need to include a statement like this one in your proposal:

This estimate is based on materials provided by the customer and discussions with [named individuals]. Whilst we have built a certain level of contingency into our estimates to deal with the unexpected, the following assumptions are material, in that if they are incorrect our estimates may be materially wrong in either direction. These assumptions are [examples]:

  • In valuing your inventory you use only one method of valuation, weighted average valuation in local currency in conformity with statutory tax regulations
  • In valuing your inventory you value it only in one currency
  • You have no need for lot tracking of purchased, intermediate or final products
  • Etc’

 

And very importantly…

  • Your staff are motivated and committed to the process of implementation and will provide timely support as required
  • Your staff will be available for the time that we have estimated is required of them’

 

If possible you should build the estimation process as a first step of the project itself, or present this as a project stage where estimates and assumptions are confirmed. If necessary, give some free days to this, since your risk is greatly reduced by it, and you have a chance to demonstrate competence.

But if you do this it is also important that you build into your contracts an escape clause.so that both parties can terminate the contract or renegotiate it if the estimates or assumptions turn out to be incorrect.