Startups vs.best practices... can't we all just get along?

Transitioning from CIO to CEO has been an interesting move for me.  This is not my first time as a CEO, but my role as CEO of Vigilant was short, and Vigilant was an IT services company, so it was still chief of IT services.  However, as much as I dog on ITIL, CObIT and other industry frameworks for being too esoteric and vague, I always have appreciated and applauded the principles and intents.  As SMAK has launched from thought to design to code to hardware, my experiences and training in lifecycly management has served me well.   Our Strategy phase quickly incorporated what our resources and capabilities could be, would be, and should be.  Since I have the unique opportunity to start this IT operations from scratch, I wanted to get our LifeCycle management clear and correct from the start.

Just because we are a lean startup doesn't mean we need to run in chaos.  I certainly am not going to cast all hard lessons learned in the trash.  I know that if a disparate development team is not given a solid and stable platform for code migration, our IT ops will be a mess.  My ITIL students and past clients have heard this expression a million times from me.  If you want to cleanse the pond, you must clean the streams that feed it.  In other words, if you want a clean IT operations platform, you must have solids standards and architectures in place for all involved to work from.  Breaking down the DEV/QA/UAT/Prod barriers is a challenge.  Typically it is based on rights and security.  Access control can be a nightmare and causes much of this angst.  By setting up boundaries and protocols up-front, the streams will stay clean and the pond will be a source of value.

So here is my strategy straight out of SMAKs operation guide on how I plan to allow autonomy and control co-exist.

User Setup and Configuration:

To secure the environment we will utilize a strategy of layered access to systems. Each environment will utilize the same set of layers with a name denoting their environment.

To gain physical access to systems (keyboard, SSH, Remote windows) there will be a user created.
Once physical access is gained you will need to change user or run-as a user with rights to access either system settings / application data (php, xml files / database settings / database information.
Access controls are organized in to functional groups based on assetts. Asset types fall into 5 categories:
Production – Production environment with real users and customers. Needs to exhibit high service warranty.
Demo – Production+ build version of our site with fake data that we will use for demonstration at events, webinars, and other marketing events. (Production+ means at least production vesion with potentially new features to demonstrate functionality)
UAT – User Acceptance Testing Environment– QA Build version signed off on by production release team for Security; Availability; Performance testing. Now awaiting user interaction; regression; usability and design; product marketing sign off.
QA – Quality Assurance Environment – Build version that has been signed off by development team and gone through integration testing. Testing in this environment will focus on Functionality; Security; Performance; Availability; Installation; Recovery. Training to production release team will happen at this build stage. Sign off by Product Management.
Dev – Development Environment – Dynamic build versions be created in this environment with 2 core focus areas

1. InnoDev - New product development focused on publishing new feature sets and requirements from Product Marketing team.
2. ProbDev – Problem Management environment focused on production snapshots for replicating issues found in production.

The following table lists the usernames:  {obviously cleansed and changed for security purposes}  Key here is to create naming conventions that make it ease for each lifcycle to be identified and controlled.  This will make it a lot easier with building RACI models in your CMS map.

User Type	Production User Name	Demo User Name	UAT User Name	QA User Name	Dev User Name
Group Name
Enterprise Cloud Administration
Access User
System Admin
Application Administration
Database Administration
Data Access User (can see datapoint for customer information)
Customer Service Access (access to configuration and registration info)

How to Maximize Outsourcers - Part 2 of 3 - Choosing the Outsourcer

This is the 2nd part of a 3-part article on how to get the most out of your outsourcing relationships.  

Part 1 - You (or your company).  Can you handle the truth?

Part 2 - The Outsourcer.  Friend, Foe or Value Provider

Part 3 - The Relationship.  Customer, Consumer or Partner 

Part 2 - Them

When making the decision to outsource, you are saying to yourself  "I want to achieve greater value for this particular service by leveraging the core disciplines of others".  What you then need to ask yourself is “what are those value drivers?”.  

There are basically 4 aspects of value you can expect to achieve from an outsourcer.

1) Quality - Since the service you are outsourcing should be core to the provider, you should be expecting an elevated level of quality.

2) Price - The outsourcer is leveraging a shared infrastructure across its customer base,  so you should expect affordability at a unit cost level.

3) Time - Focused operation should have allowed the outsourcer to become mature in their processes and architecture, enabling them to  facilitate new programs with greater efficiency.

