Managing Product Development

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.

Sometimes, I work with organizations where there’s an implicit agreement not to discuss the schedule. I’ve seen this in two flavors: the first is Dream Time, where the project team and management believe the schedule, especially if it’s in a scheduling tool with lots of graphs and different colored lines. The other is Happy Date, where management demands a date, and the project team says, “Sure, no problem. Christmas it is!” But they don’t say which Christmas.

Eventually, when some Christmas comes around, or enough dates have been missed, people start discussing the schedule. But not until the project team has missed many dates, possibly even the first few desired end-of-project dates. I worked with a project team once who hadn’t met a milestone or anything else on their project schedules in over five years. They would develop optimistic schedules with no confidence ranges repeatedly. Finally, after a senior management change, they were called into senior management meetings to explain the schedule. It wasn’t until one manager said, “Look, I want to know when something will be done. Let’s just start with one thing, and go from there,” that the project team realized they needed to change.

I have to admit, I have a difficult time understanding how people fall into this schedule game. At some point, no one can miss the reality of the project. But, I certainly have seen persuasive managers intimidate, cajole, or use political pressure to “convince” a project manager or team that they could meet the Happy Date, the date the manager wants. Combine that persuasiveness with a culture of not discussing difficult topics, and you’re ripe for the Dream Time/Happy Date schedule game.

To prevent this schedule game, you need to work on several levels. For the project:

• Explain schedule dates with confidence ranges, especially if you’re not using an iterative lifecycle.
• Use an iterative lifecycle and explain what you’ll implement with confidence ranges. (”We can do these ten features, and maybe these other three in the next month. We’ll let you know before the end of the month.”)
• Measure more than just the date of the project. I’ve discussed single-dimension measurements, especially just date measurements before. They’re poison to seeing the true project status.

But a huge problem with this game is the willingness of everyone in the organization to placate one another and avoid conflict. Constructive discussion (aka constructive conflict) can make an organization stronger. Avoiding conflict and the necessary discussions makes an organization weaker.

A few years ago, I received a call to help out a project in trouble. Unsurprisingly, when I was reviewing what had been done and what still left to do, the PM explained there were many half-implemented features. (The team had not been implementing by feature, but instead by architecture. Each architecture group had prioritized in their own way.) We created a list of things we would finish and a list we would postpone until the next release. The project finished.

I had suggested the team hold a retrospective, to learn what to do differently the next time. The VP didn’t think anyone would learn from a retrospective. He said, “But the team did a great job. They did everything we wanted in this release.”

That’s sweeping the problems — especially the changes in priority — all under the rug. Now management lacks credibility. And no one believes they did a good job. The project team is frustrated and tired. If they had known at the beginning that those requirements were unnecessary for this release, the developers wouldn’t have started working on them.

Some ideas to avoid this game:

• Rank the features to implement for a specific release. (Ranking means 1,2, 3, 4, 5, 6, …43, 44, 45,…)
• Implement by feature.
• Develop release criteria, so you have the conversation at the beginning of the project about what’s needed for release.

These strategies for avoidance all require conversations at the beginning of the project with the project stakeholders. And those conversations are difficult. But the payoff is that no one has to pretend the project was successful. Instead, the project can focus on what’s required for success and do that.

As a younger project manager, I had a conversation with my boss. “We can’t meet your schedule. Here’s what it’s going to take.” My boss said, “You can’t be serious about not meeting my schedule. I’m sure if you just put your mind to it, you’ll meet the date.” My jaw dropped as he walked away.

Denial, as in denying that the desired schedule is a pipe dream, is alive and well. It’s not limited to women managers, although to me, the name “King of Denial” sounds a little funny. (For those of you who don’t speak English as a first language, remember Cleopatra? She was Queen of the Nile and certainly in denial about a bunch of facts. This is a pun on Queen of de Nile.)

Denial occurs for a few possible reasons. The most common one I’ve seen is when the manager in question wants to encourage the project team, as my manager did. Sometimes, people are in denial because they’re in fear that the project won’t meet it’s deadline. By denying the possibility of failure, they actually guarantee failure because they haven’t performed any risk acknowledgement and management. Sometimes, managers disregard the actual schedule because they don’t have any data, and it’s easier to disbelieve the PM’s assessment of project state than it is to believe it.

Some possibilities to deal with denial, especially the denial that occurs from disbelief of failure or fear of failure:

