Total Cost of Ownership of BPPM - Part 16: Best practice - Consistency

In my last post, I talked about documentation.  As important as it is, it is impossible to document every little thing in your BPPM implementation.  Being consistent in your BPPM implementation can reduce the ongoing maintenance and support cost without excessive documentation.  A consistent approach can go a long way to reduce the total cost of ownership of BPPM.

Recently I talked to a consulting firm who just won a BPPM migration project.  They decided to use their budget to hire an intermediate-level consultant and an entry-level consultant and send them both to work on the project at the same time.  I personally would rather use the same budget to hire one expert-level consultant not only to reduce communication channels, but to enforce consistency in the entire project.

What kind of consistency are we talking about?  Here are just some examples for the purpose to get you to think more.

1) Design consistency: Do you have a UAT system that is set up as identical as possible to your production system?  If you encountered errors in your production system, can you quickly reproduce, debug, fix, and test in your UAT system? Do you have a consistent name convention for various components (cell names, file names, locations, etc.) in your environment so your maintenance staff will know exactly what and where each component is without checking the document every time?

2) Configuration consistency: When you create those monitoring policies in CMA, do you always follow the same approach such as a base policy followed by special case overwrite?  Do you limit one monitor solution per policy?  Do you name all your policies consistently so that your maintenance staff can tell what each policy is for without taking 5+ minutes to read it?  Do you keep the same copy of mcell.dir for all you BPPM cells?  Do you try to control all your event blackout in one place instead of everywhere in your system?

3) Coding consistency: When you develop your MRL rules for BPPM cell, do you limit one rule phase in one MRL file?  Do you always prefix your custom files to distinguish them from BPPM out-of-box files?  For events you no longer need, do you have a consistent decision over the choice between using filter rule, using refine rule with 'drop_new', and using refine rule with '$EV.status = CLOSED"?

4) Documentation consistency: Do you use the same templates when writing documents?   Do you always provide release notes and deployment guide?  Do you use screen shots consistently?  Do you always provide verification steps?