Managing Product Development

I’m particular about two things: calling a prose plan a project plan and calling a Gantt chart (or yellow stickies) a schedule. One of my colleagues emailed me last week, explaining he’d spent a week developing a project plan and was hoping I could take a look at it. “Sure,” I said. “Send it along.”

He did. It was a Gantt chart for the next three months, with one- and two-week tasks. I called him and asked for a project plan, with release criteria. Did he have any? No. Had he checked with the people who were going to do the work to see if they could buy into the schedule? No, none of them were assigned yet. Dead silence on my end, trying to figure out how to ask the next question: Did he realize his schedule was already behind because 6 people were supposed to have already started?

I finally just asked the question, ignoring tact. He was quiet. I asked, “Why is this schedule so important to you?” “My manager wants the project done in three months.”

Managers can want anything they want. But wanting it doesn’t make it happen. This is where it’s critical to get started on working by chunk, so you can finish some work, and see where you’re going (I use velocity charts).

He challenged me, “What do you use for a schedule if you don’t make a Gantt chart?” I explained I kept a three-to-four week rolling wave schedule, using inch-pebbles.

If you’re given a deadline, you don’t need a long schedule. You need a short in-depth schedule, along with knowing what done means. You need to spend your time managing the project, not defining a schedule.

If you want to try some templates for a project plan, take a look at the Manage It! templates.

The Projects@Work folks have posted another excerpt from Manage It! See Roll With It to read a bit about rolling wave scheduling.

Glen Alleman in What’s Wrong With This Picture says this:

dentifying, sequencing, and assigning durations to tasks is NOT the role of the Project Scheduler, it is the role of the project team, along with the Project Scheduler. The Work Package Manager, the Customer, the entire team that is accountable for delivering the business capabilities and their associated value to the customer - did I mention the Customer is accountable for the credibility of these activities as well.

I agree. That means that the team has to define and organize the schedule. And that the Customer has to understand it and be accountable for it. That’s why schedule games are so difficult for the team to deal with.

Labels: project management, schedule

I’m writing my project management book. I have no idea how far along I am. (Wait, I promise to explain.) When I write, I have several phases: the exploratory phase, where I write articles, the write-it-down phase, where I write the whole thing down (in chunks, of course), and the editing phase. I’m in the write-it-down phase right now. In this phase, I need hours at a time to blast away at a chapter until there’s little enough of it left so I can write it in spurts. (I hope you understood that.)

I was talking with my editor this morning about when I would be done with the first draft, the write-it-down part. I explained that I had a slim chance of being done by mid-October, and a stronger chance of being done at Thanksgiving. Here’s the graph of what that looks like:

Note that there’s a 50% chance I’ll be done with this phase, the write-it-down phase, by mid October. I have a bunch of writing time between now and then for the book. I have some other writing to do, some web site updates, etc. , but most of my time is available for writing the book. If I miss mid-October, I have no writing time until almost the middle of November. That’s why if I’m close in mid-October, I might be able to finish in mid-November. But if I miss mid-October because I’m not close, the mid-November date is quite risky. I have a bunch of writing time from mid-November through early December, but I expect to be traveling again and teaching, which changes my writing time.

This is an example of probabilistic scheduling. I don’t even have a 100% completion date (which you might have to have for one of your projects), because I will be replanning in mid-October, no matter what. Any 100% date I give now will be wrong, wrong, wrong. It will either be too optimistic or too pessimistic, and I won’t know which one until October.

It doesn’t matter what kind of lifecyle you use, the further out the dates are, the less you know. You can use probabilistic scheduling to help you, the project team, and your sponsors see the risk in the schedule.

One of the scheduling tips I discuss in my project management workshops is “Plan to refactor.” I explain that if you’re using a lifecycle other than Agile, where the integration and testing is built into every iteration, you’re going to have to refactor at the end, when you do integrate and test.

At one of the workshops, one of the participants said, “You always have to plan to refactor. If you do plan for it, you will. If you don’t plan for it you will, anyway. So plan for it.”

File this under wish I’d said that.

I had a discussion recently with a manager who was concerned about his developers meeting their milestones. “We have “Code Complete” as a milestone. The developers say they meet it, but that just means they wrote code until the milestone date. The code isn’t complete. I can’t even tell how complete it is.”

Ah, the hazards of a functional milestone. Functional milestones occur when a functional group says they’re done with something, not when a particular piece of the product is done (including review and integration with the rest of the product).

“Code complete” should be based on a bunch of feature deliverables (Feature 1 implemented, tested, integrated, Feature 2 implemented, tested, integrated, and so on), but we tend to use “Code Complete” (or my favorite, Code Freeze)as a milestone itself, instead of a roll-up of interim milestones. When project managers don’t have feature-by-feature (or architectural milestones if you insist) milestones, with developer testing and integration built in, the developers don’t remember or don’t feel they have the time to do the testing and integration. (Too often, developers are correct, they don’t have enough time because the original estimation was off, or they’re multi-project multi-tasking, or someone decided to add more features and not change the schedule.)

So if you’re a project manager, consider what you want to call the end of scheduled development. If you want a Code Complete or a Code Freeze, make sure that’s rolled-up task, consisting of individual tasks that include development, testing, and review. If you don’t, you’ll end up with Code Incomplete or Code Slush. “Code Complete” as a stand-alone task means the code won’t be complete.

