On Creating Successful Business Rules

Today, I attended a webinar by FICO called “11 Secrets of Creating Successful Business Rules” for which a recorded version should eventually be available (see www.fico.com/events). Here are some of the takeaways from that webinar.

[Update: 2009-06-26] The recording is available at: https://www106.livemeeting.com/cc/fairisaac/view?id=06242009


Some people oversimplify Business Rules Applications and make claims that may give a sense that business rules is easy, but we should be wary of such claims.

A developer may claim that they can write a certain number of rules per day but can the business user modify them? Are these rules documented and traceable to the original source of the rule? Could the rules be audited?

Others may claim that all rule engines are the same, it’s all in a spreadsheet. What about other types of rules such as decision trees, scoring models, etc. What about reuse of the rules?

A quick regression test of the rules is sufficient. Does a quick regression test check for missing conditions, overlapping rules, contradicting rules? With that level of testing are we reasonably certain that there won’t be some unwanted side effects to rule changes?

The 11 Secrets Of Creating Succesful Business Rules

I won’t go into all the details of the secrets here, but this should give you an idea. For the details, you can go to the presentation.

11. Select the right application

I’ve covered some of the characteristics that make an application a good candidate for rules before in this post, but in short: Are rules changing frequently? is there a short time to market window? Do the rules need to be maintained by Business Users?

10. Follow a methodology

ILOG and FICO have the same idea. Use an iterative methodology, RUP inspired. Start small and build bigger and steps.

9. Document, Document, Document

Detailed and rigorous documentation is required. Use document templates to make your life easier.

8. Manage Traceability

Make sure that the traceability to law, business unit and owner is documented as well.

7. Analyze & Establish Rule Quality

There are qualities of good business rules, conciseness and atomicity are the two qualities that were touched in this presentation. Hmmm… That gives me an idea for a new blog post…

6. Choose the right metaphor

Basically, use the right representation of the rules to fit the needs of the business. Drop down boxes? Decision tables or trees? Scorecards?

5. Validate the Rules

Have the business users configure and run test cases.

4. Perform Complete Verification

Verify the rule logic with tools, not manually

3. Simulate to Analyze Business Impact

This is to make sure that although the rules might be correct (see Secret 5.), that the effect of the changes has been measure to the fullest. What is the impact to the numbers in the end?

2. Structure for Reuse and Governance

Make sure that your business rules repository and processes allow for proper governance and management of the rules.

1. Operationalize Analytics & Improve Decisions

This is the item I am most unclear about. It seems to be taking simulations (Secret 3.) to the next level. Creating some mathematical models to estimate some pre-determined KPIs.

If you find this post somewhat interesting, I suggest you go see the recorded webinar.

[Update: 2009-06-25]

As I was browsing looking for something else completely, I stumble on the associated white paper from FICO which can be found here: http://technology.searchcio-midmarket.com/document;5136646/midmarket-abstract.htm

BPM Center of Excellence applied to Business Rules

I have to admit, that recently I have been looking for anything that mentions rules governance and management, and although this center of excellence webinar by Sandy Kemsley is geared towards BPM, I think there are common pieces that can be learned from and applied to business rules.

To put it in context, the COE usually comes into play once successful projects have been completed and the lessons learned and management processes need to be expanded to have a more global point of view for the whole enterprise.

Here is an excerpt of what is mentioned about the Center of Excellence (COE) for BPM.

The benefits expected from a COE:

  • Knowledge transfer
  • Synergies between projects
  • Shared code and components for reusability
  • Faster deployments
  • Lower costs
  • Standardized, repeatable projects

Based on survey by Forrester, the presence of a COE increases the success of the projects as opposed to not having a COE.

The functions expected from the COE are:

  • Skills. The knowledge and skill set is too rare to maintain in each project
  • Governance. The COE becomes the point of convergence for governance for creating common principles and methodologies
  • Repository. A common place for keeping training material, best practices and techniques, common code and components
  • Community. A place to share and discuss ideas and do problem solving and to shift points of view from project or departmental to global and enterprise level

 To build the COE, here is what is required:

  • Executive sponsorship
  • Methodology and best practices independent of technology
  • Co-location of the people to improve communication

The roles required in a COE (which I adapted for Rules)

  • Chief “Business Rule” Officer
  • Steering committee
  • Project manager
  • Enterprise architect
  • Business Rules analyst
  • Business Rules developer
  • User Acceptance Testing (UAT) and Quality Assurance (QA)
  • Business Rules Administrator

