Binder-chuckers
The problem with too many ITSM consultants is that they are binder-chuckers. ITSM consulting is not about inventing a process. It is about enacting cultural change.
This post was inspired by a remark on TechRepublic: "many organizations don’t seem to truly realize that Best Practice is not a one-off implementation, nor is it self-sustaining"
That ought to be the consultant's job to implement real cultural change in people and put in place an ongoing mechanism to sustain whatever they build. So many software vendors are "box-droppers". In the same way too many ITSM consultants are "binder-chuckers" who think delivering means spewing reams of paper. In my consulting practice I call myself the ITIL Archaeologist because half the time my first task is to dig out the ruins of the last investment they made.
The organisation engages a consultant to help change the way things happen. I.e. they want to change the attitudes and behaviours of people. The process is just one tool to help in that change, as is the technology.
Consultants: if you are not enabling the client to realise ROI on what they pay you, then you are stealing. Our obligation as consultants is to provide a solution to cultural change, not a binder of swimlane flowcharts and a bunch of Foundation courses and a generic implementation of a service desk tool.
Made in New Zealand 
Comments
Culture change is slow
When a manager decides to hire a consultant, there usually is some pain, some need has been recognized. Quite often the cause for that pain is some type of management problem which shows as confusion and unclear responsibilities. My consulting method is try to show them an alternative solution at a concept level. In an ideal case, the people grasp the idea and implement it themselves. Nine months later they are very happy with the solution they have invented themselves and are improving it on their own; the consultant's input may be already forgotten. The cultural change does not happen within the consulting project but it may start because of that.
If a manager hires consultants to implement and document ITIL processes, then the problem is the manager. I suppose Dogbert the consultant shows how to deal with Dilbert type of management ;-)
Aale
No brainer, but wait...
Reading the first comment through the last, being a consultant and at my altruistic best, I agree with Skep with full force. Our job as consultants (or IT Professionals for that matter - but they have less authority/leeway to make the right change) is to enact the right cultural change that our customers are requiring (regardless of 'what they ask for'). If we only did what our customers ask for, wouldn't we have even more Remedy (read CMDB/CMS in a box) tool only focused implementations out in the ITSM world?
I can see and I respect the rub (which I can commiserate with the others on) where committing to doing what the customer asks and thus keep the pipeline of work healthy necessary to keep the mortgage paid (Rob - back to our #pink11 discussion with Mr. Dancy and Mauricio) is in direct conflict of my altruistic drive to ensure the customer gets the right change/improvement/value and in the long run keeps my reputation or any follow on work safe. Working with the customer to educate and 'sell' them on the idea that "No, that's not what you need" is a tough line to hold. Thankfully, so far, my customers for the most part 'get it' and so my voice is heard, respected and we push on together.
On the bigger picture altruism side, the danger of only doing what is asked for is part of the mess we're all trying to dig out of with ITIL/ITSM. Another great discussion had at #pink11 was on that of Asset vs. CMDB vs. CMS environments. I would wager that tool vendors that don't care about 'the right thing' or don't 'get it' and are ONLY concerned with hitting their numbers and keeping the mortgage paid and their Gold status with BMC active, are high on the list to blame for the failures our industry has seen around CMDBs and CMSs. Maybe keeping the patient sick is how to handle the ITSM world and make a valueless buck, but like Skep paints, are there really that many out there that like the taste of ash over and over and over again?
organizational and people factors
And another voice, this time from ITSMWatch:
1. Culture
2. Communications, Training and Education
3. Executive Support and Buy-in
4. Governance Structure
5. Roles and Responsibilities
6. Measurement and Reporting
Perfect timing: ITSM success factors
Perfect timing from GamingWorks:
the ‘People’ related factors are seen as the largest grouping of critical success factors for ITSM success. Take a look at your ITSM improvement plan and see how many hours, how much time, money and investment is proportioned to each of the above
...and I would argue that the other factors are mostly "People" factors too: "owned", "agreed", "known".
If organisations don't address this adequately (read: over 50% of the effort) then they are wasting money on doomed efforts. The role of "consultant" is to advise and guide. If they don't ensure this stuff is done then they are wasting their clients money and taking their payment on false pretenses that they are actually going to change something.
Binger Chucker?
Is an "ITSM Binder Chucker" anything like a "Data Center Iron Hugger"? ;-)
My Best,
Frank
The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices
out of the primeval swamp
Binder chucker is the next evolutionary step up the tree
People (real change)
|
Process (binders)
|
Technology (iron)
LOL!
OK! This made me laugh out loud!
Maybe you've missed your calling???
My Best,
Frank
The International Foundation for Information Technology (IF4IT)
Open IT Standards & Best Practices
respectfully disagree.
You write that, "Our obligation as consultants is to provide a solution to cultural change."
It does not seem so to me at this time.
Our obligation as consultants is to faithfully and expertly execute on the contract. To deliver what the client wished.
Corporate cultural change is possible only if management commits to culteral change. That's rare.
No pain, no change. Organizations are like Maister's "fat smoker." They are unlikely to change unless there is some real motivation to do so (pain). And, like stopping smoking and/or losing weight it is best done with consistently applied help (consultant as coach).
In fairness to consultants, and companies - consultants are hired to do a job, often implement software. One can try, sometimes quite hard, to set an expectation that there will be some need to develop process (eat less, workout), but management optimism bias and trust in the sales literature often overwhelms customers. They read that the software will automate things - and it often will help a great deal. But, they forget they must have the process to automate first. When the miracle doesn't occur - they are dissapointed. In a project management oriented corporate culture - they want changes as a project - with no follow on maintenance.
I don't much care about their culture. As a consultant I try to follow Peter Drucker advice, "Company cultures are like country cultures. Never try to change one. Try, instead, to work with what you've got."
I care about their effectiveness and performance - things I can measure and things I can show them will improve their situation. Or, as some would put it - players know the score. As Rickover wrote, "Good ideas are not adopted automatically. They must be driven into practice with courageous impatience. Once implemented they can be easily overturned or subverted through apathy or lack of follow-up, so a continuous effort is required."
Roger Enrico's warning about change is also right, "Beware of the tyranny of making small changes to small things. Rather, make big changes to big things.” All too often organizations get wrapped around the axle on resisting small changes - and, never see the big changes needed to be competitive, so they just fade away.
make a difference
I'm confused. How can you make big changes (which actually return some value on the money spent) without changing behaviours?
I don't buy the "i'm just here to do a job" line. We consultants are there to guide and educate, to make a difference. Contractors are there to do a job, by the day - I'm not a contractor. If I don't agree with what the job is and I can't get agreement, I walk away. I'll not waste their money making changes that won't make a difference and won't stick. And i don't believe that making a lasting difference is possible without addressing behaviour and attitude. "Caveat emptor" is a warning for buyers not an excuse for vendors.
I think this is the first time I've disagreed with Cary :)
Just not culture change
I suppose what I disagree with is the idea of "culture" change and the assumption of some duty by consultants to make such change. It's too broad.
Consultants take jobs with customers knowing that perfection will not be achieved - but thinking they'll move the ball forward and get a chance for more advancement later.
All engagements require some degree of change. Changing the "culture" is something else. Besides, consultants are just consultants. Advisors. Let's not lay so much as their feet - you can lead a horse to water, you can't make them drink. Let's leave the responsibility for change with the managers and employees in the company.
Change? Behavioral change? I'm not so sure.
We can train 'em - why and how. We can help them develop process, organization, policies. We can implement their software with/for them. We can help them break down their barriers to change. If they allow us, we can coach them through working with their personnel to explain and communicate and set new expectations based upon real benefits to change.
As with the fat smoker's trainer, they must be the ones to change. In the end, they are ones that must change.
We can show the client how to do things that would cut costs by 20% - for IT as a whole. We can show them how to develop financial transparency that will lead, at last, to trust with the rest of the business. Ian and you and I can help them learn how to improve using Lean and Six Sigma techniques and standardization. But, in the end, they must have the discipline and will to follow up with that change.
There's no question that we can help them. But, until they really want to change - they won't. This is not a process thing - it's a very personal, management resistance, status quo bias thing.
Think Software Asset Management, for instance. Software licensing is some 25% of their budget. Software replacement value, total risk, often roughly the same as their labor budget. It is becoming more common for companies to get audits that result in true-ups to the tune of more than 20% of their IT budget - for one vendor only. And that doesn't address the overlicensing they've already wastefully spent on. All of that is common knowledge - yet only about a quarter of companies have taken action. Like fat smokers.
enlightenment and persuasion
Then we're in agreement, I think. Sure you can only lead a horse to water. But if the objective is to water the horses, and the job is to install drinking troughs and a dam, but nothing in the spec mentions leading horses, then I want to get leading of horses written into the statement of work. in fact I just write it in and tell the client it is essential to realising value on their investment. Town halls, workshops, newsletters, user walkthroughs, coaching, executive walk the walk, all the Kotter stuff... It's in the SoW, it's part of the scope and the estimate. If they're not buying it then i don't want to be associated with failure.
Sure the major impetus must come from management. But often all they need is enlightenment and persuasion: this is what you need to succeed. This is why your previous efforts failed or fell into ruin. Because you only changed the tools and the practices, not the people. last time, too many didn't believe it, didn't buy in, didn't want it.
Consulting
This is a really interesting topic - one which is too often glossed-over in the rush to implement tools, training and big ITIL programmes - its certainly at the core of what we do and has been for me for many years. I agree with Skep re its our responsibility to influence change, but also sympathise with Cary re the reality of dealing with projects, briefs and clients.
For me there is a clear distinction bentween (1) (management) consulting, where we have the responsibility, whether or not defined in the brief, to give the client the best advice and to try and influence their decision-making in their best interests, and (2) projects + programmes, where policy, strategic and buying decisions (should) have been made and are being executed.
Often these areas get jumbled up, but for me the key is how and where both of these types of work is sold. Is it sold at the right level and at the best time in the project or service lifecycle? if its too late then it can be a thankless task to try and retro-influence clients and flag up issues once a programme is under way - this is often the case for software vendors and consultancies when 'off the shelf' products and services are sold - but it can happen to anyone. For me the key is to get to the right people at the right time with the right proposition - this requires some bravery on the part of the sales organisation, as well as the initial consultants who may need to flag up issues that might ruin or delay the chaces of selling on a big ticket project.
Its difficult because we all have to eat and e.g. if a client is wanting to buy a project which you don't think is right for them, then it could be galling to see this go to a competitor. However the long term value and quality of the relationship should previal if there is quality and integrity in the initial sales and consulting approach. It doesn't always happen, but e.g. I would rather (and do) have a number of long term relationships based on this, than simply going for the short term option. I've taken on and regretted apparently lucrative but flawed and high-maintenance projects over the years but they're ultimately draining on resources, energy and cost - so its a business as well as personal and strategic decision to avoid them.
If I can't at least have an honest conversation with my client then it will end up coming back to me
ashes in our mouths
I too have done the odd bit of "be it on your own head" work but the rewards are ashes in my mouth. I've rationalised it to myself as perhaps I can minimise the damage and/or achieve some good results anyway. Of course that turns out to be optimistic.
I'm convinced one of the major reasons IT has such a crap track record for projects is this neglect of the people/culture/behaviour aspect. there is still a book in there though it has been way too long coming.
And many managers are amenable to the argument: why half invest and assure poor ROI?
Thoughts on why people fail
Managers make the decisions about priorities, budgets and employee discipline.
Without management support, initiatives fail.
http://www.marshallgoldsmithlibrary.com/cim/articles_display.php?aid=117
http://www.marshallgoldsmithlibrary.com/cim/articles_display.php?aid=321
David Maister's - Strategy and the Fat Smoker.
executive decisions
Yes agreed. I get mad when management blame their people for project failure. The trail always leads back to executive decisions.
And one of the most flawed executive decisions is to either never think of the people aspects or to cut the fluffy stuff when the budget gets tight. Training gets truncated, workshops get dropped, the walk-the-floor super-user coach is deemed unnecessary, no financial incentives are offered, all post implementation reviews never happen etc etc