Allen’s Getting Things Done is a resourceful book in many ways. If someone asked me for the two most valuable / interesting passages of the booking I’d probably point out the “Getting Things Done” diagram which I wrote about here and the “Natural Project Planning” which I want to write about in this post.

Natural Project Planning consists out of five steps:

1. Defining purpose and principles
2. Outcome visioning
3. Brainstorming
4. Organizing
5. Identifying next actions

If you’re like me you will probably read over that list and think “yep, that’s how it should be, so what’s the big deal here”. Well, the big deal is, that while this model is very natural it won’t be followed most of the time.

Think back to your last kick start meeting for the latest and greatest project. For sure someone said “let’s brainstorm”. That just sounds right and very actionable. The problem: If you didn’t talk about the purpose of the new project yet and if you have no idea about possible desired outcomes for the project the brainstorming will lead to absolutely nothing constructive. Without knowing the purpose of the project and without any vision you won’t be able to separate the good ideas from the bad ones. So next time someone says “Let’s brainstorm” make sure everybody is clear about the purpose, principles and outcome visions.

Once these are defined and you successfully brainstormed the new project everybody leaves the room and now what? If you’re lucky someone took a photo of the whiteboard with all the good and bad results of the brainstorming on it. Since most teams don’t have the luxury of working on one project at a time it is fairly certain that other things come up and get prioritized. After a week nobody will understand anymore what all the words on the photo of the whiteboard are really about and we have to start the process all over again.
Brainstorming is important but it will be for nothing if you don’t take the time and organize all the unordered ideas into actionable items. Start writing a project plan. I doesn’t have to be a huge formal document. Simply make a list of “next actions”. Prioritize them and assign them to concrete people.

Following these five easy steps helps to get projects started and keep them going. It works for small and big projects, however for big projects you’ll likely need more formal approaches…

While reading The Art Of The Start I was quite surprised how many parallels there are to Rework. Kawasaki’s guide gives a concise overview about many things that are helpful to know when starting either a business on your own or a new product internally within an existing company. It also contains a couple of good references to further readings.





Topics are:

• What’s your business about: Positioning, Pitching, Business Plans.
• Money: Bootstrapping, Recruiting, Raising capital.
• Create a profile: partnering, branding, rainmaking.

Some people call it the “startup bible”. That’s exaggerated. It’s a useful guide, a starting point. You might also want to read The Principles Of Successful Freelancing, since you’ll find more information about the nitty-gritty details of creating a business there.

P.S.: I’m not saying Rework is necessarily a startup guide. Fried and Hansson focus more on work quality and life / work balance. At least that’s how I read the book.

If you want to learn about increasing your productivity most people will recommend you David Allen’s book “Getting things done”.

When reading through the book you might get the impression that Allen evangelizes his productivity principles like a religion. I wouldn’t go so far and call it a religion, but certainly implementing those principles will have a notable effect on your life. It is a methodology to get organized and productive.

Getting things done consists out of three parts:

1. Master your workflow / Natural Project Planning
2. The core principles in detail
3. Key principles for a successful application of the process

If the first part Allen introduces the “Mind like water” concept. The modern world bombards everyone with thousands of inputs. Allen calls it simply “stuff”. This stuff needs to be canalized into a trusted system as fast as possible in order to keep a clear mind and to be able to concentrate on what really matters.

The complete system looks like this:

Let’s look at it a little more detailed. At the beginning stands the collection process.

Goal of this first step is to collect all the various inputs in a single inbox. This makes the next step of “Processing” a lot easier and effective. Collecting all your loose “stuff” is the very first step towards a mind like water.

Next comes the step of processing and organizing.

You need to regularly empty your inbox. If you don’t, it will soon serve as garbage dump rather than inbox. The first question you have to ask for each item is “What is it?“. This might sound dumb, but in the collection process you only collect everything without making a decision about it. Therefore when processing your inbox you first need to find out what you’re dealing with. Without knowing this you cannot figure out a good answer to the next question: “Is it actionable?”

If it’s not actionable, there are three possibilities:

• It’s not needed so trash it.
• No action is needed right now, but someday you might want to do something about it.
• No action is needed, but you want to keep it as reference material.

If it is actionable, you should do things which take less than two minutes right away. If you do that, it means one less item to think about, one less item on your lists to review.

For all other items:

• If you’re not the right person for the task, delegate it. Wait for results, if necessary follow up with the person to whom you delegated the task.
• Since you can’t get the task done within two minutes: Defer it. In case it needs to be done on a specific date / time, put it on your calendar. If it’s not bound to a time, put it on a list that keeps track of the “next action” you need to undertake.

Some things consist out of more than one action, you usually call them projects.

Projects need to be managed vertically and horizontally. They serve as constant source of “next action” tasks.

Managing horizontally means, controlling all the different kinds of topics / projects you’re involved in.

Managing vertically means to think about the distinct tasks of a specific project.

At the end of the processing / organizing step you have at least 8 categories:

