Delivering Real Business Value using FDD

By Grant Cause, IT Project Services Pty. Ltd.

Introduction

I run my own bespoke software development consultancy firm in Brisbane, Queensland, Australia. I first ran into Jeff De Luca the inventor of the Feature Driven Development methodology about a year ago where he was a guest speaker at a seminar organised by Borland.

I have been in IT for about 20 years now and have heard many people speak on software development methodologies from Waterfall to Extreme Programming. So I guess I was a bit jaded when I went into this seminar, thinking "oh no, not another methodology". To my surprise this wasn't to be the case. In just under an hour Jeff De Luca convinced me that FDD was the way of the future for all software development my firm would be conducting.

The reasons for this are many:

1. At its heart the methodology talks Business and delivering real business value; my firm has differentiated itself on this very point since we first started. So this instantly appealed to me.
2. FDD doesn't rely on gimmicks such as "pair programming" to get the job done and deliver real business results. Instead FDD was just formalising the use of the existing "best practices" we had been using for years. Don't get me wrong, I believe Pair Programming has its place in software development, I just believe it has been abused and its intent confused over time. It should not be overused but used where needed
3. FDD is a simple methodology, it only has five processes. It is easy to adapt and adopt the methodology to suit most projects. And despite its simplicity it is also quite thorough in its coverage of the software development lifecycle.
4. FDD is not some theoretical methodology. It comes from real life experience and has been proven in the field many times over, over many projects, over many years. Put simply IT WORKS!

I certainly do not purport to be an expert in Feature Driven Development having used it for only about a year now. Nor am I an evangelist for FDD. Software development is not a religious experience despite what some people would have you believe. The purpose of this article is simply to introduce the methodology to you and to share my real world experiences in adopting this methodology for my own consultancy firm.

I will let you draw your own conclusions as to whether this methodology is right for you and your firm.

What is Business Value?

Businesses these days are under extreme pressures from all sides. The pace of business has quickened thanks to advances in more efficient business practices and technology. Businesses don't have the luxury of time that they once had to run large projects and wait for the results to come out at the end. If they did this now, their businesses and their markets would have moved on and the results they were waiting for may no longer be meaningful or relevant.

Businesses are quite simply looking for one thing, RESULTS! These results generally involve some monetary quantification i.e. they can be measured in real dollars. In general the results the businesses are looking for can be broadly categorised as PRAISED items as follows:

P roductivity gains
R educed cost
A voided cost
I ncreased revenue
S ervice level improvements
E nhanced quality
D ifferentiation in the marketplace

If a software development project can deliver on one or more of the PRAISED items then it will have delivered real business value back to the business as a whole. PRAISED items are not part of FDD - it is something I have learned over 20 years about delivering real business value back to businesses.

Many consultancy firms take the wrong approach to delivering real business value. They try and force a piece of technology onto a business with little or no understanding of the business as a whole and the impact that technology will have on the business. Some of this can also be self-inflicted by the business in its desire to gain a competitive edge and have the latest and greatest innovative new technology implemented within its firm without thinking through all the implications of doing so. We will see shortly how FDD avoids this classic mistake from happening.

Another common mistake many consultancy firms make is that they tend to talk technology to business people whom, because this is not their area of expertise, are unfamiliar with the language of technology and all its three letter acronyms. This tends to lead to a lot of confusion and frustration on both sides as they are unable to communicate effectively with each other and as a result fail to get the results they are both looking for. FDD has built in naming templates that avoid this breakdown in communication and allow both parties to use a common language.

As I stated earlier FDD instantly appealed to me as my firm prefers to take a business first approach also and talk business to business people and then technology to technical people once we fully understand the business and its unique business problems. As a result we often take on the role of the trusted advisor acting as the go-between between the business people and the technical people who find they can suddenly communicate in more meaningful ways and achieve results they never before thought possible. Now that we have qualified what we mean by business value we will now explore how FDD delivers on and relates to this.

FDD and Business Value

FDD has as its basic tenet that the features being delivered in a software development project must be "client valued". That is, they have to have some real tangible benefit to the business to be considered as part of the feature list for that project. Generally if it doesn't have some business case behind it, then it should not be considered as a feature. FDD also reflects business value in the way the feature list is categorised and broken down into a hierarchy of business activities. These business activities are sets of features ("client valued" items) that will be delivered by the project to the business.

This means that when a business person looks at the feature list everything on that list will have some meaning to the business as a whole. For a technical person one of the most frustrating things is to expend time and energy on building something only to be told by the business person "oh that's not what I wanted". Having the business people involved in helping to define the feature list of what is to be built helps avoid this situation.

FDD is an all inclusive methodology in that all the stakeholders in a project get involved in developing the feature list; that way there are no surprises for any of them when the thing is finally built. FDD is not only inclusive at the up-front design and planning stages but all the way through the software development lifecycle. The reporting mechanisms are for all involved.

The design is on-going and iterative involving everyone. By being inclusive the methodology ensures that real business value is delivered as everyone is firmly focused on and working towards the same set of goals.

FDD is also an agile methodology; remember what I said before about a business not being able to wait a long time for results. FDD defines its features as anything that can be built in 1-10 days effort. Anything larger than this is broken down further until it meets that rule. The emphasis is on as granular or fine-grained features as possible. Thus, most features are about 1-3 days of effort.

The FDD development cycle is dependent on how often you choose to do the release meetings - the checkpoint that collects dates and publishes all the reports, etc. We will typically meet with our development teams first and then meet with and report to our clients on a weekly basis. This depends on what we agree with both the client and the development team. We generally run a two week release cycle where we do a build of working software which we will then make available to the end-users for testing. Only the items that have made it to the FDD promote to build milestone will be included in the release.

From what I have observed most FDD projects typically use a two or three week development cycle. Because of this short development cycle the business gets its results quickly. At each steering committee meeting the business people get used to hearing the word "complete". And when FDD mentions the word "complete" it really does mean complete - the feature is now ready to go into a businesses production environment. This is great for getting management buy-in into the methodology.

Being an agile methodology FDD has an emphasis on producing working software.

Usually traditional "waterfall lifecycle" projects have suffered from a fatal condition known as "analysis-paralysis". I say fatal because research has shown that 80% of projects don't actually get past the requirements definition stage. In the Chaos report published in 1995 by the Standish Group, 15% of the projects they studied were considered a success this only rose to 34% by 2003

In the past, they would wait and wait for wads of documentation to be completed before any real results are produced, consequently they would get frustrated by not being able to service their business needs and cancel the project and start again.

With FDD they start getting used to seeing working software instead of wads of documentation and as that working software is rolled out they start realising the business results and consequent business value they were really looking for in the first place.

Page 2   Back to the archive list