The webinar then goes into some case studies which are also very informational. Definitely worth a look if you are interested in Centers of Excellence and Governance.

The webinar on BPM COE can be found at: http://www.bpmbasics.com/resources/academy/bpm105.jsp

Update to ABRD published

Jerome Boyer posted on his blog about the latest update to the ABRD (Agile Business Rules Development) framework which can be downloaded at the following address.


I have used some of the contents of the previous ABRD release, although as a whole I thought it was not as good as it should have been (and yes, I know that it is meant to be improved by a community but I was not sure where it was going to go from there).

But this iteration of ABRD is better structured, and after a quick review, it seems to be of much better overall quality. As a starting point for people dealing with business rules, it might provide some insights and guidelines as to how to run a business rules project.

I only wish that contributing to it was a bit easier and more transparent and that people from companies other than ILOG would also contribute to it so that the best practices in ABRD have less of a bias.

There are still some holes and very simplistic descriptions used in some of the items, but the evolution from the first version to this one makes it a very promising tool for people that work on a business rules project.

On Business Rules project best practices – Part VII – Model and Vocabulary

This entry is part 7 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Of all the best practices listed so far, this is the one that I believe to be the most critical to the success of a rules project.

Why did I wait so long in the series to introduce it? Well, I could have started with it, but it is not the only best practice that needs to be considered and if the first best practice is being followed (Get help and educate yourself), hopefully the model and vocabulary will be one of the main things some external help will push for.


You can choose to skip this section and refer back to it when you encounter the word for the first time later in the article.

Before we continue with the rest of this article, it will be useful for me to provide some definitions that will be used in the article.

  • Term: a word or phrase used to describe a thing or to express a concept [1]
  • Concept: an abstract idea. Concepts are expressed by terms. [1]
  • Fact: Facts relate terms [2]
  • Fact Type: a fact type is an association between two or more concepts
  • Vocabulary: the body of words used in a particular language or in a particular sphere [1]
  • Terminology: the body of terms used in a subject of study, profession, etc. [1]
  • Fact Model: A fact model establishes the basis for shared operational business knowledge. [2] This model is usually graphical and can also be called the business object model or BOM.

The business vocabulary

Let me start with the vocabulary. This refers to the language being used by the business people to do their day to day work when they refer to what they are working on. It can also be called terminology [3]. In our specific case, we are interested in the vocabulary used by the business people, so we are referring to a business vocabulary. In the article I will usually use the shorter “vocabulary”, but it means “business vocabulary”.

Why are we talking about vocabulary? Because we need to formalize this vocabulary, clarify definitions and meanings to remove as much ambiguity as possible. This vocabulary will be used to create a fact model that will be used by the rest of the project and by the rules.

This formalized vocabulary needs to be well documented, agreed upon and communicated by the business people. There needs to be a central location for the documentation of this vocabulary.

Some will ask: I know my business, so why should I document and formalize a vocabulary? The answer is simple. Not all the people working on an IT project are as knowledgeable about the business, and ambiguity or misunderstanding of terms used by the business people can have unexpected results. I will try to explain more with a couple of examples.

I once worked with a customer that was in the importing and distribution of goods. One of the first things I usually try to do is to either look for an existing vocabulary (which did not exist) or to learn about the business to start building a vocabulary.

As I was learning about their particular business, the business person I was talking to referred to a “Purchase Order” (or PO) a few times and at some point I had to stop him and ask: “When you talk about the PO, which PO are you referring to?” He looked at me with a blank stare. “Well”, I continued, “when you place an order to your SUPPLIERS, you use a PO correct?” He simply answered “Yes”. I continued “Also, when your CUSTOMERS place an order to you they use a PO, correct?” He nodded. “Well then which PO are you talking about? The supplier PO or the customer PO?”

I will spare you the rest of the conversation in which we went on to clarify the vocabulary that they were using in that particular business, but that short conversation shows how something seemingly simple sometimes requires some clarification.

Both Purchase Orders had similar attributes but they also had specific attributes that made them different. These need to be documented well in any project, but specifically in a business rules project where some rules may need to refer to Purchase Orders and in that case we may need to know which one it is.

As a second (shorter) example

On a another project that I worked on dealing with the company customers, in discussions the business people were using the terms customer and client somewhat interchangeably. We needed to clarify if they were the same thing or if they were actually different things for that system. Once again clarification of the vocabulary was required.

The point to this exercise is that we need to document, formalize and clarify a vocabulary that will be used in the project. If there is confusion about a term, go back to the vocabulary, discuss it and if required, make the necessary adjustments since it is a work of progress after all.

