IT’s Role in Implementing Applications It Didn’t Select

Modern enterprises employ dozens or even hundreds of SaaS applications to support routine business operations. In many (most?) instances these applications have been procured by functional teams without IT’s knowledge or involvement. In other instances, IT is informed of a team’s intent to purchase an application after it’s been selected, and pricing has been negotiated.

Under either scenario, IT is expected to act solely as an administrative procurement agent, obtaining the internal security and legal approvals needed to complete the purchase. IT's feedback regarding the functionality, architecture or usability of the selected tool or the eventual need to connect it to preexisting applications is rarely solicited – and is sometimes unwelcome.

Although it might be easy (and deliciously spiteful) to relinquish all responsibility for the success of applications that IT didn’t select or buy, doing so is an abdication of IT’s broader corporate responsibilities, and probably career limiting as well. Experience has shown that there are many touchpoints between IT and business teams that must be considered when implementing, employing and supporting any new application. They may be overlooked or intentionally sidestepped at the time of purchase, but they will eventually and inevitably emerge.

Here is my list of the specific questions that should be asked and answered before a final procurement decision is made:

1. Adherence to Security and Compliance Policies

• Does the new tool create new security liabilities?
  
  
• Do new safeguards need to be put in place to address these liabilities?
  
  
• Do existing safeguards need to be extended to protect the new application and the data it employs?
  
  
• Does the new tool need to be administered in compliance with specific governmental regulations or industry standards?
  
  
• Does such compliance need to be audited and documented on a routine basis?
  
  
• If so, who will be responsible for implementing and enforcing regulatory safeguards, administering compliance controls, and working with internal and external auditors to demonstrate compliance?
  
  

2. Integrations with Other Applications

• Does the new tool need to exchange data with other applications to achieve its business goals?
  
  
• If so, who is responsible for constructing the necessary integrations?
  
  
• When are they required?
  
  
• Who will support the integrations in the future?
  
  

3. Data Quality Management and Adherence to Master Data Management Policies

• If legacy data is being loaded into the new tool, who is responsible for devising the quality rules to be applied to such data?
  
  
• Who is responsible for uploading legacy data into the tool?
  
  
• If the data being acquired by the new tool is being reused in other applications, does it violate any enterprise-wide data mastering rules (for example, does it create a duplicate version of business-critical information, such as customer billing addresses)?

   

  Related article: Combating Fear of Open Source Software by Tom Sweet

   

4. Privacy Data Management

• Does the new tool acquire or employ personal information about employees, contractors, customers or partners that has been obtained through consent agreements that prescribe its use?
  
  
• If so, what safeguards are being put in place to avoid the violation of these agreements?
  
  
• Who will be responsible for responding to data subject requests to view, modify or delete personal information they’ve supplied to the new application?
  
  

5. Change Management

• Do business users need to receive training on the capabilities of the new tool?
  
  
• If so, who will arrange for such training and who will respond to “how to” questions from business staff members when they encounter problems using the new tool for the first time?
  
  

6. Day Two Operations

• Who is responsible for devising and administering the rules that will be employed to ensure the quality of new data being entered into the application?
  
  
• Who will manage fine-grained administrative access privileges within the application itself?
  
  
• Who will respond to business requests for reports from the new application?
  
  
• Who will respond to end user issues and requests on an ongoing basis and how will they be submitted (IT service desk, Slack channel, email, voicemail, etc.)?
  
  
• Will these responsibilities be shared in some fashion with IT, or will they become the sole responsibility of the functional team purchasing the application?
  
  

7. License and Vendor Management

• Who will administer the allocation of licenses, monitor utilization, reassign licenses as needed and manage interactions with the SaaS vendor post-implementation?
  
  
• Who will take the lead in negotiations when the new SaaS service contract comes up for renewal?
  
  

Experience has shown that a great deal of confusion, wasted energy and bruised feelings can be avoided if the responsibilities referenced above are clearly assigned to either IT or functional teams before a new application is put into production. IT doesn’t necessarily need to assume responsibility for all of these issues. It merely needs to ensure that someone has!