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.

No comments:

Post a Comment