Top 10 Reasons to Automate Your Contracts in 2010

In this, our final post for 2009, we'd like to wish everyone a Happy New Year and share with you the top 10 reasons to automate your contracts in the coming year. By automating your contracts process you can:

1. Reduce the risk of using non-standard or incorrect contracts, templates or language
2. Reduce the expense involved in creating contracts
3. Decrease the time it takes to create and negotiate the contracts on your paper
4. Increase compliance with policies and procedures
5. Globally update your templates and language once and immediately for everyone in your organization
6. Spend time on high value business instead of creating and reviewing repetitive, mostly standard contracts
7. Rate your contracts according to their value to your organization and incent your business people to create great contracts
8. Create contracts through a browser so you don't have to worry about supporting or maintaining a desktop application
9. Integrate your contract automation with CRM, ERP, and other systems so you only input data once and capture everything at the end
10. Optimize your contracts with the most favorable business terms for your organization

So there's our parting wisdom for 2009. Did we miss any good reasons to automate the contracts process? Please let us know in the comments below.

Three reasons to have a post [Software] implementation project

I recently read a post on TechRepublic by Jay Rollins which said that within six months to one year after an initial software implementation project is complete, there is always a need for a second project to address opportunities that arise from the original implementation.

I agree with Jay that a post implementation project is an excellent process by which to find additional opportunities not covered in the original implementation. For our document assembly clients, we find that they benefit from added value uncovered during this process.

I'd like to add two additional thoughts to Jay's thesis as to why to undertake such a project.

