10 things that derail projects and using business rules to fix some - James Taylor's Decision Management

« Straight Through Processing for real | Main | Wish I was there... »

September 25, 2007
10 things that derail projects and using business rules to fix some

I saw this nice article over on TechRepublic on 10+ things that can send an IT project off the rails. It is a nice summary and it occurs to me that the use of business rules to manage and automate decisions can make a big difference to some of them.

The first one is, of course "#1: Sloppy requirements". As I have noted before, business rules are not requirements and the failure to recognize them as separate things causes some of the problems in requirements definition. The requirements are sloppy because they embed the rules that change and evolve. Using a business rules approach to manage business rules separate from requirements helps keep requirements cleaner and less sloppy (though you can still do a bad job of them, obviously). The use of business rules to manage decisions in this way also helps with "#4: Scope creep" as the rules can evolve and change and get more complex without impacting the main software development project or requirements scope. All of this helps with "#2: Schedule slippage" and "#3: Budget overrun" as one of the prime drivers for these two is the constant flux inherent in business rules. Separating them out and managing them separately helps avoid problems in them.

Two others are worth noting - "#6: Poor documentation" and "#8: Poor communications". The post talks about these in terms of poor project documentation and poor project communications, in which business rules cannot help much, but they are also relevant in a broader sense - if the business participants in the project cannot see from the documentation what is being built and are not communicated with, the project will have problems. The use of business rules to specify decisions means that business users can read and understand the business logic being proposed and even implemented, resulting in better documentation and stronger communication between the two "sides".

BTW I added a new category for posts about requirements as I seem to be writing more of them.

Technorati Tags: business rules, IT project, requirements, scope creep, business agility, TechRepublic