Fog Creek Software
Discussion Board

For those geeks seeking an MBA...

I borrowed my boss’s copy of Baseline (he is out of town).

Page 16: "Contrary to popular wisdom, the technology skills of a CIO are more important than the business skills."

Granted that this is one sentence out of a 1.5 page article, it also mentions that CIO bonus pay is tied to completing a project on time and on budget. "Rarely do they consider the aftermath."

Finally, "...there is no simple and uniform way to measure return on a technology investment".

Sound familiar?  I suppose that I don't have a real point.  If you can't tell, JOS is my virtual water cooler, since I am a loner IT programmer.

Top 20 CIO pay with bonuses: #1 $ 7.31e6 ... #20 $ 1.16e6.


Tuesday, June 17, 2003

Maybe in a small company a CIO is about technology, but IMHO in a large company a CIO should be 95% management, 5% technology.

I find it frightening that stuff like that is being passed off as The Absolute Truth.


Tuesday, June 17, 2003

> also mentions that CIO bonus pay is tied to completing a project on time and on budget. "Rarely do they consider the aftermath."  <

Thus the thread about whether or not to drop testing in favor of producing a project on time.
Tuesday, June 17, 2003

According to the Tapiwa School of Management, the CIO's role is not about technology, but about translating business strategy into technology requirements, and then managing that implementation.

