Feature Driven Development vs. Traditional Project Planning, part deux

A couple of weeks ago, I blogged about an experience I had that allowed me to directly compare Feature Driven Development's planning process with processes that used traditional workflow breakdown structure and the waterfall approach. 

I pointed out how much pain was felt by the teams that used the traditional approach and compared that to the relative ease with which the FDD team reached consensus and proceeded with our work.

In sharing that article, I got quite a bit of feedback. Some of it is supportive, much of it is skeptical. The last article is presented as a case study. This one is analysis. The topic is essentially the same: if we focus only on the planning process, how does FDD compare to Traditional Waterfall.

The goal of planning

Let me start with a definition: The intent of planning is to take the requirements, develop cost estimates, and get them back to the customers. The purpose of this cycle is to give control to the customers in deciding what to build. "Now that I know how much it costs, what do I really want to build?"

The key takeaway from the FDD article that I blogged is this:

    T-WBS processes provide lots of information, but do not effectively roll up the information in a way that allows the customer to answer the question above. FDD articles provide the same information in a different order that fosters better decision making.

Avoiding Sticker Shock

How many times have you presented a schedule to a customer, and they came back and said "that's too expensive?" In my experience, this is common but not really typical. Why? Because T-WBS Waterfall processes solve this problem in a different way.

In T-WBS systems, we plan things in layers so that we avoid the problem of "sticker shock." We cooperate to set high level goals, make high level estimates, and set expectations... then do it again, refining the estimates, clarifying requirements, and negotiating costs. Then we create "phases" and do it again within the coming phase. Everything moves, everything shifts. This negotiation takes time. It also assumes that the list of requirements is pretty static. 

This also puts a huge focus on the Product Manager and the Program Manager making decisions for other people. The product manager makes decisions for the customer. The Program Manager makes decisions for the dev team. Neither the customer nor the dev team is in the room.

Is this the right way to avoid Sticker Shock?

This traditional negotiation process starts to shred if the requirements are still being discovered, or if folks don't really know what they want. This is common knowledge in PM circles. If the requirements aren't known up front, you will have problems with this process. The problem is that this statement is ALWAYS TRUE. Requirements are nearly never well known up front, and even when they are, they always change as needs are uncovered or business moves.

What we lose is the ability for the customer and the team to cooperate in an agile manner throughout the life of the project. We lose the ability for the customer to expand scope in one area, restrict scope in another, and introduce entire sets of requirements part way through the process. We lose the ability of the team to offer ideas born of experience. We lose the ability for the customer to explain and expand on their understanding. 

The multi-layered negotiation stage of T-WBS, and the notion that we can "manage to schedule" is very inflexible in this regard. This traditional process assumes that we are guessing correctly about things that we don't know. It assumes that information we learn along the way is inconvenient or less valuable than the stuff we knew at the beginning.

This is an absurd notion, and no matter how well you refine and improve the Waterfall planning process, the act of building a framework on top of such an absurd notion cannot produce a stable process. 

The fact that I am making this point, when T-WBS has been repeatedly refined for 25 years, is proof positive that the traditional work-breakdown structure concept is not stable. 

Is FDD better than Traditional WBS when planning a project?

If the goal is to allow the customer the right to decide what to develop, and what not to develop, then yes, because T-WBS offers no easy way for the customer to push back on one feature, or to select one feature over another.

If you judge the process by it's output, then T-WBS is fundamentally broken.

Does FDD planning fit with Waterfall delivery?

Sure. You can use FDD to plan a waterfall project. In fact, we've done just that for some very short projects (what agilists would refer to as a single iteration or sprint). The point is not that Waterfall processes will go away any time soon. The point is that the traditional planning process, taught in project management class, is missing a basic tenent: that the tasks need to be collected into features and delivered as features, and that doing so allows the customer to provide better feedback, and to better prioritize the work.

This is an education process. It isn't easy. But I'm a pretty persistent fellow.