Contract Lifecycle Management using Microsoft Sharepoint 2016

Contract Lifecycle Management – Build vs. Buy

Contract Lifecycle Management – Build vs. Buy

Over the past 10 years we have had the opportunity to implement approximately 100 contract lifecycle management (CLM) projects. All were SharePoint-based solutions for both buy-side and sell-side applications at companies big and small, public and private, and in over 15 different industry verticals. Through our experiences we have observed that the most successful CLM projects have several common attributes including:

  1. The organization’s contract process is fully understood and well documented.
  2. The organization has selected a specific area for improvement to deliver quick wins with meaningful results.
  3. The organization has cross-functional support for the CLM initiative.

Deploying a contract lifecycle management solution is a project that for many companies has a return on-investment measured in weeks versus years. As the old adage says, “anything worth doing, is worth doing well” – the first time. So why not give yourself the benefit of learning from what others have done well and avoid the traps and pitfalls that plague unsuccessful projects.

Recently, we have observed an interesting trend developing in the CLM market. Now, fully one half of our inquiries share one of two experiences:

  • INTERNAL BUILD – they have tried and failed to build a contract management system themselves, or
  • GO LIGHT – they licensed an entry level product and either have outgrown the product or discovered that its functionality falls short of what was really needed.

Feedback from organizations from both categories is consistent. They express frustration that they have wasted considerable time and money with little to show for their investment and they have now renewed their search for a technology solution to help them better manage contract performance. Unfortunately, these organization’s experiences are both predictable and avoidable. Let’s explore both situations using real-life examples and then examine how these situations can easily be avoided.

Internal Build


Fourteen months ago we had an inquiry from an organization that was beginning a strategic CLM initiative. They assigned internal resources to work part time to define the requirements for their targeted contract process. Their primary high level objectives were to create an online web portal for self-service contract initiation, route the contract for approval electronically while enforcing business rules and policies and create real-time visibility into the status of each contract. Initial vendor reviews were performed, demos were given, questions submitted, proposals requested and then a final vendor was selected.

After some discussion, the organization decided that building a CLM solution internally would be slightly more cost effective than licensing one off-the-shelf. After all, how hard could it be? This company chose to build their own system using 3 technologies: Microsoft SharePoint Server, InfoPath, and an off-the-shelf workflow tool. The IT team proposed that they could build an equivalent CLM tool in 3 months or less.

The team proceeded to pursue this strategy and after more than a year, while spending 2-3X more money than projected, they rolled out their internally developed CLM solution to their internal customer. End users unanimously and immediately rejected the system stating it was not user friendly and did not address their needs. The rest of the story involves several employees forced to polish resumes, unhappy internal customers, significant political capital being exhausted and a renewed search for an off-the-shelf CLM solution.


We have found organizations who think that they can build a CLM system themselves generally assume that they can build a CLM system for $85,000 to $150,000 with 2-3 developers in about 3-5 months. While these numbers might sound compelling to the organization, there are three questions that most of these organizations admit later that they failed to ask themselves:

  1. Deep Technology Experience – Does the project team have the requisite solution development technology experience?
  2. Track Record of Success – Does the project team have a history of successfully developing solutions on test, on budget and on time?
  3. Deep Domain Experience – Does the project team have multiple iterations of contract lifecycle management solution development experience?

Unfortunately, most of these organizations have admitted later that they now realize their team was unqualified and their organization’s desire to “save” money clouded their ability to be intellectually honest about the probability of success. Incidentally, answering “No” to any one of the three questions above should be considered a warning sign that the odds of success are not in your favor.


  1. Inexperience = Risk – It is possible to develop a workable CLM solution successfully. Unfortunately, based on feedback from organizations who have attempted to do so, we have found most are not staffed sufficiently with experienced resources and they tend to underestimate the complexity, risk and cost of taking on an internal CLM development project.
  2. Parts ≠ Whole – Cobbling together (read as integrating) a collaboration product, a workflow product and a document assembly product is not the same thing as developing a CLM solution. Each of these products was designed to do certain things in general but nothing in particular. CLM solutions are designed to solve specific and unique CLM challenges faced by organizations.
  3. Look In The Mirror, Again – Having the intellectual honesty to know what you know and know what you don’t know is important. Organizations must also have the humility to seek outside help when their expertise and/or capacity does not match their project requirements and objectives. Most organizations would never consider building their own word processor or spreadsheet program. Building your own CLM solution is more complex by an order of magnitude.

Go Light


Every week we have organizations who describe how they manage their contracts with spreadsheets and email. Some have recently moved on to an entry level CLM product that offers a static repository, simple reporting and status indicators. These customers usually ask detailed questions about specific pieces of functionality within our solution. The questions tend to include areas such as alerts, workflow, business rules, document assembly, and integration with legacy systems.

As a matter of practice for understanding their needs, we ask why these areas are of such importance. The responses, which were originally unexpected, have become routine as it has been repeated over and over. These organization thought they had made an informed vendor selection decision to license a simple CLM product only to discover the product’s limited capabilities do not allow it to grow with their evolving needs. Unfortunately for these organizations, the product may be good but it was not a good fit for their growing needs.

Now, after a short period of time they are back in the market exploring alternative solutions.


Our observation of what these organizations have in common is that they initially failed to fully examine and define their requirements prior to selecting a CLM system. Without a full understanding of the business problem they are trying to solve, it is difficult for these organizations to match functionality with requirements. Consequently, any solution appears to work. Having failed to understand their own requirements, these organizations also find themselves in the same predicament of having invested considerable money and time with little if any value created for the organization.


  1. Define Requirements First – Among the first steps with any project is to define the business problem, objectives and key drivers so that project requirements can be developed. Only then will an organization have the information needed to begin the search for a solution that fully accomplishes solving its business needs.
  2. Gather Information – Gather data on the market, vendors, products, features/functionality, implementation experience, etc. from credible sources. Information quality always trumps quantity. Domain experts can be spotted easily as they will first seek to understand your organization’s unique requirements. Websites and customer references are good sources of information. Be wary of information provided by those using negative selling techniques, claiming to be a domain expert, or have a conflict of interest with the information they provide. Remember making an informed decision based on accurate information is imperative.
  3. Cheap Is Not Always Cheaper – Contracts play a strategic role in an organization. Companies wanting a “quick and easy” win may grasp at something unsuitable for their real needs. Buying the least expensive product is seldom the low cost alternative when considering the full lifecycle cost and retooling required if the original product cannot grow with the needs of your organization.

Contract Lifecycle Management, now more than ever, is positioned to benefit from 3 macro trends. CLM technology has just recently caught up with the need, organizations are realizing there is a better way, and the need for compliance and governance has never been greater. Through preparation and proper due diligence your organization can realize the benefits of applying technology to your contract lifecycle process.

By: Tim Sparks

Download the full version of this article here: Contract Lifecycle Management – Build vs. Buy