One of the first reasons is "the law of unintended consequences;" for example, if one particular department within a company was the driving force for the implementation (let's say the legal department) of a new technology or application, it should be noted that this is only one cog in the overall process or value chain. Legal may touch areas including sales, production, risk management, procurement, finance, and human resources; and the technology they implemented could have unintentioned (read; "beneficial") consequences to many other departments. In fact, these benefits may be greater outside of the original department that mandated the new technology.

Another reason is money. Often, initial projects are limited in budget with most of the budget being spent on the technology. After 6-12 months, an organization can much more easily "wrap its head" around how to make a new technology even more of an "exact fit" for their particular use and, more importantly, can quantify the benefits or the ROI of an add-on optimization project. These benefits could include deeper integration with front end and back end systems, application customization, enhanced training, roll out to other departments, and many other substantial benefits.

Have you been a part of a post implementation project? Please share your experiences with us in the comments below.

This post was guest authored by Lowell Moritz, Exari's VP of Account Management. Lowell runs post implementation projects for Exari clients.

Document Assembly Solution: How to Decide Build Vs. Buy?

OK, everyone now agrees; your current way of creating documents is broken (too slow; full of errors; impossible to maintain). So, how do you fix the problem? Do you build your own system, or do you buy something off-the-shelf? There are pros and cons of both approaches. But first things first; before you can make a Build-vs-Buy decision, you need to work out your requirements.

Requirements

You quickly discover that requirements gathering and analysis is hard. In fact, conflicting stakeholder expectations and internal politicking make this the most difficult (and important) part of any IT project.

(Click image to enlarge)

Even if you know what the pressing issues are right now, what about 6 months, 12 months or 3 years down the track? What about potential applications and requirements for other business units within the firm?

That's why smart companies spend a lot of time researching solutions. Specialist document assembly vendors have the experience and expertise to help you understand the sorts of problems other companies have solved and how they've done it. Once you've clarified your requirements, you can start investigating your options.

Building

This is definitely the way to go if your requirements turn out to be truly unique. However, you still need to be aware of the risks of building your own document assembly system.

• IT departments love building things. It keeps them employed, challenged and happy.


• It's not just the tool that needs to be built. There's support, maintenance and possible enhancements down the line. Don't underestimate the testing effort either. Exari document assembly solutions, for example, have had over 20 man years of product development, run thousands of test cases every day, and are the result of ongoing partner and customer collaboration.


• On the surface document assembly may seem easy. As with any area of expertise, it's only when you dig deeper, that you understand that various document types and outputs (MS Word, PDF, Web) have their own specific and unique quirks. You begin to encounter these once you start building. Styling, cross references, numbering, headers, footers, tables and business rules all contain unique challenges.


• A good end user experience is essential, and is only half the battle. Templates need to be updated and maintained. Without the right authoring tools, maintenance requirements can easily turn your project into a money pit.

If your project really is a "one off "with well known and defined requirements that are unlikely to change over time, then build it; but only if it makes sense economically and you have a well resourced, capable development team.

Buying

If it turns out that your requirements have similarities to those of other businesses, then buying is more likely to be the better option.

• Assess various document assembly vendors and identify the features and functionality that best match your business problem. Take advantage of other customers having been through what you're going through. Use the document assembly vendors to help you to define tight business requirements.


• Make sure the system can handle the hard stuff. At some point you will hit complexity. You need a stable, easy way to automate it.


• Confirm that the solution you choose works and integrates with your other applications and infrastructure. Requirements change over time. Systems with flexible APIs that are based on open standards enable you to future proof your investment.


• If the project is time-critical, remember that buying will be much faster than building.

Total Cost of Ownership

Ultimately, when making a Build-vs-Buy decision, you need to understand the total cost of ownership for each approach. That means factoring in all costs for the life of the project, including internal development costs, opportunity costs, ongoing maintenance costs, and integration costs.

For more information, check out Buy vs. build: Six steps to making the right decision. Have you been through a Buy vs. Build experience? Please tell us what you learned in the comments below.

This post was guest authored by Exari's Chief Technology Officer, Justin Lipton.

Update: Justin has done a Buy-vs-Build post for a more technical audience on the CIO website.

Inceasing Revenues: The Sales Department Business Case for Contract Automation

I discussed the law department business case for contract automation with a focus on cost reduction. Now, I want to look at opportunities for the sales department.

In a 2007 report, Sell-Side Contract Management: Opportunity-to-Order Optimization[subscription required], the Aberdeen Group determined that the #1 reason for improving the management of sales contracts is to reduce revenue leakage.

Sounds like a good reason. But what does it mean in dollar terms?

Let's revisit Company X from the law department business case: the assumption was that Company X does US $10Bn in annual revenues, and the conclusion was that Legal could save over $1M per year by improving its contracting.

Now, we're going to look at Company X from the sales perspective. According to the Aberdeen report, on average:

1. 67% of revenues are based on contracts (for Company X that's $6.7Bn per annum)


2. 5-9% of revues are leaked away due to contracting problems such as incorrect charges, missed milestones, inconsistencies in pricing, transactional errors, and penalties (for Company X, that's $335M-$603M each year)

As with the law department scenario, the question is how much that $335M+ can be reduced. Again, I would argue that improving the process should be able to reduce leakage by 10% which, in the case of Company X, means additional revenue of over $30M per year.

Once again, the notes from the law department business case bear repeating:

1. Your mileage may vary: the above assumptions are, by definition, highly generalized. I'm simply trying to provide an example so you can decide whether it's worth gathering specific data to analyze your own situation.


2. The calculation excludes other potential benefits of document assembly such as reduced risk, faster cycle times, and improved client service, all of which strengthen the business case.

Ultimately, the goal is to improve the process across functions so that Sales, Legal, Pricing and other departments can work together seamlessly.

Cutting Costs: The Law Department Business Case for Improving Contracting

In a previous post, I discussed the IACCM's finding that, in some cases, more than 40% of legal department costs are associated with bid and contracting work.

What then might a business case for automation look like? Below is a quick, back-of-the-napkin calculation.

Let's assume:

1. Company X does US $10Bn in annual revenues.
2. Total legal spend is 0.3% of revenue, or $30M p/a. (According to Rees Morrison, while actual TLS/Rev varies greatly within and across industries, 0.3% is a typical ratio)
   
3. 40% of TLS - $12M p/a - supports contracting. (As per the IACCM finding.)

The question then is, how much can that $12M realistically be reduced? I would suggest that a 10% (i.e. $1.2M) annual reduction should easily be achievable for the majority of organizations that have not yet focused serious effort on streamlining their contracting processes.

To be sure, it will cost money to realize the potential benefits. But, even over a 3 year time horizon, I would expect a very strong return on investment.

Notes:

1. Your mileage may vary: the above assumptions are, by definition, highly generalized. I'm simply trying to provide an example so you can decide whether it's worth gathering specific data to analyze your own situation.
2. The calculation excludes other potential benefits of document assembly such as reduced risk, faster cycle times, and improved client service, all of which strengthen the business case.

Let us know your experiences with contracting improvement in the comments below.

The insidious nature of the billable hour

From the You Cannot Be Serious! file:

"LAWYERS face a national crackdown on over-charging that could end the practice of billing clients for sending them Christmas cards and reading thank you notes."

This is the opening sentence in Over-charging by lawyers under scrutiny, an article in The Australian newspaper. Do some lawyers truly charge for these activities? Do they disclose this to their clients?

Hourly Billing 101

It's certainly true that lawyers are, in the most part, measured on their billings. You (usually) receive revenue for billable work (such as research, advice, drafting and negotiation on a matter); you don't for non-billable work (such as investing time now creating processes and systems that will enable you to do all future work more efficiently).

When accounting for every six minutes in their day, lawyers are constantly deciding (often automatically) whether an activity is billable or non-billable. It doesn't take long for new lawyers to conclude that billable work is 'valuable' (to the firm, not the client) and that non-billable work is worthlessnot. Accordingly, the bigger the bill, the more valuable the work.

The Impact on Document Assembly

As noted previously, Exari has law firm clients using document assembly to great effect. However, there's no question that those firms are still viewed as innovators. A recent Twitter conversation captures the thinking about what's holding back other firms, as well as potential catalysts for change.

Ron Friedmann: @VMaryAbraham @jeffrey_brandt Outside investment via LRA in UK is likely legal IT game changer. eg, Widespread document assembly at last?

Jeffrey Brandt: @VMaryAbraham @ronfriedmann I agree outside $ investment is huge game changer. 2 get widespread doc assembly, u need to change comp formula.

Mary Abraham: @jeffrey_brandt @ronfriedmann To get widespread doc assembly, U need high volume low margin work . And, clients who insist on fair pricing.

Jeffrey Brandt: @VMaryAbraham @ronfriedmann I'll disagree w/U. In order 2 get widespread D/A U need lawyers updating rules, a tradtionally nonbillbale task.

Mary Abraham: @jeffrey_brandt @ronfriedmann Lawyers do nonbillable tasks, provided there is an immediate & obvious payback. Applies 2 document assembly 2.

Ron Friedmann: @VMaryAbraham @jeffrey_brandt D/A requires much non-billable 'knowledge engineering' hence need for outside capital. What lawyer invests?

Doug Cornelius: @jeffrey_brandt @VMaryAbraham @ronfriedmann The billable hour is the enemy of document assembly for law firms. You can't get a positive ROI.

Ron Friedmann: @DougCornelius Billable hour _is_ doc assembly barrier.... that's why PE investment in UK could change market.

Unsurprisingly, the billable hour was a big focal point.

What Next?

Even though clients and law firms don't particularly like it, they understand the billable hour. They know where they stand. So, I don't see it disappearing any time soon. I agree with Jay Sheppard's comment: "it's the end of the beginning. But there's a long way to go." That said, it will be interesting to see the impact of outside investment in UK law firms when that happens.

Where do you stand on the future of the billable hour?