What value can the pointy heads add to procurement?

Effective reverse eAuction design is one area that springs to mind.

I will declare an interest up front – the company I work for runs eAuctions.

But any perceived bias should not detract from the main facts that I have seen time and time again:
1. In the vast majority of cases, running a properly-designed eAuction will deliver lower prices for the buyer than would be achievable through a traditional off-line tender process.
2. Today’s auction technology is powerful enough to model non-price value-add elements, like service, delivery etc. Building these factors into the auction leads to an even better result (in terms of total value for money) than purely auctioning price.

Naysayers complain that auctions can’t work for their category because to run an effective eAuction you have to:
1. Be clear up front about what you want to buy
2. Be clear up front about the process for awarding the contract (e.g. how you value price as against non-price elements of the bid)

But these two factors, I am told, are no more and no less than best practice in procurement. Being vague about requirements or about the contract award process can seem like a quicker way to get things going, but the cloudier they are the more scope there is for individual suppliers to lead the process down a path that is not the best for the buyer.

The best results, for both buyer and the market as a whole, will be obtained when the buyer is open about the requirements and the criteria for being awarded the business, and when both of these are made as simple as possible in order to minimise the risk of misunderstanding.

Naive, perhaps, but then again, as Einstein, the most pointy-headed of all, said, Everything should be made as simple as possible, but not simpler.

What can IT learn from Purchasing

More than they might think.

I am often struck by the similarities between Purchasing and IT functions:

• Both are often considered back-office support functions by “The Business”
• Both are of extremely variable quality – there are some very able and … not so able …. individuals in each. Meaning some of these live down to their stereotype, but many are unfairly hamstrung by the stereotype
• Both spend a lot of energy arguing that they should be represented on the board
• Both often suffer from a lack of professional prestige in their professions (compared to, say, finance people)
• Both often get brought into projects too late to be able to add any real value, so they are left to pick up the pieces, thereby confirming the business’s stereotype that they are purely a back-office support function (see above).

Judging by this the two departments seem to be natural allies. Yet somehow the prevailing mood between the two functions is often one of mutual mistrust.

A large part of the IT budget is spent on suppliers (hardware, services, etc) but the CIO has a couple of concerns:
(a) doesn’t want to lose control of this spend.
(b) is not even sure what value the purchasing guys could add, anyway. After all, how can you buy computers if you don’t know the first thing about them?

Of course, this kind of weak reasoning is exactly the same that “The Business” often applies to the IT department: “What value is IT going to give me in putting together the requirements for this new system we need – they have no idea of the processes we use.” This argument completeley misses the point. The IT department knows how to use technology to solve a whole range of business issues and is best used as an equal partner in the development process for new systems.

A dose of Do unto others seems to be called for here.

The job of the purchasing department is to negotiate with suppliers and secure supply of goods and services. Purchasing knows a thing or two about how to do this well.

Some thoughts:

1. However good a deal you think you have got from your suppliers, the purchasing guys will be able to get you a better one (i.e. more for the same money, or the same for less money).
2. Yes, they will get you a better deal. They won’t take control of the IT hardware themselves. And they will only go out and source what you tell them you want.
3. It isn’t a bad idea to have someone around who can play bad cop to your good cop when it comes to supplier negotiations.
4. Less effort for you if you get someone else involved to do a lot of the legwork in sizing up potential suppliers.

Next time you are thinking of (re-)negotiating a contract for supply of IT goods and services, do yourself a favour and pick up the phone to Purchasing. Who knows, you might be able to save some money to spend instead on all those interesting projects that you haven’t got the budget for right now?

Smile, someone else has had it worse.

The most important job for the technology department is also the least glamorous: keeping the lights on and the servers humming. “The Business” can often expect the infrastructure to be always available. So much so that when things go well “The Techies” are taken for granted and when it all goes wrong they receive no end of grief.

The techies have to take some of the blame for setting appropriate expectations. The reality is that your managers and customers are reasonable people. They will only expect 100% uptime with $0 cost if you let them think that this is reasonable.

So next time the proverbial hits the fan my advice is (when, not if):