• Write down those risks and their potential impact. Especially when I’m dealing with denial, I use High, Medium, and Low to discuss severity and exposure, not numbers.
• Show what you can do and measure the velocity you actually have on the project. Yes, iterations are your friend here. And velocity charts may help explain what’s really happening.
• Make sure people on the project have the solution-space domain expertise to perform the work.
• Investigate why your manager is in denial.

If my manager thinks that denial is the way to encourage the project team, I suggest alternative encouragement techniques. Usually, that means encouraging the manager to go do something else that would either benefit the project team (negotiate a smaller list of requirements for example), or move that manager’s attention to some other project. In my experience, the managers who think that encouraging the project team by denying problems or potential problems tend to get in the way. Focusing their attention on some other project is a useful technique for moving their attention off your project

Queen of Denial is a disaster only when the PM is the one in denial. One project team decided they would self-organize and ignore the PM. After attempting to have the PM accept reality, they gave up. They stopped attending project team meetings, ignored everything the PM said. They built pieces of the project and developed some data (but not velocity charts). After a few months, when it was clear the project was not where the PM said it was, the PM was fired. But the project team had lost so much time by that point, they had many fewer opportunities to manage what they could deliver when.

Inevitably, reality comes face-to-face with denial at some point, which is why Queen of Denial isn’t always a disaster as a schedule game. When the manager does see reality, make sure you have some part of the product working to show that manager and some data so you can discuss what to do next. This is a good time to consider how little you can do, so you can complete this project and plan better for the next one.

My quarterly column at Stickyminds is up today. It’s called Estimating Testing Time.

A few years ago, a senior manager called me. “We have a project in trouble. We started off hopeful, but now it looks impossible.” I asked a few questions, and discovered they had never done a project like this before. It was bigger, in a different language, on a new platform, with a shorter schedule. No, they hadn’t arranged for any training (for anyone), but they were hoping they could complete the project. After all the entire fortunes of the company were riding on it.

I wish I could tell you this was an isolated circumstance. But all over the world, there are projects right now where “We hope we can” is the mantra of the day. See Hal’s e-tip Hope is not a project strategy for the individual’s perspective on this.

I’m a pragmatic realist. I do understand that many times organizations and people undertake projects where they really don’t know enough to know how to pull off this project. In that case, the PM has some obligations:

• Recognize and write down where you have risks. You may have technical risks (new language, new platform), schedule risks (shorter schedule), or most likely, both.
• Choose any lifecycle other than waterfall. If you’ve never done anything technical like this before, iterate on some prototypes, or iterate on a few features, to see where your work takes you.
• Consider a Hudson Bay start” to see if you can make anything. A Hudson Bay Start will show you what you’re hoping for (those unknown risks that get up and bite you in the leg).
• Make sure people have the technical functional skills and solution-space domain expertise. If necessary, train people. It’s cheaper to train everyone on the project in a new language than waste time.
• Plan to iterate on everything, especially your planning and scheduling.
• Ask for help from the project staff on making status visible and easily updated.
• Don’t be afraid to ask for help from other people. You’ve never done this before, don’t think you can somehow know everything you need to in time to do the project enough good.
• Even if management or your sponsors don’t want management reviews, you hold them. I like developing lots of milestone criteria, as well as release criteria.

I hope for lots of things, and most of the time nothing happens, unless I work to make it happen. Same thing with projects. Hoping for a good outcome is not enough. Planning, seeing where you are, and updating the plan — that’s what makes project success possible.

I appreciate you, Hal, for writing the e-tip and triggering me to write this series.

I’ve been talking to a beleaguered colleague about his project schedule. “No matter what date I give them (senior management), they want an earlier date. I told them it doesn’t take nine women to make a baby in one month, I need some time for this project!”

The Bring me a rock schedule game occurs when “they” want it faster, but don’t tell you when or why. (In my experience, only senior management plays bring me a rock.) If they told you when, you could tell them what you can do. If they told you why, you along with the project team, could probably develop some creative solutions to meet their desires.

If you find yourself playing bring me a rock, stop and select one of at least these choices:

• Explain your confidence range for the date you provide. It’s possible your management doesn’t understand what your estimate means and it’s possible you don’t understand what they’re asking.
• Include release criteria with your date, so you can ask specific questions about how good/full the release has to be.
• Ask some questions before attempting to fetch more rocks: Would you prefer a short schedule or a longer one? More people or fewer? What if we implemented this feature with incredible performance, and ignored that feature? Can our users live with more defects?
• Elicit the strategic reasons for this project and learn what success means.

