Oct21

Deploy a CTMS: What You Need to Do

So you want to purchase a large software solution – that’s great! Do you have requirements?  Of course you do, but can you convey them to the vendor in a clear, concise fashion without ambiguity? Probably not. In this short article, you will receive some guidance to help you and your vendor bridge this requirement chasm.

As a customer, you must remember a vender will undoubtedly believe his or her solution can meet all your needs even before you have told them what you want. As the customer, it is your responsibility to describe your needs through requirements. This is not an easy task. If it were, there would never be a failed deployment. You need to describe your requirements in a manner that allows the vendor to assess your requirements and provide a software solution. Below are some simple guidelines that will help you navigate the requirements definition process that will be beneficial to both you and your vendor. So make sure you share this with them too!

Don’t assume the vendor understands your business 

Chances are that the vendor understands the industry and some of the general industry challenges. Your business is unique and so are your needs. Be sure to provide the vendor with enough information and company background to allow them to understand your business. Obviously this is confidential and valuable information and you must protect it with an iron clad nondisclosure agreement (NDA).

Get users involved early

In my last article titled “Enterprise CTMS Deployment Success”, I recommended getting the users involved early in the deployment process. The deployment process begins with determining what business issues you are trying to solve. Your users will know firsthand the challenges they face every day, and they will welcome the opportunity to share them with you. Not only will you get their requirements, but you will also have taken the first steps in getting their buy-in for the project.

Three C’s of requirements

Create clear, concise and complete requirements. They must also be realistic, specific and measurable. Avoid including technology solutions in your requirements. It is important that the vendor has the flexibility to create software that meets your business needs and not a perceived technological solution. Your requirements will be the foundation to build your test cases to confirm the delivered software meets your requirements.

Internal requirements review

Review the requirements with all stakeholders prior to sharing them with the vendor. Don’t forget to involve your users. Be sure that everyone understands the requirements and do not take silence as acceptance. During the review process make sure the stakeholders have the opportunity to play them back in their own vernacular. There are many examples of when the stakeholder explains their interpretation of a written requirement and it is determined that requirement is vague or incomplete.

Review requirements with the vendor

Review the requirements with the vendor. This should be similar to the internal review which allows the vender an opportunity to explain their interpretation of the requirements.

Allow for multiple iterations

The requirements process is a difficult process and you should not expect to complete it all at once. The requirements will need to be defined and reviewed in a cyclical manner. When planning your project be sure to provide enough time for multiple iterations of the requirement gathering process. If you fail to have complete clear, concise requirements, your solution may not meet your business needs.

Defining requirements is a difficult and time-consuming task. Getting them right will determine the success of your project, and following the above guidelines is no guarantee; but it will certainly improve your chances success.