Business Cards

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 doesn't put you off. Tea is the fuel driving my creative engine.)

Most business cards are blank on the back side. That is an obvious waste. The question is how to put the space to use.

I decided I wanted to show a little bit about what I do. I do a lot of things, so what should I choose?

Thinking a bit, I thought, wait a minute, why make a choice? If I print the cards in small batches, I can have lots of different back sides. That way, people can chose the card they are most interested in, or take a couple of cards.

I have found that many people like to take two, three, or even four different cards when I tell them it is okay to do so. That is a good thing, partly because it makes our interaction a bit more memorable, partly because they have an extra card or two they can pass along to others.

Sometimes, when I pass my cards to groups of people, they start comparing cards. This is great. One more reason for people to remember me.

I have learned to hold the cards so people see the back side before I hand them over. If I don't, most people will tuck the card away without looking at the back.

I have tested giving people the card with the back side up, and that seems to work well. One person I gave a couple of cards to today looked at them and said: "Ah, your elevator speech."

I made the card to the left this morning. I printed only eight of them. Because I print such small batches, I can tinker with the card design and keep improving it. The next batch of Strategic Navigation cards will be slightly different.

The Innovative = Competitive card was the second card backside I designed this morning. I had the opportunity to pass a few business cards around today, and this one seems to be a winner: The image and heading convey a simple, clear message, and the colors are bright.

I will stick with this one for awhile. It will be interesting to see how many phone calls I get from people who have gotten this one.

Do You Have the Right Project Success Criteria?

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 use cases

Evaluating A and B in terms of cost, scope, and time, we would say that:

A failed

B succeeded

Now consider this additional information:

Project A:

First release: 3 months

Revenue first twelve moths: 2.5 million Euro

Revenue month 13-18: 2 million Euro

Revenue after project: 500,000 Euro per month

Project B:

First release: 11 months

Revenue first twelve moths: 50,000 Euro

Revenue month 13-18: 600,000 Euro

Revenue after project: 100,000 Euro per month

Which project is the more successful now?

I have worked on extremely profitable project failures, and successful projects that were economic disasters. This happens a lot when organizations mess up their success criteria.

Clearly, scope, cost, and time are lousy success criteria. This insight does not tell us how to use the ROI idea though. I'll get to that in a future post.