Continue in 2 seconds

Getting Started: The BPM Project Life Cycle

  • January 01 2004, 1:00am EST
More in

In recent columns, we defined BPM (business performance management) and looked at the tangible benefits ­– quantifiable payback –­ it has delivered in practice. What follows is an overview of the steps you'll go through to bring performance management into your company.

Take a quick look at the project life cycle diagram in Figure 1. You'll find it reassuringly familiar, with project phases you'd expect to see –­ starting with requirements definition. However, before you call an information technology (IT) project manager into your office and ask him or her to give you BPM, you should recognize that performance management definitely packs some differences. This will not be your typical IT initiative.



Figure 1: BPM Project Life Cycle

It's instructive to look at what differentiates a BPM project from the software initiatives you have probably experienced in the last several years. With enterprise resource management (ERP) and customer relationship management (CRM), for example, the basic goals are well understood: you want to accurately record every transaction, customer, SKU (stock keeping unit) and shift of money. Because BPM is so young, there is no universal agreement on best practices, and simply deciding on the ideal functionality will trigger lengthy discussion. After assessing which business processes to engage with BPM, you'll then determine the number of existing systems in your company the BPM software will draw data from and what kinds of analysis will be most valuable.

You'll need to choose which department (s) to address and, in each of those areas, which business processes could have the highest performance improvement. It's typical to begin with the finance department, and finance is often the principal driver of BPM within a company. Often, the CFO's first priority is to focus on a thorny process such as budgeting. As was the case with ERP, it's important to pause and determine if the process itself is okay or needs reengineering. At most companies, of course, budgeting is regarded as broken at best, if not a perennial curse. Budgeting is also a logical starting point because it serves as the foundation for later analysis of performance against plan.

Other decisions that you'll make during requirements definition are rather strategic, such as whether to accompany the BPM project with a company-wide move to a unified chart of accounts. In multinational companies that have many subsidiaries and grew by acquisition, this can mean embarking on a major campaign of persuasion. In most BPM projects, the CEO is likely to get involved at some point. Whether or not your CEO takes a formal lead role, a BPM project needs a committed executive sponsor. The CFO may well be your overall project owner, and it's often necessary to involve other stakeholders at the C-level.

The requirements definition should lead to an effective request for proposal (RFP). It is important to address the requirements definition and prepare the RFP from three perspectives:

  • Intimate knowledge of your company and its systems
  • Specific understanding of how companies similar to your own have maximized the payoff from implementing performance management systems
  • Up-to-date knowledge of the many software solutions currently on the market.

It's not a simple task to absorb what the different vendors offer. Vendors make claims that sound similar, and there are evolving differences of opinion on the definition of good and successful BPM. A balanced scorecard vendor could claim to have "full BPM," but might lack 70 percent of what you need. A tools vendor will naturally believe that the flexibility to program your own functionality is essential. Application vendors have their own prejudices. In the scramble to capture leadership, vendors are frequently updating and enhancing their product lines, and it's tough to stay current.
One major risk is that you'll end up buying from the vendor with the best marketing. There could well be vendors with outstanding products but mediocre marketing. As a result, you might overlook them and miss the best choice for your company. Another pitfall is buying more than you need. It's not unheard of for vendors to push their full suites into the initial sale or for a purchaser caught up in the excitement of BPM to load the shopping cart with all available options.

For these reasons, you can benefit from a methodical, structured approach to vendor selection that enforces apples-to- apples comparisons, not only of functionality, but also of architectural compatibility and the vendor's service and pricing fit. It's valuable to supplement your team with outside BPM expertise during the combined tasks of requirements definition and vendor selection because these phases are so critical to the overall success of the project.

Performance management projects have significant visibility and impact upon the enterprise. Because their dollar cost is typically less than that of most ERP projects, however, it is easy to underestimate their complexity. In our experience, performance management typically requires the implementation of multiple application components such as portals, planning and consolidation systems, and dashboards. The projects to implement these applications can overlap. To make things more complicated, the underlying technologies of OLAP, report and query, and ETL will need to be addressed along with creation of the BPM data mart –­ all in parallel with the applications you're implementing.

You can picture the range of personnel involved in these various activities and the management attention required. Your project teams within IT, departmental subject experts, staff from one or more vendors and external implementation and best practice experts from third parties may need to be meshed into the project task force.

All of these people and their projects must be coordinated in advance within a unified framework while adhering to a tight timeframe and budget and maintaining communications with your stakeholders. For overall management of the BPM initiative, you need someone who can step back for perspective while engaging with both the business and technology sides of the project.

There are risks in every IT project. However, it is asking a lot for even an experienced IT manager to arbitrate issues that can arise between the CIO, the CFO, the SVP of marketing and the CEO. Getting full ROI from the project may depend on insistence that every department, division and foreign subsidiary give up their treasured chart of accounts to adopt an unfamiliar new one that is company-wide. An outside expert in best practices or change management who is perceived as impartial and highly knowledgeable may be able to guide you and your team through the difficult phases.

The mechanics of piloting and parallel runs, training and evaluating the user reception are complicated by the fact that this will not be a single-department system. True BPM systems will be deployed across multiple departments, geographies and levels of users.

Successful BPM is heavily reliant on user acceptance and utilization, not only for data entry but for ongoing performance analysis as well. If not regularly used, your BPM project has likely missed the mark. When properly used, BPM lets the people who can exploit opportunities and respond to problems find them. That puts larger numbers of personnel in a position to improve profitability.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access