Software Agreement – Indication of the Agreement’s Purpose

Nowsdays everyone can download or write up any standard software agreement’s, terms and conditions from software packages.  We are so used to copy, paste and modify contents that we sometimes forget to understand why we are drafting this document.

We have  a request from the Customer to release our program’s source codes for the purpose to keep them for disaster recovery.  We are concerned of any liabilities that may impact our Company in terms of misuse, reverse-engineer the codes, code compilation and deployment to other sites without the consent from us who is the Software Service Provider.  With the ‘consistent pressure’ from the Customer in wanting us to speed up this arrangement, my team went to one of the software package, use its terms and conditions to draft out the simplified software agreement.

However, this draft did not get through our Legal for consultation.  Instead we sent to the Customer, and they read, signed and returned the copy back to us for our signature to this agreement document.  Our director went back to the Legal to review this document and realized there were some clauses to be added to protect the Company’s liability.

Worst part, our director thought that this software agreement was drafted by the Customer but this was not the case.  After few emails’ exchange and an afternoon phone call with our business manager and Legal we have to honour this document and our director has no choice but to sign it.  Further clauses will be added to a master contract to cover the liabilities as we do not understand and include the purpose inside this agreement.  If we know the purpose, our Legal can identify and inputs all the possible clauses to protect the Company’s liability

This is a lesson learnt from everyone of us that in any contractual or agreement document that we IT needs to provide to our Customers, we need to go through the Legal and get them to do the rightful job to ensure we are all covered, utimately our very own objective is for the Company’s interests.

Proposal of New Project Timeline for Business Alignment

Project timeline delayed, communicated to Business Manager.  Nothing was communicated to the Customer until 2 weeks ago when they visited the Customer.  Anger, irritation arise as the Customer was not happy that no one has communicated to them about this information earlier.  Now, it has became a big escalation to our Senior Managements for  both IT and Business Development units, demanding us to fulfill the initial plan by end of Decemeber, by hook or by crook.

Today, we review on all possibilities, assumptions and derive all different types of project timelines based on these information for the business case’s presentation to the stakeholders’ meeting tomorrow.

It is important to state clearly and concise for what are the assumptions/risks/benefits considered that derive each of those project plans so that the stakeholders understands the risks involved and accepts the risk ownership for that project plan that is utimately agree with everyone.

All the cards are now lay on the tables and we are going to get the stakeholders to agree which project plan to move forward. )

Business Continuity Plan

Business continuity plan or also known as business recovery plan is a set of documents that defines all the activities that need to take place in the event of a disaster.  A disaster can be defined as an event or occurrence that causes great destruction that fails or has been ruined.  This plan is a living document and must be kept up to date at all time.

In an existing business or new business function, we need to understand where is the ‘loop-holes’ in supporting the business when a crisis occurs.  To start off the risk assessment we should consider some ‘what-if’ scenarios on our daily operations processes/procedures.  What I will share here is mainly the questions that are on the loss of customers’ files or data due to computer systems’ failures:

• Do we have backups?
• Is there any paper system that contains all the information?
• Why did it fail?
• How long will it take to replace all of them?
• How will the business function in the meantime?

IT Disaster Recovery

1. Insurance policies or third-party liability insurance
2. Network monitoring services by third-party provider
3. Off-site storage for backup data.
4. Comprehensive system documents that allows rapid deployment of systems for a new site or any system restoration.
5. Comprehensive backup strategy that ensures all critical data are backed up at least daily and stored away safely from the business premises.
6. Hot site with the mirrored image of the systems that can be activated within hours of a major disaster.
7. List of disaster recovery personnel’s’ contacts.

Standard Service Levels for Incident Management

Most companies engage  a minimum “3-Tier/Level of IT Support Structure for any incident management.  The scopes and resources involves for each level are stated below:

Level 1 Support

• Provide end users with single point of contact on all system related issues
• Consists of a team of at least 4 personnel to support 24×7
• Basic knowledge of the system with FAQ/Support guide to troubleshoot simple, common incidents
• Monitor system health and notify higher support level if system trigger appear
• Escalation to Level 2 Support if an incident is beyond their knowledge
• Provides basic preventive maintenance to the system.  E.g. backups, health checks

Level 2 Support

• Provides in-depth application support to customer’s incident
• Consists of a team with at least 2 personnel, this is to ensure that 1 person is always available when an incident is escalated to this level for resolution
• In-depth knowledge of the system.  Able to make code changes immediately with full knowledge of the impact of the change to the whole system
• Able to advise work-around if incident is not easily replicated and at the same time continue to work on investigating the cause.
• Provides advanced preventive maintenance.  E.g. Process improvement, Scripts improvement, Database tuning, Application tuning etc.
• Escalate to the next level for decision making and customer management.

Level 3 Support

• Provides point of escalation when Level 2 Support is not able to resolve the problem
• Consists of the Application manager or/and IT account manager/or Business Owner
• Make critical decision on how to resolve the incident (usually complex incident not easily resolved)
• Manage the customer and inform relevant parties, e.g. business account manager, etc
• Escalate to Level 4, if required
• Bring in additional resources, if required, to fix the issue

Level 4 Support

• Consists of the management team
• Manage customer from management perspective and inform relevant parties, eg Managing Directors of affected countries, CIO, CEO, etc
• Activate more resources, if required