It is about knowing enough technology to be able to
1. translate business requirements to some sort of tech roadmap for the business.
2. evaluate risks to business from tech issues (security; redundancy; vendor lock-in; migration; backups etc)
3. ask the right questions of people who purport to know the technology - (staff; contractors; vendors)
4. sift the chaff from the wheat when it comes to tech - (is something a buzzword; is it a passing fad; or is the vendor spreading FUD)
5. buy at the right stuff at the right price and time - (do you buy the latest fastest cpu's or do you buy at price sweet spot)
6. manage the folk that manage the projects effectively - (adequate scoping; access to staff and mgmt; project ownership etc)
7. measure the success and failure of projects in business terms - (where did we go wrong; are we on track; how does it all fit into the big picture)
8. goto 1

If there is no cohesion in the projects that you implement, then you have failed. For most businesses, it makes more sense, from a business perspective, to have one system that does most things adequately, than to have 20 different system that are Best of Breed, but do not integrate well... In a lot of cases, this explains the rise of the ERP systems such as SAP!

Even if you did deliver *ALL* your projects on time, and on budget, if those projects failed to add value to the business, then as a CIO, you have failed. You are in this case, a great project manager, but an awful CIO whose role is primarily strategic, and you should be demoted.

I have not carried out a proper study into this, but anecdotal evidence (read business/tech mags) would suggest that it is the CIOs who get excited about the technology or their pet project that fail. If I ever heard a CIO say "We only buy {insert vendor}", or "we are really excited about how {insert pet project} will revolutionise our business", then I know it is time to sell/short the stock.

Wednesday, June 18, 2003

"...there is no simple and uniform way to measure return on a technology investment".
Run to the nearest shredder and get rid of this document.

I have not read the entire thing, so not sure what context it was said in. Just a couple of things though.

There is no simple and uniform way to run a business. Nothing new there. Having said that though, a project with no metrics is a project not worth delivering.

Case in point.
We currently process x number of invoices a month. It takes x amount of time per invoice, and costs us $$x.

If we can cut the amount of time to only y per invoice, we can save $$y.

The time cut, could be due to automating the process, reducing the error levels or whatever.

We then decide to spend $$z implementing a new invoicing system.  Let us assume we get it in on time, and on budget.

As long as $$z<$$y, the project is successful. A very simplified example, but as you can see, it is not rocket science.

The problem is where some vendor sales reps have come in and demo'd  Uber Invoice System XXP, and management then spends a year rolling it out with no financial reason why. Trying to stick measureable metrics at the end of a project just won't work.

The problem is where CIO's institute projects that only give them a warm and fuzzy feeling, and or expand their empire.

A typical example. For most businesses out there, there really is no reason to move from say Office 97 to XP. The costs far outweigh the benefits. A lot of businesses do not make the move, but a lot have these irrational (at least from a financial perspective) upgrade cycles. "We always upgrade to newer office version 4 months after release....!" w.t.f.?

<bias> I still think office 97 is the sweet spot. I am yet to see a valid business case for upgrading to Office XP. </bias>

If it ain't broke, don't fix it should be tattooed to every CIO's forhead.

Wednesday, June 18, 2003

I tend to agree with the article. It is not saying that a CIO should be a supergeek capable of writing an OS in Lisp, but that he should have a firm knowledge of all the different technologies involved.

If you think of what a CIO needs to know (hardware, gigabit ethernet, ATM, voice over IP, SANs, .asp, .net, php, apache, bash, SQLServer, Oracle, data warehousing, Exchange Server, Lotus Notes, Domino, C, C++, Java. VBA and a large etc) it is clear that nobody expects expertise in all of these areas. But the CIO must know enough technology to stop vendors blowing smoke in his face, and must be able to evaluate all of these and how they can help the enterprise.

The point is that a CIO must have a good grasp of all the relevant technologies, must understand how his company works and companies in general, and also have a good grasp of human nature, both for dealing with his own staff and for judging the effect of technology on other departments and on customers. Missing any and there's a problem but it is likely that the overall grasp of technology will be the skill that is most lacking among others in his company.

Stephen Jones
Wednesday, June 18, 2003

"If we can cut the amount of time to only y per invoice, we can save $$y."

That's usually a fallacy, unless the company plans to lay off some of the people who are working on those invoices.  Almost always, "cost to do X" figures are based on an assumption that you can multiply dollars per hour times task time to find a cost.  But, for most tasks in most companies, you're not *really* going to fire people or cut back their hours if you find a way to do the task faster.

I'm not saying that speeding a task doesn't increase the business's *production capacity*, just that it rarely reduces *actual cost* on the company's bottom line.  In other words, feel free to brag about your IT projects' "cost savings" on your resume, but if you are actually *financially* responsible for a business, don't be fooled.  When somebody tells you the project will save $$y, you need to ask how many people will have to be laid off in order to produce that cost savings.

Under no circumstances should you embark on IT "cost savings" if you need real $$ but can't lay anybody off.  Don't be fooled by capacity improvement masquerading as cost savings.

Phillip J. Eby
Wednesday, June 18, 2003

Stephen - agreed. I guess my problem is that I wasn't aware that anyone was saying a CIO didn't need to know technology. I thought the industry problem was CIO's not knowing how to manage. So to see management ability poo-poo'ed in favor of tech knowledge makes me edgy.


Wednesday, June 18, 2003

One can look to Six Sigma methodologies (or in general, statistical analysis) to determine the cost of any given process for a given time frame.  One of the keys of Six Sigma is measuring - what are my costs, my error rates, cost to fix, and my total time involved.

Once you know that, and you can determine how much it would cost to fix/implement a new program/modify the current process - you can determine if its worthwhile.

But more importantly, you should have a large hopper filled with many projects you weigh against each other to determine a priority setting.

And yes, the difference between soft savings versus hard savings are very important - that's key to understanding whether or not your savings will be on the bottom line directly, or indirectly (ex. by reducing rework and freeing processors for other tasks). 

But the end result really needs to be measured and tracked over time, that's critical to understanding how well things have gone in the business.

Wednesday, June 18, 2003

Actually, it's mostly about height.

If you haven't made mangement yet, an expensive MBA won't help.

Anonymous Short MBA
Wednesday, June 18, 2003

Is that related to the Dilbert CubeFarmer principle where tall plants get repotted into bigger offices.

Thursday, June 19, 2003


That is my point exactly. It is just as wrong to use incorrect metrics as it is to assume that one cannot measure the ROI on IT spend.

In some cases, there are direct savings... folk get laid off

Sometimes the savings have nothing to do with staff...  We can now monitor our stock levels on an hourly basis! We can now order daily from our suppliers instead of weekly. This is worth £x in savings on stock ....

In others, time is freed to allow folk to be more productive by spending less time doing grunt work which is now automated. This would usually translate not to reduced costs, but to potentially increased revenue.

The trick is to use the identify the correct metric, and use it.

To throw one's hands up in the air and declare that you cannot measure returns is silly, and means money is spent by gut feel, and not to add value to the business.

Friday, June 20, 2003

*  Recent Topics

*  Fog Creek Home