by Paul Klipp

copyright 2007

I’ve read Timothy Ferriss’ The 4-Hour Workweek with enthusiasm. I’m lucky to be in a job I love, but I am rather tied to my office and I wouldn’t mind seeing that change. There are many ways that project managers can work remotely and utilize the ideas presented in this book, and most of them have to do with agile development. How’s that for a segue to my blog topic?

I recently worked from Rabka, Poland for a week and my clients were none the wiser. I could never have done this in my early days before I discovered agile development, because most of my time was spent in crisis management. Clients had to be able to reach me at any time and I had to be ready to bound into a programmer’s office or cube and demand explanations or promises. Now, however, all that is in the past, because my customers are always happy.

What makes customers of software upset? Missed deadlines and buggy code are annoying, but that’s not what really causes problems with client satisfaction in my experience. A customer gets annoyed when a deadline slips, but it’s uncertainty and helplessness that make them mad. When a client is mad, they demand, and deserve, immediate action. Immediate action is the anathema to working from the Canary Islands.

Agile projects keep clients from getting mad in two important ways. They avoid uncertainty by involving the client in daily scrums and giving them access to the actual developers. The client knows what’s happening all the time, and that takes a huge weight off. When something does go wrong, the client knows why, what’s being done about it, and most importantly, that it’s well in hand. Contact and collaboration build trust. If the client knows you and your team, and has worked closely with you when all was well, then when a problem arises they are far less likely to assume it’s your fault and worry that your team isn’t competent to deal with it.

I’ve seen many projects and many problems and it amazes me to have to say this, but it’s so often overlooked that I’ll write the obvious. A client who speaks to the team daily is very unlikely to get angry no matter what’s happening in the project because they know and trust the team. I have had some really significant surprises and setbacks on agile projects that have disappointed a client, but never one that angers a client. On the other hand, I have seen clients angry about a project that’s going just fine, but they are mad because no one’s told them that and they’ve been sitting in their office for days getting worked up and fearing the worst.

So, step one to escaping the office is to keep clients happy through regular conversation. If you talk to clients daily, you’ll almost never have to drop everything to respond to an artificial emergency. I’d rather call a client and talk for ten minutes every day, at times I choose, then have to spend an hour responding to emails and inquiries that come out of the blue.

Lesson one for reducing your ties to the office is keep in touch with your team and clients daily and watch your email and voicemail in-boxes empty themselves. Two years ago I had 100-300 emails a day. Now I get about half a dozen and respond to them in less than an hour. I spend one hour a day on the phone to clients, and less than an hour dealing with my email. Before I changed development practices I spent more like four hours a day on email and two to four hours a day taking calls. I almost never take calls now. My phone doesn’t ring. Why? Because all my clients know to expect a call from me and they know when it will be.

Can you imagine how much more time and attention I can give to projects when I don’t get email and my phone doesn’t ring? Yes, 100% of my time is spent on team development and keeping projects running smoothly, and all at the cost of a handful of short, sweet, friendly phone calls a day.

Extrapolate that out a bit and you’ll see how a PM could spend less than an hour a day on their cell phone (or in their hotel room using cheap calling cards from callingcards.com) and an hour on the internet at the cafe, and the rest of the day on the beach. At intervals, you’d still have to engage in iteration planning sessions, but those can be predicted and planned for. It is possible to manage half a dozen projects in two hours a day, only coming to the office a couple of times a month for planning games and retrospectives.

This is an extreme story, and the 4-hour workweek is not really intended for full-time project managers, but the mere fact that it’s possible should give readers cause for reflection. How do you spend your time at work? How many phone calls do you get a day? How often are you in crisis mode?

In my next posts I’ll write more about how agile project managers can get closer to the ideal of the The 4-Hour Workweek.