Contracts are of strategic importance in companies. Especially in larger organizations, contracts are often managed in different departments or even different companies. It is often not transparent which contracts are valid for which company areas, whether contracts were concluded with the same suppliers under different conditions, which planned or actual costs are associated with contracts or when which contracts can be renegotiated or terminated.

This article describes some of our project experiences when introducing contract management systems and also offers a small checklist for organizations that are dealing with the introduction of central contract management. The focus of this article is not so much on the technical implementation, but rather on the organizational setup of the project, project management and the right approach that leads to project success.

The term contract can be very broad in larger organizations, possible forms ranging from strategic framework agreements to letters of intent to normal rental, work and maintenance contracts. But non-disclosure agreements are also contracts that are not only filed, but must be found and evaluated quickly in the event of a dispute. Even commissions from suppliers, orders or service certificates are contracts or parts of contracts.

This does not make the introduction of comprehensive and transparent contract management any easier, since orders and orders are usually recorded and processed via an ERP system, while the different types of contracts are often managed in different departments with individual software solutions, Excel lists and file storage systems . Additional important information such as customer master data or orders can be in an SAP system, employee and organizational information in an Active Directory, etc.

In addition, access authorizations play a special role in contracts. For each type of contract, there is usually a defined group of users who can create, edit or view contracts. Confidential contracts may also be subject to special confidentiality regulations.

Finally, when introducing contract management, data protection aspects must be taken into account, and the works council must also be involved, since personal data is stored and processed in many contracts. Last but not least, the general data protection guidelines and the GDPR create special requirements for information and data storage.

Organization is everything

As a rule, central contract management cannot be introduced “just for once”. In order for an introduction to be successful, the following organizational requirements are essential:

• A mandate from the company management that a central, comprehensive contract management should be introduced. Such an introduction is always a change management project, and implementation cannot succeed without a clear commitment from company management, since working methods in departments are changed and resistance and delay tendencies must be expected.
• A project team equipped with this mandate, which combines organizational and technical skills, with an assertive project manager .
• Setting up a steering committee made up of all stakeholders . This should not be a round table with representatives from all departments, but a small circle of company-wide decision-making managers who support and drive the introduction.
• Central strategic objective for the entire company. What are the advantages of central contract management for the entire organization? These goals must be formulated transparently and clearly for everyone and communicated regularly in order to justify the effort involved in implementation, implementation and conversion. Typical, overarching goals are, for example:

• • Increasing the transparency of concluded contracts and thus creating room for negotiation (e.g. with suppliers)
  • Deadline controlling: Automatic reminders of notice periods and deadlines
  • Savings on capturing, approving, searching contracts
  • Comprehensive reporting
  • Avoidance of contractual risks

Consider all stakeholders

In a strategic project such as the introduction of contract management, those responsible for the project should always be clear about which stakeholders are interested in the project and what interests they are pursuing. In larger organizations, the stakeholders are mostly

• The executive board or the responsible management
• project management
• Representatives from one or more departments who are available for the first implementation as pilot departments
• Central IT/system support

The possible effects of the introduction in terms of

• Data Privacy
• Labor Law/Works Council
• GDPR

be evaluated. Since personal data is usually processed and the transparency of the work is increased, such introductions are subject to co-determination and must be evaluated by a data protection officer. With an early evaluation, you prevent later delays or costly adjustments in the actual project.

Who actually wants what?

An assessment of which parties are pursuing which interests should not be underestimated. The desired state is not always given – all stakeholders pull together. Good internal communication, team building with all stakeholders and the removal of obstacles are important. For example, the IT department should realize that an external service provider is not a competitor but a temporary addition to the team. And if employees look after old systems that are to be replaced, they should be convinced of the advantages of a new system in advance and support the project.

Of course, these considerations apply to all larger IT projects, but they are of particular importance when introducing contract management, since many departments are affected and because the documents are critical to the company.

Checklist and step-by-step plan

Before introducing a process solution for contract management , the requirements for a solution must be defined. For such purposes, the creation of a structured checklist is helpful. This effectively reduces the overall effort for an introduction, since a large part of the effort is caused by organizational issues and the often smaller part by the technical implementation.

The following checklist does not claim to be complete, but offers an introduction and should be answered or supplemented together with your service provider.

1. Target Specifications

What are the key goals for contract management? How would you prioritize these goals? Examples as shown above:

• Increasing the transparency of concluded contracts and thus creating room for negotiation (e.g. with suppliers)
• Deadline controlling: Automatic reminders of notice periods and deadlines
• Savings on capturing, approving, searching contracts
• Comprehensive reporting
• Avoidance of contractual risks
• …

2. Analysis of the initial situation

The departments concerned should be asked how they have managed their contracts up to now and which attributes/information about the contracts they will need in the future, for example to find documents again. The requirements in each department are usually individual and are then configured in the form of different contract types in contract management.

Important: When recording the requirements, you should already check which attributes are really relevant and which were only recorded historically through the use of older software or were not fully recorded and are therefore not relevant for later retrieval. The rule here is: less is more.