I gave a talk entitled “Predicting Project Completion” at the Central Mass chapter of the PMI last night. I had some suggestions about techniques to generate and discuss schedule estimates. Then, to practice a little, I asked the audience to become participants and practice a simulation. The simulation is to first estimate how long it will take to sort two decks of cards (I only allow three minutes for this part), and then to do the sorting, comparing the estimated time with the actual time.

As I debriefed the simulation, some of the people said, “Three minutes is not long enough to plan this project. Some people disagreed, “Three minutes is plenty of time to plan the project–because we can’t fully plan, so we can plan enough in three minutes to get started.”

I don’t know how much time is enough time to plan your projects. It depends on where your risks are: in the people not knowing the subject domain; in the pre-determined costs; in the whether you have enough people assigned when you need them; whether the feature set is known or will evolve; whether anyone knows how good the project needs to be. You probably have more risks on your projects.

But I am sure that for a projects of more than one person and more than one week in duration, three minutes is not enough planning. Our projects last night had actual durations of about 2.5 minutes to 7 minutes. Taking more than three minutes to plan would have been nuts–we could have spent more time planning than working. But I regularly see 6-12 month projects where the PM and technical leads spent less than three minutes planning (by their own admission).

I recommend starting every project with a project charter, and taking an hour or maybe two with the technical leads (or on a small project, with each person) participating in generating the charter. You may not know precisely where you’re headed, but you’ll already have generated some shared goals, which will help you make the decisions as you proceed. Once you’ve spent that hour or two, you can decide if you need more planning at the beginning of the project, or if you can continue to plan as the technical staff proceed, or if you iterate the plan as you proceed (or both).

There is no One Right Way to start a project, but a project charter can help. Taking just enough time to charter the project may help you understand where your project’s risks are, and how to deal with them. And that may be about enough planning.

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.

In my project management class today, one of the students asked about how to schedule interdependent sub-projects. The scheduling tool he uses doesn’t deal well with pieces of one sub-project having dependencies of other sub-projects. It’s difficult to see the critical path, and to know what’s really going on. (It’s too easy to have circular dependencies in the scheduling tool.) I asked if they scheduled by architecture component or by feature. I’m not sure if I understood the answer (or if the student understood the question), but I think they’re organizing around architecture pieces.

If you have a number of sub-projects and they’re coupled (have dependencies on each other), try rethinking how you organize the work. I bet if you organize the work by feature instead of by architectural component, you’ll be able to schedule easier. My student wasn’t so sure this would work — he has some scarce people resources who need to work on multiple features. I suggested they rank the features by priority (1, 2, 3, 4, …) and have the scarce people work on features in rank order. This requires cross-functional teams and the ability to recreate small feature-driven teams. This would be a huge change for the student’s company.

I’m a bit stuck. I only see program management (treating each feature like a project, managing all the projects, and using cross-functional development teams to perform the work) as a solution when you want to break tightly coupled interdependent sub-projects. Since I can’t think of three alternatives, it’s time to ask for help. Do you know of any alternatives?

I’m not a fan of project scheduling tools. I have trouble making the tools create the schedule the way I think, and I can never quite see the whole schedule when it’s in electronic form. Other people, especially senior managers, tend to believe the project schedule once it’s in electronic form, no matter how outrageous the schedule is. Since I mostly work on iterative or adaptive projects, I don’t normally have to use scheduling tools because I’m scheduling small pieces at a time. But when I teach project management or perform assessments, I work with people who are accustomed to using project scheduling tools. And, something that surprised me, they use the project scheduling tools from the beginning of the project to lay out the schedule.

As I was finishing this rev of my Pragmatic Project Management workshop, I realized why I like yellow-sticky scheduling (especially at the beginning of the project) so much. Yellow sticky scheduling, where you lay out the tasks on yellow stickies, one task per sticky, allow you to treat the schedule as if it’s a design. Yellow stickies help you see a prototype of a schedule. You can use a whole wall and see the “complete” (as much as you’re willing to deal with) schedule for a large project. The schedule isn’t in electronic form, where it’s not only harder to modify, you treat the schedule as if it’s something more real than it is.

The project schedule, especially at the beginning of the project, is a promise on the part of the project team to try to meet their estimates/guesses. The only thing you know about the project schedule is that the way you’ve laid it out is the one way it won’t happen. Life happens and the project schedule can’t reflect the server going down, the thunderstorm that took out power in one sub-project’s building, or the person who had an emergency appendectomy. All those events happen on projects, and you can’t know at the beginning when you schedule a project what will happen. The schedule is how you hope the project will unfold — but it’s certainly no guarantee.

So prototype your schedules, as you would designs. I like yellow stickies, but you can use index cards, or even large whiteboards, as long as your materials allow you to easily move tasks around and see how else to organize the project. Seeing the project laid out on a wall will help you see potential problems in the project or alternative designs for your project. Once you can see the whole project, you can anticipate problems and risks. Stay away from high-tech scheduling tools as long as possible. The lower-tech your scheduling, the more likely you can see problems in your projects.