Posts

Showing posts from 2008

Essential Management Semantics - Responsible vs Accountable

I've had a discussion at the office about who is responsible for a certain activity. And as expected, the junior colleagues got into a discussion of who is more and who is less responsible for the activity. The Information Technology Infrastructure Library ( ITIL ) defines two distinct roles:  Responsible and Accountable If you open Websters dictionary ( www.websters.com ) and look up the adjective " responsible " you get the following description: answerable or accountable, as for something within one's power, control, or management If you do the same for " accountable " here is what you get: subject to the obligation to report, explain, or justify something; responsible; answerable . It is a common sense to assume that "accountable" and "responsible" are synonyms. But both in Management and IT their meaning differs slightly and that makes all the difference: Accountable is the PERSON  (singular) who answers for

5 SLA Nonsense Examples - Always Read the Fine Print

I've had the opportunity to review several poor Service Level Agreement ( SLA ) contracts, which include clauses shielding the provider as if they are an endangered species. These clauses are usually masked under "general clauses" or fancy lingo to possibly go un -noticed. Here are several examples of texts that a customer should watch out for in a Service Level Agreement: 1. The data protection trick Sample clause: The provider will protect and not reveal any received or collected information about the buyer, unless it's required by legal authorities during a formal investigation or in case of protection of provider's interests Analysis : Although this particular clause may vary from country to country (legal system differences), there is NO LOGICAL ARGUMENT for anyone to reveal your information for protection of their interest . 2. The no responsibility trick Sample clause: The customer will hold harmless and indemnify the provider from all err

The SLA Lesson: software bug blues

I have been hugely busy in the past weeks with several projects, so the blogging got stuck... I will try to avoid this in the future. Now back to my latest experience Part of every Information Security Management System is the incident management process. It is as process in which the company identifies a problem which is occurring or has occurred, and performs steps to contain it, minimize the impact, identify the root cause and take measures to prevent the incident from recurring. The incident in question is a dreaded application blocking - a company of 1000 employees uses a custom made fully integrated CRM/ERP system, which exhibited complete or partial non-responsiveness of several minutes for a period of nearly two hours. This situation was identified at several departments, while the rest of the company is functioning as usual. As soon as the call came in, the incident response team was formed and the problem was analyzed. After 15 minutes, the problem was identified. Accou

9 Things to watch out for in an SLA

Image
I wasn't planning to touch the issue of the Service Level Agreement (SLA) for some time, but it appears that the incident report (Link to Blog Post) has stirred attention that merit a post on the subject. As i already mentioned, it is a very frequent occurrence that the SLA is just an afterthought when preparing a contract, and that the buyer is usually waiting for the supplier to produce the SLA agreement. Of course, this leads to the situation in which the SLA actually protects the supplier, not the buyer.So here are the items one must do to achieve at least a reasonable if not good SLA Remember that any SLA is open for negotiation, but only in initial purchase - although the supplier may propose a very rigid position on the SLA (especially common in large companies), the SLA is part of the sales process. Standing by a rigid position should immediately raise red flags that the proposed "unchangeable" SLA is protecting the supplier, not the buyer. So the best oppor