Implementing a new way of doing things is much harder than it sounds. People don't like change, and even those who say they're willing to give something new a go can quickly change their minds and revert to the old way of doing things. Because of this, we knew that we as a development team would only get so far trying to apply FDD ourselves. Sooner or later, it was going to affect the project managers and eventually clients. We decided it was better to get everyone involved up-front to increase our chances.

The next step was all about internal politics and getting the key decision-makers on side. As FDD is simple to understand, it wasn't difficult for people to see that we would be better off if we used this approach. On this basis, we obtained the funding to run a training course. Attending the course were representatives of all the groups that would be affected by a new methodology: developers, business analysts, project managers, a designer and a tester.

At the end of the course, everyone was keen. In particular, the following aspects of FDD stood out as providing solutions for the symptoms we suffered:

• Excellent reporting and planning

• Disciplined and clear

• Customer-focused

• Risk reduction via:

  • iteration of design and build in small chunks

  • clarity of requirements

  • better understanding of the system to be built

  • no wiggle room, as fewer assumptions would be made

We also realised that FDD wasn't going to be the complete answer to our problems. FDD covered development well but it didn't address the tasks of gathering requirements, interface design or testing. The things that concerned us about applying FDD were:

• its high reliance on technical leads

• it didn't deal with User Interface design and build

• it was less powerful on smaller projects than on large ones

• it didn't cover testing and deployment

FDD was not a silver bullet! In the end, we were going to have to adapt the process to our situation and needs.