August, 2008


30
Aug 08

Data Accuracy as a KPI

IBM Data Governance Council predicted that

  1. Data value will become an asset that the CFO reports on the balance sheet.
  2. The CIO will be responsible for data quality, which will become a new IT key performance indicator (KPI).

David Vellante over at Internet Evolution wrote up an insightful analysis, Your Budget Could Hang on Your Wiki.


28
Aug 08

Trying stuff is cheaper than deciding whether to try it

LinuxWorld says:

Google is one of the few large companies that gets one fundamental rule of the Internet: Trying stuff is cheaper than deciding whether to try it. (Compare the cost of paying and feeding someone to do a few weeks of P* hacking to the full cost of the meetings that went into a big company decision.)

Don’t overplan something. Just do it half-assed to start with, then throw more people at it to fix it if it works. Worked for every successful Google project from AdWords to Google Maps.

[via Kottke]


26
Aug 08

Estiquote

Clint Edmonson, an Architect Evangelist for Microsoft, asks Have you been burned by your own ‘Estiquote‘?

estiquote - ‘es-tə-kwōt’ - noun. Modern IT term referring to the horribly inaccurate estimate a developer gives, is held to, judged by, and ultimately rewarded for despite the fact that requirements for the project were not available at the time of the request.

[via Jason Bock]


24
Aug 08

When Continuous Improvements Fail

Photo by ThunderChild tm

Here’s the theory:

  • Big improvements require big risks. Small changes require small risk.
  • Conversely, If you only take small risks, you can only expect small improvements.
  • As an aside: People always look for “deals” (where a small risk gives you a big improvement), but like the rest of the world, real deals are far and few between.

Now in terms of continuous improvements, small risks with small improvements are ok as you only need to show improvement – any improvement. Small changes are sort of the point of CI. But in terms of long term sustainability, small changes only work so long. This is best illustrated by an analogy:

You own a pay phone, and you want to continuously improve it. So you replace the buttons and you polish the black handset till it shines. Maybe you even outfit it with a credit card reader. You have continuously built a better pay phone.

But what was missed in the exercise is that there are 3 billion cell phones on the planet. How do you continuously improve a pay phone into a cell phone? You can’t! At least not with small incremental improvements. At some point, the pay phone has to go wireless. This is a huge change. It affects everything in the pay phone world: sales, support, infrastructure, equipment design, etc.

So to add to the theory:

  • Small improvements, if they are not occasionally broken up by big improvements, can become equivalent to no improvement at all.
  • In terms of risk: If you never take big risks, you may find your continuous improvements hit a wall  and cease to deliver competitive advantage.

By “big risk”, I am not specifying an exact size. Only that it is large enough to move from a pay phone to a cell phone in your own industry or environment.

And I am not saying that you can’t make significant improvements incrementally – you can and companies do every day. But you should step through it carefully – you don’t want to discover cell phones have taken over the world, and you’re still shinning up your very pretty pay phone.

The solution to this problem is to not use Continuous Improvements exclusively, or with too narrow of a focus. You could also succeed by running parallel process to investigate/prototype/etc a cell phone while continuing to incrementally improve the pay phone. At a later date you then have the ability to sustain your business by choosing to discontinue one in favor of the other. There is a fine line here because simply trying something different could be constituted as a big risk in your environment. Neverless, it is about perspective – and here you would not continuously improve your pay phone, but you would continuously improve your business.


22
Aug 08

Redux

I posted about these items once, and more than a year later I still think they are every bit as interesting and relevant as when I first posted them. If you missed them then, perhaps you’ll enjoy them now.

REDUX POSTS FROM JUNE, JULY, AND AUGUST OF 2007

* Wikipedia runs on a meager 20 servers, with the Open Source database MySQL. They serve more than 154 million annual visitors to the web site, has nearly half a million updates each day, and about 25,000 SQL queries/second.

* Quote: “Progress is made by lazy men looking for easier ways to do things.” – Robert A. Heinlein

* Ever need to write something down? No access to paper/pencil but have your cellphone? This is one of the most useful free services I’ve come across in a long time: http://jott.com Call their 800 number, speak your note, and the service transcribes it to text and sends it to you in an email. Want to send a reminder or question to someone else? You can jott individuals or groups and it will email them and send them a text message.

* “Eco-friendly reusable bags” We’ve been making great use of our’s and have avoided using many plastic bags from target and the grocery store.

* Quote: “I wonder how different the world might look if the default ‘new meeting’ time in calendar programs were 10 minutes instead of 1 hour.” – Merlin Mann