So using leanpub and publishing early and often pushes me way out of my comfort zone. Which is why you haven’t heard anything from me about my book under development up until now. Yesterday, I announced the beta of my newest book Manage Your Job Search: Reduce Your Overwhelm, Focus Your Search, and Get Your Next Job!

I couldn’t just push the button and publish. Oh no, no, no. I had to make it a beta, because it’s not done. It’s not even close. Oh, more than the outline of the book is there. The networking chapter is great. How to use personal kanban is great. Much of how you reflect on the past week is great. The tips and traps are great. And, I know they are not complete, which is making me nuts.

That’s not all that’s making me nuts. The copyediting is not done. The layout is not done. The what to do now is not done. I need feedback from readers to know what to do next, which is why I needed to publish, and oh boy, it’s not perfect. That’s why I don’t have a real cover, because I don’t know that I have the correct title. How do I balance my perfection rules against the need for feedback?

Beta! Especially if I explain that it’s a beta book. That’s what I did in my announcement yesterday. I was able to balance my need for perfection against my need for feedback.

I bet my fellow leanpub authors are delighted to not have to hear the teenage drama queen angst on the leanpub list anymore. I will get the feedback I need. I will be able to perfect the book from people looking for a job. It’s a win-win.

If you are looking for a job, please do check out my new book, Manage Your Job Search: Reduce Your Overwhelm, Focus Your Search, and Get Your Next Job! It’s not perfect; it’s a beta book. I would love your feedback.

Sure, if I have the flu or a tough vertigo attack that lasts a while where I don’t have enough slack to absorb too many “incomings,” I become overwhelmed. But I can generally manage my work. I can maintain a sustainable pace.

I tried to explain to my system to some of my executive coaching clients, but it wasn’t until I read Personal Kanban: Mapping Work | Navigating Life by Jim Benson and Tonianne DeMaria Barry that I had the words, and clearer definitions for what I was doing. Before I read the book, I didn’t know about “The Pen.”

The Pen is the place where you corral all those call-backs that can pile up. IMNHO, The Pen is a magnificent invention! It gives me the transparency I need to see that the people I need to talk to are–or are not!–calling me back, so I can decide what to do about it. If the plumber is not calling back, I might make one decision. If a potential client is not calling, I might make another decision. What’s key is that I have all the data literally at my fingertips.

What’s great about personal kanban is that I see all my work. I use it along with one-week iterations so I can track the work I don’t do. That’s how I knew it was time to ask for help in redoing my web site. It was clear to me that “redo my site” was going to stay in “ready” and never move into “doing”.

When I read this book, I kept nodding, saying, “Yes, that’s exactly how I work! That’s how I think! Why are Jim and Tonianne in my head? At least, they are doing a good job there.”

Jim and Tonianne have written a conversational, wonderful book to help you understand how to move away from todo lists to a system that helps you see your context, your work, and your work in progress.

Personal kanban has two rules: visualize your work and limit your work in progress. That’s it. Personal kanban is the way I manage my personal project portfolio. Try it for yours.

They talk about the cost of delay when using distributed teams: delay costs, rework costs, and context switching costs. But the real costs are the

But these rational cost components don’t even begin to take into account the frustrating, time-wasting, common mistakes made in coordinating meetings across time zones, such as missing the meeting by one hour because of time zone computation error.

They discuss many tricks and tips to manage distributed and dispersed teams. I already discussed the zoner in Break the Email Chain. One that surprised me was this:

Mumbai at 13:00 is the center of the business world.

It is, but not for the US. Those of us in the US don’t normally think of ourselves as outliers. But in the timezone sense, we are.

Carmel and Espinoza have data, not arguments about whether there is delay and performance degradation about geographically distributed teams. Their answer? Yes, there is delay for distributed teams. There is performance degradation. Can you manage around it? Yes. You need to do some planning, around the calendar time you meet, identifying the scattertime in your organization, the zoners, and the timeshifting and who will do it. You cannot take any of this for granted.

