The idea of creating legal products is not new. Just over 20 years ago I…
Estimating projects is never an easy task, even for seasoned project professionals. Solicitors estimating litigation costs and preparing case budgets as part of the Costs Management Pilot Scheme seem to view the exercise as worthwhile, but appear uneasy about their lack of expertise concerning detailed cost (project) estimation.
The discipline of project management is replete with tools and techniques to assist with project estimation. What follows are a few basic heuristics that project estimators – including solicitors – may like to bear in mind. The principles below should be applicable when estimating potential litigation costs.
1. Estimators need to make sure they have a good understanding of project size first.
Estimates relating to resources, effort and costs will reflect project size. This sounds really obvious, but until all project tasks have been listed and understood, it is extremely difficult to appreciate the size of the project ahead. So estimators should first concentrate on listing all tasks first before they try to start estimating.
2. Estimators should create appropriate task lists
In the Costs Management Pilot Scheme, precedent Form HB lists litigation stage categories – such as ‘Disclosure’, ‘Witness Statements’ and ‘Experts Reports’ – against which solicitors should fill in cost estimations as part of the case budget plan. Obviously each of these categories can be broken down further so that with reference to Disclosure for example, an immediate sub-listing might look something like:
- Advising client of disclosure obligations
- Gathering documents for own party’s disclosure
- Reviewing own party documents
- Creating disclosure list
- Inspection of own client’s documents by other parties
- Reviewing other parties disclosure
- Applying for specific disclosure
- Applying for disclosure before proceedings start
- Applying for disclosure by a non-party
These immediate sub-categories can be broken down still further. To take the most obvious example, when reviewing own party documents: approximately, how many documents are there? Does the number of documents require special storage arrangements (eg a trial prep room)? To what extent to the documents need to be categorised? Who will do the categorisation? Will IT assistance be required? And so on – keep identifying tasks required.
One of the most common mistakes in project estimation is simply not taking into account all of the tasks needed to complete a project successfully. So start by listing all tasks. Try to break tasks down to a reasonable level of granularity, as it is easier to appreciate the effort required to complete a smaller task than it is for a much larger one (see below).
Also, one reason why its best for the people who actually do the work to do the estimates is that they will know all about the time needed for preparation, research and general running around in order to set-up and complete a task. When you think about it, this ‘other’ effort, which is often unseen by those not directly involved in task execution, are also tasks and so should of course also be factored in when preparing the task break-down.
3. Whenever possible, base estimates on historic data
Generally, estimating is best done when based on historical data of previous projects which are similar to the one at hand. Lawyers are lucky here as their Practice Management Systems and / or Case Management Systems should hold this kind of historical data. Ideally the historical data used should be from cases the lawyers responsible for preparing the current estimates worked on previously. In the absence of that, lawyers should mine historical data of similar cases worked on by others in the firm. It should be relatively easy for IT departments to produce reports which group together cases of similar type and then sum and average out the amount of time taken for particular tasks, such as reviewing own party documents for example.
Whilst, to a degree, every case is different it is also true that there are plenty of similarities between cases – after all, if this were not so there would be no such thing as Precedent in common law. Legal estimators should therefore take the view that past case management performance in similar cases is a pretty good indicator of future performance.
4. When using historical data, focus on relatively small units and tasks.
Obviously linked to point two above, estimation on a smaller task by task basis will generally be more accurate than trying to estimate a project based on over generous categorisations of tasks. When reviewing historical data, slice the data into tasks which match the initial project task listing.
5. Generally, in project estimation it is better to over-estimate than under-estimate.
Ah, there could be a problem here when estimating litigation costs. This heuristic is commonly applied when managing projects of all kinds outside the law, and it seems to be especially relevant to software development projects. As a general rule, estimators and project managers build in a contingency of about 20% across the entire project.
But what of estimating potential litigation costs? Although Form HB encourages parties to list identifiable contingencies, there is the issue that if a party is seen to attempt to inflate its costs – so that costs estimated are not proportionate to the claim – a Costs Order can be made. On the one hand good project management practice encourages contingency and therefore a degree of ‘over estimation’. Contingency is allowed as part of the costs pilot scheme but where, I wonder, is the line being drawn between costs which are reasonably contingent and costs which are viewed – and presumably therefore disapproved – as being ‘disproportionate’?