4) Risk Mitigation – Lastly, you should expect that the resources required to plan, manage, control, and counteract risks are stronger in the outsourcer, since business tolerance for failure is far less for an outside party than for internal groups. (for the most part)

No doubt there are many other reasons to choose an outsourcing relationship, but these are the major contributors to deriving value from the relationship.  

Before you embark on the transition of the service, you must determine  whether this outsourcer has the "right stuff" to service ME.

Did you know that Outsourcing Fails?  Of course you do; a lot of outsourcing initiatives fail.  Usually this is because of Part 1 of this article "You".  (well, not you personally) 

 However, it also has to do with how the outsourcer was evaluated.

When it comes to evaluating an outsourcer it is important to recognize a few myths:

Myth 1) The outsourcer is in business for me.

Myth 2) Bigger is Better.

Myth 3) SLA's and Contracts protect me

Let's take a look at these myths to determine if our outsourcer is a "friend", "foe" or "Value Provider".

Myth 1) The Outsourcer is in business for me.

OK fine, the outsourcer has chosen to offer a capability you are looking for.   That doesn't mean that they are in business for you.  

That doesn’t mean that they are making decisions to provide capabilities for where your business is going.

In other words, you may mistakenly make the assumption that your anticipated needs are clearly understood by the outsourcer and that their investment strategy is targeted towards your business consumption.

This is a myth that many outsourcers will be glad to let you believe.  

The frank fact is that outsourcers are in business for themselves.  They want to deliver the service that you buy at a given time and maintain that service without change for as long as possible.  Thus, as a buyer, you are not going to get the value unless you clearly articulate your expectations up front and your outsourcer can clearly articulate the service portfolio of current and future offerings.

A 2004 survey from OutsourcingBestPractices.com  stated that 23% of the outsourcing failures were because of "The buyer's unclear expectations up front as to its objectives".

Friend: "We have provided this service for lots of clients, we know what you need."

Foe: "Changes to services only introduce risks, we will accommodate enhanced services after we have stabilized you as a client."

Value Provider: "Here is our Service Catalog of current services.  We are predicting these areas of market demand and have these service in the pipeline to delivered by these dates"

Bottom line:  

If the services aren't in their plans, they won't be in your hands.

Myth 2) Bigger is better

There will be no argument here that for pure play utility services, selecting  a larger company will give you great value.  What I want to focus some light on here is the sometimes mistaken assumption that all services added to a larger firm’s portfolio will be as good and as valuable to us as the core services for which they are known and trusted. 

Another key factor to keep in mind is the life-cycle of an outsourced arrangement.

According to "IT Outsourcing Part 1: Contracting the Partner" there are 5 phases.

Phase 1: Decision Making - Should the organization outsource (see Part 1 of this article)

Phase 2: Supplier selection - what this article is helping cover.

Phase 3: Transition - Transfer services to provider, transformation of retained service ownership

Phase 4: Service Delivery - Maintaining performance and governance over provider.

Phase 5: Contract Completion - Handling renewals, changes or withdrawal.

When thinking about these phases, you need to ask yourself if the size of the outsourcer accommodates your goals.  Remember that outsourcers love to bring clients in and hate to see them go.   So while bigger shops can more readily support the first 3 phases of the life-cycle, what’s their reputation for supporting Phase 4  and 5?  How hard will it be to end the contract with a larger firm?

Larger firms have more resources, yes, in their legal teams.  

This brings us to our next myth.

Myth 3) SLA's and Contracts protect me

This has been, in my experience, one of the greatest mistakes made by either side of the outsourcing arrangement, trusting that an  SLA will provide you service.

The brutal truth is that the SLA is a contract that is in place to fall back on when either party so significantly fails that you have to litigate.  You can reinterpret the claimed breach to a court that will really have no clue what you both are talking about.
You need to think of your SLA like your life insurance policy; you want to have it, but never want to use it.  Understand the risks and conducts that could go against the contract, but otherwise do the right thing.

SLA's are important, don't get me wrong.  However, their greatest usable value is in determining the guidelines by which performance and capacity will be managed.  Outsourcers like any other company provide value for money.  Their value model will be based on the requirements and commitments that you as a client make with them.  The SLA documents these important requirements and commitments, so that resource planning, controls, and execution decisions can be made at multiple levels of the organization.

So if you really want to get the most out of your outsourcing contract, you have to create a Service Network Relationship.  In my next and final part of this article I will share with you the 4 different aspects of Service Perspective.  I promise this won't be your Mama's ITIL Pie and Service Cream.

 Part 3 - The Relationship.  Customer, Consumer or Partner 

