Kallokain

I try to apply the principles I advocate not only in large things, but also in small. My business cards are a good example. When we design something, we need to consider the purpose of the thing we design. The purpose of my business card is to: • make it easy to contact me • make me memorable • make the card holder want to contact me The first item is easy. The contact information on my business card is no different from that of any other business card: Name, occupation, and contact info. I have stacks of business cards I've got from people I've met, whose faces I don't remember. I often take a snapshot with a camera when I meet someone for the first time, and add the picture to the address book in my computer. This is a bit of a hassle, so it was a pretty obvious idea to add a picture of myself to the card. I chose a picture of me when I am working. The idea is to show that I do work if you hire me. (The picture also shows that I drink tea while working, but I hope that do

Traditionally, projects have four success criteria: scope, cost, time, and quality. The focus tend to be on scope, cost, and time. Quality is quietly forgotten when the project is evaluated, unless the project deliverables malfunction. Agile software development methods have a different success criteria: Maximum Return On Investment (ROI). This tends to create a bit of confusion. Nobody knows how to measure ROI, so management sticks to specifying scope, cost, and time in contracts, usually with a wish for high quality, but nothing about how to measure it. This is a bad idea. Here is why the traditional success criteria do not work: Consider two software development projects A and B. Both have the following original assumptions: Cost: 2 million Euro Time: 12 months Scope: 60 use cases When we evaluate the projects after they have been executed, we find that: Project A: Cost: 3 million Euro Time: 18 months Scope: 52 use cases Project B: Cost: 1.9 million Euro Time: 11 months Scope: 60 us