• Trash.
• Someday / maybe list.
• Reference.
• A list with projects and for each project a list actionable items (project plans).
• A waiting-for list, holding all things you delegated and are waiting for results.
• A calendar, containing all tasks which need to be done at a specific time.
• A list of “next-actions”, containing atomic actions you need to work on.

Now, after putting all the energy in collecting, processing and organizing you have to regularly review these lists, update them and then most important: getting the specific action items done.
The review step is at least as important as the “do” step. It guarantees that your lists stay up to date and you won’t forget about something. If your lists are not up to date, you can’t trust them. They might contain stuff you have already done or which is outdated. If you don’t trust the system, you won’t use it and you won’t get the benefit of the “Getting things done”-methodology, you won’t feel the relieve of a mind like water ;-)

There’s a whole lot more useful stuff in this book. One of which is “Natural Project Planning”. I will write about this in a future post.

If you have read Getting Real you’ll notice some overlap with Fried’s (@jasonfried) and Hansson’s (@dhh) new book “Rework”. Despite that, it’s a great business book. Especially, but not only, for those who want to create a small business.

Some randomly picked stuff I specially liked:

• Learning from mistakes is overrated – Learn from successes instead. They make a really good point here. After making a mistake you still might not know how to do it actually the right way. If you did something successfully however, this becomes crystal clear.
• Workaholism – Working longer hours often results in getting less work done instead of more.
• Try to solve your own problems. The advantage of that is, that you exactly know what is the problem because it’s your own. Moreover you probably have a pretty good idea about how to solve it.
• Don’t think or talk about doing something, do it.
• No time is no excuse. If you don’t find time to do what you want you don’t really want.
• Businesses who think about an exit strategy, start thinking at the wrong end. Think about how you can grow your business. That’s the road to success.
• Constraints help you to be creative. Embrace constraints instead of seeing them as real limiting factors.
• Start at the epicenter – Meaning: What’s the core of your product? Start there, don’t think about stuff you don’t necessarily need. Don’t think about problems you don’t have yet.
• Less is more
• Launch early, get good feedback.
• Interruptions are one big productivity killer
• So are meetings, just that they multiply it by the number of persons who take part in the meeting
• Most meetings are not necessary. Try to limit them as much as you can. Think about it that way: A meeting with 5 person for 1 hour is really 5 hours of work which could get done instead.
• Split big tasks into small ones. That’s easier to manage.
• With that goes: Make many small decisions instead of big bold ones.
• Don’t copy. If you want to do something that’s “like” your competitors product or service you already lost.
• Say no by default – Don’t say to everything yes, think about new features carefully, see if they really are needed, if they really fit to the product.
• Out teach your competition – Teaching customers is an easy way to compete even with the big players. And it’s mostly for free.

I thought this is an excellent article:

Doing It Wrong

So good that I want to waste some of my time citing from it:

[...] What I’m writing here is the single most important take-away from my Sun years, and it fits in a sentence: The community of developers whose work you see on the Web, who probably don’t know what ADO or UML or JPA even stand for, deploy better systems at less cost in less time at lower risk than we see in the Enterprise. This is true even when you factor in the greater flexibility and velocity of startups. [...]

[...] More important is the culture: iterative development, continuous refactoring, ubiquitous unit testing, starting small, gathering user experience before it seems reasonable. All of which, to be fair, I suppose had its roots in last decade’s Extreme and Agile movements. I don’t hear a lot of talk these days from anyone claiming to “do Extreme” or “be Agile”. But then, in Web-land for damn sure I never hear any talk about large fixed-in-advance specifications, or doing the UML first, or development cycles longer than a single-digit number of weeks.[...]

Everybody knows that many millions and billions have been wasted in enterprise IT systems, so:

Plan A: Don’t build systems

If you really have to, Plan B: Do it better.

Please read the article: Doing It Wrong

If you used the public transport in Prague recently, especially the metro, you might have noticed commercials of Bonus.cz.

The idea itself is great and for sure pays out for the company running the site. The concept is this: People buy points. For these points they can bid on a product. By biding on a product the price increases. The product is available for at least 24 hours during which the user can bid. If someone else bids in the last 30 seconds however, the countdown resets again to 30 seconds. If no one else bid during that last 30 seconds period, the user who bid last on the product won.

The calculation for the user:
Final product price = Cost for points he needed for biding + final state of the bid

The calculation for the company:
Profit = Cost of all (!) points bid on that product – Price for buying the product

So far so good. The “dangerous” thing here is that most people won’t get that this is pure gambling (like in the casino) and the bank always wins: You buy your tokens and make a bet e.g. when playing roulette. There’s a small chance you win but usually you’ll loose!

So your calculation is not really “Cost for points + final state of the bid”. By trying again and again to “win” you will invest so much money that in the end it’s likely that you’ve paid more for points than you would have paid for the desired new mobile phone, digital camera or what so ever…

There’s a similar site in Germany: www.dealstreet.de and I’m sure you’ll find sites with the same concept in other countries, too.

Just read this article: Business leaders to get back to basics

Great stuff:

Leadership qualities are constant, yet fluid. Those that were important a century ago – for example, integrity, leading by example, motivating people, developing talent, customer satisfaction, creating and maintaining a competitive advantage – remain vital today. Still, other qualities have been less enduring, proving to be panaceas for their time.

