Managing Product Development

We talk blithely about the “crisis” in software development or IT. But most of the time, that’s just projects over schedule, over budget, and under featured. Real project crises are about people.

I heard that one of my clients died today. She was a young-ish project manager. I’d never met her in person (she lived overseas from the US); we had a phone, email, and IM coaching relationship. But I worked with this person. She was a real person to me, even though we’d only met electronically.

I can only imagine how the project team feels. The project team is surely in crisis now, and will probably remain in crisis for a while.

When something devastating occurs to a member of a project team, the entire project team feels it. Some occurrences are easier to manage than others. For example, providing support to a project team member whose spouse is having medical problems may be easier for a team to deal with than if the project team member was having those same problems. And certainly, when a team member dies, that’s truly devastating to a project team.

If you’re in the position of being a manager of team with a real project crisis — a crisis of the human variety — the best thing you can do is show your humanity. Don’t expect people to plod on. That’s nuts. Allow yourself and the team to come to terms with whatever has happened. Without becoming a therapist, you can help each person on the project team accept what’s happened, and determine their own ways of dealing with the problem. Whatever you do, don’t ignore this crisis.

I’m certainly not comfortable discussing death and severe illness with fellow workers. But I do it anyway. I’ve found most people will accept my condolences, offering sympathy, offering help (if that fits for you), or other gestures of sympathy and empathy.

I once worked with a project team that was stuck. They could not make progress on anything. After a couple of days with the team, I asked one of the developers if something was bothering him. He explained that the architect had died suddenly a year ago and no one (in management) had acknowledged it. I spoke one-on-one with each team member, and worked with the management team to hold a memorial type of meeting. It helped, but it took months for that project team to trust their managers again. (If you can ignore death, what else can you ignore?)

Project crises are real. And I hope you don’t experience one on your project. But chances are good that someone will marry, divorce, have children, become sick, or even die. Even though some of these crises are happy ones, they stress the project team. Approach the crisis with humanity and you and your project team will weather it. Ignore it, and the crisis will never end.

Tweet This Post 

Esther and I are editing (the next-to-final pass, we think) the book this week, integrating comments from our reviewers. We are very fortunate; our reviewers provided wonderful feedback. And some of the feedback we’re not going to use — at least, not in this book.

One of the hardest things to do, whether it’s in a book or in a project (or many other undertakings), is to decide what you’re not going to do. As we’re walking through the comments, we’ve been asking ourselves, “Is that comment for this book?” We’ve been drawing the boundaries around what we decided to accomplish with this book, and we’re not adding more.

This is frustrating, relieving, and freeing for me all at the same time. It’s frustrating, because I would like to address many of these topics. But it’s relieving , because our reviewers want us to address these topics, and many of them will be going into my project management book (which has been put aside for the moment), to finish this book. Our boundaries are freeing for me, because I don’t have to consider things outside of the boundary for this book; I can consider them for future writing.

Esther and I decided on our boundaries for this book with something that looks like a project charter (but was our purpose for writing the book). If you haven’t developed a project charter yet for your project, do so. It will help you draw — and keep — the boundaries on your project.

Tweet This Post 

I’ve changed a few things about this blog:

• I enabled each post to be its own archive. You can click on the title or on the “link” in the byline.
• You should be able to use the little email icon to email a blog entry to someone.

Please let me know if you find any problems.

Tweet This Post 

I maintain the AYE web site as part of my responsibilities this year for the conference. I post the news, the new articles, and do the general updating. Monday, I posted one of Don Gray’s articles, Shifting the Burden – Whose Monkey Is It? Except, Don and I had both made a mistake. Don had originally spelled Whose Monkey as ‘Who’s Monkey.’ Something looked off (!) to me, but I couldn’t figure out what it was. One of the people who attend the conference yearly reviews the site updating I do, and she told me about the Who’s and Whose. So I fixed the article title. Today, I received an email reminding me that the title wasn’t just in one place, it was in several places, and could I please update all of them?

After saying “duh” several times, and fixing the name, I realized what had happened. I had literally fixed the title of the article and that’s it. I had forgotten about all the referring places.

I didn’t mean to be stupid, or fix just one piece of the problem. But I was in a rush and didn’t take the time to ask myself, “Where else is this problem?”

If I’d been pairing, I doubt the other person would have let me forget. We would have had a good few seconds saying “Where else is this mentioned?” and fixed everything at once. But this is why I ask for peer review.

I find it impossible to see all of my own mistakes, even when I look for them. I’m sure you also find it difficult to find all of your mistakes. But other people who haven’t authored the work are much more likely to see my (and your) mistakes. So it’s ok if we have blinders on, as long as we make sure someone else reviews the work who can see what we’ve done.

Tweet This Post 

It’s been a tough week, and it’s only Wednesday morning. We’ve had a bunch of family illnesses — nothing deadly, but difficult to diagnose with long term effects. A very old friend of the family died. And because it’s June, the kids have a gazillion things with school and sports. I’m not quite back on East Coast time, so it’s been a tough week. And it’s only Wednesday morning.

I was originally going to title this post “Adaptability is Key for PMs,” but that would be incorrect. Everyone’s adaptability is the reason my family with our assorted projects is managing to get everything done.

