IT may be one of the few industries where competing companies can work together to become more than the sum of their parts. We work with several local and national companies in order to spread our coverage and widen the skill set available to our customers. We participate in several industry groups where we share ideas with our 'competition' rather than hiding behind our own IP and shooing away anyone who dare ask about how we do things. The power of sharing and working together certainly does seem stronger than the need to compete sometimes. We find that we rarely end up competing for a prospect with the guys we site beside in these groups, which means there are customers our there for all of us. We just need to make sure we find the ones that are the best fit for our specific areas of expertise.
I enjoy reading Arlin Sorensen's blog Peer Power. He recently wrote about the Lessons from Peers (part 1 and part 2). Have a read!
Sunday, May 1, 2011
Saturday, April 30, 2011
The Merits of Jailbreaking
A while ago I wrote about jailbreaking your iDevice. Now one of the biggest proponents of jailbreaking, and the king of Cydia, Saurik gives you reasons why you should jailbreak your iPhone. Well worth a read!
Saturday, April 9, 2011
Service Level Agreements
How do you define an acceptable service level agreement (SLA) when negotiating service contracts with customers? There may be many factors that you want to manage and measure (remember: if you don’t measure it, you can’t manage it), including things like maximum response and resolution time and a number of fixed metrics, such as priority levels.
There is a school of thought that as a service provider, you shouldn’t give anything away in an SLA unless it is specifically asked for. Though in a competitive market you will certainly want to offer something different to ‘the other guys’. Whether that is guarantees of quicker response times or a lower percentage of missed SLA targets before penalties apply is up to you. A missed SLA target for example may be where you have a target response time of <1hr for a priority one incident and it takes your 70 minutes to respond. Most SLAs will allow for a small percentage of targets to be missed, so long as some defined average measurement remains within targeted limits.
When defining SLAs, one thing that is often overlooked is how your supplier agreements and even internal (inter-departmental) agreements compare with the SLA your offer customers. Think about it. If you guarantee to replace a server hard disk within 24hrs but your supplier has a 2-day lead time for delivery, how can you meet the SLA? Or maybe your supplier is not a problem but your Accounts team has a policy to only pay invoices when they reach their terms? That hard drive you ordered may not be delivered until after the bill is paid, which could be 30 days down the track.
Other factors may come into play. Maybe you have a standard SLA response time for priority 1 that says you will have an engineer on site within 1 hour. If you have the same terms across multiple customers, then you are going to have to make sure that you always have engineers on standby, or at least in the office doing work they can drop if the need arises. How you schedule your engineers is key in this scenario. Keep an eye on the number of short-response SLAs you put out there and make sure that you actually have the staff to cover them, otherwise you might end up paying the penalty. Literally.
I’ve mentioned priorities a couple of times, so we really have to make sure that we have defined how we come to decide on the priority of a job. Otherwise you know what happens: The customer sets the priority of the job and it is always priority 1! How you define your priorities will be different depending on the services you are offering but just make sure that you do define them clearly. You will most likely define priorities based on the number of users or services affected in an incident, the business impact of an incident or some other arbitrary measurement. Like if the CEO’s PA calls, it is priority 1 every time!!
Lastly, make sure you define the scope of your SLA. Maybe you cover servers and routers but don’t cover printers - make sure that is clear.
SLAs tend to be full of legal jargon. Unfortunately they have to be but the key points I’ve mentioned have to be spelled out unambiguously in plain English for all to understand. For me, that is the key to executing an SLA that keeps all parties happy.
There is a school of thought that as a service provider, you shouldn’t give anything away in an SLA unless it is specifically asked for. Though in a competitive market you will certainly want to offer something different to ‘the other guys’. Whether that is guarantees of quicker response times or a lower percentage of missed SLA targets before penalties apply is up to you. A missed SLA target for example may be where you have a target response time of <1hr for a priority one incident and it takes your 70 minutes to respond. Most SLAs will allow for a small percentage of targets to be missed, so long as some defined average measurement remains within targeted limits.
When defining SLAs, one thing that is often overlooked is how your supplier agreements and even internal (inter-departmental) agreements compare with the SLA your offer customers. Think about it. If you guarantee to replace a server hard disk within 24hrs but your supplier has a 2-day lead time for delivery, how can you meet the SLA? Or maybe your supplier is not a problem but your Accounts team has a policy to only pay invoices when they reach their terms? That hard drive you ordered may not be delivered until after the bill is paid, which could be 30 days down the track.
Other factors may come into play. Maybe you have a standard SLA response time for priority 1 that says you will have an engineer on site within 1 hour. If you have the same terms across multiple customers, then you are going to have to make sure that you always have engineers on standby, or at least in the office doing work they can drop if the need arises. How you schedule your engineers is key in this scenario. Keep an eye on the number of short-response SLAs you put out there and make sure that you actually have the staff to cover them, otherwise you might end up paying the penalty. Literally.
I’ve mentioned priorities a couple of times, so we really have to make sure that we have defined how we come to decide on the priority of a job. Otherwise you know what happens: The customer sets the priority of the job and it is always priority 1! How you define your priorities will be different depending on the services you are offering but just make sure that you do define them clearly. You will most likely define priorities based on the number of users or services affected in an incident, the business impact of an incident or some other arbitrary measurement. Like if the CEO’s PA calls, it is priority 1 every time!!
Lastly, make sure you define the scope of your SLA. Maybe you cover servers and routers but don’t cover printers - make sure that is clear.
SLAs tend to be full of legal jargon. Unfortunately they have to be but the key points I’ve mentioned have to be spelled out unambiguously in plain English for all to understand. For me, that is the key to executing an SLA that keeps all parties happy.
Tuesday, April 5, 2011
FT won't give up subscriber relationship to Apple | Reuters
I wrote about Apple's new subscription policy a little while back (Apple's Publication Subscription Strategy - good business or magazine-killer?) saying that publishers would be motivated to provide a better solution. Well it seems that the Financial Times is the first to take a stand with Apple. Apparently the media giant is 'in talks' with Apple to avoid paying them the 30% they demand for all electronic subscriptions.
Watch this space, it could get interesting .....
Watch this space, it could get interesting .....
Monday, March 21, 2011
Peer Power: 10 Key Area's of Attention For Your Business
Arlin Sorensen's blog - making running a business look easy!
Peer Power: 10 Key Area's of Attention For Your Business
Peer Power: 10 Key Area's of Attention For Your Business
Saturday, March 19, 2011
Skills complimentary to your IT knowledge?
I remember doing work experience at a chemical plant and a steel mill in the late eighties (yup, showing my age here). The guy I was shadowing made a point of saying that IT skills alone were not enough to succeed and that I would need to have some complimentary skills and knowledge, such as chemistry or physics. Granted, most of the systems I 'worked' on during this time were process control systems rather than office admin type functions, so his comments were probably true.
I later took a full-time position at that chemical plant (along with a large percentage of the people I went to school with in all honesty) and though I didn't need any specific chemical knowledge, I did have to know a bit about accounting when dealing with the finance people, a bit about warehousing and transport when working with the logistics guys and so on. We spend so much time and effort (and money) on IT training, it is easy to forget that to properly support people running IT hardware and software, you really do need to know a about what they do and how they do it. Otherwise, you are just offering generic advice that may not suit the specific situation.
The same applies at all levels of IT. As a salesman, if you don't understand the requirements of the customers you are selling to, you are going to give them the wrong solution which then has pretty serious ramifications for the relationship going forward. In the almost 20 years I've been in and out of IT, I've learned about finance and accounting, factory production lines, steel fabrication, food processing, legal documentation, airline ticketing, construction and property management ..... I could go on!
So I was thinking the other day about the guy telling me I needed to go and learn about chemistry and thinking he was pretty much spot on - not specifically on chemistry but on needing to know a lot more than IT to be successful in IT. Here endeth the lesson.
I later took a full-time position at that chemical plant (along with a large percentage of the people I went to school with in all honesty) and though I didn't need any specific chemical knowledge, I did have to know a bit about accounting when dealing with the finance people, a bit about warehousing and transport when working with the logistics guys and so on. We spend so much time and effort (and money) on IT training, it is easy to forget that to properly support people running IT hardware and software, you really do need to know a about what they do and how they do it. Otherwise, you are just offering generic advice that may not suit the specific situation.
The same applies at all levels of IT. As a salesman, if you don't understand the requirements of the customers you are selling to, you are going to give them the wrong solution which then has pretty serious ramifications for the relationship going forward. In the almost 20 years I've been in and out of IT, I've learned about finance and accounting, factory production lines, steel fabrication, food processing, legal documentation, airline ticketing, construction and property management ..... I could go on!
So I was thinking the other day about the guy telling me I needed to go and learn about chemistry and thinking he was pretty much spot on - not specifically on chemistry but on needing to know a lot more than IT to be successful in IT. Here endeth the lesson.
Tuesday, March 15, 2011
Jailbreaking your iDevice
Jailbreaking - the process of removing your device from the restrictions imposed upon it by the manufacturer. Opening the operating system up to allow new addons and installations.
I'm on my third iDevice now and I've always had them jailbroken. There are so many great apps out there that Apple wouldn't allow in the App Store - often because they replicate features that exist in the stock firmware and quite often because they do it better!
There are lots of contentious issues around jailbreaking your device. Apple have tried to say it invalidates the warranty but most jurisdictions have ruled otherwise. Apple will tell you that allowing 'unsupported' third-party apps on your iDevice poses security risks. And while this may be true to an extent, time and again we have seen the 'hackers' fix security holes that Apple has taken months to attend to.
From a personal point of view, jailbreaking allows me the freedom to do whatever I like with the device I have spent my hard-earned dollars on. Why should Apple dictate how I use my own device? I bought it, I don't rent it from them. Can you imagine buying a 50" high-def plasma and the manufacturer saying "well yes, you can only watch it in black and white". Not bloody likely!
Anyway, what prompted me to write this short piece was an interesting article on jailbreaking on Gizmodo.com.au. Have a read and tell me what you think.
I'm on my third iDevice now and I've always had them jailbroken. There are so many great apps out there that Apple wouldn't allow in the App Store - often because they replicate features that exist in the stock firmware and quite often because they do it better!
There are lots of contentious issues around jailbreaking your device. Apple have tried to say it invalidates the warranty but most jurisdictions have ruled otherwise. Apple will tell you that allowing 'unsupported' third-party apps on your iDevice poses security risks. And while this may be true to an extent, time and again we have seen the 'hackers' fix security holes that Apple has taken months to attend to.
From a personal point of view, jailbreaking allows me the freedom to do whatever I like with the device I have spent my hard-earned dollars on. Why should Apple dictate how I use my own device? I bought it, I don't rent it from them. Can you imagine buying a 50" high-def plasma and the manufacturer saying "well yes, you can only watch it in black and white". Not bloody likely!
Anyway, what prompted me to write this short piece was an interesting article on jailbreaking on Gizmodo.com.au. Have a read and tell me what you think.
Subscribe to:
Posts (Atom)