Recently I have received several questions regarding to the high level technical information to help determine if BPPM is the right monitoring tool for an IT organization and if so how resources should be planned.
Realizing majority of the information out there is more for marketing purpose, I thought it would be beneficial to address some high level technical key points in BPPM that marketing people don't know how to talk about and technical people don't want to talk about.
As you may have known, BPPM is not one single product but several products integrated (or 'stitched') together. The core components of BPPM include PATROL, BMC Event Manager (BEM) & Service Impact Manager (SIM), and ProactivetNet. Each core component was a separate product acquired from a separate company at a separate time in 1994, 2003 and 2007 respectively.
BPPM made its first release 8.0 in 2010. In 2014, BPPM (BMC ProactiveNet Performance Management) was re-branded with a new name called TrueSight (BMC TrueSight Operations Management) after integrating with another acquired product 'TrueSight IT Data Analytics'.
Since BPPM 8.0, BMC has made several releases. The current release is 9.6. Between 8.0 and 9.6, BMC made major architecture and feature changes in release 8.6, 9.0, and 9.5. When a new release contains major architecture changes, it means that you cannot take advantage of the new features available in the new release without re-implementing the most part of the existing BPPM implementation.
When trying to understand any monitoring software for your IT organization, there are primarily five aspects you need to look into:
1) Implementation (both new implementation and upgrade)
2) Development (adding or modifying features not available out-of-box)
3) Integration (integrating with other monitoring software and ticketing software)
4) Administration (configuration and troubleshooting on demand)
5) Operation (performing pre-configured actions repeatedly)
You need to consider all five aspects for technical information when making a decision on purchase and resource planning. Of course, you need to consider other non-technical information too such as support, documentation, license cost, etc.
In the next few posts, I will go into depth sharing my experience on these five technical aspects with you.
Monday, March 30, 2015
Monday, March 23, 2015
Project Management in BPPM Implementation - Part 8: Common mistakes in BPPM project management
As the final post in project management series, let's talk about the common mistakes in BPPM implementation projects. Those common mistakes cause BPPM implementation projects behind schedule, over budget, and not meeting the business requirements.
1. No planning phase: This mistake is usually seen with new BPPM customers. Many new BPPM customers start BPPM implementation by immediately jumping into installation without architecture and capacity planning. 9 out of 10 times, whatever they had installed ended up being uninstalled and reinstalled after they eventually figured out the right architecture and capacity.
2. Not planning the initial implementation phase based on available budget: This mistake is usually caused by unrealistic expectation. For example, one BPPM customer I talked to wanted to complete the entire BPPM implementation on $23K budget. If you scale down the initial implementation phase on both features and deployed servers to fit available budget, you can have a small but working BPPM implementation in production. Once BPPM starts adding values in your business, you have a much better chance to receive more budget for the next phase. A BPPM implementation that had to be stopped half way when running out of budget is a big waste of time and money.
3. No WBS (Work Breakdown Structure): This is usually caused by lack of BPPM implementation experience. Without WBS, it is very difficult to track progress and forecast schedule/budget. Not only you need to know what tasks each work package should include, you also need to know how to verify the completion of all tasks in each work package.
4. Hiring one external resource to implement multiple product lines: Each BMC product line has its unique best practices and complexity. It is rare that one consultant who has top expertise on both BPPM and another product line such as ITSM. Just as you see separate doctors for your dental and vision needs, it is much better to hire different resources to implement different product lines.
5. Hiring multiple external resources to implement single product line: Many people believe doubling the number of people in the project will cut the project time in half. That is not true in BPPM implementation. First, more resources increase the number of communication channels as the number of communication channels = n*(n-1)/2. More importantly, due to rapidly added new features and the uniqueness of each IT environment, 'road bumps' are inevitable in your BPPM implementation. Each 'road bump' can delay your project in several days. When you have multiple external resources, each one of them needs to go through the 'road bumps' individually. Having a single external resource can minimize the delays caused by those 'road bumps' thus minimize the total number of man-hours (cost) to complete the project. It is better to use internal resources for on-demand help such as PATROL agent deployment than hiring additional dedicated external resources.
6. Completely hands-off when outsourcing: Outsourcing is a great way to jump start your BPPM implementation project. But outsourcing is not a hands-off process. You must be proactive in requirement analysis, risk management, and knowledge transfer. Remember that your outsourcing organization has different goals and priorities than yours. And your organization is ultimately responsible to see the positive ROI for your BPPM implementation. Perform each milestone inspection before moving forward in your BPPM implementation. If you don't have BPPM expertise in house, hire an expert from a 3rd party to help perform milestone inspection.
1. No planning phase: This mistake is usually seen with new BPPM customers. Many new BPPM customers start BPPM implementation by immediately jumping into installation without architecture and capacity planning. 9 out of 10 times, whatever they had installed ended up being uninstalled and reinstalled after they eventually figured out the right architecture and capacity.
2. Not planning the initial implementation phase based on available budget: This mistake is usually caused by unrealistic expectation. For example, one BPPM customer I talked to wanted to complete the entire BPPM implementation on $23K budget. If you scale down the initial implementation phase on both features and deployed servers to fit available budget, you can have a small but working BPPM implementation in production. Once BPPM starts adding values in your business, you have a much better chance to receive more budget for the next phase. A BPPM implementation that had to be stopped half way when running out of budget is a big waste of time and money.
3. No WBS (Work Breakdown Structure): This is usually caused by lack of BPPM implementation experience. Without WBS, it is very difficult to track progress and forecast schedule/budget. Not only you need to know what tasks each work package should include, you also need to know how to verify the completion of all tasks in each work package.
4. Hiring one external resource to implement multiple product lines: Each BMC product line has its unique best practices and complexity. It is rare that one consultant who has top expertise on both BPPM and another product line such as ITSM. Just as you see separate doctors for your dental and vision needs, it is much better to hire different resources to implement different product lines.
5. Hiring multiple external resources to implement single product line: Many people believe doubling the number of people in the project will cut the project time in half. That is not true in BPPM implementation. First, more resources increase the number of communication channels as the number of communication channels = n*(n-1)/2. More importantly, due to rapidly added new features and the uniqueness of each IT environment, 'road bumps' are inevitable in your BPPM implementation. Each 'road bump' can delay your project in several days. When you have multiple external resources, each one of them needs to go through the 'road bumps' individually. Having a single external resource can minimize the delays caused by those 'road bumps' thus minimize the total number of man-hours (cost) to complete the project. It is better to use internal resources for on-demand help such as PATROL agent deployment than hiring additional dedicated external resources.
6. Completely hands-off when outsourcing: Outsourcing is a great way to jump start your BPPM implementation project. But outsourcing is not a hands-off process. You must be proactive in requirement analysis, risk management, and knowledge transfer. Remember that your outsourcing organization has different goals and priorities than yours. And your organization is ultimately responsible to see the positive ROI for your BPPM implementation. Perform each milestone inspection before moving forward in your BPPM implementation. If you don't have BPPM expertise in house, hire an expert from a 3rd party to help perform milestone inspection.
Monday, March 16, 2015
Project Management in BPPM Implementation - Part 7: Get an expert for milestone inspection
In today's economy, IT organizations are trying to do more with less. Even you understand the complexity and magnitude of your BPPM implementation project, you may not be able to get as much budget as you requested. For example, one of the BPPM customers told me that they could only get $23K for the entire BPPM implementation project comparing to $230K.
With limited budget, when it comes to hire consulting resources for a BPPM implementation project, many IT organizations have to hire the ones with the lowest cost even they are not confident about the resources' competencies. What is worse is that they are not aware of many problems in their BPPM implementation until the project is claimed to be "completed". Then they would have to re-do part of the implementation if they are lucky enough to get additional budget, or live with the crippled implementation as many IT organizations won't be able to get additional budget.
The #1 reason that many BPPM implementation projects are behind schedule and over budget is re-work. For example, hundreds of PATROL agents were deployed 2-3 times because the PATROL agent deployment packages had to be rebuilt after they were already deployed. If you can minimize re-work, you would have a much better chance to complete your BPPM implementation project on time, within budget, and with high quality.
The most effective way to minimize re-work is through milestone inspection. At each project milestone, have an expert to perform inspection on what has been completed and look for any issues or potential issues. For the above example, your inspector should perform quick check for anything that may cause re-work including product versions, product patches, installation accounts, installation directories, integration services, cells, CMA tags, etc.
It would be great if you have BPPM expertise in house. If not, it is the best to hire an external expert who has been doing BPPM implementation for a long time. Because it doesn't take long to perform a milestone inspection, this would be a small investment. But this small investment will save you lots of major headaches in the long run.
This is very similar to building a home. Several years ago, when I was building my first home, I knew nothing about home construction. But I hired Bob as my home inspector. Bob worked for home builders for many years before becoming a home inspector. Based on his inspection results, I was able to get my builder to fix a long list of problems and potential problems before closing my home. My small investment of hiring a home inspector has saved me from costly home repairs.
If your consulting resources are sent from a consulting company, performing milestone inspection by an expert in house or from a 3rd party can often make the consulting company raise your priority and send you their best consultants.
With limited budget, when it comes to hire consulting resources for a BPPM implementation project, many IT organizations have to hire the ones with the lowest cost even they are not confident about the resources' competencies. What is worse is that they are not aware of many problems in their BPPM implementation until the project is claimed to be "completed". Then they would have to re-do part of the implementation if they are lucky enough to get additional budget, or live with the crippled implementation as many IT organizations won't be able to get additional budget.
The #1 reason that many BPPM implementation projects are behind schedule and over budget is re-work. For example, hundreds of PATROL agents were deployed 2-3 times because the PATROL agent deployment packages had to be rebuilt after they were already deployed. If you can minimize re-work, you would have a much better chance to complete your BPPM implementation project on time, within budget, and with high quality.
The most effective way to minimize re-work is through milestone inspection. At each project milestone, have an expert to perform inspection on what has been completed and look for any issues or potential issues. For the above example, your inspector should perform quick check for anything that may cause re-work including product versions, product patches, installation accounts, installation directories, integration services, cells, CMA tags, etc.
It would be great if you have BPPM expertise in house. If not, it is the best to hire an external expert who has been doing BPPM implementation for a long time. Because it doesn't take long to perform a milestone inspection, this would be a small investment. But this small investment will save you lots of major headaches in the long run.
This is very similar to building a home. Several years ago, when I was building my first home, I knew nothing about home construction. But I hired Bob as my home inspector. Bob worked for home builders for many years before becoming a home inspector. Based on his inspection results, I was able to get my builder to fix a long list of problems and potential problems before closing my home. My small investment of hiring a home inspector has saved me from costly home repairs.
If your consulting resources are sent from a consulting company, performing milestone inspection by an expert in house or from a 3rd party can often make the consulting company raise your priority and send you their best consultants.
Monday, March 9, 2015
Project Management in BPPM Implementation - Part 6: Risk management
As with all projects, a BPPM implementation project will bring changes and risk is a prominent aspect of changes. Project risk management helps you identify, describe, prioritize, quantify, respond, and manage the risks.
A risk is a future event that, if it occurs, will affect one or more project objectives. It is much better to start your risk management in the planing phase so that you can anticipate future problems to avoid being surprised in the middle of implementation phase and have an action plan to solve problems or prevent problems from happening.
BPPM implementation project risk management discussed in this post is a simplified version for the purpose of illustration. BPPM implementation project risk management in real life can be much more complex.
1. Risk identification
In a BPPM implementation project, a risk can be product related, resource related, or environment related. Review all project documents and pay special attention to WBS (Work Breakdown Structure) and project assumptions. Identify all risks that may impact project scope, time, cost, and quality. Document causes and effects for each risk.
Because each version of BPPM introduces quite a lot of brand new features but not all BPPM documents are updated with these new features, product related risks are inevitable. One example of product related risks is that you may not be able to configure a PATROL KM in CMA because the configuration steps described in KM document are for PATROL console only. Now your scheduled 1-day task in WBS would take you 3 days to complete because you have to get BMC support involved. This will obviously impact your project completion date and cost.
Resource related risks can be caused by the lack of experienced employees/consultants as BPPM expertise is still rare. This is especially true if you rely on a consulting firm to supply you consultants but had no opportunity to evaluate their competencies in advance.
Environment related risks can be caused by the dependency on another project - for instance, automated BPPM ticketing depends on the completion of Remedy incident management project.
2. Risk analysis
In risk analysis, you evaluate each risk and decide on its likelihood/probability of occurrence and its impact magnitude. You can use 5-level scale (very low, low, medium, high, very high) or 3-level scale (low, medium, high) for likelihood and impact. The result of likelihood x impact is risk exposure. Risk exposure helps to prioritize each risk.
For example, if the risk of not being able to configure a PATROL KM in CMA without contacting BMC support has a very high likelihood of occurrence, and the magnitude of its impact is also very high (delaying project completion for 2 days), the risk exposure will be very high and you need to assign a very high priority to this risk.
3. Risk response
In risk response, you determine options and select actions to reduce the threats to project objectives. These include mitigation plans to reduce the likelihood of risk occurrence, contingency plans to reduce the impact, fallback plans, and workarounds.
For example, for the risk of lacking experienced consultants when you rely on a consulting firm to supply you the resources, you may want to interview the assigned consultants before the project starts and also ensure they are dedicated resources to your project.
4. Risk monitoring and control
Risk management is an on-going process. During BPPM implementation project, you need to update the risks that have occurred and that will no long occur, update risk analysis and response as needed, evaluate the effectiveness of risk response actions, and identify new risks.
A risk is a future event that, if it occurs, will affect one or more project objectives. It is much better to start your risk management in the planing phase so that you can anticipate future problems to avoid being surprised in the middle of implementation phase and have an action plan to solve problems or prevent problems from happening.
BPPM implementation project risk management discussed in this post is a simplified version for the purpose of illustration. BPPM implementation project risk management in real life can be much more complex.
1. Risk identification
In a BPPM implementation project, a risk can be product related, resource related, or environment related. Review all project documents and pay special attention to WBS (Work Breakdown Structure) and project assumptions. Identify all risks that may impact project scope, time, cost, and quality. Document causes and effects for each risk.
Because each version of BPPM introduces quite a lot of brand new features but not all BPPM documents are updated with these new features, product related risks are inevitable. One example of product related risks is that you may not be able to configure a PATROL KM in CMA because the configuration steps described in KM document are for PATROL console only. Now your scheduled 1-day task in WBS would take you 3 days to complete because you have to get BMC support involved. This will obviously impact your project completion date and cost.
Resource related risks can be caused by the lack of experienced employees/consultants as BPPM expertise is still rare. This is especially true if you rely on a consulting firm to supply you consultants but had no opportunity to evaluate their competencies in advance.
Environment related risks can be caused by the dependency on another project - for instance, automated BPPM ticketing depends on the completion of Remedy incident management project.
2. Risk analysis
In risk analysis, you evaluate each risk and decide on its likelihood/probability of occurrence and its impact magnitude. You can use 5-level scale (very low, low, medium, high, very high) or 3-level scale (low, medium, high) for likelihood and impact. The result of likelihood x impact is risk exposure. Risk exposure helps to prioritize each risk.
For example, if the risk of not being able to configure a PATROL KM in CMA without contacting BMC support has a very high likelihood of occurrence, and the magnitude of its impact is also very high (delaying project completion for 2 days), the risk exposure will be very high and you need to assign a very high priority to this risk.
3. Risk response
In risk response, you determine options and select actions to reduce the threats to project objectives. These include mitigation plans to reduce the likelihood of risk occurrence, contingency plans to reduce the impact, fallback plans, and workarounds.
For example, for the risk of lacking experienced consultants when you rely on a consulting firm to supply you the resources, you may want to interview the assigned consultants before the project starts and also ensure they are dedicated resources to your project.
4. Risk monitoring and control
Risk management is an on-going process. During BPPM implementation project, you need to update the risks that have occurred and that will no long occur, update risk analysis and response as needed, evaluate the effectiveness of risk response actions, and identify new risks.
Monday, March 2, 2015
Project Management in BPPM Implementation - Part 5: A Work Breakdown Structure (WBS) example
In a previous post, we discussed two common methods to determine the time and cost of a BPPM
implementation: WBS (Work Breakdown Structure) and historical average. Regardless which method you used when you requested your budget, WBS is required when you
start the initial implementation phase of a BPPM project.
WBS decomposes a project into smaller work packages. And each work package has its own verifiable deliverables. WBS allows you to plan resources, track progress, and make adjustment to the time and cost estimates.
Assuming that the planning phase is completed successfully with an architecture diagram and all the required hardware systems are in place, here is an example of WBS for the initial implementation phase of a BPPM project. Please keep in mind that this is still a high-level WBS and you can decompose each task into several tasks.
WBS decomposes a project into smaller work packages. And each work package has its own verifiable deliverables. WBS allows you to plan resources, track progress, and make adjustment to the time and cost estimates.
Assuming that the planning phase is completed successfully with an architecture diagram and all the required hardware systems are in place, here is an example of WBS for the initial implementation phase of a BPPM project. Please keep in mind that this is still a high-level WBS and you can decompose each task into several tasks.
1. Install
BPPM components with required high availability
2. Configure
BPPM Components and inter-component communication
3. Create
PATROL installation packages
4. Configure
staging integration service and create staging policies
5. Deploy
PATROL installation packages on a few test servers
6. Install
PATROL classic console or PATROL central console
7. Create
monitoring policies in CMA for operating systems, log files, and a few selected
databases/applications
8. Create
tagging and grouping policies in CMA
9. Test
monitoring solutions on deployed test servers
10. Deploy
PATROL installation packages to a group of selected production servers
11. Test
all configured monitoring solutions on all selected production servers
12. Customize
PATROL agent thresholds
13. Create
server thresholds (absolute and signature) for each monitoring solution
14. Create
cell rules/policies to process PATROL agent events at each integration service
cell
15. Create
cell rules/policies to process intelligent events at server cell
16. Create
cell rules/policies to process self-monitoring events
17. Propagate
events to server cell
18. Set
up event (or data) blackout
19. Integrate BPPM
with LDAP (optionally)
20. Create
user interface for administrators, operators, and developers
21. Set
up alert email or other notification method to end users in selected business
units
22. Deploy
BPPM to production servers
23. Perform
user acceptance test on production BPPM
24. Complete
documentation
25. Perform
knowledge transfer
Subscribe to:
Posts (Atom)