Is there a duration limit for FDD Project when those projects are likely to fail due external and internal factors?

For example XP projects should kept short due the openess of the concept and dependents on the individuals in the team and lack of documentation which is vulnerable to disturbances like losing team members and so forth.


The possibility of project failure is something that you try to factor in early on. If you see a project has a very high probability of failure, either it won't get off the ground, or in the early exploratory phase the risks identified will need to be managed. As per the OPs example, people getting sick or leaving the team are factors that can occur in any project, and a good project planner will try and build a little additional slack into the schedule to try and cater for the "unforseen" problems that may arise.

The issue of a lack of documentation should not arise on an FDD project, as it is very much an artifact-heavy method. Also, the lack of documentation on an XP or an agile process to extend the OPs example should not be an issue for an agile process if the code is written to be readable, and the requirements have been listed and collated appropriately.

So a "duration" limit really doesn't make much sense as per the OPs question, as the duration of an FDD project is usually something that is fixed by contract. Deliverables within the project duration would usually be defined as Feature Sets, and the duration of a feature set will be variable as it depends on the number and complexity of the features being implemented.

However, FDD is also what I like to think of as a wrapper methodology, in that within the scope of the Develop/Test stages, the feature sets can be treated as mini-projects in themselves, and could be implemented using an Agile methodology if it is deemed to offer value to the project and all of its stakeholders. What FDD really offers is a collection of artifacts - and in particular the reports - which can be used to measure project progress, and this is particularly important when it is seen as difficult to offer working code at the end of every iteration, as the customer wants to know that months of development where they don't see what they have been paying for has been spent fruitfully. Thus, where risks are high and working modules are contractually specified at only a handful of intervals over a long period of time, deliverables in the form of reports and other project artifacts can be used to mitigate some of the problems that can arise when a project looks like it could be going off the rails. The earlier the reports/parking-lot charts/etc... can be delivered, the sooner measures can be taken to try and keep a project either on track, or limit the damage that running over time may cause.

  • FDD seems to be pretty robust against team changes.
    – jpse
    Mar 31 '12 at 14:57
  • +1 for the artifacts and solved with "wrapper methodology"
    – jpse
    Mar 31 '12 at 15:03

Any project where there's a high risk of failure should aim to deliver something as soon as possible.

This is of benefit for several reasons:

  • You can gauge whether there is going to be the necessary demand for your product and fail early.
  • You can get rapid feedback on features already developed.
  • You can get rapid feedback on which outstanding features are still considered important. The relative priority of features will change over time and new requirements will come in while old ones fall by the wayside.
  • You can have something "out there" to show investors so they keep giving you money.

This is true regardless of the approach you use to development.

Obviously the exact duration of each phase/stage/sprint will depend on the development effort you can put in and the minimum set of requirements that need to be fulfilled at each iteration.

  • That is true for all project... further what are the points of failure that are design immanent in fdd?
    – jpse
    Oct 27 '11 at 13:53
  • @jpse - that's my point. I don't think that FDD is any more special in this regard. It's always a case of release early and release often.
    – ChrisF
    Oct 27 '11 at 13:58
  • This true when its possible to deliver often, image a solution when the cost of failure is high, like in aerospace projects
    – jpse
    Oct 27 '11 at 14:05
  • I'd like to add that FDD was before The Agile Manifesto so its not really bound to its principles... like deliver often and and value changes
    – jpse
    Nov 2 '11 at 14:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.