Tobias Fors and Magnus Ljadas interviewed me about a wide variety of topics. This podcast is part 2 of 2.

The questions are:

1. What does PSL stand for? (Tobias)
2. What would the opposite of Problem Solving Leadership be? (Magnus)
3. Can you tell us more about the hands-on practical tools you learn in PSL? (Tobias)
4. You mentioned MBTI and how different preferences form your personality. The three of you, Jerry, Esther, and you have different types. How do you mix your differences together? (Magnus)
5. Do you use MBTI in your work as a consultant? If so, how? (Tobias)
6. What would you say is the most important part of your work as a consultant?(Magnus)
7. Talking about jiggling, do you have any special jiggling tricks? (Magnus)
8. What makes you really angry? (Tobias)
9. Have you ever seen Jerry or Esther get angry? (Tobias)
10. How do you respond to project politics? (Magnus)
11. What do you do when you're faced with a failing project and you're called in to fix it? What can you do? (Magnus)
12. Tell me about your books (Magnus)
13. What does pragmatic mean in a management context for you? (Tobias)
14. For people, not familiar with the word "agile", how would you explain it? (Magnus) (and then I asked Tobias and Magnus to answer this too)

Here is the information page for PSL in Sweden. You don't have to be a Swede to join us!

Click here for the mp3 version of this podcast.

Tobias Fors and Magnus Ljadas interviewed me about a wide variety of topics. This podcast is part 1 of 2.

The questions are:

1. How did you meet Jerry Weinberg and Esther Derby? (Tobias)
2. What is experiential training/learning? (Tobias)
3. How do you create a safe environment for participants to learn? (Magnus)
4. What about safety in the workplace? (Tobias)
5. Have you ever lost a job? (Magnus)
6. How do you find the balance between changing things and letting them be? (Magnus)
7. How do you detect your own blind spots? (Magnus)

Here is the information page for PSL in Sweden. You don't have to be a Swede to join us!

Click here for the mp3 version of this podcast.

I'm Johanna Rothman, and this is the Pragmatic Manager podcast.

In this podcast, we’ll take a look at how to talk about how many projects you are attempting to finish.

I meet people all the time, and I'm always amazed when I meet developers, project managers, testers, writers, and other project staff who look as if they haven't slept in days.

One project manager said, “I'm managing three projects. I'm not making any progress on any of them. But my boss thinks I should be able to manage at least three projects. How many should I be able to manage?”

I wish I had the right answer. The best answer is “It depends.”

Here’s why. If you have an extraordinary team who knows how to work together, who can resolve issues among themselves, who can remove obstacles by themselves, who can negotiate for resources if they need them, and who have enough discipline to monitor their work and steer the project without you, you can manage that project team--because they don't need you--and one other normal team.

Same thing with developers. Same thing with testers.

If you're multitasking and trying to work on multiple projects, you know you are shortchanging at least one of them, if not all of them. A successful project manager can manage one project at a time. Same with developers. Same with testers

You can make yourself nuts by trying to work on more projects, but you're unlikely to be successful.

And yes, I know several people who seem to be quite good at managing multiple projects. They all have extraordinary teams, not normal teams made up of normal human beings.

So why do people have more than one project at a time to finish? Because their managers don’t know how or don’t realize how to manage the project portfolio. While you wait for me to finish the project portfolio book, here’s a six-step plan for what you can do:

1. Make a list of all the work you are trying to do. Just a list. Write each piece of work, every item on that list, on a sticky note.
2. Now, make a grid on your whiteboard or a flip chart, or, if you must, in a spreadsheet.
3. You need 5 columns on this grid. On the top left, write the word “Tasks”, and then for each of the next four columns, write the words week 1, week 2, week 3, week 4. Make a dark vertical line between Tasks and Week 1. You have 5 columns with a dark vertical line between Tasks and Week 1.
4. Now, assign each sticky note to one of the weeks. If you have a project that spans more than one week, write another sticky note for each week. Duplicate the stickies for each week. If you’re managing Project 1 for four weeks, you’ll have a sticky for Project 1 for each week.
5. Underneath all the stickies, mark a big black horizontal line, and write “Unstaffed work” in the left-most column. You have “Tasks” and then some space, and “Unstaffed Work.” You have 5 columns, Tasks with Weeks 1, 2, 3, 4, to the right. You have stickies. You have another row labeled “Unstaffed Work” at the bottom.
6. Now comes the hard part. You have to be honest with yourself. Know that you are human. You have a limited amount of time in any given week. Take the stickies you cannot fully commit to, and put them in the “unstaffed work” row for each week. Making these decisions is not easy. It is necessary.
   

