Managing Product Development

I write a roughly monthly email newsletter, the Pragmatic Manager. I (finally) posted Refocusing: Emerging from the Split Focus Schedule Game. Yes, I’m working on the July issue now. Enjoy!

My most recent Stickyminds column is up: Are Your Pants on Fire, or Do You Suffer from Split Focus?. There’s also a podcast on that page. You can leave comments there or here.

My Eliminating the 90% Done Schedule Game Stickyminds column is up. Enjoy!

For those of you who remember the schedule game series from a few years ago, yes, this is one of the games. I added several more and wrote more in Manage It!.

My Stickyminds column, Codependent Schedule Games is up. Enjoy!

Months ago, Debbie asked this question, “Do you have any comparative analysis on the disciplines (project management and program management) that you would like to share?”

To me, program management is the ability to take a project or a series of projects and manage those deliverables in the context of an entire organization. Not a trivial task. When I work as a program manager, I find that I the work tends to revolve around seeing the status of each project or set of deliverables. If I keep in mind the variety of schedule games, I’m much more likely to be able to ask questions that help me and the other people see their true state. For example, when a project manager tells me the project is 90% done, I ask “What did you see or hear that leads you to that conclusion?” If the PM says that everyone is 90% done, but doesn’t talk about deliverables or interim milestones or is working in some way that leads me to believe the project really is 90% done, I know I have some work to do. The work lies in two places: determining the true state and helping the PM and the project team see the state. Not trivial work.

So, Debbie, it’s not that I can give you comparative analysis on the two disciplines. If you work in a sufficiently large organization, where you are part of a team that manages multiple deliverables, or if you manage multiple deliverables, you need program management. Just managing a project isn’t enough. Too many other people have deliverables that are affected by your — or your deliverables affect their ability to complete your work.

I’m not sure that schedule games are the biggest problem for program managers, but they are at least one of the biggest. Remember, when a project or program is late, it affects the organization’s ability to manage the project portfolio (the sequencing of which work will be done when by whom). If you’re a PM or a program manager, make sure you’re watching out for schedule games. Otherwise, you’ll feel as if the project or program is managing you.

I’ve learned about schedule games from lots of people and projects. Here is the list of acknowledgements, as I remember them. If I left anyone off, please let me know.

We had a discussion of schedule games on the AYE wiki, which helped me remember just how many games there are.

I’m pretty sure I first discussed Schedule Chicken with Dave Smith and Jerry Weinberg. I recently discussed it more with Benson Margulies.

I can’t remember when I first learned about the name of 90 % done. I’m fairly sure it’s already in the literature somewhere. If anyone knows a definitive reference, I’d love to know what it is.

I learned about the name for Bring me a Rock from Jerry Weinberg.

I first learned about Hope is Our Most Important Strategy from Esther. And, Hal’s post triggered me to write this series.

I first heard of Queen of Denial from Benson Margulies.

I’d run into Sweep Under the Rug a bunch of times in my consulting practice, and I think I heard Elisabeth Hendrickson name it.

I first heard Tim Lister talk about Happy Date.

Elisabeth Hendrickson named Pants on Fire”

.

I think I named Schedule == Commitment”. It’s funnier when I talk about it, show the guillotine maneuver and explain commitment. Update: Dave Smith may have had a hand in naming this game back in 1998.

My husband named Chasing Skirts (or We’ll Know Where We Are When We Get There).

I don’t know if Esther or I came up with the name The Schedule Tool is Always Right.

If you know of other schedule games, or have heard other references for these games, please let me know.

You’ve probably gathered by now that I’m not enamored of project scheduling tools. And since I most often do rolling wave planning, I don’t normally need a scheduling tool. But, here’s another true story.

I was coaching a PM in an organization where the execs only understood the waterfall lifecycle. They thought iterating was a waste of time. And, they expected to see a Gantt chart the first week of the project, that the PM would manage to the chart, and everything would be fine. (I know, this sounds more like Hope is Our Most Important Strategy. But it’s not.) And, inevitably, if the PM had to report that the project was not on track some helpful senior manager would say something like, “Well, it says on the schedule that you’ll be here. What’s wrong with you, that you’re not on schedule?” The execs didn’t understand projects where people had to think and react to what they’d learned.

The PM explained this to me, and I asked some of the execs why they wanted to see a schedule so they could beat up the PM. (Well, I asked a little more nicely.) The execs were accustomed to reports of already-completed work/sales figures/whatever, that reflected what had happened in the past. I explained that the schedule is a guess about how things will happen in the future.

I wish I could tell you that they believed me and everyone lived happily ever after. Nope, these folks had been successful before (they believed), so they wanted their schedule now. I wanted to tell the PM not to do a schedule, but that wasn’t going to fly.

I suggested a rolling wave schedule, where the first few weeks were detailed, and only major milestones laid out till the end of the schedule. The PM would deliver a new and updated schedule with completed tasks and the next rolling wave and updated milestones every month. That worked. The execs still wanted to see the whole schedule laid out, but the PM explained he would be updating the schedule with real dates, and working hard to meet their desired deadline. This way he could show them what had occurred.

The PM had other alternatives too. One was to do yellow-sticky scheduling, and leave the stickies up on his wall until the project was complete. He could have invited the execs in any time to review it. In a less formal, smaller organization, that might have worked. Another alternative is to provide confidence estimates with a schedule.

The problem with the belief that the scheduling tool is always right is that it assumes the estimated schedule is accurate. The problem is that few schedules are accurate. Many are precise — “We’ll release Wednesday, at 3:32 pm” — but not particularly accurate. That’s because the schedule is an estimate. Making it look pretty doesn’t change the fact that the schedule is an estimate and has some margin of error.