Building the vocabulary

The vocabulary can be built using multiple techniques, but some of the usual ones are:

  • Interviews with business people
  • Review of documentation
  • Review of current systems

The vocabulary will be a work in progress and you should not expect to build it completely before starting other work. You should start building the vocabulary with the most common terms, and eventually put it aside to come back and add or update the vocabulary as needed throughout the project. It is an incremental piece of work (sometimes tedious) but essential to the rest of your rule project.

The model

Now that we have a vocabulary that the business agrees upon, it is time to start working on the model (sometimes called a fact model). This model is used to represent the main entities from our vocabulary (if not all) and their relationships to each other. This will be a very useful tool when trying to write business rules since it will graphically show what the business and the rules are about.

Here is an example of a simple model:

It may also be used to identify gaps in the current vocabulary as I will demonstrate below.

The model on the left shows the first pass at coming up with a vocabulary and building a model from it. It became apparent that there was a concept missing and therefore the vocabulary was amended to add the term “pet” of which Dog and Cat are types. The resulting model is shown on the right.

The model can also become the starting point for other work that will be required in the project such as a data model and an object model. So we could add additional information such as multiplicity between the facts as shown below.

All of these details will give the business a common starting point when discussing anything between themselves or with other people, especially IT technical people.

The Foundation for other work

When discussing the importance of the vocabulary and model when dealing with rules, I often compare it to the foundation for a house.

Having a good foundation for a house will allow building sound structure on top. Having a good vocabulary and model will allow you to build good rules.

Adding an extension to the foundation and structure of an existing house will allow the house to evolve and fit the new needs of the owners. Similarly, it is possible to add to a good vocabulary and model and eventually to rules and it is to be expected.

The danger lies in the inappropriate foundation of a house. If the foundation for a house is inappropriate and needs to be redone without touching too much of the existing structure, it is possible, but it is complicated and costly. The house needs to be lifted of the current foundation, the current foundation need to be destroyed, the new foundation needs to be built and then the house can rest on the new foundation again.

The same goes for the vocabulary and model used for business rules. If the vocabulary and model are not done properly to start with, it will be hard work to change it later, especially if rules have already been built using them.


Should you start with the model or the vocabulary? I personally like working the model and building the vocabulary that goes with it alongside. How you decide to do it in your environment is not that important. What IS important is that you DO actually create the model and vocabulary. These will be the building blocks of the foundation for a lot more work in the future. If you don’t have it, your foundation may be too flimsy to support that future.

[1] From askoxford.com, oxford dictionaries

[2] Ross, Ronald G., Business Rule Concepts, 2005, Business Rules Solutions

[3] Terminology denotes a more formal discipline which systematically studies the labeling or designating of concepts particular to one or more subject fields or domains of human activity, through research and analysis of terms in context, for the purpose of documenting and promoting correct usage. From wikipedia.

On Business Rules project best practices – Part VI – Divide and Conquer

This entry is part 6 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Divide and Conquer

Once you have scoped the full project size, it is now time to divide it up in to smaller pieces that are easier to manage and develop. In essence this is “Divide and Conquer”.

There are many advantages to taking this path. First, should there be enough resources available, multiple pieces of the whole might be able to be worked on in parallel. Second, each piece or phase of the project will allow teams to work on goals that are easier and faster to attain and that work toward the ultimate goal.

Working in parallel

Depending on the nature of your business rules and the availability of some key resources, it may or may not be feasible to work on parallel streams to complete multiple pieces of the project at the same time. But in some cases it might be beneficial, and when depending on the project manager and the timeline you have to respect, this may be a good option.

The only caveat I have to mention about working in parallel is that it is better to have completed the prototype or pilot before attempting this. This way, your lessons learned and knowledge from this first experience can be leveraged accordingly.

Smaller goals

The journey of a thousand miles must begin with a single step. – Chinese proverb

Working on smaller goal will help teams build confidence and knowledge on what and how to do perform the activities required to attain the goals. They may decide to readjust some of those activities based on lessons learned and the whole project will benefit from this experience. The teams and the rest of the organization will see progress and the completion of each phase will be yet another milestone towards a successful project.

How to divide and conquer?

At the project level

There are many different ways of dividing the business rules projects and how you decide to do this in your own project may differ from the following, but here are example options:

