Esther, in her Get out of your way! post describes a situation where by our behaviors, we cause the thing we don't want to happen. It happened to me this week.

I've been working on the PM book, and I've been struggling with the lifecycle chapter for a couple of months now. Probably longer, since I knew I was struggling in mid-October, and I'd already been messing with it for longer than that. I drew more pictures, wrote more text, and it still wasn't working. I finally asked for feedback from Esther and Andy.

I'm so glad I did. They were able to articulate what's not working with this chapter. I'll be rewriting it, as soon as I have a few things worked out in my head (I have a few other things to finish first).

But that's my pattern--to wait too long for review. First I struggle with the writing, adding more words and pictures. Even when I edit, I add more. How's that working for me? Not well :-(

The thing I don't want to happen is to be late with the first draft of the book. But by not asking for help earlier, I might cause that to happen. (We'll see. I'm in danger of being late, and I'm in danger of making my deadline. I can't actually tell where I am in the schedule, and won't know for another couple of days.)

If you're in a position where things aren't quite working, Esther's question, "How's that working for you?" might jolt you out of your self-reassurances that things are just fine. It worked for me.

A colleague asked how to deal with this situation. "It's clear Brad is being a jerk. I'm working with him on how to be less of a jerk. But Susie asked me today when I'm going to do something about the problem--nothing she says seems to make a dent in his behavior. What can I tell Susie?"

Nothing. Not anything at all. You can say, "I'm working on the problem." That's it. And if you have to fire Brad, you say something like, "Brad has decided to pursue career opportunities elsewhere." If anyone asks about Brad's jerkiness problems, you say, "Brad has decided to pursue career opportunities elsewhere." (That's the management equivalent of a "no comment" answer.

You can't say anything because even if you comment, how will they know what you say about them? You create a lack of trust by commenting about other people.

So, never ever talk about other people's performance.

This is #11 and #12 in Memo for Bosses: 101 Ways to Prevent your Office from Hating You.

If you're a regular reader of this blog (or the Hiring blog), you can see that I'm not shy or demure. I'm blunt and direct. And in most circumstances, I manage to straight-talk without hurting anyone, even myself. But that wasn't the case earlier this week.

I was writing the PM book, concentrating. The phone rang. (Note to self: Put the phone to voicemail when writing.) I answered "Johanna Rothman." The nice person on the other end was on a speakerphone and paused a moment before saying, "This is Nice Person from a-company-who-sends-you-multiple-credit-card-offers-in-the-mail. Is this a good time to talk?"

I assume Nice Person is a telemarketer, and say, "Not if you're going to try to sell me something." Blunt and direct, right? Yup. Nice Person picks up the handset, and says, "I wanted to talk to you about the Managing One-on-One workshop."

I got that knotty feeling in my stomach, and said, "I'm sorry. I thought you were a telemarketer. Can we do this over again? I'm Johanna and it's nice to meet you." We went on from there.

My assumptions--a slight pause, speakerphone, and the company name implies telemarketer--might have been right most of the time, but not this time. Luckily, Nice Person seemed to have taken it well. But I bet it's not the first time this has happened.

I'm an idiot sometimes, and this was one of them. One of my great strengths--putting the clues together to see the system and being able to discuss it clearly--is also one of my greatest weaknesses. For those of you who were at my StarWest keynote, this is yet another non-career enhancing conversation. (Maybe I should develop a keynote about non-career enhancing conversations and show how to change just one or two things to change them into career-enhancing conversations. Let me know if you'd go to a conference to hear that.:-)

We all have assumptions. And some of us jump to conclusions quickly with the clues we have. But we don't always have all the clues, as I didn't in this conversation. If you also jump to conclusions as I do, make sure you're not embarking on a non-career enhancing conversation. Those conversations are not always as easy to rescue or start over. And they may prevent you from gathering more clues.

The more information you gather, the easier it is to have a career-enhancing conversation, instead of the other kind.

I have an all-in-one machine, a fax/copier/scanner/printer, that I use for copying, scanning and primarily faxing. It's fine fax machine. And it's a great copier. But when I hook it up to my computer for scanning to a file, it falls apart. Half the time (or more), my computer can't establish a USB connection to the device. I was ready to throw the damn thing out the window when I thought, "Huh, I bet other people have this problem. I bet there's new software. Go see." I did. There was. I started to download.

I have a high speed connection, and it took me about 20 minutes to download the updated driver. OK. I can do other things while I'm downloading. And I did. 30 minutes later, I finally open the installer and try to install. It hangs about 3 minutes into it.

Since I have experience with crappy software from this vendor, I decide to quit a few applications. I do and the install proceeds a little farther. It stalls again. Ok, I quit all the applications and leave my computer alone to install. It does.

20 minutes later, I start up the scanning application, and wowie zowie, the entire UI has changed. Ok, I'm a smart person, I can figure this out. I was able to start scanning and save my files.

This should be a happy ending, right? Well, I'm only sort-of happy. That's because my implicit requirements for the whole experience were not met. I expected:

