It seems I’m not the only one dealing with name changes. Guy Kawasaki had two recent posts on picking names, How to name a name and The mother of name change reports, which explores the reason behind the 1900 corporate name changes last year. (Hat tip to Gernot Ross).
And of course there’s also Seattle local The name inspector, who focuses on phonetic breakdown of names, explaining why some work and some don’t.
With the end of year coming around, my highlights and lowlights for 2007 are coming to mind. One clear failure was my Scoliday project. In 2004 I set about creating my own holidays, to honor what I thought was important. I did them that year, fell off in 2005, and the started again in 2006 with a new list of days, some of which I celebrated.
Somehow in 2007 I didn’t even try.
I know a few folks did their own flavor of this idea, including antigeek, Konrad West, and more, and I hope they’ve faired better than I have.
I’m reading through my journals for 2007 and trying to see if I can figure it out.
Thoughts so far:
I’m still in love with the idea – but trying to learn from my mistakes, and improve my commitment level for 2008.
Three months ago, I asked all of you to help me decide the name of the revised edition of the art of project management (if you want to know why we’re changing the name, read that last post).
After more than 300 votes, here’s what won: Making things happen

After many discussions with the fine folks at O’Reilly, the final name is Making things happen: mastering project management. I’m excited about the name! My favorite chapter in the book is #12, the one called how to make things happen, and now it gets top billing.
For those interested in the behind the scenes drama: this was not a fun process. Like naming a child, naming a book is something one only expects to do once. If you don’t like the outcome, or the fact that there is a name change, I understand, but do consider this was 20 times less fun for me to deal with, than it was for you.
What’s most interesting is this – behold the power of the web! You guys say it and it happens! I must thank all of you who took the time to vote: the ability to point to data from actual customers played a key role in my discussions with the editors at O’Reilly Media on the new title.
The revision is well underway, and I’ll post more about it, and its timeline for release, soon. In related news, the existing book will be out of print soon, so pick it up if you want a collectors item.
For fun, here were some of the best, and funniest, write in votes:
The time has come. As mentioned a few weeks ago, the book formerly known as the art of project management will be going out of print. A revised edition, with a new title, will be out in 2008 (If you want to know why, read the post).
If you’ve been waiting to buy a copy of the book, you should do so soon. Amazon and other retailers already have limited inventory (noted by 5-10 day ship times). The used inventory on amazon and e-bay look good, but I don’t know how out of print status will effect that.
Once the book is out of stock, you’ll have to wait for the new edition, which will be out next year.
I hate most systems of innovation I see or read about, as they fail to directly attack most of core challenges innovators face. But one idea I’m found of is the idea approval index. Here’s how it works:
How many approvals do you need to release something to a customer?
Think it through. It’s probably more than you think. Include informal or implicit approvals. Even if you’re the CEO, can you code the idea yourself? Design it? There are always people to convince or cajole.
The higher the number, the harder innovation is. The lower the number, the easier. It’s that simple. For example:
A) Joe Blogger has an idea for a way to radically improve his wordpress blog. He stays up late and codes it up. The next morning he posts it on his website. Idea Approval Index = 1. It’s just him – he thinks it, makes it, ships it.
B Fred is the engineering lead at Bozotech. He stays up late and codes it up. He shows it to another engineering lead for some feedback. They review it with the Quality assurance manager, who requests some changes, and get their designer to clean up their UI. Finally they show it to the group manager who loves it, and asks them to present it at the next feature review meeting (4 other team leads). Finally, days later, the web team agrees to get it online. Idea Approval Index (IAI) = 10 .
Counting approvals is a rough guide – it tells you how many chances there are for an idea to get killed before it makes it out the door.
Are there problems with this metric? Sure (Feel free to play devil’s advocate in the comments). But as a rough guide it’s handy. If you want more innovation and change, you want to lower the approval index. If you want more predictability and stability, raise the index. If you want both at the same time, on the same project, you’ve got a tougher problem – I’ve got answers: leave a comment if you care and I’ll post a follow-up.
It’s no surprise that the risk taking required to develop a new idea most often happens in small groups or by people working solo – their approval index is low.
In chapter 3 of The Myths of Innovation, I explore why innovation methedologies are prone to fail. It’s not their fault – there are many factors involved that are out of the control of any individual. You can do many things right and still fail.
There are dozens of challenges that must be overcome, but to be handy I distilled them down into 8 basics. This provides a handy checklist for evaluating why ideas die, why a start-up failed, or where the real tough spots are in making innovations happen.
The book digs deeper into these challenges, and how succesful innovators overcame them, so if you dig this view take a look at the book, The Myths of Innovation.