Project Size

As a general rule of thumb, FDD is extremely effective on large projects with complex business logic. It is not so effective on small projects with little business logic. That's not to say that you can't use elements of FDD to help manage your projects better but it's pretty hard to enforce code and design reviews (see processes 4 & 5) when you only have one developer on the project!

Technology

There is nothing in FDD that dictates what technology to use. However, the simple fact that the first process is primarily object modelling means that if you are not using an OO technology, using FDD is not going to be straight forward. Having said that, I've successfully used aspects of FDD on web projects using a variety of web orientated technologies such as ASP, JSP and PHP.

People

The key to FDD is process one, the key to process one is having a great object modeller and a great project manager.

Note: it doesn't matter what process you use, you need good people. No process, including FDD will help you if you don't have the right people. If you are thinking about FDD to help you resolve this issue, think again.

What it Doesn't Cover

You need to be well aware that FDD, to quote Fred Brooks, is not a silver bullet. It doesn't cover every aspect of development. There are many aspects of a standard project that you'll still need to manage outside of what FDD can help with. These aspects include

A Starting Point

Trying to implement a new process is difficult regardless of which process you choose. Not only do you have to learn the process you also have to produce a result at the same time. Be prepared for some confusion and difficulty which goes hand in hand with trying anything new. That being said, the structure of FDD can easily be adapted to move gradually from your existing process to an FDD approach.

What I found to be an effective way get started is to look at projects in an FDD way - that is, start to think of projects as a set of features. This approach can be used on almost any project regardless of size or technology.

1. Define a project as a list of features or functions
   At some point, every project needs to be defined by what it does or what functionality it provides. By listing all these functions (or features) of the system, you are defining what it is you need to build to complete the project.
   The key is to make sure you use the same language as the client, don't use technical terms that the client won't understand because they won't care if you build it. If they understand the feature, they will care about whether it has or hasn't been built.
   

2. Plan development based on features
   Once you know what you have to build, it's a fairly straight forward task to work out the order. As some features will be dependant on others, they clearly have to be built first. Whatever the order, you now have a development plan that you use to track your progress.
   I find it useful to get the lead developer to provide you with the order and time frame for the development plan, that way, they commit themselves to the plan and I have something to go back to when things aren't happening when they are supposed to.
   

3. Weekly project status meetings based on features completed
   If you have a list what needs to be done and by when, it's easy to then track progress and report back to the client. It's amazing how effective it is to be able to tell a client what features have been completed and what you're currently working on.
   As a project manager, you also find out about problems much early in the piece and have a chance to deal with them before they become a major issue.
   

Conclusion

There is no doubt that FDD can be used for web development, it has been done successful on numerous projects. As a process, it is easy to understand takes a common sense approach. But the qualities of FDD are not as important as whether FDD is appropriate to the type of development you do and will help you to achieve what it is you hope to gain from adopting FDD.