Divide by:

  • Subject Area (or domain). If the business rules in the subject areas have little or no co-relation, this may be a first level of division.
  • Sub-domain. Some domains are large and may be composed of sub-domains that may be easy to separate from each other.
  • Business Process. Depending on the size and complexity of the business processes, the business process might be an appropriate chunk to separate for a project phase.

At the rule harvesting level

Although the details of the steps to follow during a rule project will be detailed in separate posts, the rule harvesting portion of a project may also be divided into pieces depending on resources, and the number of rules. The following suggestions are inspired by a presentation made by Gladys Lam at the Business Rules Forum 2008[1].

Divide by:

  • Business Process. If the business process has few business rules within its tasks and decision points (50 rules per task)
  • Task: If there are more than 50 rules per task
  • Decision Point: If there are more than 100 rules in the tasks.

In short, if the work is broken down into smaller manageable pieces, your chances for success will be increased.

[1] Lam, Gladys S.W., Organizing a Business Rule Harvesting Project: Divide and Conquer, Presentation made at the Business Rules Forum 2008

On Business Rules project best practices – Part V – Plan the project

This entry is part 5 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Some people may find it weird that project planning is suggested so “late”, but there is a good reason for it. Any planning performed before the completion of a prototype or pilot will have to be reviewed to take into account the information gathered during the execution of the prototype so although some of it may have been done already, now is the time to actually do the planning.

Plan the project

So there you are. The prototype or pilot is completed and works. Your team understands much better what they are involved with. The organization feels confident about this new technology and way of working.

With their newly acquired knowledge and experience, now is the time for the project manager to review the scope of the project, identify missing tasks, update estimates and resources required to actually perform the rest of the project.

Here are some questions that the project manager may want to ask himself or his team:

  • What are the (updated) processes and tasks required to complete the project?
  • For each task, what are the estimates on resources required as well as time required to complete the task?
  • Which tasks can be performed in parallel or independently from each other?
  • Can we break this project up into smaller pieces (see the next post on this subject)?

After that exercise, the project manager will have a much better idea on all the details of the project and then the work can proceed.

Although this “Best practice” post is a short one, it still needed to be mentioned. Project managers should be able to take this “best practice” and make it their own.

On Business Rules project best practices – Part IV – Build a prototype

This entry is part 4 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Build a prototype

Building a prototype serves multiple goals that will help you with your project.

First it will serve as a real life starting point for your team to get acquainted and more knowledgeable about the processes and technologies involved in the project. Second, it will serve as a test for the architecture that is proposed for the system you are building. Third, it will accomplish something tangible that your team and the rest of your organization can see and touch and really discuss.


I covered this in the previous post on the topic which you can see here, but it is worth mentioning it again. There is a good chance that your team will not have all the knowledge it requires to work on the project at the beginning. This prototype* or pilot* will serve them well as a step to acquiring the knowledge they need for the rest of the project. You will need to take this into account for this phase of your project.

You first need to identify the key people that you want involved in this portion of the project. This prototype or pilot will serve as a learning tool for those people and they will become references to other people in your team later on.

With some outside help, this team will start working on the prototype and learn more about how to use the product, how the product relates to other components of the architecture, what needs to be done, in what order, to what degree of completeness, etc. This knowledge and experience is usually specific to each organization, so they will need to learn how to do things and then prepare checklists and processes that will make all of this work in the organization.

By no means should these processes and checklists, etc. be set in stone, but it is a starting point for future work and will need to be adapted as new situations arise.

Once the prototype is completed, the people involved will become references for others that will be joining or expanding on the project. They might become advocates and evangelists for the project and the technology.

Although the focus has been on getting the team to gain the knowledge, another person that will benefit from this exercise is the project manager. They will get to see what is required to succeed in the full project. The team he is working with will also be able to help the project manager with the planning phase of the project since their estimates and comments will be based on experience, not on guess work.

Validating the architecture

Having a business rules project usually means changes to an existing architecture or a totally new architecture (in the case of a legacy system replacement for example). The prototype will serve as a test for this architecture. The focus should be on the “happy path” making it work is of the upmost importance. Dealing with exceptions and special cases should be delayed as long as possible since it will add little value if the architecture doesn’t work in the first place.

The team that will work on the prototype will have to deal with most of the technical issues to make things work. But once they have worked through this, it should prove that the architecture works and that it is something that can be worked with in the future. Of course, you should expect some adjustments to be required, but it should be considered somewhat of a rubber stamp on the direction that was taken.

During this phase of the project, you should also expect to have to perform some proofs of technologies* or short tests to prove the technical feasibility of one technical option or to help choose between equivalent technical options.