This game isn’t the fault of the scheduling tool — the problem is in the belief system of the people who use the tool. As a PM, you’ll need to determine the most effective techniques for scheduling your project and for explaining that schedule to other people. So it’s fine to use a scheduling tool, if that works for you. Just don’t believe it because it happens to make pretty charts.

One of my clients claimed he had ADHD. He had trouble keeping projects focused on one goal. I’ve known him for a while, and he didn’t have this problem when he was a project manager. Nope, he made sure that each project he managed had a goal, and beware any senior manager who wanted to change that goal. But when he moved into senior management, he had trouble allowing the projects to finish, focused on one goal.

This schedule game occurs when senior managers change the goals of a project, or have a great idea that changes what the project is supposed to deliver, or when someone derails the project. I’ve seen unseasoned project managers derail the project in the same way that a senior manager does. “Oh, look over there. Doesn’t that look like a great idea? Let’s do that.”

This schedule game is sometimes called “Chasing Skirts”, a particularly un-politically correct name The chasing skirts name arose from this story: A number of years ago, my husband came home from work disgusted. He said, “They won’t decide on a product. They’re chasing skirts.” Mark doesn’t usually speak like that, so I asked him for an explanation. “They won’t focus on something we can do. It’s like they’re waiting for the next pretty girl to come along. It’s like they’re dating her for a while, but if another pretty girl comes along, they’ll drop the first one and move on to the next one. In the meantime, we’re not working on a product we could actually deliver.”

No matter what you call this schedule game, the effect is the same. The project doesn’t stay focused on a product the team could deliver. It keeps changing focus. The last time I consulted on a project like this, one of the senior managers said to me soothingly, “We’ll know where we are when get there.”

Not in my experience. Keeping a project focused on its goal(s) is the fastest way to finish a project. Allowing a project to lose focus will prevent it from finishing for a very long time, possibly forever.

Some ideas to consider:

• If you’re a PM, make sure you’ve written a project charter with project goals and release criteria.
• If you’re a senior manager, decide what the goals are. Stick to them.
• If the project is “too long,” organize the project into iterations. Evaluate where you are after each iteration. If you’ve accomplished enough of the goals, end this project and start another.
• If you’re an unseasoned project manager, make sure you know what the goals are, keep the project staff focused on the goals, and consider iterations.

Sometimes, none of these possibilities help, because management interferes with the PM, working around the PM to assign other work to the project staff. If that’s happened to you, talk to your managers and explain how you will benefit them. If they don’t listen, or can’t stop their behavior, remember you don’t have to stay there.

Projects need crisp goals and everyone to continually focus on those goals. Don’t let anyone allow your project to drift. You won’t know when you get there. All you’ll know is that you’re not anywhere.

You and I know that the schedule is an estimate. The project schedule is your best guess about when the project team will reach which milestones, and when the project may complete. But a schedule is not a prediction; it is a guess. So when I meet senior managers who want a project team to commit to a schedule, I ask the next two questions:

• Do you care what the project team delivers?
• Do you care how good the product is?

We can’t talk reasonably about schedules unless we also talk about the feature set we plan to deliver in that time, and how good the feature set will be at that time. If the people involved aren’t ready to discuss the schedule, the feature set, and the defect levels, then any discussion of schedule being a commitment is premature.

One technique I like to use when senior managers demand a commitment is to provide them confidence levels. “I have a 90% confidence level in Aug 1 as a release date. I have a 100% confidence level in Oct 1 as a release date.” Explaining what has to happen during that time, between the 90% and 100% confidence dates, helps me explain what a commitment to the schedule means to me.

Another technique I like to use is the date-for-a-date discussion. “I can tell you we’ll be able to release in the last half of the year. I can narrow it down to a quarter at this time (and specify a date), and I can narrow it down to a month here (another date), and then will be able to provide you a final release date.

But the best technique I know is to use iterations (2-4 week long iterations). That way, you can release virtually at any time. You know that the contents of each iteration works. You know you’ve implemented the most important requirements first. And it’s ok if management wants to release — because the product is ready. No one needs a commitment from the developers; you need a commitment from the people who decide on the requirements that they are telling you which requirements are needed when.

If someone demands you commit to a date, consider how you’ll organize the project. Try iterations. Or, date-for-a-date. Or, confidence levels with a date estimate. But don’t just commit to a date. That’s inviting Murphy to hang out on your project. You’ll commit to a date, but something will happen and you won’t meet the date.

You’re a project manager. Your project is proceeding fairly well. You’ve had a few bumps, but you’re making progress. You come into work one day, and there’s a message to meet with the Big Cheese. Big Cheese says, “Stop working on that project. Start on this one!”

Not only does this happen once, it happens several times, either bouncing you and the project team among several projects, or back and forth between two projects. Whatever the circumstances, you’re multi-project multi-tasking, and so are all the people on your project team. You know you’re not making progress on anything, and the urgency of all the projects keeps going up and up and up…

This schedule game is called “Pants on Fire.” It occurs when management is afraid to focus on one thing at a time. It has several possible causes: when the technical staff has a track record of being late, when there’s no corporate strategy, or when the corporate strategy hasn’t been broken down into sufficiently-detailed tactics.

Some actions you can take:

• Plan for iterations, and start something new on an iteration boundary. To make this work, the iterations have to be short enough to start something new. (I’ve made a staged delivery lifecycle work in a company that was addicted to Pants on Fire management.)
• Help management develop a corporate strategy.
• Help test the tactics against the strategy.
• Modify your current estimation techniques, so the project team is more likely to meet their original estimated dates.

Pants on Fire wastes everyone’s time. But sometimes, management either cannot change their management style or cannot believe that multiprojecting wastes time. If you’re in a situation like that, consider how you can create a project-wide environment that allows you and your project team to work successfully.