I bet the same thing happens on your projects. Things happen. The build breaks, the performance isn’t quite right, some customer wants something different. Whatever happens, it’s not what you expected. The ability of you and the entire project team to adapt to whatever problems exist are the key to solving these problems and moving past them to achieve success. And there are weeks (sometimes even months) when adapting and problem solving seems like the hardest thing in the world to do.

This week isn’t fun for me, but it will be over whether I replan or not. I’ll replan and adapt, and determine ways to achieve at least some of the things I need to do before the week is over. And then I’ll replan next week to make the most of it. That’s all anyone can do. The more you adapt to your current state, the more you can create a future state that’s close to what you want. And for weeks like this, what else can you do?

Tweet This Post 

If you’re managing a project longer than a few weeks, you may realize that the project’s progress is not quite where you think it should be. It can seem impossible to change course. But choosing to continue what you’re doing is a choice. So you can choose to do something different.

I started thinking about this for two reasons. Frank’s entry, Cost of Project Delay started me thinking about projects I’ve met where the people were not increasing value and the PM didn’t change course. And, last weekend, I visited Masada, a triumph of Roman engineering (in Israel). It took Herod a few years to build the three (!) palaces on top of this mountain. Herod had a virtually unlimited number of slaves, and I’m sure he had a separate architect and project manager.

But I suspect that not everything went smoothly sometime during those few years of building. And, Herod’s PM probably didn’t have a drop-dead date. Well, I hope not, because it was probably literal back then. But when these folks ran into trouble, they changed course.

You can too. The key is to recognize when you need to change course. So gather some data (qualitative and quantitative). Ask yourself if you are headed in the direction in which you want to be headed — that you and your team are continuing to create value. If so, great. If not, change course.

Tweet This Post 

I’ve been thinking a lot about impossible schedules. I’m talking about the project schedules that no matter how you organize the project, it’s not possible for this group of people to cram that set of features into this much time. At least, the developers don’t think so.

If people are up against impossible schedules, in my experience, they stop thinking. They cannot imagine a new technique or tool will help them. So even if their configuration management is in the pits, they will limp along instead of acquiring and using a new tool. And a change in technique is even worse. People who can’t imagine any way to success resist any ideas like iterations, implementing by feature, test-driven development, or even peer review of code. (This happens to testers too, it’s just that my examples here are for development.)

People aren’t stupid. When they’re up against an impossible schedule, they will hunker down and do what they can, so they won’t be fired. That’s all.

But with merely a difficult schedule, people will consider alternatives. They know that with alternatives they could make this into a not-so-difficult schedule, and they may be willing to take the chance on a different technique or tool — or even both.

So if you have an impossible schedule, don’t try to change anything. Or, change enough of the schedule that people have a little breathing room to try something new. But don’t expect people to try something new in an impossible schedule. The personal risk is too high. It’s much safer not to take a risk and miss the schedule than it is to take a risk with something new and miss the schedule.

So if you want your project staff to think, make a difficult schedule, and then set a personal challenge: “How can we make this schedule more reasonable?” In my experience, this is the kind of challenge many of us thrive on. But don’t set a stretch goal. That discourages thinking and will encourage people to throw out any good ideas that have not yet become good habits.

Tweet This Post 

I’m in Israel this week, continuing an assessment I started last week. For those of you in the US, sit down. The people who have offices on an outside wall have windows that open. Yup, they do. The A/C and the heat know to shut off when the window is open. (I think they do, it seemed that way to me.) It’s a great way to regulate the freshness of the air, not just the temperature.

Tweet This Post 

I’ve been thinking about project retrospectives. Too few project teams participate in end-of-the-project retrospectives, and to few managers arrange for them. My clients seem concerned by the price of an outside facilitator and the cost in time to the next project.

To address the facilitator cost, I’ve suggested that any facilitator not on the project team is acceptable. Oops. I wasn’t specific enough. Any facilitator who understand retrospectives *and* is able to not blame anyone on the project team is an acceptable facilitator.

The retrospective facilitator has to be non-judgmental, and willing to postpone finding solutions to problems until the retrospective data is gathered and absorbed by the retrospective participants. In fact, I like to see the retrospective participants define their own solutions. One of my clients was attempting to use the process staff as facilitators for their retrospectives, but one of the process people was too eager to blame some people (”Those developers wrote bad code”) and was too eager to decide on a course of action (”You should use month-long iterations”).

Blaming people, especially in a retrospective where the objective is to see the history of the project and learn from it — to see how things got the way they are — is counterproductive. And it’s not just counterproductive for the moment. Blaming will prevent people from fully participating in future retrospectives.

And, as much as I’m a fan of iterations, deciding that month-long iterations is the Right Size during a retrospective is premature. Maybe 3-week iterations is the right duration. Maybe 5 weeks. Maybe even 2 months, while using a staged delivery lifecycle. Until people look at the entirety of how they are willing to work, a retrospective is too early for someone *not on the project team* to decide how long the iterations should be.

So schedule retrospectives as you schedule the end game. And make sure you select a facilitator who understands enough of the issues to be helpful, but will not push the project team into one direction or another.

Tweet This Post