A starting point

Once the prototype is completed and operational, some debriefing of the team needs to take place to learn from the experience, document that knowledge and to prepare for future phases of the project. This is a time for reflection on what worked well during the prototype and what didn’t. Outcomes from this should be lessons learned, preliminary processes for future development and a list of skills and knowledge required to succeed, etc.

The prototype can also be used to communicate to others in the organization. It can be used to excite people about the new architecture, new possibilities and business rules. Other people in the organization will be able to see what “it” looks like, how it works, ask more specific questions, etc.

All in all, the prototype serves as a learning tool, communication tool and architecture validation tool, and all of those are good things.

On Business Rules project best practices – Part III – Scope the project

This entry is part 3 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Scope the project

Project managers always work with the “triple constraint” of scope, time and resources and this is the first component of these constraints. It basically answers the following question: What needs to be done?

All project managers should be very knowledgeable about “what needs to be done”, but what we want to extract as a best practice for a business rules project is actually related to other best practices.

One of the first pieces that needs to be focused on is the “build a prototype” best practice (coming soon to a post near you!). In a business rule project we will want to build a prototype or pilot. So part of the current scoping exercise is to try and identify a piece of the pie that will be sufficiently large to be of use, yet sufficiently small so that it is manageable as a first step in this type of project.

The biggest challenge here is probably not to identify which pieces of the business rules can be used in the prototype, but which pieces are required to make this prototype work.

  • Which pieces of the complete architecture needs to be in place for the prototype to work? 
  • Are there other choices that minimize the number of architectural components that need to be involved?
  • Can we build on the work of the prototype for subsequent phases?
  • And eventually, what is the effort required for the implementation of this prototype?

In short, we need to scope the project as a whole, but also to identify and scope what is required for a prototype to work. We will eventually look at this scope again with the experience of the prototype behind us and re-evaluate the scope and plan the project.

[Addendum based on James Taylor’s comments, 2009-02-14]

James Taylor wrote a comment on this and I think that it is a very good point and decided to add it in to this post.

Focus on the decision(s) you are automating. Start with the decision in mind and it is a lot easier to determine if a given rule source or collection of rules is going to be relevant. 

Yes, decisions are the starting point of it all. This advice will help guide you in your project. (And yes I am becoming partisan to the idea of decision management… 😉 )

Scope the business rule harvesting

One of the new pieces of the project that needs to be scoped in a business rules project is the business rules harvesting effort. This is something that you will probably need help in doing the first time around and is important enough that it needed to be discussed separately.

In a webinar called “Scoping a Business Rule Harvesting Project: What Questions Should You Ask?”[1] available on the business rules forum web site, Gladys Lam presents many questions that need to be answered so that the scope of the business rules harvesting work can be established. The webinar is definitely worth a look, but I will repeat some of the questions here:

  • What are the objectives for the business rules harvesting?
  • What types of rules are present?
  • Is there subject area (domain) knowledge available?
  • What are the sources of the business rules and how easy are they to understand?
  • How many rules are expected?
  • Is there a consistent vocabulary (terminology) and model being used (and enforced) today?
  • What is the experience in rule harvesting of the people that would be involved?
  • How many review cycles are used? Who are the key players?
  • What are the traceability requirements?
  • How complex are the rules?
  • Do the rules need to be re-engineered?
  • What tools will be used?

Answering these questions will give you some of the information required for scoping your business rules harvesting project and will help you evaluate your need for external help.

[1] Lam, Gladys S.W., Scoping a Business Rule Harvesting Project: What Questions Should You Ask? Webinar available at http://www.businessrulesforum.com/webinars_active_viewing.php?view=375


On Business Rules project best practices – Part II – Help and Education

This entry is part 2 of 7 in the series Business Rules Project Best Practices

In my previous post, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Get help and Educate yourself and your team

First, if the organization is new to business rules, get help. Chances are guidance will be required and hopefully will help you succeed with your project. Yes consultants can be expensive, but they can help you avoid some of the pitfalls on this type of project, and if you make sure your team stays close to the consultants, they should be learning so that you will eventually become independent.

This brings me to my second point. Educate yourself and your team. Yes there is a cost to upfront classes and education (in time and $) but it will hopefully help you get the most out of your rules project. The formal courses, book readings and other resources available around should give you a kick start and then working with some experienced consultants should complete this education as well as give you some practical experience within your specific environment.

Why did I combine these two topics? Because the people you get to help you should also be there to educate you with their practical experience and knowledge similarly to some mentoring.

