Delivering Real Business Value using FDD - Page 4

By Grant Cause, IT Project Services Pty. Ltd.

FDD lends itself readily to the use of repositories or knowledge bases of information and the publishing and dissemination of that information which ensures high visibility and reporting of results. These range from simple pen and paper solutions through to enterprise level solutions where all project stakeholders can see the project progress reports.

FDD consists of just five processes as follows:

Figure 6 - FDD Model / Copyright © 1997-2004 Jeff De Luca

As can be seen in Figure 6, FDD has two phases - a start-up phase and a construction phase. Each phase has a series of processes associated with it and each process has one or more deliverables associated with it. The start-up phase is short and once off whereas the construction phase is made up of many short iterations (between 1 and 10 days) which together may last many months.

The start-up phase consists of the first three processes.

The first process is to develop an overall model, here technical people work in collaboration with domain experts (usually business people) to derive the shape of the system to be built.

The second process uses the information derived from this modeling activity the team produces a categorised list of features. The categories used are:

Subject Area -> Business Activity -> Feature

In the third process a plan is derived from the features list and features are assigned to class owners who then take responsibility for them through to their implementation. When planning an FDD project the basic rule of thumb is that for every week spent in the up-front design process there will be 3 months of development time required to build the system.

Once the planning process is complete there is enough information for the business to make a go or no-go decision on the project.

By conducting these first three processes the business now has a low-cost, high-value, low-risk assessment as to whether there is a real business case to develop a solution to solve a particular business problem. These first three processes have also taken a very short amount of time to achieve - typically weeks. With all this information in mind the business can now make a well informed decision as to whether to proceed with the project or not.

The construction phase consists of two processes.

Design by Feature and Build by Feature, as their names suggest means there is an initial design process followed by a build process. It is in this design stage that the details of the object model are fleshed out in collaboration with the customers' domain experts. Once all the details have been identified a design is finalised and then inspected and once passed the solution is built and then inspected again before being promoted into the build.

Note the term "promoted to the build", a feature is not considered complete until it has been promoted. That is it is now working software ready to be tested by the customer. It is not half-working, it is not nearly there, there is nothing whatsoever left to do on this feature except for the user to test it.

When FDD says a feature is complete it means it. Developers tend to have a problem with this concept, it is too black and white for them. If you ask a developer if he has finished a particular feature you might get some answer like "Yes its finished, but I just have to do..." this answer means it is incomplete - it will not be promoted to the build. Once the developers get through the first few iterations they quickly realise what the word "complete" means and what it really means to promote something to the build.

By having this "promote to build" milestone FDD reduces the risk of a project failure by ensuring that only working software is ever produced and provided to the business.

Conclusion

I know this has only been a cursory look at FDD but even though it is a simple methodology with only 5 processes the depths and nuances that it contains can be quite complex to describe. Indeed books have been written on FDD and even they do not cover all the details. This isn't surprising given that FDD is drawing on 30 years of industry experience and best practices and Jeff De Luca's own insights into how to make best use of them.

I hope this article has given you some insight into its value as a methodology that truly does deliver real business value.

How FDD delivers real business value that can be broadly categorised via the PRAISED items I mentioned earlier.

P roductivity gains	Short release cycles with short iterations that deliver working software. Focused development efforts through the use of features and workpackages.
R educed cost	Higher chance of project success by involving the customer in every aspect of the design. Being able to develop business systems in a way that allows the business to quickly react to changing conditions in the market.
A voided cost	By finding problems early through inspections. The high cost of "Analysis Paralysis" is avoided. Project success rates increase avoidingthe cost of failed projects which have to be restarted or abandoned.
I ncreased revenue	Having business systems delivered to the business in a timely manner allows the business to get on with its core business and react quickly to market trends.
S ervice level improvements	Having good systems enables the business to better service its customers. Employees enjoy a working environment where business systems support their ability to perform their jobs.
E nhanced quality	The use of inspections means the quality of the business solutions delivered to the business increases.
D ifferentiation in the marketplace	Being able to deliver on promises to customers by having business systems that support the core capabilities of the business in a timely manner.

I said at the beginning of this article that I will let you draw your own conclusions as to whether this methodology is right for you and your firm.

All I can do is tell you that it has worked for us. Since adopting this methodology we have had a number of successful projects delivered on-time, to-budget with agreed functionality.

Although we had of course done this in the past, we had never done it with such ease as we have experienced when using FDD. In the past it was always a constant struggle to collate all the information to produce reports for our clients, in some cases it would literally take days to produce these status reports. Now it takes us only a few seconds to print out these reports based on the data we have constantly kept up to date in our FDD knowledge base product.

Since adopting FDD we have had clients compliment us on how well our projects have been run and in particular how we have been able to engage everyone from their organisation in their projects. Our clients have told us how pleased they are with the finished results and how sure they are that the finished results will deliver real business value to them for many years to come.

For my business FDD is definitely the way to do projects. We have only just begun implementing the methodology. There are many more techniques and best practices it contains that we can adopt and adapt that will enhance our ability to deliver real business value to our clients.

And in the end anything that allows us to deliver real business value to our clients is welcome in my business. After all if our clients are doing well, then so are we. FDD has certainly been a welcome addition to our business.

For further reading on this subject I would suggest the following web pages:

www.featuredrivendevelopment.com	The FDD community webpage. It has discussion forums, resource pages and further reading.
www.nebulon.com	Jeff De Luca's company home page provides details of the FDD processes as well as training courses and further reading.

Thank you for taking the time to read this article. Your feedback is always welcome.

References

Jeff De Luca is the original inventor of FDD he runs his own consultancy based in Melbourne, Australia see www.nebulon.com for more details and further details on FDD. Jeff has kindly allowed me to usesome of his artwork for this article and has provided some editing of this article.

Copyright © 2004, IT Project Services Pty. Ltd.

---

More Agile and Scrum Project Management Knowledge

Scrum Expert

---

Return to Page 3   Back to the archive list

This article was originally published in the Winter 2004 issue of Methods & Tools