Implementing a Contract Lifecycle Management System Is Like Building a House

Implementing a Contract Lifecycle Management System Is Like Building a House


Just like building a house that is specific to your family’s needs, when you begin planning to implement a contract management system you need to assemble your organization’s specifics needs. When building a house you need to assemble your requirements to establish possible neighborhoods, size, the location of the rooms, finishes, and other special items that are needed. These are then assembled by the skilled hands of the architect and documented in a design document called a blueprint. The same applies when implementing a Contract Lifecycle Management (CLM) system: you need to build a blueprint of your needs to guide the construction and implementation process.

In this 3 part series we will break down the process into parts to show the similarities between the major phases of building a house as compared to the implementation of a Contract Management System:


Blueprints versus Needs Analysis

Before the blueprint for a house can be drawn up you need to collect and prioritize the family’s needs and wants. These typically begin with the number and types of rooms (i.e. bedrooms, kitchen, dining, entertainment rooms, etc.) and an initial budget. In order to keep everyone as happy as possible, you need to define what are the key needs are of the family and what you can afford
So too with a Contract Lifecycle Management System. It is critically important to define what the foundational requirements of your ‘to-be’ system are. These are not vendor/product specific items, rather they are the framework of how your contract lifecycle needs to operate.



What goals are to be achieved? Although it may be a given that you need a repository for your contracts, do you need to address other issues such as:
• Internal and external audit demands.
• Regulatory or financial control and reporting.
• Reduction in cycle-time.
• Consistency and control over the contractual language.
What corporate policies and procedures does your CLM system need to adhere to? • Is the approval and/or signatory process defined and adhered to.
• Are we following Records Retention policies?
What is the 50,000 foot view of your “as-is” and “to-be” process? • It is important to understand what your as-is process involves so that know who all the stakeholders are, what works, and what needs attention
• Measurement of what you are doing today (i.e. cycle-time, quality, quantity, accuracy, etc.) will help define what needs to be improved in order to help scope out you to-be CLM process.
What IT infrastructure limitations are to be considered? • Will the Contract Lifecycle Management system need to be hosted on-premise (i.e. behind your firewall) or externally hosted by the CLM vendor a third party hosting provider?
Do multiple languages and/or currencies need to be supported? • Who updates the contract templates when the original corporate master gets changed?
• For currency exchange, are we using a default conversion rate or are we linking to the current market rate?
What are your Governance, Risk, and Compliance (GRC) requirements? • While there are common GRC requirements in specific industries, most organizations have their own unique governance items that need to be managed.
• How are these to be identified (i.e. email, reports, dashboards) and who needs to be notified?


These foundational items start to shape the major design elements that you need to ensure are included in the delivered system.
In building a house you need to take the foundational items and add on the major architectural components such as the size and location of the rooms, kitchen design, mechanical services, bathrooms, parking, etc. It is no different when designing a Contract Lifecycle Management system.


What extent can a library of clauses and templates be leveraged? • Estimating how many of your contracts are created on your paper versus third party paper will be a good indicator of the need for these types of libraries.
• Do you use common clauses in multiple templates?
What level of document version history is needed? • Is there a requirement to keep each version of the contract document?
What are the high-level workflow needs? • While this is typically a financial delegation of authority issue, other dimensions such as risk, insurance, etc. may be equally important.
How are requests for contracts to be handled? • Is there a process advantage to utilize an online questionnaire for people to ask for a contract?
Is there a requirement that data from line of business systems needs to be shared with the CLM? • It is not uncommon for staff to only have access to the CRM, so there may be value in communicating the status of an in-process request and/or pushing a copy of the executed agreement into the CRM.
Are there specific types of contracts that have unique data requirements? • Meta-data of the contract can vary according to the type of contract. Capturing data that is specific to the type of contract can be of enormous value for analysis and retrieval purposes.
• Setup the system so that the data entry requirements are commensurate with the importance of the contract.
Who should have access to what data? • Delineate who needs what information as some data may be very confidential.
• There should be some linkage to corporate policies to ensure an appropriate level of visibility exists.


At the end of this phase of building your house or your Contract Management Software, you will have a detailed set of plans—the blueprint—that articulate the major structural pieces that need to be in place. This planning should also take into consideration what the future needs are: do we need to have the capacity to expand or adapt to the environment as the family/organization grows.

COMING UP IN PART 2 OF THIS SERIES: Putting the finishing touches for our house and our design specifications for our Contract Management System.

Chris Craddock, Director, Symfact

This article may be shared and republished if credit and linking is maintained to