•  Important but not mission critical

There is no point in trying EDM on something unimportant - you will simply not prove anything. A pilot project must matter, though ideally not too much. After all, this is an attempt to prove a new way of doing things and wonderful though EDM is, it is not risk-free.

•  Low visibility

While your pilot project should be important, it should not be too visible. There are bound to be disagreements and challenges in adopting EDM, say when analytic modelers object to being held accountable for implementation of their models or when programmers resist allowing business users to maintain some of the rules. Like any disagreement in life, it will be easier to resolve these amicably if you are not (metaphorically) standing in the high street yelling at each other.

•  Non-time critical

Picking a project that is not time critical gives you a crucial advantage - you can re-do something if you realize too late you have misunderstood or misapplied something. For instance, some teams find that their first attempt to engage the business users in their own rule maintenance fails because the design is too IT-centric. They find they need to do more than just make the rules available to business users, they have to make the rules fit the way the business users think (this is one of the secrets of business user rule maintenance). Having the time to correct this kind of thing will make the pilot more valuable as it will show what can be done with EDM, not just what you happened to succeed in doing quickly.

•  Manageable scope

While I think this is a true statement for ANY project, not just a pilot, it is particularly important on pilot projects. Remember, you are trying to learn about the approach not just complete the project. A larger scope will force the focus away from learning EDM and on to the project itself.

•  Reasonable size

This is particularly important on the rules side. If the project does not require very many rules and those rules are neither complex nor volatile, it may be hard to see why you would use business rules and not just code something. On the analytic side this is less of an issue as often a single predictive model can make a real difference.

•  Staffed with experience people

Not only should you make sure you have some people who are experienced in your systems (the decision service you are piloting is certain to use data from, and perhaps interface with, other systems and services you already have), you should also try and have someone experienced in rules and/or analytics available if you are not. EDM is a very practical, straightforward approach but experience really helps.

•  Suitable

There is no point in picking a project where the value proposition of EDM does not resonate. Unless you have a system, service or process that needs to be made more precisely, more consistently executed or easier/cheaper to change (more agile), then EDM is unlikely to show any benefits. Pick a project that has, at its core, the need to develop a decision service that is going to add value. Pick something with lots of rules, rules that change often, rules that are complex or rules that should be owned by the business. Pick something where the "right" decision is something that changes and evolves over time. Pick something where you have, or can get, data that seems likely to help you predict something. And so on.