A Novel About Project Management

Inspired by George Gamow‘s story-like books about the secrets of physics, Tom DeMarco delivered a great book about project management. Since his lectures are wrapped with a nice story it makes them a) nice to read and b) easily understandable because the story is sort of a real world example of what DeMarco wants to teach us.

It all starts with Mr Tompkins, the central character of the book, being laid off from his job as a manager. While attending some HR lectures he’s kidnapped. A few hours later he finds himself in the fictitious post communistic country of Morovia where he’s offered a job to build up the countries software industry. He accepts and from that point on the reader is learning about management by simply following the adventures of Mr Tompkins as a top manager. Luckily Mr Tompkins writes all his experiences down into a diary.

His diary starts with the Four Essentials of Good Management:

1. Get the right people.
2. Match them to the right jobs.
3. Keep them motivated.
4. Help their teams to jell and stay jelled.

(All the rest is Administrivia)

I’m pretty sure I can’t just copy all entries 1:1 here due to copyright issue or such, but let me try to sum up the key points I got from reading The Deadline

• Change is essential to all success in project work, but people need to feel save in order to embrace change and take risks.
• Threats are a bad people motivator or tool for increasing performance.
• Management is not a completely technical discipline at all: Management involves heart, gut, soul and nose. However, you can try to model your hunches. You can use models to simulate results and tune the models by comparing these results with the actual results.
• Don’t try to hire alone – two guts are more than twice as good as one. Also listen more than you speak.
• Productivity improvement always comes from long-term investment, never short-term.
• You can’t and shouldn’t avoid risks. Just you need to manage them. Part of that is to have a method to discover early symptoms of a risk. A good method to do so is to appoint a risk officer, one person who is not expected to maintain a Can-Do attitude. Another method could be to establish easy and / or anonymous channels for bad news.
• Keep good teams together.
• A lost day at the beginning of the project is as bad as a lost day at the end.
• Pathological Politics: You have to be willing to put your job on the line any day, even though that doesn’t guarantee that this sort of tactic will work out.
• Pathology has effects on team size: Leanly staffed projects become unsafe (Because it might be argued that you didn’t put enough men power on the project)
• Metrics are useful but don’t worry necessarily about the units. For a first try that could be anything. Try to collect archaeological data to derive productivity trends.
• People under pressure don’t think any faster! Also extended overtime is a productivity reduction tactic. Short bursts of pressure however can make people focus better and increase the sense that the work is important.
• Anger and contempt in management are always counter productive. When upper management is abusive, lower management is likely to mimic the behavior.
• If a specification of a software product doesn’t come to the point (doesn’t at least specify input and output of the system) it’s often a sign of unresolved conflict among the various system stakeholders.
• Conflict deserves respect. Conflict is not a sign of unprofessional behavior.
• Negotiation is hard; mediation is easy. BUT: the parties need to agree on mediation and it can’t come from upper management, rather from someone who is not involved or wouldn’t have any advantage from the one or the other outcome.

As always a summary can’t tell the whole story so I really recommend everyone who is interested in the topic and who has come that far reading this article to get a copy of The Deadline at Amazon:

Even in a 5 out of 5 stars book, there’s always one point you don’t totally agree with. For me that is DeMarco’s suggestion to invest the major amount of project time into the design phase of the project, so that coding can be pushed rather to the end. This should improve the quality of the software and also limit the need of QA and later refactoring (which is expensive). In my mind this won’t work in most real life projects because the requirements are just to fuzzy and become more stable in a rather iterative process. Therefore the software development process should also be rather iterative like suggested for example in various agile methodologies

Additional Resources:

• More books by Tom DeMarco
• A review of The Deadline by Dr. Patricia McQuaid

Getting Real is a startup guide published by the company behind Ruby on Rails and products like Basecamp and Campfire: 37 Signals. You can read it either for free online, purchase the PDF version for 19$ or get a printed copy for 25$.

On roughly 140 pages you get a lot to know about what’s important and what’s not, specifically for web startups. IMO it contains great advice and the good thing is: it comes from practice not theory. 37Signals really lives the principles they describe in the book.

Go get a copy or read it online. It’s very well worth even if you’re not thinking about starting up a business.

On November 1st, Joel Spolsky wrote another column on Inc.: Does Slow Growth Equal Slow Death?

I found it interesting to read, because it covers an important aspect of business: How fast should you grow your business. Spolsky’s thesis is that if you grow too slow you might be slowly but surely pushed outside the market by a faster growing competitor even though your product is great and your customers are satisfied. The last paragraph sums it up pretty well:

We don’t want to win with lousy products or high-pressure sales tactics. We have no intention of giving up our commitment to good customer service or high-quality code. But we do have to work closer to the limits of our abilities, we have to invest more of our profits in hiring more salespeople and software developers, and we have to focus relentlessly on winning more enterprise sales. We have to do that, because otherwise, we’re going to end up being the company you’ve never heard of.

Even though that makes perfectly sense to me, I wonder if it applies to all kinds of business.