I’ll be posting a picture of a blank portfolio on the podcast page. See the blank portfolio picture.

Now you have a picture of a project portfolio, and you can talk to your boss about it. In another podcast, I’ll give you some hints on how to say No to work you can’t do. At least now, you have a picture of all the work you’re supposed to do.

I'm offering a public project management workshop Sept. 22-24, 2008 in Waltham, MA. You’ll learn how to start, steer, and end a project successfully, using pragmatic approaches. You’ll have a chance to practice approaches to project management that prevent this business of trying to manage multiple projects or manage the people who are supposed to be working on multiple projects at the same time. Go to jrothman.com/workshops.html for more information.

I’ll have the specific URL with the workshop description and registration in the show notes for this episode as well as a transcript of this episode.

Some of my listeners have requested that I respond to questions or run these podcasts as an interview. Sounds like fun to me! If you want to interview me, contact me.

Have comments on this podcast? I’d love to hear from you. Email me at jr@jrothman.com

Click for the mp3 file.

A project manager at a client took me aside recently. "Johanna, how many emergency projects should I have?" I was a bit surprised and asked what he meant. "Well, my boss thinks I can manage two normal projects and two or three emergency projects. I'm swamped."

I would think so. If I'm managing one project--actively managing, not caretaking--I can't even take on one emergency project, never mind two or three. Asking a project manager to actively manage risks, remove obstacles, and help the team accomplish the work on several projects--a couple of which are the most important thing the company can do--is overloading the project manager.

So, how do things get this way? One reason for emergency projects is from a previous project’s technical debt: work that was necessary for a product--but  not completed--in a previous project. To be fair, when the world changes out from underneath you, you might have an emergency project to catch up, but those shouldn’t be the norm. Emergency projects have names such as "hot fix" or "patch release" or "service pack" or something else that acknowledges the work wasn't finished the first time—those are the one that have technical debt. But the debt can be anywhere.

If you don't have a coherent and cohesive design, writing and testing the code feels as if you're strangling yourself, and the product doesn't quite work the way you and the customers expect it to. Without requirements in some agreed-upon form, developers and testers decide on their own what the features need to be. Sometimes they even agree--but the customers might not. If the project team ran out of time for a feature or two or three, features the customers expect but are missing, some High Manager will say, "Ok, we'll do a patch release." If the testers don't have enough time to test and the developers don't have enough time to fix defects, the number of total defects may overwhelm the customers, which will require a hot fix.

If you have an emergency project, convince your manager that you need to pay attention to that project to the exclusion of every other project. If you don't, it's likely you and the team will not pay down enough technical debt, or that you won't know when you're done, or that you won't be able to meet the desired release date. Once you've got an emergency project, finish it.

Now that you're past the emergency, can you see ways to organize, manage, or replan your current projects so you don't require more emergency projects? If you're not sure how, here are some ideas:

- Timebox work on every single project. A timebox helps people focus on the work they need to complete *now*.
- Work feature-by-feature instead of across the architecture, so everyone can see how good the features are and if the team will finish all the features by the desired date.
- Integrate testing into every part of your project, instead of waiting for everything to be done before you start testing. If you work feature-by-feature, you can test feature-by-feature, which helps developers see how good their work is.

Emergency projects slow everything down and prevent project managers and teams from making real progress on their work. Prevent them when you can. Finish them if you've got them.

I'm offering a public project management workshop Sept. 22-24, 2008 in Waltham, MA. You’ll learn how to start, steer, and end a project successfully, using pragmatic approaches to project management. You’ll have a chance to practice approaches to projects that prevent emergency projects. Go to jrothman.com/workshops.html for more information. Here's the specific URL for the Manage It! Pragmatic Project Management Workshop. The registration form is on that page.

Have comments on this podcast? I’d love to hear from you. Email me at jr@jrothman.com

You can also listen to this podcast as an mp3.

To read a transcript of this episode, go to Timeboxes Help Multisite Teams. To see the description of the workshop, go to Manage It! Pragmatic Project Management.
 
Due to popular (at least one!) demand, I'm also attaching an mp3 file to this post.