If you agree to a too-short schedule, you’re headed for project failure.

I was a fortunate young developer. In my first three months at work, I ran into the 90% done schedule game. I did it to myself.

I estimated a particular task was going to take 6 weeks. Of course, being an arrogant and naive developer, it never occurred to me to break the task down into inch-pebbles. (That would have told me whether I even knew what to do for the task.)

At the end of the first week, I was 20% done. At the end of the second week, I was 40% done. At the end of the third week I was 60% done. At the end of the fourth week, I was 80% done. Right on time, at the end of the fifth week, I was 90% done. At the end of the sixth week, I was 92% done. Seventh week, 93% done. Time and I both marched onward. At the end of the 10th week, I was 97% done. But this time, I actually believed I was within a week of being done — I only had three one-day tasks left to complete. It took me two more weeks. A total of 12 weeks for a 6 week task.

During the time I was 92%, 93%, 94% done, I wrote status reports to my manager, explaining I’d run into unanticipated problems and that I hadn’t estimated all the things I needed to do. He was lovely about it, and kept saying, “Ok, let me know your updated estimate.”

At the end of this task, when I was finally done, he was all set to move on. I told him I would be estimating differently from now on, with much more detail, and several deliverables each week. If I couldn’t give him a date to be done, was that ok with him. We talked and I agreed to supply a date with a risk factor with each estimate.

I wish I could tell you I became a perfect estimator then. I didn’t. I’m still learning to estimate. But I now know that when I think I’m 90% done, I’m probably only 50% done.

I’m not the only one. The 90% done schedule game can occur under any conditions: reasonable or unreasonable schedule, low or high risk technology. 90% done is about our ability to predict the future, to perform accurate estimation, and to understand — in advance — if we will be interrupted. Not a trivial problem.

The 90% done schedule game is the reason I like feedback during project work, in the form of inch pebble estimation, one-on-one meetings with managers, visible project status, and project-wide rolling wave planning.

I’m thrilled to announce that you can see the announcement of Esther’s and my book, currently entitled Behind Closed Doors: Secrets of Great Management Revealed. Yes, this is the book we pair-wrote. We’re in the final stretch. First is working with Andy and Dave and whomever from Pragmatic Bookshelf to make sure we didn’t miss anything, add too much, and, of course, more editing. Then comes the “final” copyediting. We are on the road to a Sept 1, 2005 release date.

In case you’re not sure, this is a show-and-tell book. First we show you what a great manager does. Then we tell you how to do it. Just a quick anecdote to wet your appetite: one of our reviewers didn’t want to return his marked-up copy. He wanted to keep it, so he could follow the advice. We sent him a clean version, so we could use his edits

As we know more, we’ll pass along the information.

I’ve been meaning to write a series of posts on schedule games, and a story I heard over the weekend has jolted me into writing about schedule chicken.

I’m most familiar with schedule chicken that happens in meetings. Usually in a project status meeting, with the project manager and the project team, especially where the meeting is a form of serial status, everyone claims they’re on time. But the reality is that each person is waiting for another person to explain why he or she is not ready. In that case, each person graciously says, “Oh, that’s fine with me if you take an extra week or two or three. No problem.” Of course it’s no problem, if everyone else needs more time.

But I just learned of another schedule chicken. In this case, everyone claims to be on time. And, the developers are checking in code every night and building every night. But imagine there’s a milestone, named something like “code freeze.” After code freeze, you can’t add any more code, all you can do is fix the code that already exists. The day before code freeze, developers check in two to four times as much code as they had any of the previous days before. The results? Sure, you “met” the code freeze milestone, but the build doesn’t work, or even worse, you can no longer build. You spend the next week or two (at one of my clients, it was up to three weeks) fixing the code just so you have a successful build. Now that you have a working build (some time later than the testers expected), the testers find all kinds of problems.

Schedule chicken occurs when PMs only measure the milestones (the date), and not the stuff that’s created (the feature set) and the progress towards creating that stuff (velocity) and how good that stuff is (the defect levels) all throughout the project. If you know how much progress people are making, you can use your sense of smell to see if all those checkins were really to make code freeze, or were developers covering their tushes to meet the milestone.

When I manage projects, I want to know the reality of the project, whether I like it or not. I don’t want to play schedule games with the project team, nor do I want them to play schedule games with me. And if you’re in senior management, or are a project sponsor, don’t make people “commit” to a project date they don’t think they can make, because you’re setting yourself up for schedule chicken.