Everything changes, but nothing changes.
Service Management in the a SaaS environment is in a state a flux. Practitioners are told on a daily basis competing and contradictory tales on how Service Level Management is dead or central to their business. Tales of how Apple delivers value with little or no service. Or a SaaS solution only succeeds if it excites the customer base.
In essence, everyone is right and everyone is wrong. The stories are rationalisations of a historic reimagining of what has happened.
The days of long delivery lead times are dead. SaaS is more akin to baking cupcakes than building aircraft carriers. The short lead times mean PRINCE2 and heavy metal ITIL processes strangle SaaS innovation. In the time it takes you to think of writing up your Request for Change (RfC), your competitor has already delivered a killer feature. A Change Advisory Board meeting will take longer to organise than the programmer takes to write the code.
The flip side is if you mess up in an unstructured environment the results can be devastating. We are all waiting to see what will be the long term effects on Snapchat, but there are some pointers we can identify now. Turning down the Facebook offer seems a trifle rash. The arrogance/ignorance of not reacting to a threat you were made aware of my a third party has to ask questions of IT governance. The simplicity of the hack has to ask questions of the testing rigor performed. Do you see a theme?
The British Computing Society put in place structures in order to manage just the dangers that have beset Snapchat. ‘IT is the business’ is my favourite. The idea that the business always comes first. Safeguarding the investment is what IT governance is all about.
A risk board, a release management process and rigorous testing would all have gone a long way to mitigating Snapchat’s exposure.
Risk Board
This just needs to perform. Give it an owner. Give that owner a spreadsheet with risks and issues laid out. Plug the owner in to the entire business (so much easier in a SaaS company with low employee numbers). Then support and motivate that owner tackle the business head on.
Release Management
Again, cut away all the fat out of the change and release processes you see in ITIL. Distill it down to the bare bones. Every change to the system needs to be tracked, but only the big ones need an RfC. Get your users involved. Empower them to do the process management – in the long run it is in their interest. Get the adage across “do it right once and never look at it again”. Kanban is great, but it depends on motivated staff – motivate your staff. One rule, always separate the developer from the release.
Testing
This follows on from release management; test the hell out of your product. Employ people to do it. Again this is a step change from the huddle of desks making up the Operational Acceptance Testing team. Use internal resources. Involve all staff members in this. It’s a great way of explaining what the business does, training sales people and giving ownership to those on the periphery of the toolset. If you can’t explain it to your colleagues, what chance do your customers have.
One bug means every product you have sold has a bug in it. If Toyota are sending out all their cars with a design flaw where the gas pedal gets stuck they will not hold on to the moniker of the best build cars in the world for long. It happened on just a few cars and it was world wide news. SaaS means a bug in one product is guaranteed to be in all products.
I’m going to try and make a weekly buzz out of this. All comments are appreciated (so long as they are nice).