Service Catalogs are the key to demonstrating Value

What is a Service Catalog? Simply put it is system or documentation that allows people to preview the services they can obtain from you and the expectation they can have of getting those services (time, cost, quality, etc...).
Do we need a Service Catalog? Do you need a resume to get a job? No, but if you want the right job, and want to get paid fairly for the abilities you can bring, and want to set the right expectation, then you will want to have a clearly articulated resume.
Same thing with the IT Service Catalog. If you want the business to appreciate the value IT brings to the organization, and you want to ensure that staff, suppliers, and costs are adequately budgeted for, then you must present to the business your capabilities. The Service Catalog is where you will publish and present what IT will do, and thus what they will not do. At face the business will not necessarily want IT to have this. If you do not currently have an IT Service Catalog, then currently the Business can ask you for whatever they want, and IT has to scramble to either try and justify why they can't do it, or figure it out. If there is no cost allocation in place for IT resources, then in the eye of the Business stake holder IT is a free resource, and we all know what the value of free - zero - free has no value.

Thus to really drive the value of IT services, IT must put in place a definitive "what we do, how we do it, and how much it costs" communication platform. More advanced organizations are using this information to build an on-line IT ordering site where people can order account setups, email boxes, new laptops, PDA's and Blackberries, and other enablement services. These sites will typically hang-off the Service Desk platform so that people can get services ordered without having to interact with a service request person. This can lead to tremendous cost savings and it also leaves the business in more control. So many organizations are finding the business more willing to fund the Service Catalog under the umbrella of Self-Service optimization and cost efficiency.

Next blog: "Is the customer always right?" I'll share some tech support stories to show the difference between a customer focused support person and a person who answers the phone and follows a script.

The Art of Triage

To many, troubleshooting seems to be a gift that either you have or you don't. For instance, my father is a mechanic. When he owned his own repair shop he would hire young guys who would spend hours troubleshooting a problem, but then within minutes from my old man getting involved he could quickly diagnose the cause of a problem. The timing belt, carburetor issues, whatever it was, he was quick to pinpoint. Inevitably once the problem was found there was the “oh, of course” from the Junior grease monkey.

I was too clumsy to be a mechanic, so my dad fired me and forced me into Computers. However, I didn’t forget what I had learned about troubleshooting.

First, troubleshooting is not something you are born with. It is a skill that is harnessed based on 3 common factors:
1) What you know
2) What you don’t know
3) What you are learning

When you piece these 3 factors together you create the framework for discovery. By adding at negative and positive approach will then lead you down a path of what good troubleshooters simply call the process of elimination.

Do you know what is working? Do you know what is not working?
What don’t you know is working? What don’t you know is failing?
What have I proved with this step? What have I disproved with this step?

So when it comes to troubleshooting complex systems, the same principle applies. You just need to analyze them in layers. Here are the layers that VIGILANT has documented as the logical points to eliminate.

Infrastructure: Hardware, Networking, Operating Systems
Application: 3rd party application services
System Interfaces: Connectivity between dependant systems
Business logic: Business rules that cause transactions to operate differently
Business Process: The way the end-user is executing the transaction
Business Service: Dependency on data or other elements for success

For really complex issues, take each of these tiers and apply the 3 principles of discovery to them and you fill find the problem is not as much as a black-hole as you thought it was.

Why are we still fighting fires?

"We have spent so much money on monitoring tools and consulting, why are we still fighting fires?" I heard this from a recent prospect. The simple answer is because we live in a complex and high demand world. As IT proffesionals we are trying to do a lot with a little; little training, little vision, little strategy, little focus. Organizational process alone is not going to cut it. If we want to fight fires, then we have to campaign like Smokey the Bear. "Only you can prevent forest fires!" was his motto. What is yours?

How about these? "Only you can prevent outages from unplanned changes!"- By implementing some more rigourous controls around change and release management.
"Only you can prevent unnecessary downtime by distracting priorities!" - By implementing better incident management procudures, you could avoid the "SWOT" call mentality that takes the engineers attention off of restoring the service and diverts it into CYO for mangaement.
"Only you can prevent business impact from IT service failure!" - By properly planning and validating your infrastrcuture through capacity and load testing, infratstucure validation for fail-over and applicaiton profiling, you can ensure your build and release managment processes are catching issues before your users do.

Why are you still fighting fires? Probably because your processes are like disconnected piles of twigs and your culture is overly reactive.