When I was reading Scott Ambler's book, The Enterprise Unified Process, he had some great tips for picking a pilot project that I thought I would shamelessly steal and adapt for a discussion of pilot projects for enterprise decision management or EDM. Scott suggests 6 points:
- 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.
To Scott's list I would add
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.
I would also suggest trying business rules or predictive analytics first rather than trying to adopt them together and considering adaptive control a nice second project, though I would always build in some adaptive control infrastructure before using rules and analytics together.
One last comment. It often surprises me how many EDM projects I come across that we mission-critical and very visible yet were also a company's first. Part of the reason for this turns out to be that these companies have tried other approaches, often repeatedly, without success or have seen firsthand the impact of a lack of agility in their systems. In these circumstances the issue is not so much conducting a pilot as keeping the company in business! Remember, these guidelines are for picking a pilot - a first project designed to prove the value and effectiveness of EDM and to learn about it. Successful EDM projects often lack many of these characteristics - they just don't make good pilots.