This week I'm focusing on scoping - for me the most important step in the process. Good and detailed scoping can make the difference between a quick and efficient automation project and one which becomes a black hole of time and expense. The aspects that I will cover in this post are:
- what level of automation should you aim for?
- how much time should you spend on scoping?
- what output should you expect?
What level of automation should you aim for?
It is quite easy to get swept up in an automation project and want to go all out to achieve the highest level of automation. This kind of enthusiasm is great but consideration should be given to: (i) the complexity of the documents (again!), (ii) whether the documents are typically the subject of extensive negotiation and (iii) your risk appetite for letting non-legal teams produce documents once they've been automated.
Concerning complexity, I would always recommend breaking the automation of a complex document down into a series of iterations. Automating a complex document fully can take a long time and it could be months, if not a year, before you start to derive any benefits. In this case you should identify some quick-wins, prioritise and automate those, and then gradually work on the more complex features. This is a great way to help with stakeholder buy-in that I referred to in my previous post and to validate the project without incurring too much expense.
As regards negotiability, you may decide that, because you work in an area (e.g. procurement) that involves a lot of back-and-forth on documents, you may just want a well progressed first draft rather than an execution version - enough to nail the boilerplate, get your party details sorted and perhaps your data privacy terms lined up. The rest can be the subject of commercial discussion.
In respect of risk appetite, there will be some areas where you just don't want to run the risk of a non-legal drafter getting things wrong - either because the stakes are too high, there are a high number of documents being produced which need to be consistent or they simply don't have the legal knowledge. In these kinds of situations you probably want the document produced to be locked down and uploaded straight into an e-signature platform. You therefore have to go fully automated.
How much time should you spend on scoping?
The short answer to this is, as long as is required to make sure all stakeholders are comfortable with the automation you are about to commence. I include in that group the automation vendor.
It is easy to think that once you have a template, containing all the square brackets and footnotes it needs, you are ready to go. However, those "static" (i.e. non-automated) templates and the optionality and guidance contained in them rarely account for all the permutations that could form the output of automation. Nor does that template usually provide any logic structure, flow or wording for the questionnaire that will need to be completed to produce the output.
In the case of a simple document such as an NDA, I would therefore recommend doing at least a quick page turn with your vendors to ensure there is clarity on all of the above.
In the case of a more complicated document such as a security document, you are more likely looking at a few 1-2 hour meetings to make sure that the above is all in order and ready to automate. Any legal expertise that your vendor has in the chosen field will be a plus here.
This might seem excessive and at the end of the day it is only a guideline, but in the CC Dr@ft team we recommend a ratio of effort for scoping: development: testing of 3:1:2. I also can't highlight enough how much easier it is to build from the outset based on a complicated specification, than it is to reverse engineer it from halfway down the line - something which could be very important for auditing purposes.
What output should you expect?
At the end of the scoping process, in addition to a price range and timescale, you should have agreed with your automation vendor the following:
- in respect of your infrastructure:
- infrastructure design: the breakdown of your test and live server environments and any special arrangements such as how users would log on to those environments
- styling details: a list of any styles or visuals that you would like applying to your environment
- approval workflows: if applicable, a summary of any approval procedures that you would like implemented for your soon to be automated templates
- in respect of the templates themselves:
- marked-up documents: showing where and how functionality is required
- questionnaire structure: setting out roughly how the questionnaire should look and feel (at CCAS we provide a mock-up of the questionnaire for clarity)
- logic flow: if required, clarity on any particularly complex logic
- high-level testing strategy: if required, a summary on the testing strategy for the particular suite of templates and a means by which to collaborate on this
At CCAS, we split our scoping into two phases.
The first phase provides an estimate price range for automation based on our review of the static template(s) and limited discussions.
The second phase involves a detailed review and discussions which give rise to the outputs listed above, following which we then refine our proposed pricing and timeline.
Scoping is, of course, a significant step in the automation process and we have only scratched the surface above but hopefully this provides a good overview of what you can expect (from CCAS at least).
For the next article in the series, we'll move onto development - where the magic happens!!!
Get in touch
If you've found this article helpful and would like to discuss our approach to template automation further, please get in touch by emailing firstname.lastname@example.org.