Well, it’s been a few weeks, but I’m back to continue this series on our ideal customer profiles. We’ve already had the Process Guy and the Tech Guy, now it’s time for the budget guy.
If you remember, the way it generally works is that the Process Guy is the alpha – he’s the one with a problem to solve that is related to process. Often the organization wants to get a handle on some real qualitative data about IT performance – either for budgetary reasons or for lofty ambitions like ITIL and continuous improvement. The Process Guy brings the Tech Guy in to establish a) that trying to get that data out of ServiceCenter or Service Manager is going to be like divorcing Cheryl Cole - painful, drawn-out and expensive, and b) that SMI Suite will remove all the pain, time and some of the money.
At some point in this sales cycle, the Budget Guy shows up, because despite the very low cost of SMI Suite, neither the Process Guy or Tech Guy has any spending power – it simply isn’t a function of their role to sign off on more than a few bucks worth of software.
In some ways the Budget Guy is interesting because he’s the first person we’ve met in the organization whom we don’t have to convince – the Process Guy and the Tech Guy’s advocacy and belief in SMI Suite does far far more to convince the Budget Guy than anything we could say to him. But still, the introduction of the Budget Guy into the proceedings is far from a gimme.
After all, he wouldn’t be doing his job – and wouldn’t be entrusted with signoff on budget – if he didn’t at least do some due diligence. Sometimes this takes the form of fact-checking and re-checking everything that has already been discussed and agreed upon with the Process and Tech guys, but more often than not, the Budget Guy wants to look at the bigger picture.
He’s usually happy to take at face value that SMI Suite can, technologically, do what it promises if the Tech Guy says so, and he also understands, with the Process Guy’s advocacy, that SMI Suite will unlock the door to satisfying certain business needs – like the need to have accurate data about ITSM activities.
But he will almost always question the business benefit of all this. To use a rather labored metaphor, identifying a new type of spot welder that allows workers to weld three times as many bits of steel together as they could before, and is five times safer, and costs half as much to run as the old type, is all well and good… but not much use if you run a day-care facility.
Luckily for us, the business benefits of SMI Suite are pretty universal, so long as the organization in question runs an IT helpdesk and uses HP ITSM software. And, of course, each company we deal with is individual, so the benefits that are applicable change from organization to organization, but when we start to talk about improving helpdesk efficiency by accurately benchmarking and constantly remeasuring response times, or we talk about cutting costs based on accurate workload metrics, the Budget Guy usually takes an interest.
Next time: the Department Head
Tom

So happy is clam who discovers that someone else has written a really interesting piece on another blog, all about SaaS and ITSM,
Information cascades can have wide organizational, societal or economic impact. The unprecedented economic downturn of 2007-2009 may well indeed have been the result of an information cascade. In an article titled ‘How a Bubble Stayed Under the Radar’, published on March 2, 2008 in the New York Times, professor of Economics Robert J. Shiller exemplifies how an information cascade caused the real-estate market bubble: “even if houses are of low investment value, we may […] have two people who make purchasing decisions that reveal their conclusion that houses are a good investment. As others make purchases at rising prices, more and more people will conclude that these buyers’ information about the market outweighs their own.” He proceeds to state that “It is clear that just such an information cascade helped to create the housing bubble. And it is now possible that a downward cascade will develop — in which rational individuals become excessively pessimistic as they see others bidding down home prices to abnormally low levels.”
A fool with a tool is still a fool.



You know how this one goes: someone high up in the company decides that measuring the performance of IT is probably a good idea, and this directive gets passed down the line until reaches that guy who has far too much time on his hands and far too much autonomy, and who decides it would be just peachy if he could use this as an excuse to test out some of those theories he’s been working on about data warehousing and middleware. Next thing you know he’s put the order in for a new liquid-cooled server room, twenty-seven new servers and a team of DBAs, programmers, BI experts and coffee-fetching monkeys to look after it all.