Section II is Time Zone Strategy. This is where the book really shines. Carmel and Espinosa discuss Follow-the-Sun and Round-the-Clock. Follow-the-Sun is about the speed of development. Follow-the-Sun is where the item to be developed was supposed to be worked on 24/7, handed off from one group to another, never waiting. I’ve never seen it happen, and that’s because when you hand off you have to have a conversation about the handoff. That means I have to braindump everything in my head to you. What are the chances I can remember everything I am thinking of? Not so good. How long does it take for a handoff to occur? A lot longer than we think it does.

They haven’t seen Follow-the-Sun succeed either. They do recommend agile for it, if it could ever happen. (My personal opinion: highly experienced agile, really small stories, with kanban limits. Gotta keep the WIP down.)

Round-the-Clock is where you have coverage around the clock. In Round-the-Clock, you have no dependencies between the work items, so you don’t have handoffs. It’s why you can have a call center anywhere in the world.

In Chapter 7, they discuss Two Radical Options, the social contract between the organization and the employee (Establish a 24-Hour Culture When Far Flung) and simulate realtime colocation with always-on technology (Co-location for Overlapping Time Zones)

They also address the health issues of asking people to stay late/stay up late, wake up early, or time shift in some way. Some organizations are literally working their people into an early grave. Is it worth it?

When I come in as an outsider, I see projects that are over budget, over schedule, are not delivering. I have to wonder.

The first thing all the managers should do is read this book. Are you organized for success? Instead of randomly organizing or reorganizing people, look at the timezones and see if you can create teams of people who are closer. Then see what else you need to do.

Remember, you will be spending money. The question is where. Don’t fool yourself into thinking that you are going to save yourself a pile of money on project cost. Wage cost and labor cost are not the same thing on a project.

Read this book. Decide what you need to do on your project. And, while you’re at it, join  Shane Hastie and me in our geographically distributed teams workshop April 17-18, 2012. We can help you with these and other issues. We would love to have you.

• Project portfolio management helps you finish your software projects on schedule.
• You must understand your mission to make choices about prioritizing software projects.
• Managers must select which projects to undertake and which to avoid.
• Create a visual overview of all current and upcoming projects to depict who will work on them and when.
• Some managers dislike project portfolio management because it prevents them from shifting developers between assignments. This is, in fact, a primary benefit.
• Project portfolio management aligns your team’s work objectives with your organization’s strategic objectives.
• Project portfolio management’s central truth: You can do all your software projects – but you can’t do them all at once.

I get to display this nice badge on the book’s page on my site, and the Prags have it on the book’s page already.

You don’t have to read just the abstract. You can read the entire book. Buy it from the Prags in both the ebook (many forms) and/or print as a holiday present to yourself so you can start the new year right.

Or, if you are still a print-only reader, and want to buy it from Amazon, that works too.

But, if you are still trying to plug people into projects part-time, or if you are still trying to figure out how to get it “all” done, stop. You can’t. You need to engage your peers into having those difficult discussions about what you can commit to for now, what you can’t commit to for now, and what projects you will never commit to.

Welcome to the project portfolio!

When the Prags turned down my book proposal (sniff, sniff), I had to decide what environment to use to write in. I decided to self-publish, to get the book out quickly. That means I want to be able to publish in all electronic formats and eventually in print form, too. Yes, I want to publish electronically first.

I am accustomed to seeing the book evolve as I write, so that was my first preference. I remembered a conversation from a conference a couple of years ago, and asked Neal Ford for a recommendation about writing environments. He suggested Asciidoc.

Asciidoc, or some other docbook-based toolset was my first choice. But I’m no longer a developer, so I have no idea how to install software that’s not packaged prettily, and asciidoc is not packaged prettily. I looked at the instructions. I can read them, but I don’t understand them.

I asked for help on the prag authors mailing list, and Andy Lester offered help. Andy suggested MacPorts, which is not what Asciidoc needs, so I got halfway through the installation and got stuck. Oops.

