It was an awesome day today. To follow up on my previous post about our participation at the annual itSMF Arizona Local Interest Group summit, this was indeed the day for sharing best practices - a packed, day-long event filled with industry veterans and luminaries.
Continue reading "Infosys' day out at the annual itSMF AZ LIG summit" »
Are you actively in pursuit to increase value, optimize costs and induce innovation into your IT services BUT instead...
Well, if any of the above symptoms are showing then it is surely a sign of something I call SaS, 'Service anxiety Syndrome'.
Firstly, you are not alone! This is prevalent in most of the IT organizations of the corporate world today. Strangely even some of the hottest (or the coolest depending on how you look at them) technology companies suffer from it. This syndrome does not discriminate on the size, capacity, location, domain, experience or resources of the company. It's also one of those where prolonged avoidance actually causes further collateral damage causing the service maturity of the entire organization to rapidly deteriorate. To make matters worse, we are all nurturing IT in isolation and each organization seems to have their own prescription to battle and survive this. With all the lessons learnt and knowledge being kept within closed doors it's a huge loss with zero collective healing.
Well the first good news is that IT is moving higher! A little background first... IT units were always 'told' or directed by the business. It was only after years of being in the basement that IT was finally placed somewhere higher when it let loose its pack of Business Analysts. Although a lot of 'requirements' were being gathered very less of 'analysis' was really being done. At best it was just listen, document & build (to make matters worse... troves of wisdom was getting lost as the requirements were sometimes just a single point of view). No one's really to blame... the engineering was so heavy that it left very little time and resources for anything else. To add further pain, engineering (or rather the tooling) was everything. Even business seemed to be excited to brush up and spill a few technical jargons within rounds of being confused, lost and nervous at the same time.
So where do we go from here? Well, SaaS changes this... IT is no more about just the tool but more of utility. In simple terms quite a lot of the engineering and maintenance is already done and managed somewhere else and only the services (benefits) are available to pick and choose from. This is a welcoming change as IT can now focus on the 'value essentials' (i.e. analysis, processes, design, innovation, strategy, user experience, integration, reports, dashboards and other features). This is enabling the gap between what the business expects and what IT tries to provide to reduce. This is a striking difference as IT organizations will now create and own 'process' rather than just hone 'tools'.
The fact that the process is the focus changes the pattern of dialogue. IT teams will now be expected to participate and engage with richer thought contributions to business. The role will be more of an advisory. The shared knowledge contributions will be beneficial to building process ownerships and this will be what the organizations will find competitive advantage in. A successful process design will need to be tool agnostic. Conversely, a great SaaS offering will need to be process absorbing (following some best practices and being domain aligned). The best SaaS tools will be able to manage multiple permutations as needed with pure configuration. IT will need to understand and learn to operate faster, leaner and higher up the value chain with focus on business value by helping with fitment at the macro as well as the micro level.
Unfortunately, there is no single magic (or pill) to overcome the 'Service anxiety Syndrome' as this is no 'common cold'. Yes, SaaS alone does not cure SaS. It is also not just about jumping into SaaS by signing-up or bringing in some consulting/technical expertise to fix things up. It's a lot lot more and rather combined. As in the case of all anxiety cures the healing has to first start from within and with eating well. In the case of 'Service anxiety Syndrome' it starts with having an appetite for change!
In my last blog I mentioned about the importance of Data Governance and its evolution. I also tried to focus on the reasons behind the need and the opportunities that lie ahead. In this blog I would like to elaborate further on the challenges/needs mentioned and also try to outline ways to prevent/resolve them. I will focus on some seemingly obvious but mostly ignored concepts. Link to my previous blog Data Governance for SaaS (Part 1 of 2)
1. Firstly, the most obvious one... Involve all stakeholders and have expectations and solutions balanced and agreed upon at all times.
In IT Asset Management certain asset types carry confidential information (mobile sim PIN, User password, delegation rights control etc.). Managing security breach due to access of vital data via different screens or unforeseen entry points (i.e. via the reporting module or direct target url entry) is always a challenge.
To avoid this there can be data exchange agreements between the data provider and consumption teams. So by virtue of such agreements across the enterprise there can be a defined understanding for handling critical information across the various system records, archives etc. As the impact of these are fairly systemic its build should include expert advice & consent from Enterprise Architects, Information Security, Access & Risk Managers.
2. Follow the middle path... One should not relying on technology or tool alone to solve all their data problems.
Managing sensitive data (i.e. financial, health, legal data) in Incident, Problem, Change, Release, Service Catalog Management etc. often defy security rules. There are times when the business may need urgent solutions and ignorantly attach/share restricted information. This is unavoidable but nevertheless it is possible to have alerts based on the nature of the data that is being shared (A form of context driven help and support).
Sometimes, simple features and a little more thought goes a long way towards preventing inappropriate data sharing and mishandling. Process design, usability and training along with technology should be managed as a single piece to help achieve effective outcomes during implementation. Don't just focus on one aspect too much but rather focus on the whole (Ashwani's blog has some well compiled best practices around this).
3. Innovate... Have an integration framework in place and continuously weigh out options, consolidate and evolve.
Building interfaces, channeling data/triggers for Deployment provisioning, Product Catalog etc. and compliance could be the biggest security juggernaut. Having reliable interfaces to data sources and to be able to equally disperse information is priority for SaaS systems.
In one of our implementations we managed this via 'web services' as it was a strong capability of the platform we chose (Please refer to my earlier blog 'ITSM - Choice Matters'). With the right data structure we were able to have it exchange real-time updates across different tools (i.e. Scheduled jobs via inbound email rules is also effective but not preferred in all cases). The needs can be different but having a consolidate way of managing this maintains predictability and is more reliable & scalable option.
4. Think!... Getting a little more out of the tool by means of customization is tempting but it is important to first challenge the need and thoroughly evaluate the solution.
There will always be a need for new processes and modules (i.e. items which do not form a standard module in some tools). Most SaaS tools generally come with powerful admin configuration features. These are sometimes extendable to create one's own modules which can be integrated to leverage the combined benefits with existing modules (i.e. To avoid email overload to end users the need to build a subscription based project/release communication management module).
It's important to map and keep an alignment on the requirements, processes workflows and overall data architecture of the tool. Of course there is always a fine line between plain configuration and the need to customize (Please refer to Satsang's brilliant blog where he weighs out the options). Customizations are usually an overhead and this should be seriously weighed against priority and needs with the feedback from technical architecture and the vendor.
5. Celebrate... Dashboards are infact the most alive part of the system where the benefits of Data Governance become apparent. Groom and cherish it!
Graphical plans and charts (for incident, problem change reports, rollout plans, conflict detection, release schedules etc.) are no more nice-to-have's but rather a must. Data governance is not just about data security but also about combining data to create meaningful information for tracking, reporting, continuous improvement & business value. Reports were usually assumed to be basic and at best just data dumping capabilities.
Powerful visualization and report generation features are a valuable assets of SaaS tools today and some have taken a leap in redefining this. The concept of dashboards is a powerful one and this should be factored in early during requirements so that data structures can be defined with useful outcomes in mind.
Just to summarize... its common that project teams tend to ignore the most obvious. They sometimes push too hard in one direction and tend to deprioritize other important aspects. It's often a shame that innovation and brain power (or even gut feel and experience) has to give way to bureaucracy and heavy processes. The solutions are there and we obviously know them. It just takes a little more from all to appreciate and manage it instead of letting things go out of control...
It's critical that IT Departments are abreast with not only the current but also future needs of their business. This is easier said than done... but with SaaS in the picture, software development and deployment is not the same anymore. The ease of evaluation and adoption is quick and hence it's important for IT leaders to be ahead of the curve in knowing what's around and introducing these within the organization where they see fit. This should be done before the businesses start taking independent decisions without IT in the picture.It is important to understand and realize that rapid prototyping possibilities of SaaS does not necessarily reduce the expected time for analysis and testing. These are still critical and required. Cloud adoption is quick but this should not make it vulnerable to business pressure and prone to hasty signoffs or decisions. SaaS does not make Data Governance easier nor does it make it riskier. The paradigms are shifting, the possibilities are surely greater but dealing with it will require more focus on vision, innovation, creativity and most importantly leadership.
Posted by Aswin Kumar
Here is another one on Change Management from me. I have started feeling harder for the word 'End-to-End' and its time now that I speak up and share!
Normally, in a decent size organization with sound service management processes, we find that Change Management indulges in putting effective Change controls in place. The day for a typical Change Management process associate passes in reviewing Changes and running through the Change advisory meetings. The implementation teams work their ways to assure that the Changes pass the success criteria and are accepted by the sponsors after implementation. In this whole chicken and egg game, I feel that the piece before the Change planning and after implementation is generally weak or completely ignored.Continue reading "Managing Changes: Are you right brained or left brained?" »
Posted by Aswin Kumar
It may be a funny debate if I start scoping out the extra number of R’s required in Change Management. Anyway, I’m not a potential author of the next version of Service Transition book yet 
Of course, I always wonder why all the R’s were fitted under the magic number ‘Seven’? Was someone inspired by the ‘McKinsey 7-S Model’ or the ‘7 principles of Supply Change Management’?
Hey, Shirley and Ivor, Are you reading?
Continue reading "Does the next version of ITIL needs more than 7 Rs of Change Management? YES!" »
Preparing the Consulting team of North America for the next giant leap – By Anurag Bahal
As we saw our turbaned colleague tethered with the fragile rope struggling to breathe and sweating profusely we were excited and thrilled, not because of the moment of doubt but on the heights he had already accomplished. We wanted him to succeed; we wanted him to ring the sound of bell at the mountain. We cheered him to continue the relentless pursuit to the top and when he made it we were all lifted to the high spirits.
At the fag ends of the Infosys Consulting N.A. rendezvous, as I saw the bodies of top brains overcoming their limitation and climbing rocks, my mind echoed the thoughts of Og Mandino ( Author and Speaker)
"Failure will never overtake me if my determination to succeed is strong enough."
What happens when top consulting brains come together? Opportunities abound, sky is what we can do. Rewind a few months, there was some apprehension on the value of doing an all-hands meet, but I was overwhelmed by the enthusiasm of our group that put all doubts to sleep. There was a wave of exhilaration, an ocean of ideas in our 2 days meet.
Day 1
When the Infosys Leadership Institute (ILI) delivered the training program on Client Interfacing skills, all the consultants were jumping right into the thick of discussions. It is such an important area of a consultant life, that enough does not seem to be enough. The lessons on Probing Skills were very well received by the group and so was the exercise on practicing various types of questions. The Relationship Tracker is a good tool to track the client affinity for Infosys. The lesson on Polite Disagreement helped us frame our next client discussion for saying “No”. My personal favorite is the instructor’s definition of a good client interaction that goes “It is a good interaction only when the Value is flowing in both directions”
The 8 hours of training including the pizza lunch just flew away. We could have done for another 8 hours but for the promise of a beautiful evening at Malee’s. As William Feather, Writer said it "Plenty of people miss their share of happiness, not because they never found it, but because they didn't stop to enjoy it.", our group made sure that they not only found their fun but also had enough of it. People were amused to see Bombay curry at the Thai restaurant. Time to booze and celebrate the bonding.
Continue reading "Reminiscence of Consulting All Hands Meeting on 18th and 19th July 2008" »
- Anurag Bahal, Senior Consultant, Infosys
How do we create a common language of Communication and create Team Synergy using metrics?
America’s first billionaire J. Paul Getty said it “I would rather have one percent of efforts of a hundred people than a hundred percent of my own efforts”
Does web 2.0 hold any meaning from an IT Service Management (ITSM) perspective? RSS feeds, wikis, blogs - do they hold any promise of transforming ITSM as we know it?
Over the last couple of years, there has been an explosive increase in the adoption of web 2.0 concepts fuelled by the internet community. But how much of this has trickled to the ITSM space? Web 2.0 aspects including this blog have largely focused on commenting about ITSM and not really in the actual service delivery.
So are these two huge phenomena going to give each other a skip? Or are their paths destined to cross somewhere? And if so, what does that really mean?
Continue reading "Web 2.0 and ITSM: Long & Winding Roads?" »
When should I raise a Change Request?
That's an innocent enough question. So what's your answer -
In my earlier blog on Change Management metrics, I wrote about how several organizations use total number of Changes as a measure of the success of their Change Management process. Here, I would like to share with you some practices I have found useful in deciding what type of metrics to measure.
Continue reading "Musings on Change Management Metrics - Part 2" »
The total number of changes has gone down - our Change Management process is a success ... Is it?
A while back, I was assisting an organization to implement ITIL based Change Management process. Apart from (the usual?) complexities of implementation, something that struck me was the trigger for this implementation. "There are far too many changes within our organization - we need to reduce the total number of changes".
So, why am I writing about this? Well, for one, I am still quite amazed by the number of organizations that use total number of Changes as a primary measure of how successful their Change Management program is.
Does it make sense? No? So, is "total number of changes" a wasted metric? Not really. Arguably, it is a relatively easy and very visible metric to measure. But is it sufficient? Does it give a sense of what impact these changes have had on services? Does it indicate whether testing happened rigorously? Or, for that matter, does it even indicate whether basic adherence to process happened or not - such as having a back-out plan, impact analysis carried out, etc. Obviously it's not a stand-alone metric.
So then, what's a better measure? Hmm ... we'll get to that in a bit.
Continue reading "Musings on Change Management Metrics - Part 1" »
