Which Project Management method goes well with FDD?

I recently read Head First PMP which describes Project Management (PM) in a very visual and understandable way. The book is at the same time the Study Guide for the worldwide acknowledged PMP certificate from PMI Institute. I say this because it makes PM more tangible for people who are new to this field.
Other PM methods like Agile PM as defined by Jim Highsmith are also to mention (however I'm not sure how much Jim was influenced by PMI).

PMI provides a bunch of knowledge areas (KA) with project management wisdoms. Those KAs are:

Integration Management
Scope Management
Time Management
Cost Management
Quality Management
Human Resource Management
Communications Management
Risk Management
Procurement Management

Each Software Development (SD) process, like FDD, has some plug-ins to above list of knowledge areas. And this is valid for every combination of PM method and SD process, like e.g. Scrum (PM) and extreme Programming (SD).

Now, which PM method is the one that goes well with FDD? - Or is it all nonsense and a SD process does not need a PM method above itself?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jeff De Luca's picture

Not a fan

I don't really understand the question. Do you mean of the lists KAs are in FDD? If not, then what do you mean by a PM method?

My opinion is that PMP/PMI are too focused on what I call project administration and not project management.

follow me on Twitter


Jeff De Luca wrote:
Do you mean of the lists KAs are in FDD?

Yes. These Knowledge Areas (KAs) all play a role at some stage and a project manager has to tackle them. I'm not sure whether FDD covers them all. Is there a PM method FDD works fine with, like say Scrum works fine with XP?


FDD not living in a nut shell

FDD is not living in a nut shell. Once there is a project management environment in place, FDD has to adapt somehow to it. I mentioned the book Head First PMP and PMI association because they relate to the Project Management Body of Knowledge (PMBOK) which I highly respect as jewels of project management.

If time allows, I will present a small graphic here and show you how FDD perfectly match with PMBOK in my opinion, adding value to each other and making up a whole project environment Smiling .

5 process groups

I'm going to show you the 5 process groups defined in by PMBOK. There are total 44 processes all knowledge areas together. A knowledge area has processes for some or all process groups. But the baseline for all knowledge areas is the following graphic with its 5 process groups:

I'm not sure whether this discussion is of interest to anyone. So let me know if we should keep on with it.

44 processes and the big question

See the 44 processes below. The big question: which process is covered by FDD and which not?

All 44 processes build a whole PM process framework in which FDD is embedded. However which processes can be replaced by FDD Smiling ?

heptaman's picture


This is a very interesting topic, because it's very related to the reality of many companies.

I've analyzed the relationship between FDD and other PM approaches, like Scrum, PMBOK and PRINCE2. The following represents a brief understanding of the subject:

1) FDD and Scrum
High level of agreement. I've been proposing FDD as a major complement to Scrum for some years now. Scrum only touches the project administration (as Jeff says), with no clues on the Engineering aspect. Given the strong appeal of FDD on Engineering, it's an almost natural fit. A team goes through the Start Up processes (1, 2 and 3) to create the Product Backlog, and then, for each iteration, the team goes through the Construction processes (4 and 5). Scrum daily meetings are similar to the "Morning Roll Call" proposed by David Anderson at the Singapore project. Burndown Charts can be used to track the velocity of the team during an iteration, in place or in parallel with Cumulative Flow Diagrams, and both complementing the Parking Lot Chart.

In time: If the team is not using Scrum when they get to know FDD, I simply discard Scrum completely. In my opinion, FDD doesn't need Scrum, but Scrum really needs FDD (or other Engineering methodology) to achieve real results. I claim this because I used FDD for quite some time before knowing Scrum, and even after knowing it (I'm a Certified ScrumMaster, but I really hate this title), my opinion remains the same.

2) FDD and PRINCE2
Given the IT origin and product-oriented nature of PRINCE2, it's well aligned with FDD. PRINCE2 even has Configuration Management as a mandatory component, just like FDD. In fact, I currently present PRINCE2 as a more practical and useful approach than PMBOK, at least for IT projects. This claim is supported by the fact that PRINCE2 is indeed a PM methodology, whereas PMBOK is more like a reference model (as the name says, it's a body of knowledge, a pointer).

3) FDD and PMBOK
Because FDD has embedded PM practices, surely it presents some aspects suggested in PMBOK. Actually, FDD offers the "hows" for the "whats" in PMBOK. FDD, as a methodology, guides the team through most of the phases and processes preconized by PMBOK, in a way that it's not even noticed by team members. At the end of the day, the team gets the job done in such a fast and effective way, that they just call it "common sense" or "obvious". In fact, FDD is so effective that people with some experience with it ask: "Is there another way of doing this?". :)

Comments? Other points of view?


Adail Muniz Retamal