• That the file download in about 10 minutes. I'm not sure why the download had to be that big. Why not zip it?
• To be able to install an application the way other Mac apps are installed--while I'm still working. Having to close all other apps is a very non-Mac approach. (Do you Windows users really have to do this? My goodness.)
• To specify a filename once. In order to save a file as an image, I had to specify a filename (that's not used), start the scan, and then specify a filename again. To me, this is a defect.
• To use the Mac Finder to deal with my files in the application. Instead, I have to use the app's view of the finder which doesn't look much like my Mac.

I had a number of implicit requirements that were not met, mostly that the application look and feel like the other Mac apps on my machine. I'm not sure why that was so hard to do. Maybe the developers have never seen a Mac.

So imagine now that you're a developer who's just started to work in the banking domain. You have a lot of experience with selling online, so you know about transaction processing systems, but not about banking. How will you learn about the implicit requirements?

It's worth thinking about this, no matter what your role is on the project. Those implicit requirements are still requirements. If your product doesn't meet them, you will have unhappy customers. Even though I managed to accomplish the tasks I needed, the time it took me to accomplish them and the foreign approach to the UI made me not happy. Implicit requirements are still requirements. It's worth thinking about how to make them more explicit. (One technique is to get early feedback from customers :-)

I'm trying to describe the costs of multitasking. Here's what I've got so far:

There are three parts to multitasking:

• Stopping the work you're doing. The stopping cost is the time it takes to mark your place, save your work, etc. You haven't stopped thinking about what you're doing, but when you stop to take a phone call or answer a question, there's a stopping cost. If you're in flow, this is surprisingly high.
• Swapping out what you're working on. The swapping out is the act of clearing your mind of the work you'd been doing so you have room to swap in the new work. If you were in flow or concentrating deeply, this can take anywhere from 5 minutes to 30 minutes. Sometimes, it takes me even longer.
• Swapping in the new task. The swapping in depends on the complexity of the work and how long it's been since you last touched the task. The more complex and the longer the time since you last touched the task, and the more people you have to talk to, the longer it takes.

I don't know how to give ballparks for each of these. Certainly, for some tasks, it's fairly trivial. If I'm organizing a normal weekday dinner, my swapping in/out is very fast, because there's little knowledge associated with each task. But now when I write chapters of a book (or back when I was writing code,) the costs can be very high, because the knowledge in my head is not yet written down. For me, the stopping the work is defect-inducing. Unplanned interruptions help me make defects. So does the swapping back in, if it's been a long time since I last worked on this task.

Did I miss anything?

I'm finally back home after 4 weeks on the road. Yes, I was completely nuts to spend 4 weeks away. My office is a disaster, and so is my email. (My domain name is being spoofed, so I'm getting thousands of returned failed email messages a day. Pain in the tush to process.) So, here's my trip report from AYE 2006.

Normally, I lead 5 sessions out of 6 session slots. This year, because Jerry was recuperating and unable to be there, I led 6 sessions. I'm thinking of limiting myself to just 4 sessions in the future. We'll see :-)

Monday morning, I led a session about Multitasking. The multitasking simulation went well, although I'm planning to get different puzzles to make the work different for each group. I then added too much stuff to the session, to deal with multi-tasking. I'm going to have to focus the next piece better next year. This simulation is different from the one in my PM workshop. I think this one is better.

Monday afternoon, Esther and I led a Behind Closed Doors session. I was pleased with this one. We even got a nice writeup on cio.com. Esther and I have been refining the simulations and activities for a couple of years now and our practice shows.

Tuesday morning, I facilitated Reinventing Yourself. This session is about recognizing the patterns we have in our (work) lives, and choosing whether to continue those patterns. Last year, I had about 40 people in the session. This year I had about 10. Because of smaller group, I was able to abandon my session design partway through the session and kept moving with the energy in the room. (One of the reasons I keep my workshops small is so I can see where the energy is and move with it.) I'm still hearing nice things about this session, so I'm happy with it.

Tuesday afternoon, Naomi Karten and I led a Presentation session. Naomi's been a professional speaker for many years, and suggested I also join National Speaker's Association. I've been a member for about 10 years, and have found it valuable. Several of the participants started the session concerned and ill-at-ease speaking in front of groups. By the end, they seem to have learned some ideas and tips to help.

Wednesday morning, Naomi and I led a writing workshop. I love facilitating this session. You can see some of the results here. I'm planning to post my rough draft about multi-tasking there, and refine it here, and then further refine it for the PM book.

Wednesday afternoon, I led Transforming Rules into Guides originally one of Jerry's sessions. We all have survival rules. Looking both ways before you cross the street is a very handy survival rule. But some of our rules, especially about our conduct with other people or what we can say to other people can be quite limiting. We may need to choose whether we keep these rules as is or transform them into guides, so we can choose whether to follow them. We were able to transform two rules in the session--quite an accomplishment. (I was the facilitator; the people in the session do all the work.)

I'm finally back, working on the PM book and catching up on my email. Hope you had a delightful 4 weeks :-)

One of my clients said to me, "There's no one who doesn't need a boss." He meant it as "Everyone needs someone to check with, to make sure they're headed in the right direction." I agree.

I've encountered a number of projects where people didn't know the context of their work. As developers, they were working on the thing they had to develop or fix today. They might remember what they had done yesterday, but there was no sense that they knew what they needed to do tomorrow, or that they were working on something that's part of a whole. (I wrote an article about this years ago, Of Crazy Numbers and Release Criteria) I'm at a client now doing an assessment and I saw some data yesterday that made me realize people assessing projects need trend numbers, to see the data over time, not just snapshots of data.

When I do assessments, I always ask for trend data (about velocity, requirements, defects during the project and defect escape rates, sometimes code). For many of my clients, the data doesn't exist, and it's hard to obtain.

Trend data shows you the context of your progress, whether it's fast or slow. Velocity charts show you how much work you're accomplishing over time and how much change is in your project. Defect trend charts show you how well you're dealing with defects (are they overwhelming you or are you keeping pace). Trend data allows you to see the context of a project. Are 15 (or 150 or 1500) open defects good or bad? It's hard to know without trends. PMs can't make decisions about how to guide the work until they know the context, not individual pieces of data.

If you're managing project work, take a look at your project. Do you have trend data or daily (or weekly or monthly) snapshots? What would you have to do start gathering trend data? And what would the trend data show you?