In the previous post, we discussed the advantages of phased approach over a big bang production release. How does a phased approach work?
Just as each builder builds houses somewhat differently, each organization takes phased approach somewhat differently. This is largely because the following three major inputs to project planning process vary from organization to organization: 1) Business Requirements; 2) Enterprise Environmental Factors; and 3) Organizational Process Assets. While I am showing phased approach outline as an example in this post, your experience may vary.
When I had my house built, it took a planning phase to confirm architecture blueprint, a building phase to complete the house, and numerous add-on phases to add windows blinds, deck, and walk way after I moved into my house.
Similarly in BPPM implementation, it takes a planning phase, an initial implementation phase, and numerous add-on phases.
In the planning phase, the objectives are: confirm and prioritize the business requirements; decide the scope for the initial implementation phase; make major implementation decisions such as capacity, the level of high availability, and CMA vs PCM; confirm hardware requirements; and deliver an architecture diagram. Planning phase usually takes 1-3 weeks depending on how much prototyping work you need to do.
In the initial implementation phase, the objectives are: build core infrastructure for data and events to flow end to end; build required high availability; configure monitoring solutions for operating systems, log files, and a few selected databases/applications; deploy monitoring solutions to a group of selected servers; handle basic blackout for maintenance windows; build initial user interface for service desk/NOC operators; and deliver alert notifications to end users in selected business units.
In the add-on phases, the objectives are: improve the core infrastructure built in the initial implementation phase based on the feedback from end users; configure more monitoring solutions; deploy monitoring solutions to more servers; add BPPM integration with other systems; and add customizations to bridge the gaps between BPPM out-of-box solutions and your business requirements.
How long each add-on phase should take depends on your organization's preference. I personally prefer Agile-style approach by releasing a set of new add-on features every 2-4 weeks. This approach has been well received by my clients. By incorporating user feedback into a new release every 2-4 weeks, I have found that end users are more engaging and willing to take ownership of the monitoring requirements. I also have the operations support staff involved in each add-on release so that knowledge transfer becomes an on-going and less overwhelming process.
Monday, February 23, 2015
Tuesday, February 17, 2015
Project Management in BPPM Implementation - Part 3: Phased approach vs. big bang release
I have been to several rescue missions. They all had something in common: An organization had one or more consultants working on a new implementation for 6-9 months and made to a big production release with a long list of features. Shortly after that, they noticed that things just didn't work as expected. They didn't know where to begin to investigate. Worse than that, they ran out of budget.
A few organizations I ended up helping rescue the implementation were lucky enough for allocating additional budget. But many organizations were not so lucky. Their internal staff had to spend months to figure out which piece worked and which piece didn't.
At each rescue mission, I noticed the client had some service models built in its initial implementation but the service models didn't work due to issues in monitoring events. When I asked why, all of them said that they were so impressed with service models in BMC product demo that they didn't realize the dependency between service models and monitoring events. When I discussed re-implementation options with them, all of them agreed not to include service models in the initial implementation.
On the other hand, phased approach has worked much better. Each organization may have a different reason for purchasing BPPM license at the first place, but all organizations want to see positive ROI from BPPM after all. Here are just a few reasons why phased approach may work better for you:
1) Phased approach allows you to see ROI much sooner. Instead of waiting for 6-9 months for a big production release, phased approach can give you a small initial production release as soon as 3 months. For example, instead of implementing all 10 features on all your servers, you can implement 5 features on 1/2 of your servers first.
2) BPPM is a very complex product. Each new release of BPPM contains new features that may or may not work in your environment on the first try. By implementing a few features first, you can ease the learning curve and build expertise one piece at a time.
3) Many detailed requirements such as event correlation and dynamic thresholds can only be finalized after running BPPM in production for a while. A phased approach helps you plan the next set of features based on live data not just estimated data.
4) Not all issues can be detected during QA test. If there are issues after the previous phase goes production, you still have the time and budget to fix them. And these issues may help you plan the next phase better.
5) Phased approach allows your implementation staff (or consultants) and your operations support staff work more closely with on-going knowledge transfer and feedback.
6) Phased approach allows you to target on 'low hanging fruits' first. The sooner you can see positive ROI from BPPM, the better chance you have to convince your management for additional budget for advanced features.
A few organizations I ended up helping rescue the implementation were lucky enough for allocating additional budget. But many organizations were not so lucky. Their internal staff had to spend months to figure out which piece worked and which piece didn't.
At each rescue mission, I noticed the client had some service models built in its initial implementation but the service models didn't work due to issues in monitoring events. When I asked why, all of them said that they were so impressed with service models in BMC product demo that they didn't realize the dependency between service models and monitoring events. When I discussed re-implementation options with them, all of them agreed not to include service models in the initial implementation.
On the other hand, phased approach has worked much better. Each organization may have a different reason for purchasing BPPM license at the first place, but all organizations want to see positive ROI from BPPM after all. Here are just a few reasons why phased approach may work better for you:
1) Phased approach allows you to see ROI much sooner. Instead of waiting for 6-9 months for a big production release, phased approach can give you a small initial production release as soon as 3 months. For example, instead of implementing all 10 features on all your servers, you can implement 5 features on 1/2 of your servers first.
2) BPPM is a very complex product. Each new release of BPPM contains new features that may or may not work in your environment on the first try. By implementing a few features first, you can ease the learning curve and build expertise one piece at a time.
3) Many detailed requirements such as event correlation and dynamic thresholds can only be finalized after running BPPM in production for a while. A phased approach helps you plan the next set of features based on live data not just estimated data.
4) Not all issues can be detected during QA test. If there are issues after the previous phase goes production, you still have the time and budget to fix them. And these issues may help you plan the next phase better.
5) Phased approach allows your implementation staff (or consultants) and your operations support staff work more closely with on-going knowledge transfer and feedback.
6) Phased approach allows you to target on 'low hanging fruits' first. The sooner you can see positive ROI from BPPM, the better chance you have to convince your management for additional budget for advanced features.
Tuesday, February 10, 2015
Project Management in BPPM Implementation - Part 2: Project management basics
Scope, time, and cost are called project management triangle where each side represents a constraint. One side of the triangle cannot be changed without affecting the others.
When I talked about total cost of ownership in BPPM, I often compared the process of implementing BPPM to the process of building a house. Interestingly, when it comes to scope, time, and cost in project management, BPPM implementation is still very similar to home building.
For scope, when you are building a new house, you must know in advance the size, the number of stories, the floor plan, and the materials to be used. These will be the major factors that determine the time and cost of the construction though other details (such as counter top material and light fixture style) can still contribute to time and cost to certain extent. If you don't know the above information, you need to get an architect to produce the blue print first.
Similarly in a new BPPM implementation, you must know how many servers to monitor, what applications to monitor, how many BPPM servers you need, how many integration services you need, how many BPPM cells you need, what database to use, what integrations to include, etc. These will largely determine the time and cost of your BPPM implementation though other details may still change the time and cost to certain extent. For new BPPM customers, if the above information is unknown, a small discovery project should be scheduled to find it out and to produce an architecture diagram first.
If you are renovating an old house, you must decide what to keep, what to remove, what to add, and what to reproduce. Similarly in a BPPM upgrade/migration/extension project, you must decide exactly what to keep, what to remove, what to add, and what to migrate in order to determine the time and cost of the project.
Among many different methods to determine time and cost, two methods are used most often: WBS (Work Breakdown Structure) and historical average.
WBS (Work Breakdown Structure) method is a bottom-up approach that involves decomposing the project into smaller work packages with deliverables. The total time and cost is determined by adding up the time and cost of all work packages. WBS is most effective if the level of effort for each work package can be accurately estimated and if the estimate is done by the person who will perform the tasks. The drawback of WBS method is that it may not always be easy to estimate the level of effort when implementing new features. For example, configuring a new CMA monitor policy could take you up to 3 days working with BMC Support while your estimate was only 3 hours.
In my own experience, WBS method is most effective with development projects such as PATROL custom KM development and BPPM cell knowledge base extension.
Historical average is another effective method to come up with a rough estimate on time and cost. Many organizations have their time and cost decided before knowing who will implement BPPM and what detailed features to implement especially for new BPPM implementation. In the city I live, a medium-sized family house costs about $200-$250K (excluding land cost) and takes 6-9 months to build. The time and cost for a medium-sized BPPM implementation are very similar to building a medium-sized family house.
A smaller sized BPPM implementation will cost less and take less time, but not proportionally with size reduction. Similarly a larger sized BPPM implementation will cost more and take more time, but not proportionally with size increment. If you use your internal staff instead of hiring consultants, it will most likely cost you less but will take you much longer.
In my own experience, historical average method is most effective with new BPPM feature implementations when the top objective is to demonstrate positive ROI. One example is the implementation of accurate incident ticket assignment rule that freed up 20 man-hours per week from manually re-assigning tickets. Another example is the integration of non-BMC monitoring events into BPPM for automatic Remedy ticket generation that eliminated costly Remedy gateway license.
When I talked about total cost of ownership in BPPM, I often compared the process of implementing BPPM to the process of building a house. Interestingly, when it comes to scope, time, and cost in project management, BPPM implementation is still very similar to home building.
For scope, when you are building a new house, you must know in advance the size, the number of stories, the floor plan, and the materials to be used. These will be the major factors that determine the time and cost of the construction though other details (such as counter top material and light fixture style) can still contribute to time and cost to certain extent. If you don't know the above information, you need to get an architect to produce the blue print first.
Similarly in a new BPPM implementation, you must know how many servers to monitor, what applications to monitor, how many BPPM servers you need, how many integration services you need, how many BPPM cells you need, what database to use, what integrations to include, etc. These will largely determine the time and cost of your BPPM implementation though other details may still change the time and cost to certain extent. For new BPPM customers, if the above information is unknown, a small discovery project should be scheduled to find it out and to produce an architecture diagram first.
If you are renovating an old house, you must decide what to keep, what to remove, what to add, and what to reproduce. Similarly in a BPPM upgrade/migration/extension project, you must decide exactly what to keep, what to remove, what to add, and what to migrate in order to determine the time and cost of the project.
Among many different methods to determine time and cost, two methods are used most often: WBS (Work Breakdown Structure) and historical average.
WBS (Work Breakdown Structure) method is a bottom-up approach that involves decomposing the project into smaller work packages with deliverables. The total time and cost is determined by adding up the time and cost of all work packages. WBS is most effective if the level of effort for each work package can be accurately estimated and if the estimate is done by the person who will perform the tasks. The drawback of WBS method is that it may not always be easy to estimate the level of effort when implementing new features. For example, configuring a new CMA monitor policy could take you up to 3 days working with BMC Support while your estimate was only 3 hours.
In my own experience, WBS method is most effective with development projects such as PATROL custom KM development and BPPM cell knowledge base extension.
Historical average is another effective method to come up with a rough estimate on time and cost. Many organizations have their time and cost decided before knowing who will implement BPPM and what detailed features to implement especially for new BPPM implementation. In the city I live, a medium-sized family house costs about $200-$250K (excluding land cost) and takes 6-9 months to build. The time and cost for a medium-sized BPPM implementation are very similar to building a medium-sized family house.
A smaller sized BPPM implementation will cost less and take less time, but not proportionally with size reduction. Similarly a larger sized BPPM implementation will cost more and take more time, but not proportionally with size increment. If you use your internal staff instead of hiring consultants, it will most likely cost you less but will take you much longer.
In my own experience, historical average method is most effective with new BPPM feature implementations when the top objective is to demonstrate positive ROI. One example is the implementation of accurate incident ticket assignment rule that freed up 20 man-hours per week from manually re-assigning tickets. Another example is the integration of non-BMC monitoring events into BPPM for automatic Remedy ticket generation that eliminated costly Remedy gateway license.
Monday, February 2, 2015
Project Management in BPPM Implementation - Part 1: Introduction
As a certified project manager (PMP) for the last 14 years, I have always paid close attention to project management in BPPM implementation whether or not I was doing project management work. Due to the complex nature of BPPM, BPPM implementation presents its unique challenges in both new implementation and upgrade implementation.
What makes BPPM more complex comparing to most of the off-the-shelf application software such as payroll software, most embedded self-monitoring software such as Oracle Enterprise Manager, and most "standard" system management software such as Microsoft SCOM?
First, BPPM is not one product. It is a product suite consisting of three major products acquired from different companies at different time and numerous small products. These three major products are: 1) PATROL, developed primarily in C (not C++), acquired in 1994; 2) Master Cell, developed primarily in Prolog (an Artificial Intelligence language), acquired in 2003; and 3) ProactiveNet, developed primarily in Java, acquired in 2007. Your expertise with one product often has very little to do with your expertise in another product. Understanding the background of each product would help a lot to set the right expectation and manage risks.
Second, BPPM is aggressively going through major changes with each release as BMC has been putting tremendous effort to integrate these three major products together. It is up to each BMC customer to decide whether to adopt the changes right away or wait until they are more mature, what to do if they don't work all the time, and how much extra time and cost to include to justify the learning curves due to these changes.
Third, BPPM delivers extra features if you know how to customize and integrate. In another word, BPPM is a 'race car' not a Honda Accord. You need to know how to drive a 'race car' in order to deliver extra performance. Just as most drivers are not race car drivers, the expertise to customize and integrate BPPM is hard to find too. Most likely your organization paid premium price for BPPM over other "standard" products because these extra features are critical to your business. Being able to secure 'race car' expertise is important to ensure your BPPM implementation project successful.
Before sharing some of my lessons learned in project management triangle (scope, time, and cost) as well as risk management for BPPM implementation in the next few posts, I would like to list a few common myths out there.
1) "Once installation is complete, the implementation is half way done." Not true. A successful installation of BPPM acutally counts for less than 5% of complettion of BPPM implementation.
2) "Let's just get it 'done' in a 'standard' way." Actually there is no 'standard' way. Each BPPM implementation is done to help meet specific business requirements. Because each organization has its own unique business requirements, each BPPM implementation is different. As a customer, you need to know 'what' you expected from BPPM to meet your business requirements before 'how' can take place.
3) "Since we paid for all features in BPPM, let's implement all of them at once." This is a common issue in new BPPM implementation. At the beginning of a new BPPM implementation, it is hard to list all detailed requirements with a 10,000-foot view. Many detailed requirements will become more obvious after BPPM has been running for a while.
4) "We want the entire BPPM implementation to be completed in 4 weeks." No, I didn't make this one up. This type of wishful thinking does exist. I just hope there is an easy way for customers to obtain industry statistics data in BPPM implementation so that they have a realistic expectation in implementation time before purchasing BPPM software.
What makes BPPM more complex comparing to most of the off-the-shelf application software such as payroll software, most embedded self-monitoring software such as Oracle Enterprise Manager, and most "standard" system management software such as Microsoft SCOM?
First, BPPM is not one product. It is a product suite consisting of three major products acquired from different companies at different time and numerous small products. These three major products are: 1) PATROL, developed primarily in C (not C++), acquired in 1994; 2) Master Cell, developed primarily in Prolog (an Artificial Intelligence language), acquired in 2003; and 3) ProactiveNet, developed primarily in Java, acquired in 2007. Your expertise with one product often has very little to do with your expertise in another product. Understanding the background of each product would help a lot to set the right expectation and manage risks.
Second, BPPM is aggressively going through major changes with each release as BMC has been putting tremendous effort to integrate these three major products together. It is up to each BMC customer to decide whether to adopt the changes right away or wait until they are more mature, what to do if they don't work all the time, and how much extra time and cost to include to justify the learning curves due to these changes.
Third, BPPM delivers extra features if you know how to customize and integrate. In another word, BPPM is a 'race car' not a Honda Accord. You need to know how to drive a 'race car' in order to deliver extra performance. Just as most drivers are not race car drivers, the expertise to customize and integrate BPPM is hard to find too. Most likely your organization paid premium price for BPPM over other "standard" products because these extra features are critical to your business. Being able to secure 'race car' expertise is important to ensure your BPPM implementation project successful.
Before sharing some of my lessons learned in project management triangle (scope, time, and cost) as well as risk management for BPPM implementation in the next few posts, I would like to list a few common myths out there.
1) "Once installation is complete, the implementation is half way done." Not true. A successful installation of BPPM acutally counts for less than 5% of complettion of BPPM implementation.
2) "Let's just get it 'done' in a 'standard' way." Actually there is no 'standard' way. Each BPPM implementation is done to help meet specific business requirements. Because each organization has its own unique business requirements, each BPPM implementation is different. As a customer, you need to know 'what' you expected from BPPM to meet your business requirements before 'how' can take place.
3) "Since we paid for all features in BPPM, let's implement all of them at once." This is a common issue in new BPPM implementation. At the beginning of a new BPPM implementation, it is hard to list all detailed requirements with a 10,000-foot view. Many detailed requirements will become more obvious after BPPM has been running for a while.
4) "We want the entire BPPM implementation to be completed in 4 weeks." No, I didn't make this one up. This type of wishful thinking does exist. I just hope there is an easy way for customers to obtain industry statistics data in BPPM implementation so that they have a realistic expectation in implementation time before purchasing BPPM software.
Subscribe to:
Posts (Atom)