The reasoning behind this

Of course, being a consultant and instructor myself probably gives me a bias towards this, but I will point out why I think this is important with some details below.

Suppose you are starting a project and as you are evaluating your requirements, you realize that you will need a business rules engine (BRE) (I will focus on BRE here, but this may also apply to BPM as well). Now since you are new to this technology, you start reading on the subject (which is great), and start looking at the different products out there. You might even want some of them to come in and present you their products in demos (or through webminars), etc. Because of time and effort constraints you will probably limit yourself to some 3 or 4 products and your eventual choice would be based on their presentation and marketing material. Since you are new to this technology, you might not make the right decision. Getting help at the stage of the evaluation will hopefully provide you with an unbiased opinion and make sure that your choice is based on a more educated evaluation of the products in comparison to your requirements. You might be able to get away with not getting outside help for this part, but getting help would give you a sanity check.

Now that you have selected a product or a shortlist of products, it would probably be beneficial to ask the vendor(s) to do a proof of concept* for you. This proof of concept should be a relatively simple list of requirements that you have and you want to see how each product will respond to your requirements. The help you would get from an outside consultant here would be to keep a close eye on how each product is actually responding to your requirements, and help you identify places where you should ask more questions. This is also a time where you need to educate yourself more about how each product is going to require you to work in the future.

Next you select a product, and hopefully it is the best product to fit your requirements. The best thing for you to do is to educate yourself on that product. Identify the team members that you will want to be part of a prototype* or pilot*, that is the business analysts and developers that will be involved and send them on the appropriate courses provided by the vendor. This will give them a kickstart on the product and hopefully, working on the prototype will allow them to assimilate these new skills faster. This team will also become the internal experts, and possibly evangelists and teachers for the future phases of the project.

When working on the prototype, get help from either the vendor professional services and or outside consultants so that you learn how to do things using the best technique. This prototype is an excellent opportunity to improve on the skills of the team you trained and to give them the knowledge they need to take this over in the future. Your team will be learning from the consultants and be executing some of the work.

There is always more to learn, but this route should be taking you to the path of independence from outside consultants short of getting more manpower to execute some of the work faster. The need for consultants should reduce over time except when you have very specific challenges that require specialized knowledge to accomplish.

A sample timeline

The following graph displays a sample timeline for a business rules project from the help and education perspective. The scales used are arbitrary and used for demonstration purposes only.

Help And Educate Sample Timeline

Help And Educate Sample Timeline Legend

First, the red line shows that the internal team starts small, eventually grows to involve the staff required for the prototype (or pilot) and then grows further when subsequent phases of the project continue to proceed. It shows what happens during a project, and not what would happen after the end of the project, where the internal staff might be reduced to fit only what is required for operations.

Second the blue line shows the involvement of external consultants. They get called in early in the project as to guide the team in the right direction. We eventually see a progressive withdrawal of the consultants once the project is well under way, with specialized interventions when there is a need for them.

Third, we see a Green line that might show additional manpower required to achieve some of the work in the timelines set by the project. This is an optional involvement that is required only if the internal staff is not sufficient to meet the deadlines, etc. This does not suggest that extra help will absolutely reduce timelines, the usual laws of adding people to a project still apply, but sometimes external help is required.

Finally, in purple, we see the evolution of the internal knowledge of the team that is involved. This is also for demonstration purposes and does not intend to imply that the team will not learn what they need faster (or slower).

In summary

  • Get help: to start in the right direction and to learn from people with experience.
  • Educate yourself: to be more efficient and to be autonomous sooner

On Business Rules project best practices – Part I – Introduction

This entry is part 1 of 7 in the series Business Rules Project Best Practices

Over the years I have seen things go well in projects that involved business rules, and I also have seen things go not so well. I am sometimes asked for “best practices” or practices to avoid, so I figured I would document some of them in the series that will follow.

In this post, I will introduce the best practices that I will cover in more details in future posts. Please note that some of these best practices can be performed in parallel to other ones and they are not necessarily presented in order. Whenever possible through the series I will provide references for what I write.

Here is a global view of the practices

Whenever I can I will refer to other articles and resources that complement the contents of the best practices.

During this series, I am hoping to get some questions and comments that will help improve the contents of the posts, this blog is hopefully going to become an interesting resource on the topic.

*This best practice is to me the most important stepping stone to a successful project. It is introduced later in the series, but if you were to choose only one of the best practices, this one would probably have the largest impact. Some will disagree with me but then again, this is my opinion… 🙂