I contacted Tim Berglund, and he was helpful, but my partial installation was still in my way. His instructions did not match what I saw in my terminal window. Oh, boy.

I decided to use Scrivener. I wouldn’t be able to see the book as I wrote it, but I would be able to generate all formats at the end.

Then I saw Michael Nygard at Oredev this past week. I explained my quandry, and Michael offered to help. We spent 5, yes, five(!) hours on Monday yak-shaving, installing and uninstalling software. I could not have installed Asciidoc without him. I now have a working directory for the book I’m writing and a generic directory I can copy for other books. Yippee!

I am using git scribe to generate my book. Every time I make a change and gen a book, I can see all the formats. I can check all the formats as I proceed. I will be able to generate all electronic formats when I am done. I will be able to see the book in all formats as I write, so I can check the images as I write. This is a huge deal, because I have a ton of images. Ok, maybe to you 2-3 images per chapter is not a ton, but to me it is. That’s what I have now, and I don’t even know where I am in the book.

I could not have done this without the help of these many gentlemen.

Neal, I appreciate you for the suggestion of asciidoc. It is the tool I want to use.

Andy, I appreciate you for the suggestion of Macports as an install mechanism. You got me started.

Tim, I appreciate you for your encouragement and the suggestion of brew. That got me farther.

Michael, I appreciate you for helping me install asciidoc. That included explaining what we were doing as we proceeded,  your handholding, and  keyboard driving when you just couldn’t take it anymore. (I owe you hours of WordPress help when you decide you want it.) You made it possible for me to write this book the way I want to write it, and all the successive books I have planned. And, I enjoyed chatting with you, when we were downloading, compiling, installing and eating lunch. I liked being your client for five hours. You are a wonderful consultant.

For those of you who are wondering, yes, I have moved my files into the directory, and have already compiled two chapters. Ah, it is such a great feeling.

If you are looking for advice around what to measure when tracking your projects, how to come up with an actionable mission statement, or just how to effectively communicate the state of your portfolio ask Santa for a copy of Manage Your Project Portfolio. It could be exactly what your company is looking for going into the New Year.

Thanks, Jonathan.

Agile is a way of developing software that reminds us that although computers run the code, it’s people who create and maintain it.

Jonathan Rasmussen, the Other JR, has written a great, short, to-the-point book about how to move a project to agile. From the beginning “Deliver something of value every week” to the Agile Principles sprinkled throughout the book, such as “The best architectures, requirements, and designs emerge from self-organizing teams” to the conversations between the student and the Sensei, you can learn how to move your project from where it is to agile.

Some pieces I particularly like are:

1. All of Chapter 4, Seeing the Big Picture, where Jonathan suggests we need an elevator pitch for our project. I’m stealing this idea right away.
2. Chapter 8: Agile Planning, Dealing with Reality. After a humorous side trip with Murphy and his Law, Jonathan introduces us to burndown, burnup, and team velocity charts.
3. Chapter 15: Continuous Integration: Making it Production-Ready. What if you only had one hour to deploy your product. Could you? Jonathan walks you through what you need to do to make the code production ready.

Jonathan has great advice about how to know how agile you are:

And don’t forget. It’s not about “being” agile. It’s about building great products and delivering world class service to your customers.

This is a great book. The Prags offer it in print, pdf, mobi, and epub. Amazon offers The Agile Samurai: How Agile Masters Deliver Great Software in print. If you are thinking of starting an agile journey, do yourself a favor and get this book. You will not be sorry.

this book gives a more complete view of what is at stake when dealing with project portfolio management and will really help organisations to move forward faster with implementing and improving this key business issue of the 21st century, the Project Age. A very inspiring book!

Inez has lots of nice things to say about the book. She also likes Behind Closed Doors and Manage It! A great way to start my day!

Thank you, Inez.

However, as a journeyman project manager (PM), I would look at the book and dream wistfully of the day in the future when I would need to read it. Don’t you be fooled! This book indeed is a great reference book for the senior PM, but it is absolutely indispensable for the PM who wants to become a senior PM.

Thanks, Matt!