1. Don’t get into the blame game
2. Fix the problem, with a smile on your face
3. When the problem is fixed, get out your risk register (with costed mitigation plans) and show to your manager why this issue happened, how likely it is to happen again, what its likely impact is, and the costs needed to avoid/fix/etc the issue in the future
4. Also, while you’re on the subject, explain the other risks that the business is open to right now.
5. Keep in mind that this stuff happens to other companies – and sometimes far worse than what you’ve just experienced. Not that I’d be advocating shadenfreude … but a quick trawl through the news and gossip of the last few weeks turns up:

Kaiser Permanente losing their CIO last week – apparently linked to a disastrous software implementation.
Register.com keeling over a couple of weeks ago after what looked like an epic DDOS attack and taking with it thousands of DNS records.
Morgan Stanley sending out credit card statements last month with all values multiplied by 100.

Then there’s my all-time favourite example of tech muppetry:
Nasa trashing the Mars Climate Orbiter (cost: $125m) because one part of the software had been written on the assumption that everyone was operating in metric units while another part had been written on the assumption that imperial units were the order of the day.

Till next time

The Economist’s Fifth Annual Innovation Awards Ceremony

Happened today 9th Nov in London’s Science Museum. Some notable highlights:

Sam Pitroda, Chairman of WorldTel and The National Knowledge Commission, India, being recognised for his achievements as a telecoms inventor, entrepreneur and policymaker: giving a particularly impassioned and inspirational speech about his work with India’s telecoms under Rajiv Gandhi, the development of India over the last 20 years and about planting the seeds for a new explosion in India’s development for the next 20 years. And being refused his coat by the cloakroom attendant because he didn’t have his ticket. To be fair, she was only doing her job… but even so.

Janus Friis of Skype announcing that it is “really fucking cool to get this award from the Economist”. Can’t wait to see how they report this in the magazine.

Hernando De Soto, Chairman for the Institute of Liberty and Democracy explaining the need for co-operation in all innovative efforts: co-operation that has to be founded on the rule of law and strong property rights – things that first worlders take for granted.

And last, but not least, John Micklethwait and Tom Standage of the Economist looking incredibly young. You know how they say that you know you’re getting old when policemen start looking young …. you really know you’re getting old when the guys who run the Economist start looking young 🙂

Who Should the Technology Leader report to?

Christopher Koch posted CIOs reporting to CFOs: The Numbers Do the Talking in which he cites a raft of stats to show that CIOs prefer to report to the CEO rather than to the CFO.

He even goes so far as to say that Having the CIO report to the CFO destroys value in nearly every possible way.

Pretty dramatic stuff, but none of the stats back this assertion up. If you report to the CFO you spend more of your time on compliance, have a lower budget, and spend less time on innovation than if you report to the CEO. So perhaps reporting to the CFO is less fun, but there isn’t any evidence offered as to why it is better for the business if the CIO reports to the CEO.

The most telling stat is that 26% of CIOs who reported to the CEO grew revenue as against 16% of CIOs who reported to the CFO. What a damning indictement of Technology leaders. 75% – 85% of Technology leaders don’t do anything to increase revenues. And yet we, as an industry, have the gall to whine about how much fun it is for us to report to the CEO or the CFO!!

I like to keep things pretty simple (one of the beauties of working in a smaller company is that you are close enough to the sharp end to be able to do this). To put things in their simplest terms, any leader in a business can do any of the following:

1. Increase Revenue (short term or long term)
2. Control Costs
3. Soft Stuff that can’t be quantified: process improvement, controlling assets etc

If you can do 1-3 then you are of strategic significance to the business and can make a strong case to be reporting to the CEO. If you are only doing 2 and 3 then things are more debatable, but you are basically a support function and so you may as well be reporting to the CFO.

The challenge and disconnect are where the Technology leader believes that IT can impact current or future revenue growth, but the rest of the business sees IT purely in terms of its nature as a support function.

But rather than complaining about whether you are reporting to the right person, Technology leaders should focus on demonstrating how their activities are increasing revenue, or could increase revenue (or, if you prefer, company valuation). If keeping the lights on helps you grow revenue then shout about it. If you are building new products and processes that deliver revenue then shout about the revenue you are building. If there is nothing you can do about revenue then just keep your head down, who you report to doesn’t matter.

After caffeine

Now I’m getting older I figure it’s time to cut down on all those extra strong, extra sweet, extra white coffees that kept me going through all those all-nighters. Instead I’m gradually moving over to goji berries. Unfortunately my employer has no plans for a goji berry dispenser so I may still have to sneak the odd cuppa.