The next step was to work out how to actually apply FDD to our work. There were many projects in production and we couldn't simply change our approach midstream. Nor could we expect all new projects to start using the new methodology, as not everyone on the team had had training. We were going to have to take a staged approach to implementing the methodology.

We decided to tackle the problem from a number of angles. Firstly, we would slowly introduce a few of the key aspects of FDD into new projects:

• Define projects using features (customer-focused)

• Plan development based on features

• Implement new team structure, design and code reviews

• Conduct weekly project status meetings

Secondly, we would run an internal test project. Our intranet needed redevelopment and we thought this would be a good opportunity to give FDD a go, as well as a chance to try to work out how to deal with the interface and testing areas not covered. Thirdly, although it wasn't planned, a developer and project manager that had been through the training decided to use FDD on their next project for a paper merchant.

The intranet project didn't go well for many reasons, none of which had anything to do with FDD. The project suffered from the same problems that many internal projects face: it lacked buy-in and a dedicated stakeholder. Even though we went through a fairly comprehensive requirements gathering process, the project lacked clarity of purpose. It didn't matter what development process was applied, that project was destined to be difficult. But what it did indicate is that FDD works best when there are clear requirements to start with.

The paper merchant project, on the other hand, went extremely well. The developer, one of our best, did an excellent job in modelling the domain and the project manager was able to track the project easily. The team experienced some challenges, though. In defining the overall model, FDD uses a modelling technique called colour modelling (as explained in the book Java Modeling In Color With UML).

Normally, modelling is not completed in collaboration with the client; in FDD it does involve the client and, therefore, the client needs to have an understanding of the technique. That doesn't mean they need to be UML experts, but they do at least need an idea of what's happening. Explaining this to the client was the only real challenge. With most clients, we anticipated that this would be fairly straight-forward and, once they understood it, they'd actually find it fun!

As the project had a small project team of just one developer, one designer and one project manager, it went smoothly. There was no need to create work packages, assign features to individuals, track progress of each individual, and so on. One of the issues that arose in the FDD post-training workshop was the process's reliance on the chief architect. This project had only one developer, who played chief architect, chief programmer and developer. This was risky: if he was not good at his job, the project would be in big trouble. However, this is the case with all small projects: if you don't have a decent programmer, you're in trouble!

Overall, we saw a significant improvement in the project's progress on a number of levels, some of which were quite unexpected. The goal was to find a way to deliver projects more effectively, but what we found was that the effect on morale was much more positive. The simple fact that we had decided to improve the way we worked had a positive effect. The team was happier because we were doing something about the problems. The new approach also helped to bring together the different disciplines (development and project management in particular) who had previously not always worked closely. There was a palpable sense of focus and direction.

In terms of projects, there was also an improvement. Although most projects still had issues, the problems were lessened and easier to manage. It was much easier to get a real idea of where each project was at, and how much work had actually been completed. For instance, asking a programmer how they were going with database optimisation can lead to one of many responses, some of which don't necessarily answer the question the client asked: when will it be finished? That's not to say that programmers deliberately try to avoid answering questions, it's just that sometimes the questions are hard to answer: often, it's not easy to say when something will be finished.

This was a key benefit of the feature-driven approach. When a project is defined in terms of "features", some of the complexity is removed from the questions the client asks. A feature should require no more than two weeks' work, so when asked how long it will take the developer to finished a feature (assuming it's been started!), the developer should answer with a figure between 1 day and 2 weeks. This approach actually helps developers to manage themselves, and avoid trying to make project managers happy by telling them what they want to hear, rather than the truth.

Unfortunately, we were unable to monitor the long-term impact of the introduction of FDD. Within 6 months of the training, the dotcom collapse hit the company and we saw a number forced redundancies.