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.

Knowledge

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