IT services and processes are highly suited for optimization using a Lean Six Sigma approach. The inherent drive towards continuous optimization in ITIL and the excellent alignment principles of MOF are very well complemented by Lean Six projects*. The frequent misunderstanding of performance metrics and effective optimization in IT departments, coupled with the abundant management information handily collected by ticketing tools makes this area of the business a prime candidate for some black belt attention.
A practical example:
A certain mature and successful service provider supplies helpdesk services, system administration and infrastructure as a service to a customer, a large and professional organization. During the tender phase certain reporting standards and KPI's were agreed upon. The service is managed by these metrics, with the provider paying a malus fine whenever average performance falls below certain levels. These levels are defined and agreed in a separate service level agreement.
After a year it is clear that the services, on average, are provided at or above the agreed service levels, but that the occasional breaches in incident resolution time are a significant source of dissatisfaction for the customer. The service provider knows the traditional method to improve service in this area is to add resources to the team that resolves incidents, but this is expensive since the customer pays a fixed fee and the margin of the provider relies on resolving incidents cheaply.
At the customer's urging, the service provider brings in a team of Lean Six Sigma experts to see if there is a better way. The team knows very little about service management, but a lot about process optimization. The service provider watches with interest as the problem is defined, large amounts of data are requested and fed into spreadsheets and some over-caffeinated sessions ensue where one variable after another is scrutinised.
A few surprising truth emerge from the project. Instead of adding resources, the service provider is better served by re-architecting their incident management process to lower the time it takes to resolve incidents by a just few minutes each. Lowering the error rate of the resolver group turns out to be very important as well. Both of these findings are meticulously researched and presented to the supplier's management team.
It turns out that lowering the error rate and the process cycle time of the incident management process correlate very strongly to performing within agreed service levels, and to lower costs per incident. Adding resources to the pool actually turns out to have little effect on resolution time, and has a negative effect on the cost per incident. In hindsight, this makes a lot of sense to the service provider. After all, once there are enough resources to handle a regular workload, adding more people means that some of them will have little to do most of the time, and the team will be bigger, more complex and more costly.
Also, the project finds that the already low error rate of the service desk is a bottleneck. Errors engender a lot of confusion and necessitate double work, greatly increasing the time it takes to resolve the incident. The project digs into the factors that affect the error rate and find it can be lowered by creating more knowledge items for the service desk. These provide technical information and checklists to ensure incidents are resolved correctly.
By using Lean Six Sigma to optimise the service, specifically the all-important incident management process, the service provider gets far more than a happy customer. It matures beyond using a standard remedy for a common problem. Instead, the issue is managed by calmly considering the facts, gathering the relevant data and improving the aspects of the service which cause a bottleneck in the process flow. In this case, decreasing the time it takes to go through the process by a few minutes and unlocking more knowledge for employees turned out to be powerful solutions which would not have been found or implemented otherwise.
This example perfectly illustrates the value of 'Lean Six' for Service Management. Service levels are dependent upon many, often indirect variables. Customer satisfaction often has little to do with 'three nines' uptime, which needs to be taken for granted. Cookie-cutter solutions really are not good enough in the highly competitive IT industry.
An outside-in view is the hallmark of a successful Lean Six Sigma project. By targeting the customer's dearest wish (resolve all incidents on time), considering supplier-side constraints (cost per incident), crunching the data on actual performance instead of agreed performance levels this project found the way to deliver the desired result, every single time. This is the sweet fruit of applying management science to the IT department.
*: Jack Probst and Gary Case published an excellent whitepaper on integrating Six Sigma and ITIL to practice continual service improvement way back in '09: http://www.best-management-practice.com/gempdf/sixsigma_itil_csi_wp_july09.pdf
Showing posts with label ITSM. Show all posts
Showing posts with label ITSM. Show all posts
Wednesday, October 23, 2013
Tuesday, October 8, 2013
Tools of the trade
For a company looking to take the next step in service management maturity, there are many great software solutions for IT Service Management Tooling. Many of them are cloud-based and can be used for a monthly fee instead of a large upfront investment in licences. This post explores some of the do's and don'ts in setting up new service management tooling.
A common mistake made by both small and surprisingly large IT departments (who should know better), is to merrily start implementing a shiny new tool and expect some positive effect. This without exception leads to an infamous IT project that takes way longer than planned. When it succeeds in its primary objective, the implementation itself, it fails to achieve any positive net effect on the department. Tooling vendors tend to over-emphasize the capabilities of the tool and understate the need for a thorough preparation. Preparation for new tooling involves at least prior alignment to end user expectations, proper demand and supply management within the customer's IT department meticulous process design and a lot of training.
Many IT service providers have responded defensively to this trend of ad-hoc implementations at their customers. Providers prefer to rigidly adhere to their own well-developed processes and tooling and prevent working with a variety of bad implementations across their customer base. Especially larger IT service providers are able to enforce their approach of standardized services and service levels on customers. However, enterprises are not consumer-level mobile phone customers and often respond poorly to this take-it-or-leave it treatment, leading to a low renewal rate on contracts.
The best results are obtained when customer and service provider are well-matched and can develop an approach respecting the suppliers need for consistency while enabling the customer to make large improvements in process maturity and make use of customised solutions. Tooling is very much secondary in this approach, being implemented near the end of the transition phase after services, processes, organization and accountability have been defined and aligned between customer and service provider. Once this alignment is in place, tooling can be set up in one of two ways: a shared instance or connected instances.
A common approach is to set up a single instance of the tooling that everyone, from end users to service resolver teams can use over their respective computer networks. This works well as long as customer and service provider agrees to use a common set of processes, which may well be in the case of co-development mentioned above. Rights management tends to be an issue in this kinds of setup, as it involves authenticating users and sharing protected data on two different domains.
Because by and large the available tools are based on ITIL and provide roughly the same options it's often possible to create a coupling between two instances. This allows customer and service provider to exchange ticket information between their respective ticketing systems. This way everyone can keep their own way of working while providing the requisite connectivity at a tooling level. Care must be taken to allow for data exchange in the SLA times, and reporting on the end-to-end ticket lifecycle can be challenging. If both customer and service provider are large enterprises with mature processes and able to build and maintain such a link, it is often well worth the investment. I'm still waiting for the IT service management bus which will make transitions and links between tools a much more pleasant exercise.
In short: do not skimp on preparation and try to find a good match between customer and service provider, this will greatly benefit service quality and help to defray indirect costs due to inefficient service delivery.
A common mistake made by both small and surprisingly large IT departments (who should know better), is to merrily start implementing a shiny new tool and expect some positive effect. This without exception leads to an infamous IT project that takes way longer than planned. When it succeeds in its primary objective, the implementation itself, it fails to achieve any positive net effect on the department. Tooling vendors tend to over-emphasize the capabilities of the tool and understate the need for a thorough preparation. Preparation for new tooling involves at least prior alignment to end user expectations, proper demand and supply management within the customer's IT department meticulous process design and a lot of training.
Many IT service providers have responded defensively to this trend of ad-hoc implementations at their customers. Providers prefer to rigidly adhere to their own well-developed processes and tooling and prevent working with a variety of bad implementations across their customer base. Especially larger IT service providers are able to enforce their approach of standardized services and service levels on customers. However, enterprises are not consumer-level mobile phone customers and often respond poorly to this take-it-or-leave it treatment, leading to a low renewal rate on contracts.
The best results are obtained when customer and service provider are well-matched and can develop an approach respecting the suppliers need for consistency while enabling the customer to make large improvements in process maturity and make use of customised solutions. Tooling is very much secondary in this approach, being implemented near the end of the transition phase after services, processes, organization and accountability have been defined and aligned between customer and service provider. Once this alignment is in place, tooling can be set up in one of two ways: a shared instance or connected instances.
A common approach is to set up a single instance of the tooling that everyone, from end users to service resolver teams can use over their respective computer networks. This works well as long as customer and service provider agrees to use a common set of processes, which may well be in the case of co-development mentioned above. Rights management tends to be an issue in this kinds of setup, as it involves authenticating users and sharing protected data on two different domains.
Because by and large the available tools are based on ITIL and provide roughly the same options it's often possible to create a coupling between two instances. This allows customer and service provider to exchange ticket information between their respective ticketing systems. This way everyone can keep their own way of working while providing the requisite connectivity at a tooling level. Care must be taken to allow for data exchange in the SLA times, and reporting on the end-to-end ticket lifecycle can be challenging. If both customer and service provider are large enterprises with mature processes and able to build and maintain such a link, it is often well worth the investment. I'm still waiting for the IT service management bus which will make transitions and links between tools a much more pleasant exercise.
In short: do not skimp on preparation and try to find a good match between customer and service provider, this will greatly benefit service quality and help to defray indirect costs due to inefficient service delivery.
Tuesday, October 1, 2013
Fundamentals
It's commonly said by my IT Service Management compatriots that there are too few management benefits to be fully compliant to frameworks such as ITIL and COBIT. They're held to be much like the pirate code in Disney's Pirates of the Caribbean tetralogy, more like guidelines than actual rules, yarr.
The truth is, these frameworks are not enough, or rather, they are only a small part of what the IT department needs to deliver excellent results. The frameworks and good practices have been over-emphasized as a way to 'professionally' manage an IT department at the expense of general management practices which are much more urgently needed from a business perspective.
Running an IT department is like running any other business, or part thereof. The secret sauce of a great company or a great IT department is all in having good people and managing them well. That the good people in the IT department happen to be of the geek persuasion and tend to focus more on technology than process is no reason to throw management science out of the window and solely rely on IT industry inventions like ITIL.
Many IT departments and managers tend to fall on the spectrum between total ad-hoc troubleshooters and fairly compliant best practice fanatics, but the thoroughbred business manager is a rare find. A team of cherry-picked staff in the IT part of the business is even scarcer, and that is a crying shame.
The worst cases have an under-qualified team of admins report to the facilities manager. This is the IT management equivalent of stuffing your servers in a damp broom cupboard. No disrespect to the facilities guys who may be doing an excellent job managing the facilities, but IT services are rather dissimilar to their field of excellence.
The time when IT merely supported the business is long gone. IT is the business, in the the sense that there is no business to speak of when the IT is not perfectly in order. Gartner is very clear about it, business who don't get that they cannot afford incompetence in this area are playing a loser's game. If you give CEO's the choice between going without their headquarters, their car park or their IT infrastructure for a week, I guarantee they will not choose to be without the IT. The services delivered by the IT department or outsourcing partner fall squarely within the must-have category. This means that the management of these services can be left to Petered-out sysadmins as much as the corporate finance department can be left in the hands of anyone once certified in Excel 2003.
What the IT department needs is a good manager (a great manager if you can find one), a good team and an equal status to your finance and HR clubs, preferably in a tightly run shared service center with direct access to the executive team. That is no more or less than what your business needs these days. Only when those conditions are met the IT service management frameworks become useful good practices. There's always room on the wall for one more ISO certificate, but without good general management practices it won't do much good.
When advising my customers on IT strategy I draw upon some accessible management classics such as Jim Collin's Good to Great, Mastering the Rockefeller Habits by Verne Harnish and Daniel Pink's Drive to underpin my holistic IT management proposals in line with the views presented here. Have a gander.
The truth is, these frameworks are not enough, or rather, they are only a small part of what the IT department needs to deliver excellent results. The frameworks and good practices have been over-emphasized as a way to 'professionally' manage an IT department at the expense of general management practices which are much more urgently needed from a business perspective.
Running an IT department is like running any other business, or part thereof. The secret sauce of a great company or a great IT department is all in having good people and managing them well. That the good people in the IT department happen to be of the geek persuasion and tend to focus more on technology than process is no reason to throw management science out of the window and solely rely on IT industry inventions like ITIL.
Many IT departments and managers tend to fall on the spectrum between total ad-hoc troubleshooters and fairly compliant best practice fanatics, but the thoroughbred business manager is a rare find. A team of cherry-picked staff in the IT part of the business is even scarcer, and that is a crying shame.
The worst cases have an under-qualified team of admins report to the facilities manager. This is the IT management equivalent of stuffing your servers in a damp broom cupboard. No disrespect to the facilities guys who may be doing an excellent job managing the facilities, but IT services are rather dissimilar to their field of excellence.
The time when IT merely supported the business is long gone. IT is the business, in the the sense that there is no business to speak of when the IT is not perfectly in order. Gartner is very clear about it, business who don't get that they cannot afford incompetence in this area are playing a loser's game. If you give CEO's the choice between going without their headquarters, their car park or their IT infrastructure for a week, I guarantee they will not choose to be without the IT. The services delivered by the IT department or outsourcing partner fall squarely within the must-have category. This means that the management of these services can be left to Petered-out sysadmins as much as the corporate finance department can be left in the hands of anyone once certified in Excel 2003.
What the IT department needs is a good manager (a great manager if you can find one), a good team and an equal status to your finance and HR clubs, preferably in a tightly run shared service center with direct access to the executive team. That is no more or less than what your business needs these days. Only when those conditions are met the IT service management frameworks become useful good practices. There's always room on the wall for one more ISO certificate, but without good general management practices it won't do much good.
When advising my customers on IT strategy I draw upon some accessible management classics such as Jim Collin's Good to Great, Mastering the Rockefeller Habits by Verne Harnish and Daniel Pink's Drive to underpin my holistic IT management proposals in line with the views presented here. Have a gander.
Friday, September 16, 2011
IT's added value
Amidst the bearish sentiments and imminent collapse of the Greek economy it's a good moment to reflect on the business case of the IT department.
The good news: the IT department is definetly necessary. The obvious news: it has to demonstrate more added value to its company. The bad news: IT guys are not good at demonstrating value, because they're necessary. Performing at SLA levels is not added value, that's the agreed minimum. Yet soon enough some nice finance guys come knocking with cutback plans, and a requirement to show one's worth.
The IT department does have a strong process orientation in common with its financial department brothers, and a penchant for metrics and service level agreements. However, this will not be enough to prevent the finance guys from pulling a Cain on many IT department jobs when it's crunch time.
Factor in aggressive competition between IT service providers, outsourcing and offshoring alternatives, and cloud computing, and before you know it the entire department is Abel. Doom scenario? Of course.
So, plan V for value. The hidden power of an IT department is continuous service improvement. One clear way to demonstrate value is to provide clear metrics on the improvement of IT operations over time. If the department can show it delivers better warranty and utility to the business than last year, preferably saving dollars at the same time, it's a good show. I'll briefly discuss seven areas to measure and report on. For all of these area's, the real power is showing the trends over time.
People, IT operators
People are the core asset of the department, not computers, systems or processes. Measure their performance and show it front and center. Not only is it the most important data, but it's the easiest to relate to for the alpha-educated. People-related KPIs show not just how well employees perform, but displays the vital statistics on the department itself, its health and wellbeing. Overtime and sick days are writings on the wall to experienced executives.
Users
Our dear problems between keyboard and chair are of course second in line to be measured and reported on. User-related stats and KPIs show the value of the department to the business like nothing else. Basically, it shows how much work the department makes possible elsewhere. Show how many users to a single operator. Show how fast a new user is up and running with a new computer, phone, account, software etc. Show the department as an enabler.
Partners and suppliers
If you have mastered the exact art and subtle science of multi-vendor contracts, devote time to playing them off against each other. The opportunity is to create competition for quality, and the pitfall is to allow competition for price. Therefore measure and report on your partners and suppliers the same way you do on your own department, focus on the people and the quality of work delivered, focus on the value to the business. Make no bones about who gets more pie when it's time to re-negotiate those contracts.
Incidents
Incident metrics are real measures of quality for an IT department. For an operational report on the department level, this data would be perhaps second in line. When it comes to reporting added value, it's a bit lower in the list but therefore no less important. The business wants to know its uptime, its operational risks and the speed and efficacy of its solution mechanisms. Incidents per timeframe or average resolution time alone are not going to cut it. Showing a breakdown of self-service desk resolved incidents versus operator-resolved incidents and their respective severity, now that is showing why they pay the big bucks. A short story on the emergence and resolution of a major incident does not go amiss either.
Changes
Change management is absolutely vital, but the related data is almost unbearably boring. Standard changes / request fulfillment can be reported on by average time to fulfillment and closure. Non-standard changes are mainly interesting for how well they are executed. Therefore report the numbers of change-related incidents, and if it's a tight ship then the trend should slant to the lower right. A well done report harks back to the section on users: show the department as a business enabler by providing insight into the business changes enabled by IT Change management.
Configurations
Now, and only now, do we get around to the original raison d'être of this whole ITSM bit: the computers and other configurations. Lots of things to measure, lots of ways to demonstrate value. Show the reliability of the standard configurations, their total cost of ownership. Show how much discount was brokered in volume agreements with large manufacturers. Keep in mind that this stuff is really boring. Internally, maintain comprehensive data on the fleet, the stock and the various costs. Externally report the basics. Configuration-related metrics are important for driving operational excellence. Stock-keeping and supply chain management are arcane sciences of their own, which IT guys may underestimate. The larger your operation, the bigger the issue. Smart contracts can keep the onus largely on the supplier side.
Miscellaneous metrics
There are many more things to be reported on, according to preference. Some nice forms of report padding are storage size / cost versus utilization and my personal favorite: e-mail. Mail volume / related incidents / cost of mail solution per user / per e-mail are all eminently relatable for decision makers. Odds are the report was received by mail and is acted on with e-mails, so it's an appropriate and ironic salute to the IT-dependency of the company.
PR Metrics
Last and least are what I call PR-metrics such as customer satisfaction. I am gleefully swearing in church by saying this. If all the above measures are signs of a well-functioning IT department, then this happy user stuff should be completely superfluous. Conversely, of there is trouble in any of the above areas the customer satisfaction will be adversely affected.
Measuring customer satisfaction as your primary KPI is like measuring how close you are to port, while neglecting to measure your course, speed and prevailing weather. Sure, it tells you how well you are doing, but does not tell you a blessed thing about how to get better. Therefore measure and report all the rest first.
The bottom line
Never forget who holds the wallet and show your results to that guy. Everyone else is just filling a chair. It's not important how well you or anyone else thinks you do, it's important how well he thinks you do.
Secondly, don't think for a minute that this is too much paperwork. On good days, this paperwork enables operational excellence. In the bad days ahead, it's survival.
The bottom line of any executive decision is cost versus (expected) profit. Know your cost, show your profit.
The IT department does have a strong process orientation in common with its financial department brothers, and a penchant for metrics and service level agreements. However, this will not be enough to prevent the finance guys from pulling a Cain on many IT department jobs when it's crunch time.
Factor in aggressive competition between IT service providers, outsourcing and offshoring alternatives, and cloud computing, and before you know it the entire department is Abel. Doom scenario? Of course.
So, plan V for value. The hidden power of an IT department is continuous service improvement. One clear way to demonstrate value is to provide clear metrics on the improvement of IT operations over time. If the department can show it delivers better warranty and utility to the business than last year, preferably saving dollars at the same time, it's a good show. I'll briefly discuss seven areas to measure and report on. For all of these area's, the real power is showing the trends over time.
People, IT operators
People are the core asset of the department, not computers, systems or processes. Measure their performance and show it front and center. Not only is it the most important data, but it's the easiest to relate to for the alpha-educated. People-related KPIs show not just how well employees perform, but displays the vital statistics on the department itself, its health and wellbeing. Overtime and sick days are writings on the wall to experienced executives.
Users
Our dear problems between keyboard and chair are of course second in line to be measured and reported on. User-related stats and KPIs show the value of the department to the business like nothing else. Basically, it shows how much work the department makes possible elsewhere. Show how many users to a single operator. Show how fast a new user is up and running with a new computer, phone, account, software etc. Show the department as an enabler.
Partners and suppliers
If you have mastered the exact art and subtle science of multi-vendor contracts, devote time to playing them off against each other. The opportunity is to create competition for quality, and the pitfall is to allow competition for price. Therefore measure and report on your partners and suppliers the same way you do on your own department, focus on the people and the quality of work delivered, focus on the value to the business. Make no bones about who gets more pie when it's time to re-negotiate those contracts.
Incidents
Incident metrics are real measures of quality for an IT department. For an operational report on the department level, this data would be perhaps second in line. When it comes to reporting added value, it's a bit lower in the list but therefore no less important. The business wants to know its uptime, its operational risks and the speed and efficacy of its solution mechanisms. Incidents per timeframe or average resolution time alone are not going to cut it. Showing a breakdown of self-service desk resolved incidents versus operator-resolved incidents and their respective severity, now that is showing why they pay the big bucks. A short story on the emergence and resolution of a major incident does not go amiss either.
Changes
Change management is absolutely vital, but the related data is almost unbearably boring. Standard changes / request fulfillment can be reported on by average time to fulfillment and closure. Non-standard changes are mainly interesting for how well they are executed. Therefore report the numbers of change-related incidents, and if it's a tight ship then the trend should slant to the lower right. A well done report harks back to the section on users: show the department as a business enabler by providing insight into the business changes enabled by IT Change management.
Configurations
Now, and only now, do we get around to the original raison d'être of this whole ITSM bit: the computers and other configurations. Lots of things to measure, lots of ways to demonstrate value. Show the reliability of the standard configurations, their total cost of ownership. Show how much discount was brokered in volume agreements with large manufacturers. Keep in mind that this stuff is really boring. Internally, maintain comprehensive data on the fleet, the stock and the various costs. Externally report the basics. Configuration-related metrics are important for driving operational excellence. Stock-keeping and supply chain management are arcane sciences of their own, which IT guys may underestimate. The larger your operation, the bigger the issue. Smart contracts can keep the onus largely on the supplier side.
Miscellaneous metrics
There are many more things to be reported on, according to preference. Some nice forms of report padding are storage size / cost versus utilization and my personal favorite: e-mail. Mail volume / related incidents / cost of mail solution per user / per e-mail are all eminently relatable for decision makers. Odds are the report was received by mail and is acted on with e-mails, so it's an appropriate and ironic salute to the IT-dependency of the company.
PR Metrics
Last and least are what I call PR-metrics such as customer satisfaction. I am gleefully swearing in church by saying this. If all the above measures are signs of a well-functioning IT department, then this happy user stuff should be completely superfluous. Conversely, of there is trouble in any of the above areas the customer satisfaction will be adversely affected.
Measuring customer satisfaction as your primary KPI is like measuring how close you are to port, while neglecting to measure your course, speed and prevailing weather. Sure, it tells you how well you are doing, but does not tell you a blessed thing about how to get better. Therefore measure and report all the rest first.
The bottom line
Never forget who holds the wallet and show your results to that guy. Everyone else is just filling a chair. It's not important how well you or anyone else thinks you do, it's important how well he thinks you do.
Secondly, don't think for a minute that this is too much paperwork. On good days, this paperwork enables operational excellence. In the bad days ahead, it's survival.
The bottom line of any executive decision is cost versus (expected) profit. Know your cost, show your profit.
Monday, September 12, 2011
The call of the cyber sirens
The promise of new technology can be a real siren's call to an IT department. New
windows versions, new storage systems, a better process implementation can seem
so incredibly good that the business case seems to write itself. Then comes the
implementation project, and reality serves cold coffee for breakfast.
Jim Collins (Good to Great) once likened smooth operations and steady improvements in great organizations to a flywheel. It turns steadily, and with steady increments it can go faster and faster. Great results come from evolution.
Similarly, the most important function of an IT department is to support the central process of the company by ensuring the utility and warranty of its IT assets. In short, keep it ticking over nicely. Improvements are always welcomed, revolutions are not.
The cloud, (internal) social networks, Bring Your Own Device (BYOD) support are al great phenomena with a lot of promise, but at the same time they are silly fads that have yet to prove that they can add to your company's bottom line. Yes, they add billions to Apple and facebook, but the odds are your company has a different focus altogether. Readiness for 2015 does not mean equipping all employees with telepathy chips over the next six months.
Once in a while the sales pitch is just too good and an IT department saddles up, corrals some consultants, and goes to work delivering tomorrow, today. Research says at least 30% of IT projects fail, costing businesses green stuff without ever delivering on their promise. Some estimate as many as 68% of IT projects are doomed. Most participants are even aware of this, never expecting a hyped up IT project to succeed at all. What happened there? Lack of ambition? Steady improvements? Nope. Finance forgot to tie Odysseus with a nice tight budget.
On the other hand there are a lot of businesses doing amazing things with technology, step by step bypassing their impulsive competitors to reach a level of sophistication beyond any of them. The aforementioned book contains examples of companies progressing steadily from old-skool a-technical companies to operating their own custom satellite systems, one small step at a time, never trying to go from 0.1 to 2.0 in one giant leap.
In short, IT departments might do well to instill a motto, "we live to serve" or something humble like that, and make sure that they run the smoothest IT operation rather than the most cutting edge. DevOps, anyone?
Jim Collins (Good to Great) once likened smooth operations and steady improvements in great organizations to a flywheel. It turns steadily, and with steady increments it can go faster and faster. Great results come from evolution.
Similarly, the most important function of an IT department is to support the central process of the company by ensuring the utility and warranty of its IT assets. In short, keep it ticking over nicely. Improvements are always welcomed, revolutions are not.
The cloud, (internal) social networks, Bring Your Own Device (BYOD) support are al great phenomena with a lot of promise, but at the same time they are silly fads that have yet to prove that they can add to your company's bottom line. Yes, they add billions to Apple and facebook, but the odds are your company has a different focus altogether. Readiness for 2015 does not mean equipping all employees with telepathy chips over the next six months.
Once in a while the sales pitch is just too good and an IT department saddles up, corrals some consultants, and goes to work delivering tomorrow, today. Research says at least 30% of IT projects fail, costing businesses green stuff without ever delivering on their promise. Some estimate as many as 68% of IT projects are doomed. Most participants are even aware of this, never expecting a hyped up IT project to succeed at all. What happened there? Lack of ambition? Steady improvements? Nope. Finance forgot to tie Odysseus with a nice tight budget.
On the other hand there are a lot of businesses doing amazing things with technology, step by step bypassing their impulsive competitors to reach a level of sophistication beyond any of them. The aforementioned book contains examples of companies progressing steadily from old-skool a-technical companies to operating their own custom satellite systems, one small step at a time, never trying to go from 0.1 to 2.0 in one giant leap.
In short, IT departments might do well to instill a motto, "we live to serve" or something humble like that, and make sure that they run the smoothest IT operation rather than the most cutting edge. DevOps, anyone?
Friday, September 9, 2011
Creeping elegance
Programmers tend to be perfectionists, and are familiar with a phenomenon known as
creeping elegance. While writing code, it becomes an obsession to write it as tersely
and elegantly as possible, which comes at the expense of time, readability and focus on
the final product.
Projects can also experience creeping elegance, in this form an insidious variety of scope creep. Say there's a process optimization going on in a very basic environment. Little documentation, lots of informal procedures, opaque and implicit knowhow ingrained in the employees, organic structure, the works. The project brief states that the goal is to document knowledge and procedures, design and roll out a standardized process, and train employees in the new and formal way of working. The allotted time is nine months, 5 internal people are put on the project for 20% of their time, and three consultants are hired.
A year later, a cold cup of coffee overhears a debate about indentation in the new documentation template, mixed with comments on the frequency of detailed status reports. The cup quietly reflects that, just like twelve months ago, neither the template nor the report are used operationally, but once the project is done they will surely be things of awesome perfection, terrible to behold and a slap in the face of any IT department who gets by with a lesser standard.
What happened? Creeping elegance. It's very hard to decide when to stop once you're improving something. At what point has enough knowledge been documented? When is a process good enough? That's undefined. It's not like a building plan where you're done at some point, when the building stands tall and happy tenants are preparing dinner inside.
Operationally, this is easy. Continual Service Improvement (CSI) is the name of the game. Steady progress. But when improvement becomes a project, it's very hard to keep the creeping elegance genie in the bottle. The only solution is strict timelines, and a project manager with enough common sense to nip creeping elegance in the bud. When the sand runs out in the hourglass, whatever is agreed on is delivered as the final product, and operational CSI takes over. Mission accomplished.
Projects can also experience creeping elegance, in this form an insidious variety of scope creep. Say there's a process optimization going on in a very basic environment. Little documentation, lots of informal procedures, opaque and implicit knowhow ingrained in the employees, organic structure, the works. The project brief states that the goal is to document knowledge and procedures, design and roll out a standardized process, and train employees in the new and formal way of working. The allotted time is nine months, 5 internal people are put on the project for 20% of their time, and three consultants are hired.
A year later, a cold cup of coffee overhears a debate about indentation in the new documentation template, mixed with comments on the frequency of detailed status reports. The cup quietly reflects that, just like twelve months ago, neither the template nor the report are used operationally, but once the project is done they will surely be things of awesome perfection, terrible to behold and a slap in the face of any IT department who gets by with a lesser standard.
What happened? Creeping elegance. It's very hard to decide when to stop once you're improving something. At what point has enough knowledge been documented? When is a process good enough? That's undefined. It's not like a building plan where you're done at some point, when the building stands tall and happy tenants are preparing dinner inside.
Operationally, this is easy. Continual Service Improvement (CSI) is the name of the game. Steady progress. But when improvement becomes a project, it's very hard to keep the creeping elegance genie in the bottle. The only solution is strict timelines, and a project manager with enough common sense to nip creeping elegance in the bud. When the sand runs out in the hourglass, whatever is agreed on is delivered as the final product, and operational CSI takes over. Mission accomplished.
Saturday, September 3, 2011
Framework Sceptics
Once in a very great while one comes across a project or company so embroiled in paperwork that you come to suspect their managers of a fetish for red tape. However, most projects want to succeed and most companies want to make money, so it does not occur too often, and when it does the consequences for success and profit are easy to predict.
Amongst IT Service Management consultants its a bit of a sport to speak disparagingly of commonly used process frameworks like ITIL and BiSL, and project consultants in general like to make light a of full-blown PRINCE2 approach to projects. It would be very amusing for a physicist to essay the shortcomings of relativity, a composer to mock music theory or an accountant to say that the GAAP standard takes itself too seriously, but they don't tend to do that. These people realize that you don't have to involve Einstein's entire work every time you conduct an experiment with time and space, not all notes need be in a composition, and not all rules apply to all ledgers at all times. They go quietly about the business of being good at whatever they're good at.
Not the IT consultant. You're not a man to be reckoned with until you've stated that this or that framework is far too complex, never mind that you've never worked for an organization large or complex enough to utilize it. Project leaders are even worse. Depending on whom you ask, well over half or, according to some, more that three quarters of projects end in failure. Failure. Not on time, not within budget, and certainly not delivering the desired result. In my (albeit limited) experience, most projects suffer from a lack of preparation and an excess of unstructured work. I've yet to encounter the truly pointless progress report, the completely useless review meeting or the irrelevant risk register. Neither have I seen an IT department run so well that it cannot benefit from a little process optimization and a smidgeon more compliance to standards.
The criticism that a framework is too complex is irrelevant as long as it is not the stated purpose of that framework to be implemented down to the last detail. Scalability is at the heart of all frameworks I mentioned. The criticism that compliance comes at the price of agility and efficiency is a non-sequitur. It's true, but compliance is still worth the warranty it gives.
BP can tell you, they were not broken by over-compliance to a set of rules and regulations. One or two executives might even admit that a few more inspections and reviews would not have gone amiss. Similarly, I doubt a CIO was ever berated by his CFO for wasting money on process compliance. Rather a lot of them have had complaints about budget overruns on their projects, poor knowledge and asset management and opaque departments, I daresay. A little bit of common wisdom, also known as a best-practice based framework would not hurt to make sure the same comments don't come up during the next review.
Rather than proving the mastery of your trade by critiquing the work of others (which is used to great effect by many on a daily basis), contribute to the improvement of your tools and help to make the frameworks as slim and efficient as they can be. It's not like ITSM is an academic discipline (as opposed to, say, aerospace engineering).
Amongst IT Service Management consultants its a bit of a sport to speak disparagingly of commonly used process frameworks like ITIL and BiSL, and project consultants in general like to make light a of full-blown PRINCE2 approach to projects. It would be very amusing for a physicist to essay the shortcomings of relativity, a composer to mock music theory or an accountant to say that the GAAP standard takes itself too seriously, but they don't tend to do that. These people realize that you don't have to involve Einstein's entire work every time you conduct an experiment with time and space, not all notes need be in a composition, and not all rules apply to all ledgers at all times. They go quietly about the business of being good at whatever they're good at.
Not the IT consultant. You're not a man to be reckoned with until you've stated that this or that framework is far too complex, never mind that you've never worked for an organization large or complex enough to utilize it. Project leaders are even worse. Depending on whom you ask, well over half or, according to some, more that three quarters of projects end in failure. Failure. Not on time, not within budget, and certainly not delivering the desired result. In my (albeit limited) experience, most projects suffer from a lack of preparation and an excess of unstructured work. I've yet to encounter the truly pointless progress report, the completely useless review meeting or the irrelevant risk register. Neither have I seen an IT department run so well that it cannot benefit from a little process optimization and a smidgeon more compliance to standards.
The criticism that a framework is too complex is irrelevant as long as it is not the stated purpose of that framework to be implemented down to the last detail. Scalability is at the heart of all frameworks I mentioned. The criticism that compliance comes at the price of agility and efficiency is a non-sequitur. It's true, but compliance is still worth the warranty it gives.
BP can tell you, they were not broken by over-compliance to a set of rules and regulations. One or two executives might even admit that a few more inspections and reviews would not have gone amiss. Similarly, I doubt a CIO was ever berated by his CFO for wasting money on process compliance. Rather a lot of them have had complaints about budget overruns on their projects, poor knowledge and asset management and opaque departments, I daresay. A little bit of common wisdom, also known as a best-practice based framework would not hurt to make sure the same comments don't come up during the next review.
Rather than proving the mastery of your trade by critiquing the work of others (which is used to great effect by many on a daily basis), contribute to the improvement of your tools and help to make the frameworks as slim and efficient as they can be. It's not like ITSM is an academic discipline (as opposed to, say, aerospace engineering).
Tuesday, August 30, 2011
ITSM-fu, beware the acquisitions!
IT service management is all about ensuring the warranty and utility of IT assets and services. Simply put, the IT has to support the company's main process well. Incident management, change management and so on are fairly standardized processes that help companies manage their IT environment.
Some changes to the environment are wholly out of scope of these regular, 'busines-as-usual' processes, because they do not originate from within the processes themselves. IT Service Management is a bit introspective.
A favorite activity of growing companies is acquisition: gobbling up big competitors, promising start-ups and maybe something more outré for diversification. These companies are bought for their valuable people and assets, and nowadays a lot of the value of a company is its data. IP, content, patents, customer data, research databases, what have you.
A lot of this virtual gold is in formats and systems which are different from, sometimes fundamentally incompatible with, the buyers own data and systems.
The positive impact of new purchases is therefore determined in part by the ability to absorb new data, and bring it in line with ones own databases, systems and procedures for access.
IT Service Management frameworks need to expand their focus beyond running business-as-usual IT services. Robust procedures and best practices for integrating new IT systems and large, diverse data sets need to be developed as part and parcel of IT service management in general. Running a series of technical projects every time an acquisition is made is less effective for bypassing the regular IT service management organization, because that is where, ultimately, all new systems and data end up being managed anyway.
Currently, a lot of knowledge resides within large companies. Some of them have very strict policies for this sort of thing, and have absorbed a new buy in six months. Others take forever as ponderous projects with lots of external expertise are sent up to digest acquired data. The technical know-how can always be found, however, all the management and governance level experience is currently not distilled into frameworks and best practices, and companies are poorer for it.
As long as an integration process is not properly managed from the perspective of the regular IT-organization, it will have a large and detrimental impact on regular ITSM processes because they are calibrated towards preserving the business-as-usual IT organization, not towards merging IT organizations while preserving the current warranty and utility of IT services. This is a hard thing to do.
The next iteration of frameworks like ITIL need to address the needs of large companies when it comes to adopting acquisitions to maintain their status as comprehensive IT Service Management frameworks.
The current set of processes needs to be expanded. Currently, change management and release management are originators of change in the environment, presuming that IT service management instigates change, rather than reacts to it. New processes have to be defined and integrated with the rest, which deal with imposed change and seek to absorb and integrate new data and systems. The knowledge is definitely out there, and it is up to platforms like the IT Service Management Forum to distill it into the current frameworks. I mentioned ITIL a lot, but certainly BiSL and ASL are up for the same improvement.
The bottom line is that the biggest changes in an IT environment often come from the outside, and the success of the company can hinge on how well these changes are dealt with. IT service management frameworks need to adjust from introspection to adaptivity: ITSM-fu.
Some changes to the environment are wholly out of scope of these regular, 'busines-as-usual' processes, because they do not originate from within the processes themselves. IT Service Management is a bit introspective.
A favorite activity of growing companies is acquisition: gobbling up big competitors, promising start-ups and maybe something more outré for diversification. These companies are bought for their valuable people and assets, and nowadays a lot of the value of a company is its data. IP, content, patents, customer data, research databases, what have you.
A lot of this virtual gold is in formats and systems which are different from, sometimes fundamentally incompatible with, the buyers own data and systems.
The positive impact of new purchases is therefore determined in part by the ability to absorb new data, and bring it in line with ones own databases, systems and procedures for access.
IT Service Management frameworks need to expand their focus beyond running business-as-usual IT services. Robust procedures and best practices for integrating new IT systems and large, diverse data sets need to be developed as part and parcel of IT service management in general. Running a series of technical projects every time an acquisition is made is less effective for bypassing the regular IT service management organization, because that is where, ultimately, all new systems and data end up being managed anyway.
Currently, a lot of knowledge resides within large companies. Some of them have very strict policies for this sort of thing, and have absorbed a new buy in six months. Others take forever as ponderous projects with lots of external expertise are sent up to digest acquired data. The technical know-how can always be found, however, all the management and governance level experience is currently not distilled into frameworks and best practices, and companies are poorer for it.
As long as an integration process is not properly managed from the perspective of the regular IT-organization, it will have a large and detrimental impact on regular ITSM processes because they are calibrated towards preserving the business-as-usual IT organization, not towards merging IT organizations while preserving the current warranty and utility of IT services. This is a hard thing to do.
The next iteration of frameworks like ITIL need to address the needs of large companies when it comes to adopting acquisitions to maintain their status as comprehensive IT Service Management frameworks.
The current set of processes needs to be expanded. Currently, change management and release management are originators of change in the environment, presuming that IT service management instigates change, rather than reacts to it. New processes have to be defined and integrated with the rest, which deal with imposed change and seek to absorb and integrate new data and systems. The knowledge is definitely out there, and it is up to platforms like the IT Service Management Forum to distill it into the current frameworks. I mentioned ITIL a lot, but certainly BiSL and ASL are up for the same improvement.
The bottom line is that the biggest changes in an IT environment often come from the outside, and the success of the company can hinge on how well these changes are dealt with. IT service management frameworks need to adjust from introspection to adaptivity: ITSM-fu.
Monday, April 4, 2011
IT matters
The central assumption of IT service management is that IT matters, that if it's worth running your business on computers it's worth doing it properly.
Computers become really useless, really fast without maintenance, support, life cycle management and many other processes indispensable to a modern business.
All too often, the IT department is part of the facilities department, or seen as a necessary evil, a cost center populated by informally dressed nerds.
As information and communication have become indispensable to a modern organization, proper IT service management has become a must have and a significant competitive advantage. An IT department, ideally, is a true enabler. An enabler of productivity, of change, of control and optimalisation. An equal to and partner of every other part of the organization.
Proper IT service management enables companies to run their IT department as tightly and effectively as they run their central process and their HR and finance departments.
The field is not fully developed, academically speaking, and continues to balance precariously between demand and neglect by large enterprises. Compared to the volume of academic work on HR management and finance management it is barely developed at all. There are great developments, however.
The most thorough approach to IT service management is the ITIL framework, which is has as many detractors as fans. The ITIL framework is commonly used as a set of best practices and followed loosely by many IT organizations. True ITIL experts or masters are few and far in between, customers usually demand practitioner (mid-level) certification and working experience.
IT governance is the top of the ITSM pyramid and the hardest part for organizations to master. Great CIO's are even harder to find than other great executives, and it will be a while before seasoned IT executives are common. Because ICT is such a rapidly changing sector, it's hard to acquire the seniority necessary for an executive position while staying on top of the field. Fresh graduates lack the experience and power, and veterans can easily get out of touch with the latest developments such as cloud services and social media.
It is a great time to be an interdisciplinary IT and business expert, however, as companies make do with the expertise offered by the market. Universities like the TU Delft are turning out experts in business informatics, and large IT service companies like Cognizant are rapidly expanding their ability to be a partner in IT service management.
In a few short years business science and business practice will have caught up completely with computer science and IT practice, and companies will look back and wonder how they ever got by with improvised IT service management and most of all IT governance.
IT matters too much for any other development.
Computers become really useless, really fast without maintenance, support, life cycle management and many other processes indispensable to a modern business.
All too often, the IT department is part of the facilities department, or seen as a necessary evil, a cost center populated by informally dressed nerds.
As information and communication have become indispensable to a modern organization, proper IT service management has become a must have and a significant competitive advantage. An IT department, ideally, is a true enabler. An enabler of productivity, of change, of control and optimalisation. An equal to and partner of every other part of the organization.
Proper IT service management enables companies to run their IT department as tightly and effectively as they run their central process and their HR and finance departments.
The field is not fully developed, academically speaking, and continues to balance precariously between demand and neglect by large enterprises. Compared to the volume of academic work on HR management and finance management it is barely developed at all. There are great developments, however.
The most thorough approach to IT service management is the ITIL framework, which is has as many detractors as fans. The ITIL framework is commonly used as a set of best practices and followed loosely by many IT organizations. True ITIL experts or masters are few and far in between, customers usually demand practitioner (mid-level) certification and working experience.
IT governance is the top of the ITSM pyramid and the hardest part for organizations to master. Great CIO's are even harder to find than other great executives, and it will be a while before seasoned IT executives are common. Because ICT is such a rapidly changing sector, it's hard to acquire the seniority necessary for an executive position while staying on top of the field. Fresh graduates lack the experience and power, and veterans can easily get out of touch with the latest developments such as cloud services and social media.
It is a great time to be an interdisciplinary IT and business expert, however, as companies make do with the expertise offered by the market. Universities like the TU Delft are turning out experts in business informatics, and large IT service companies like Cognizant are rapidly expanding their ability to be a partner in IT service management.
In a few short years business science and business practice will have caught up completely with computer science and IT practice, and companies will look back and wonder how they ever got by with improvised IT service management and most of all IT governance.
IT matters too much for any other development.
Subscribe to:
Posts (Atom)