• What types of contracts exist or should be managed with the software?
• How many contracts exist per contract type (order of magnitude)?
• In what condition (paper, scan)?
• Which additional information (covering letters, communication) has been managed together with the contracts or should be managed in the future?
• How were terms, periods of notice, etc. managed so far?
• Who are the contractors? Do corresponding contact lists already exist in electronic form?
• Is there (for each type of contract) contract management currently in place, in which the essential contract features such as deadlines, conditions, validity, etc. are kept up to date? In what form is the administration carried out (Excel, ERP system…)
• For which departments/contract types should the software be implemented in the first implementation?

For the identified contract types, which additional information (meta information) should be managed per contract type? See below for examples of possible fields.

3. Gather and consolidate requirements

When concretizing, focus on one or two pilot departments. Even if the requirements/requests of all departments should be included, the restriction to one pilot department makes a lot of sense in order to shorten a long – possibly never-ending – requirements discussion. The requirements could be structured as follows:

contract filing

Which types or classes of documents should be managed? Examples are draft contracts, signed originals, price lists, correspondence, letters of termination, confirmation of termination, documents/presentations of the contractual partner, etc.

contract attributes

The following list is an example and includes the most common attributes (from our project experience)

• contract title
• contractor
• Contractor/contractual partner
• Contract status (What status can a contract have (possibly differentiated by contract type)? Example: Active, Dormant, Expired, Terminated, Resubmission, Inactive, Interrupted)
• Contract type (rental contract, leasing contract…)
• assigned department/division
• Contract numbers (number ranges of the creating departments, number at the contractual partner)
• Contract Key/Category
• Persons responsible for the contract
• Areas of application for the contract (e.g. geographical areas of application for globally operating companies)
• Assigned/dependent contracts (framework contracts, comprehensive contract regulations, separately managed systems, e.g. service certificates)
• Contract dates (closing date, contract term, cancellation dates, extension options, resubmissions)
• Signing persons/signing date
• Location of filing of the original paper contract
• contract language
• Contract Costs (Once/Periodic/Variable)
• contract currency
• terms of payment

Depending on the constellation, many more contract attributes may be desired/useful, and certain information may also be managed in third-party systems such as an ERP system. It is important to consider and balance between

• the desire to later be able to carry out all types of evaluations as comprehensively as possible
• the effort involved in entering contracts

In principle, only attributes that must be entered as mandatory fields can be comprehensively evaluated. A frequently useful approach is to prescribe as few mandatory fields as possible when creating a contract in order to enable a quick initial entry, and only to provide further mandatory fields when a certain contract status occurs, for example when a legally valid contract is filed.

document management

• Editing and automatic versioning possible/required?
• approval workflow?
• Import/Export of documents?

Compliance Requirements

• History/versioning of all changes to contracts and contract attributes?
• Revision security given? How is revision security defined in your organization?
• Contract archiving: is legally compliant archiving with the destruction of original paper documents desirable or necessary, or is a reference to the original storage locations sufficient?

Permissions and Responsibilities

• Which persons have which roles in relation to the contract (responsible person, clerk, supervisor, legal contact).
• For which persons is a contract relevant/valid? Are these people allowed to view or edit the contracts? Only insight into the contract attributes (evaluations) or also into the documents themselves

reporting

• What types of evaluations are required?
• Easily create/extend reports

Search/retrieval of contracts

• full-text search
• Search for categories/attributes or combinations
• entry pages
• To-Do Lists

notifications

Automatic notifications for certain changes, e.g

• imminent expiry of the notice period
• Changes made by other people

multilingualism

Is there a central company language, or does the system have to be multilingual? Which languages must be supported?

Interfaces

Which third-party systems provide data? For which third-party systems must data be provided. Examples:

• Personal master data can come from a SAP or Navision system or from a directory service (Active Directory).
• Contract partner master data can come from an ERP system
• Contract information may need to be provided to other systems
• If other contract management systems are in use and are not to be replaced immediately, synchronization of contract information must be ensured
• It must be possible to provide/export contract files for third parties (e.g. a law firm).

data migration

In the course of replacing other contract management systems, data migration must be carefully planned. This is usually a small sub-project.

4. Implementation Roadmap

The creation and approval of an introductory timetable (also known as a roadmap) is of crucial importance. This plan should take organizational and technological aspects into account

• catalog of requirements
• Internal conception of the project
• Call for tenders/evaluation of product manufacturers/service providers
• selection process and budgeting
• Possibly pilot project with provider(s)
• Development of fine concept/implementation specification together with provider/service provider

Only then should the classic implementation be started. In these first phases, “selling” the advantages of a central contract management internally is at least as important as selecting the “right” partner and service provider.

Once these hurdles have been overcome and stakeholders, project team and external partners are really in the same boat with a common goal, then nothing stands in the way of a successful introduction.

summary

Many implementation projects still take longer than planned, become more expensive or fail completely. Ultimately, there is no guarantee recipe for the successful introduction of contract management, but experience shows that the organizational hurdles are repeatedly underestimated. If the organizational prerequisites are good and the service provider is competent and well-versed in both technology and organization, these projects will easily succeed. If the organizational requirements are not in place, even the best project team can fail.